I
have a solution for this
problem.
Basically
if any LSR receives an Label withdraw message from its valid Next
hop neighbor then before propagating to its upstream peers it need
to check the value of the label being withdrawn, if the label
happens to be an NULL label then it should not propagate the label
withdraw to its upstream peers. Now this LSR should now assume
itself as an egress for that LSP.
[Vijayanand C - CTD, Chennai.] What
will happen in valid cases when the eggress actually wants to
withdraw label and when u no longer want to switch for that FEC
?The pennultimate hop should not hold the label in that
case. How will the Phop know for which case the withdraw
applies ?
[Ramia, Kannan Babu] Actually
here we are not holding the egress label, we are sending a
label release for the corresponding withdraw message
and also i am expecting only the INGRESS will start the
LSP deletion process for any genuine case (of course assumption is
all LSR is configured with the forwarding of the label
release)
[Ramia, Kannan
Babu] [Vijayanand C - CTD, Chennai.] By
holding the label I mean, the PHop would be holding its upstream
labels unnecessarily even in genuine LSP tear down
scenarios( when withdraw is received from its downstream node which
is egress)
Here ingress is
not initiating deletion the egress does it by sending
withdraw.
[Ramia, Kannan
Babu] I have one more idea for differntiating a
genuine withdraw to the special withdraw. i.e if the LSR
A sends a label with draw message to LSR B with the FEC-X
and label TLV has label value IMPLICIT NULL and in the optinal
paramters it can send a changed label value to be used, there
by we can differntiate from the genuine case (in genuine case the
optinal paramter wont contain any label) to the special case.
if we have this check in the label withdraw procedure it will solve
our problem. This solution wont distrub the LSP setup where as the
ingress retry solution will distrub the LSP, which
is undesiarable one also we need to provide the checking
criteria for re-establishing the
LSP.
Second
one could be there should be a provision to change the label for the
particular FEC. I.e any point of time the valid next hop LSR can
advertise a change of label for that FEC. Here problems are we need
to maintain the context of that advertisement (LM).
[Vijayanand C - CTD,
Chennai.] This becomes unsolicited
advertisement.
[Ramia, Kannan Babu] i dont see any problem
in this kind of advertisement, even if u are configured with DOD
ordered mode if any change in hop count or PV, the
downstream LSR will anyway generate a LM with out any
outstanding LR. So i want to treat the change in label also the
same way as that of change in hop count.
[Vijayanand C - CTD,
Chennai.] Changing the attributes of the label mapping
( like PV) is different from changing the label itself.
Again the context maintenance (old label, FEC) for this is a problem
as you said. Even the question of communicating changed attributes
seldom arises in DOd Ord control. In cases where it happens, such as
Next hop change, it was debated at length earlier in this list if it
was proper to unsolicitedly advertise the changed
attributes.
A better way would be
for the egress to withdraw the label. However the ingress will
not issue a request unless it is in Independent control. This
anyway is a problem. My suggestin would be - The ingress
after sending a release can issue a fresh request for the label
even if its not in independent control if it still supports label
switching on the FEC. I feel This would be more cleaner
.
[Ramia, Kannan Babu] How the
ingress will know that it need to request again or initate LSP
establishment once again for the same FEC (i mean here what criteria
or conditions it checks before it does this again..) because in some
genuine cases if egress wants to remove the LSP then it may
lead to infinite looping.
[Vijayanand C - CTD, Chennai.] This kind of
situation( retrying) will anyway apply in Independent
control( all nodes along the LSP may potentially retry). So how
will you solve the problem in that case ? What I am suggesting
is if ordered control is used the retry can be done only by the
ingress. Any retry mechanism would have some back off and stopping
criteria associated with it
implicitly.
Vijay
