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

[Rama Ramakrishnan <[e-mail]>]

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