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

[Eric Gray <[e-mail]>]

Rama,

    Actually, it is still used for the same purpose - to decide how to 
forward packets.
It is just associated with a different decision.  My point is that it is 
not impossible (or
even hard) to avoid the problem we are blasting away at.

--
Eric

Rama Ramakrishnan wrote:

>
>
> 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