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