The MPLS WG Archive

["Gray, Eric" <egray@celoxnetworks.com>]

Vijay/Kannan,

 

            Please see below...

 

Eric W. Gray

Systems Architect

Celox Networks, Inc.

egray@celoxnetworks.com

508 305 7214

 

-----Original Message-----
From: Vijayanand C - CTD, Chennai. [mailto:vijayc@ctd.hcltech.com]
Sent: Wednesday, September 18, 2002 5:19 AM
To: Ramia, Kannan Babu
Cc: mpls@UU.NET
Subject: RE: Clarification on Handling a specific event in LDP

 

Again you are overriding the Dod Ord control by using a label map along with a withdraw whereby  it becomes an unsolicited mapping.

Apart from the Question of syntactical correctness of sending an unsolicited label map there is another problem.

 

There are cases in which DoD vs DU distribution and Ordered vs Independent control

become rather vague distinctions.  That is the problem hidden behind the fact that

people talk past each other on this topic, rather than talking to each other.

 

Rather than talking about the gross terms, consider the details of implementation

you are likely to encounter. If the negotiated mode between two LSRs is DoD, then

each LSR is required to accept one or more Label Request messages for each FEC

and neither is required to accept _any_ unsolicited Label Mapping messages.  The

LSR that receives an unsolicited Label Mapping may decide to immediate release

it - or worse yet - it may assume the peer has become confused and tear down the

LDP session. This is in essence the problem that Vijay is probably concerned with.

 

However, there is always the robust notion of being generous in what you accept.

 

While, IMHO, the LSR that sends an unsolicited Label Mapping when in DoD mode

is generally in the wrong, it seems _very_ un-robust behavior to terminate the LDP

session and it might be more robust to at least retain the new Label Mapping (yes,

even if in conservative retention mode - thus blurring another distinction).  In fact,

it is likely that some implementations will treat such an unsolicited Label Mapping

as an implied Label Withdraw (though - with effort - I can dredge up an old E-Mail

message in which members of the LDP design team were adamant that this was

not the way it is intended to work).

 

In the case Kannan is pointing out, the retention of the new Label Mapping (in case

the previous one is withdrawn) is very much more robust than almost anything else

you might do (with the possible exception of using it as an implied Withdraw).  If

the new Label Mapping is not retained, then the LSP is removed edge to edge and

must be re-established. 

 

This - by the way - is exactly the behavior originally intended in the DoD, Ordered

control mode: LSR A in Kannan's case would Withdraw all Labels associated with

forwarding toward the newly discovered peer LSR C and then wait for all affected

ingress LSRs to send Label Requests to re-establish LSPs.  I brought this up with

the LDP design team 3 years ago and many of them agreed that this would not be

good behavior.  However, it was not clear that any other behavior should be explicitly

specified.

 

 The domain in configured for Dod Ord. THis may be due to constraints in the switches to install labels. For example, in GMPLS, the set of desired labels is sent along with the request indicating the range of labels the upstream can switch onto. Hence the Dod Ord control has significance in such scenarios' and overriding it may cause confusion.

 

The issue of change in next hop for an FEC right at the egress( which is usually egress for routing domain) is a very rare situation and I think it does nt warrant drastic changes to the semantics and operation of LDP

 

Vijay

-----Original Message-----
From: Ramia, Kannan Babu [mailto:kannan.babu.ramia@intel.com]
Sent: Wednesday, September 18, 2002 2:20 PM
To: 'Vijayanand C - CTD, Chennai.'
Cc: mpls@uu.net
Subject: RE: Clarification on Handling a specific event in LDP

See my inline Comments

-----Original Message-----
From: Vijayanand C - CTD, Chennai. [mailto:vijayc@ctd.hcltech.com]
Sent: Wednesday, September 18, 2002 12:15 PM
To: Ramia, Kannan Babu
Cc: mpls@uu.net
Subject: RE: Clarification on Handling a specific event in LDP

See my comments inline

-----Original Message-----
From: Ramia, Kannan Babu [mailto:kannan.babu.ramia@intel.com]
Sent: Wednesday, September 18, 2002 11:48 AM
To: 'Vijayanand C - CTD, Chennai.'; Ramia, Kannan Babu
Cc: mpls@uu.net
Subject: RE: Clarification on Handling a specific event in LDP

hi vijay..

  

thanks for ur reply ..but i still have some thing to get clarified ... please see in line Comments

 

bye

kb

-----Original Message-----
From: Vijayanand C - CTD, Chennai. [mailto:vijayc@ctd.hcltech.com]
Sent: Wednesday, September 18, 2002 11:39 AM
To: Ramia, Kannan Babu
Cc: mpls@uu.net
Subject: RE: Clarification on Handling a specific event in LDP

Kannan,

This is a special case.

 

 

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