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