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

[Eric Gray <[e-mail]>]

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.

>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