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)
[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.
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