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
Nick, Yes, I recollect that this problem is already discussed long time back (Jan'02). And there is no concrete solution proposed for this problem, yet. http://www.cell-relay.com/mhonarc/mpls/2002-Jan/msg00117.html Venkata. -> -----Original Message----- -> From: mpls-bounces@lists.ietf.org -> [mailto:mpls-bounces@lists.ietf.org]On -> Behalf Of Nick Weeds -> Sent: Thursday, October 07, 2004 12:38 PM -> To: 'Ina Minei' -> Cc: mpls@ietf.org (E-mail) -> Subject: RE: [mpls] For your review - Issues/errors/clarifications in -> RFC3 036 -> -> -> 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. -> -> 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 |
|