Re: [mpls] For your review - Issues/errors/clarifications in RFC3 036

[Rama Ramakrishnan <[e-mail]>]

Eric Gray wrote:
> Rama,
> 
>    Yes, Bob Thomas and I talked about this problem _years_ ago (:-))
> 
>    Bob seemed to feel that there are several way that an implementation
> can avoid re-issuing the same label too soon after it "becomes available".
> Since he and I were both working on separate LDP implementations at
> the time, I couldn't really find a hole in that argument. Therefore, 
> this is a
> "race" condition where you can hobble the competition.
> 




>    One other comment in response - the protocol that issues a label should
> be irrelevant in the sense that you're addressing. Either the multiple 
> signaling
> protocols are getting the labels from the same pool or they're not. If 
> they're
> not, the problem does not exist. If they are, then a sensible 
> implementation
> would benefit from using a common under-lying label allocation scheme.

One clarification. The reason I mentioned RSVP is just to stress the point
that the old label is currently used for a different purpose.

Regards,

Rama

> 
> -- 
> Eric
> 
> Rama Ramakrishnan wrote:
> 
>>
>>
>> Eric Gray wrote:
>>
>>> Nick,
>>>
>>>     Thanks for filling in the details. Please see one comment below.
>>>
>>> Nick Weeds wrote:
>>>
>>>> Ina,
>>>>
>>>> Sorry I didn't explain this clearly.
>>>>
>>>> The problem arises in window cases where the upstream (U,B) and 
>>>> downstream
>>>> (D,A) routers happen to send LDP messages at the same time.  The 
>>>> likelihood of this is low, but it
>>>> is possible.
>>>>
>>>>                !                       !
>>>>                !              /---<----! Label Mapping
>>>>                !             /         !
>>>>                !            /          !
>>>>                !           /           !
>>>>                !          /            !
>>>>                !         /             !
>>>>                !<-------/              !
>>>>                !                       !
>>>>  Label Release !---->---\              !
>>>>                !         \             !
>>>>                !          \            ! <-- ROUTE CHANGE
>>>>                !           \           !
>>>>                !            \ /---<----! Label Mapping (update)
>>>>                !             X         !
>>>>                !            / \------->!
>>>>                !           /           !
>>>>                !          /            !
>>>>                !         /             !
>>>>                !<-------/              !
>>>>                !                       !
>>>>
>>>>
>>>> The Label Release is initiated by the upstream router.  It is not a 
>>>> response
>>>> to a Label Withdraw.  For example, the upstream router might send 
>>>> the Label
>>>> Release because it is using conservative retention.
>>>>
>>>> The downstream router sends the 2nd Label Mapping before receiving 
>>>> the Label
>>>> Release.  For example, a route change might cause the downstream 
>>>> router to
>>>> signaling a change of hop count or a change of MTU.
>>>>
>>>> At the end of this sequence the downstream router has sent two Label
>>>> Mappings and received a Label Release, so it considers the label to be
>>>> released.  The upstream router has sent a Label Release and received a
>>>> subsequent Label Mapping, so it considers the label to be valid.  In 
>>>> most
>>>> cases the upstream router would send another Label Release, but if 
>>>> the route
>>>> has changed then the upstream router might install the label for
>>>> forwarding/switching use.  If so then any data sent using the label 
>>>> will be
>>>> dropped by the downstream router.  This isn't a transient condition, 
>>>> it can
>>>> continue indefinitely.
>>>>
>>>>  
>>>>
>>
>>
>>> Not if the downstream router sends a label withdraw as an appropriate
>>> recovery response to getting a packet with a label that is invalid.
>>>
>> But there may be a problem if the downstream router allocates the same 
>> label
>> for a different FEC (may be for a different protocol like RSVP)
>>
>> Regards,
>>
>> Rama
>>
>>>> As I said, the likelihood of this happening is low.  I believe 
>>>> typical LDP
>>>> usage would avoid this problem by avoiding loop detection, MTU 
>>>> signaling
>>>> etc.  Nevertheless, RFC 3036 allows such usage, describes hop count
>>>> behaviour that can lead to the problem, and fails to mention or 
>>>> prevent the
>>>> problem.
>>>>
>>>> Is that clearer?
>>>>
>>>>    Nick.
>>>>
>>>>  
>>>>
>>>>> -----Original Message-----
>>>>> From: Ina Minei [mailto:[e-mail]]
>>>>> Sent: 07 October 2004 16:31
>>>>> To: Nick Weeds
>>>>> Cc: [e-mail] (E-mail)
>>>>> Subject: RE: [mpls] For your review - Issues/errors/clarifications in
>>>>> RFC3 036
>>>>>
>>>>>
>>>>>
>>>>>    Nick,
>>>>>
>>>>>    I think I am missing something... The label release is sent by
>>>>> router B in response to a label withdraw it received from router A.
>>>>> A should  wait for the release before attempting to send a label map
>>>>> again. In the meantime, the label is considered dead on A, and
>>>>> if A wants to resurrect it, A should wait until receiving the release.
>>>>>
>>>>>    Are you suggesting that A can resurrect the label it just killed
>>>>> before waiting for the release to come?
>>>>>
>>>>>                Thank you,
>>>>>
>>>>>                    Ina
>>>>>
>>>>> On Thu, 7 Oct 2004, Nick Weeds wrote:
>>>>>
>>>>>  
>>>>>
>>>>>> Ina,
>>>>>>
>>>>>> Just a couple of points on the update to RFC 3036...
>>>>>>
>>>>>> First, the list of issues not addressed says that RFC 3036     
>>>>>
>>>>>
>>>>> already says that
>>>>>  
>>>>>
>>>>>> loop detection should not be used in DU mode.  I can't find     
>>>>>
>>>>>
>>>>> this statement
>>>>>  
>>>>>
>>>>>> in RFC 3036.  Which section is it in?
>>>>>>
>>>>>> Second, the LDP protocol can fail if a Label Mapping     
>>>>>
>>>>>
>>>>> crosses with a Label
>>>>>  
>>>>>
>>>>>> Release.
>>>>>> This was raised by Kishore Tiruveedhula     
>>>>>
>>>>>
>>>>> [[e-mail]] on 25th
>>>>>  
>>>>>
>>>>>> August in connection with loop detection, but it is a more     
>>>>>
>>>>>
>>>>> general problem
>>>>>  
>>>>>
>>>>>> with the protocol.
>>>>>>
>>>>>> The problem arises with the following sequence:
>>>>>> (1) Router D sends a Label Mapping
>>>>>> (2) Router U sends a Label Release
>>>>>> (3) Independently router D sends an updated Label Mapping     
>>>>>
>>>>>
>>>>> (same FEC and
>>>>>  
>>>>>
>>>>>> label, different details).
>>>>>>
>>>>>> If messages (2) and (3) cross in transit then the label mapping is
>>>>>> programmed on U (on receipt of the updated Label Mapping)     
>>>>>
>>>>>
>>>>> but released on D
>>>>>  
>>>>>
>>>>>> (on receipt of the Label Release).  Any data sent using the     
>>>>>
>>>>>
>>>>> label will be
>>>>>  
>>>>>
>>>>>> lost.
>>>>>>
>>>>>> The problem can occur whenever the downstream router sends     
>>>>>
>>>>>
>>>>> a Label Mapping
>>>>>  
>>>>>
>>>>>> message to update an existing mapping.  This is probably unusual in
>>>>>> practice, but RFC 3036 allows it and indeed describes it     
>>>>>
>>>>>
>>>>> for hop count
>>>>>  
>>>>>
>>>>>> changes when using independent control (see Kishore's     
>>>>>
>>>>>
>>>>> email).  From a quick
>>>>>  
>>>>>
>>>>>> check, the MTU signaling extension
>>>>>> (draft-ietf-mpls-ldp-mtu-extensions-03.txt) also seems to     
>>>>>
>>>>>
>>>>> require Label
>>>>>  
>>>>>
>>>>>> Mapping updates.  I am not aware of other examples, but the     
>>>>>
>>>>>
>>>>> problem is a
>>>>>  
>>>>>
>>>>>> potential trap for any LDP protocol extension.
>>>>>>
>>>>>> It is unclear how to proceed on this, as potential fixes     
>>>>>
>>>>>
>>>>> are likely to
>>>>>  
>>>>>
>>>>>> require protocol changes.  Perhaps it would be sufficient     
>>>>>
>>>>>
>>>>> to explain the
>>>>>  
>>>>>
>>>>>> problem and suggest how to avoid it.
>>>>>>
>>>>>> (This problem was drawn to my attention in discussions of     
>>>>>
>>>>>
>>>>> C-bit negotiation
>>>>>  
>>>>>
>>>>>> in draft-ietf-pwe3-control-protocol-xx.txt.  This     
>>>>>
>>>>>
>>>>> negotiation takes care to
>>>>>  
>>>>>
>>>>>> avoid Label Release messages in response to Label Withdraw     
>>>>>
>>>>>
>>>>> "Wrong C-bit".
>>>>>  
>>>>>
>>>>>> The protocol problem in RFC 3036 was suggested as one     
>>>>>
>>>>>
>>>>> reason for suppressing
>>>>>  
>>>>>
>>>>>> the Label Release, but there are probably other reasons too.)
>>>>>>
>>>>>>    Nick.
>>>>>>
>>>>>>    
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: [e-mail]
>>>>>>> [mailto:[e-mail]]On
>>>>>>> Behalf Of Ina Minei
>>>>>>> Sent: 27 September 2004 19:31
>>>>>>> To: [e-mail]
>>>>>>> Subject: [mpls] For your review - Issues/errors/clarifications in
>>>>>>> RFC3036
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>   As part of the effort to move RFC3036 to draft       
>>>>>>
>>>>>>
>>>>> standard, here is an
>>>>>  
>>>>>
>>>>>>> annotated version of RFC3036, with the changes enclosed by ###.
>>>>>>> There is a separate section summarizing all changes towards
>>>>>>> the end of the
>>>>>>> document.
>>>>>>>
>>>>>>>   Please review the changes and send comments to the       
>>>>>>
>>>>>>
>>>>> list by October
>>>>>  
>>>>>
>>>>>>> 11th.
>>>>>>>
>>>>>>>   At the end of this mail is a list of issues that were       
>>>>>>
>>>>>>
>>>>> raised but
>>>>>  
>>>>>
>>>>>>> were not included in the annotated RFC (with an explanation of
>>>>>>> why).
>>>>>>>
>>>>>>>   Please review both the RFC changes and the list of issues not
>>>>>>> included. Also let me know if I forgot to include any other issues
>>>>>>> that were raised on the list.
>>>>>>>
>>>>>>>   Many thanks to all who contributed, and in particular       
>>>>>>
>>>>>>
>>>>> to Bob Thomas
>>>>>  
>>>>>
>>>>>>> for maintaining an extensive list of errors/issues over the years.
>>>>>>>
>>>>>>>
>>>>>>>            Thank you,
>>>>>>>
>>>>>>>            Ina
>>>>>>>
>>>>>>>
>>>>>>> Issues that were raised but not included in the annotated RFC
>>>>>>> =============================================================
>>>>>>>
>>>>>>> - Issue: discussion on the merits/drawbacks of       
>>>>>>
>>>>>>
>>>>> independent-control and
>>>>>  
>>>>>
>>>>>>> ordered-control
>>>>>>> - Issue: discussion on which FECs should be advertised
>>>>>>> Reason why not included: The above two issues are either for the
>>>>>>> applicability doc or for the "experiences with the       
>>>>>>
>>>>>>
>>>>> protocol" document.
>>>>>  
>>>>>
>>>>>>> - Issue:  minor optimization: if A is a stub node, i.e.,       
>>>>>>
>>>>>>
>>>>> only one LDP
>>>>>  
>>>>>
>>>>>>> session, does it really have to send a label mapping for
>>>>>>> every FEC that
>>>>>>> it has, or can it do it lazily, e.g., when it has a second
>>>>>>> LDP session?
>>>>>>> Reason why not included : It is not clear what problem       
>>>>>>
>>>>>>
>>>>> this change in
>>>>>  
>>>>>
>>>>>>> behavior brings, and what would be the added benefit,the       
>>>>>>
>>>>>>
>>>>> issue must
>>>>>  
>>>>>
>>>>>>> be discussed on the list first.
>>>>>>>
>>>>>>> - Issue: the ldp loop detection mechanisms don't make sense in DU.
>>>>>>> We should add something explicitly that
>>>>>>> says that these TLVs should not be used in DU mode. ( This is the
>>>>>>> current practice in all implementations that I know of )
>>>>>>> Why not included: RFC 3036 already states this in the section
>>>>>>> describing these TLVs, when it talks about the usage of the TLVs.
>>>>>>>
>>>>>>> - Issue: the rfc should specifically say that  a  wildcard release
>>>>>>> message should be sent only in response to a wildcard
>>>>>>> withdraw message.
>>>>>>> Reason not included: it is covered in the rules in the appendix.
>>>>>>>
>>>>>>> - There is a long list of issues that was added to the "for future
>>>>>>> study" area of the RFC. The list is quite long, we could probably
>>>>>>> remove some of the items.
>>>>>>>
>>>>>>>       
>>>>>>
>>>>>>
>>>>> Nick Weeds
>>>>> Software Developer
>>>>> Network Protocols Group
>>>>> Data Connection Ltd
>>>>> Tel:    [phone]
>>>>> Fax:    [phone]
>>>>> Email:  [e-mail]
>>>>> Web:    http://www.dataconnection.com
>>>>>
>>>>>   
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> mpls mailing list
>>>> [e-mail]
>>>> https://www1.ietf.org/mailman/listinfo/mpls
>>>>
>>>>
>>>>
>>>>
>>>>  
>>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> mpls mailing list
>>> [e-mail]
>>> https://www1.ietf.org/mailman/listinfo/mpls
>>
>>
>>
>>
>>
>>
>>
>>
> 
> 



_______________________________________________
mpls mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/mpls