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

["Naidu, Venkata" <[e-mail]>]

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: [e-mail] 
-> [mailto:[e-mail]]On
-> Behalf Of Nick Weeds
-> Sent: Thursday, October 07, 2004 12:38 PM
-> To: 'Ina Minei'
-> Cc: [e-mail] (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:[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