The MPLS WG Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] [mpls] For your review - Issues/errors/clarifications in RFC3 036
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:ina@juniper.net]
>>>>>> Sent: 07 October 2004 16:31
>>>>>> To: Nick Weeds
>>>>>> Cc: mpls@ietf.org (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
>>>>>>
>>>>>>
>>>>>>
>>>>>> [tiruveedhula@avici.com] 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: mpls-bounces@lists.ietf.org
>>>>>>>> [mailto:mpls-bounces@lists.ietf.org]On
>>>>>>>> Behalf Of Ina Minei
>>>>>>>> Sent: 27 September 2004 19:31
>>>>>>>> To: mpls@ietf.org
>>>>>>>> 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: +44 1244 305200
>>>>>> Fax: +44 1244 312422
>>>>>> Email: Nick.Weeds@dataconnection.com
>>>>>> Web: http://www.dataconnection.com
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> mpls mailing list
>>>>> mpls@lists.ietf.org
>>>>> https://www1.ietf.org/mailman/listinfo/mpls
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>> ------------------------------------------------------------------------
>>>>
>>>>
>>>> _______________________________________________
>>>> mpls mailing list
>>>> mpls@lists.ietf.org
>>>> https://www1.ietf.org/mailman/listinfo/mpls
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>
>
>
>
>
>
_______________________________________________
mpls mailing list
mpls@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls
|
|