Re: [mpls] RtgDir review: draft-ietf-mpls-tp-rosetta-stone-12.txt

[Alexander Vainshtein <[e-mail]>]

Greg,
Lots of thanks for a prompt response.

I do not think that there is any contradiction between the two statements in question:

1. From the data plane point of view, when an OAM packet is trapped by a transit LSR due to TTL expiration (there is no other way to do that), it is identified as such based on the GAL/GACH in its label stack and passed to the "OAM engine" which is NOT part of the data plane. 
2. The difference between co-routed and associated bidirectional LSPs only comes into play if/when the "OAM engine", as part of its handling of the specific trapped packet, decides to send a response back to the its originator:
(a) In the case of an associated bi-directional LSP it may be unable to do so in MPLS-TP (in IP/MPLS the response could be sent as an unlabeled packet)
- In the case of a co-routed bi-directional LSP it can always send a response to the head-end LER because it understands the pairing between the forward and backward directions of this LSP (and it is the only entity that understands that). This pairing effectively means that the outgoing label for the backward direction of the co-routed bi-directional LSP can be found by the OAM engine if it knows the incoming label (and its context) of the trapped OAM packet
- If (as in the case of segment OAM) the response should be trapped by an upstream transit LSR and not by the head-end, it needs, the OAM engine, in addition to forming an appropriate label stack, must set the TTL to the right value - this is what http://tools.ietf.org/html/draft-ietf-mpls-lsp-ping-ttl-tlv-05 is about.

Hopefully these notes clarify my understanding of the situation. IMHO and FWIW they comply with the general claim of shared data plane between IP/MPLS and MPLS-TP.

Regards,
     Sasha


> -----Original Message-----
> From: Gregory Mirsky [mailto:[e-mail]]
> Sent: Monday, October 14, 2013 7:01 PM
> To: Alexander Vainshtein; John E Drake
> Cc: [e-mail]; [e-mail]; Bhatia, Manav (Manav); draft-ietf-
> [e-mail]; [e-mail]
> Subject: RE: RtgDir review: draft-ietf-mpls-tp-rosetta-stone-12.txt
> 
> Hi Sasha, John, et. al,
> isn't there bit of contradiction when first stating that co-routed bidirectional
> and associated bidirectional LSPs are indistinguishable in data plane to note
> that there are difference in their OAM? OAM, in large part, is in data plane and
> how co-routed and associated bidirectional LSP being references in OAM is
> different in the data plane, not only in control and/or management planes.
> 
> 	Regards,
> 		Greg
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> Alexander Vainshtein
> Sent: Monday, October 14, 2013 8:27 AM
> To: John E Drake
> Cc: [e-mail]; [e-mail]; Bhatia, Manav (Manav); draft-ietf-
> [e-mail]; [e-mail]
> Subject: Re: [mpls] RtgDir review: draft-ietf-mpls-tp-rosetta-stone-12.txt
> 
> John,
> Lots of thanks for a prompt response.
> 
> I fully agree with you that there is no difference in the data plane between two
> directions a co-routed bi-directional LSP and two directions of an associated bi-
> directional LSP. The difference is mainly in management/control plane, in the
> OAM etc.
> 
> This is exactly why I find the term "fate-sharing" inappropriate when it is
> applied to forward and backward directions of a co-routed bi-directional LSP
> because to me fate-staring refers to first of all to the data plane behavior.
> 
> Regards,
>      Sasha
> 
> 
> > -----Original Message-----
> > From: John E Drake [mailto:[e-mail]]
> > Sent: Monday, October 14, 2013 6:10 PM
> > To: Alexander Vainshtein
> > Cc: [e-mail]; Bhatia, Manav (Manav); [e-mail];
> > draft-ietf-mpls-tp- [e-mail];
> > [e-mail]
> > Subject: RE: RtgDir review: draft-ietf-mpls-tp-rosetta-stone-12.txt
> >
> > Sasha,
> >
> > My point was simply that in the data plane there isn't any difference
> > between the two.
> >
> > Yours Irrespectively,
> >
> > John
> >
> > > -----Original Message-----
> > > From: [e-mail] [mailto:[e-mail]] On
> > > Behalf
> > Of
> > > Alexander Vainshtein
> > > Sent: Monday, October 14, 2013 7:34 AM
> > > To: John E Drake
> > > Cc: [e-mail]; Bhatia, Manav (Manav); [e-mail];
> > > draft-ietf-mpls- [e-mail];
> > > [e-mail]
> > > Subject: Re: [RTG-DIR] RtgDir review:
> > > draft-ietf-mpls-tp-rosetta-stone-12.txt
> > >
> > > John,
> > > Not sure I fully understood your message.
> > >
> > > My comments have been about applicability of the term "fate-sharing"
> > > to the two directions of a co-routed bi-directional LSP.
> > > It is of course true that each direction of an associated
> > > bi-directional LSP can fail independently of the other one, but,
> > > presumably, nobody has expected anything else in this case.
> > >
> > > Regards,
> > >      Sasha
> > >
> > >
> > > > -----Original Message-----
> > > > From: John E Drake [mailto:[e-mail]]
> > > > Sent: Monday, October 14, 2013 4:42 PM
> > > > To: Alexander Vainshtein; Bhatia, Manav (Manav)
> > > > Cc: [e-mail]; [e-mail];
> > > > draft-ietf-mpls-tp-rosetta- [e-mail];
> > > > [e-mail]
> > > > Subject: RE: RtgDir review:
> > > > draft-ietf-mpls-tp-rosetta-stone-12.txt
> > > >
> > > > Sasha,
> > > >
> > > > I think your comments apply equally to bidirectional LSPs.
> > > >
> > > > Yours Irrespectively,
> > > >
> > > > John
> > > >
> > > > > -----Original Message-----
> > > > > From: [e-mail] [mailto:[e-mail]]
> > > > > On Behalf
> > > > Of
> > > > > Alexander Vainshtein
> > > > > Sent: Sunday, October 13, 2013 9:16 AM
> > > > > To: Bhatia, Manav (Manav)
> > > > > Cc: [e-mail]; [e-mail];
> > > > > draft-ietf-mpls-tp-rosetta- [e-mail];
> > > > > [e-mail]
> > > > > Subject: Re: [RTG-DIR] RtgDir review:
> > > > > draft-ietf-mpls-tp-rosetta-stone-12.txt
> > > > >
> > > > > Manav and all,
> > > > > Regarding one of the nits you've identified:
> > > > > "it would be useful to mention that an important property of
> > > > > co-routed bidirectional path is that the forward and backward
> > > > > directions
> > > share fate."
> > > > >
> > > > > IMHO and FWIW this is not correct. To the best of my
> > > > > understanding the two directions of an MPLS-TP co-routed
> > > > > bi-directional path share lifespan (i.e.,they are set up and
> > > > > torn down in a single management or
> > > control plane operation).
> > > > > But they do not share fate, as can be seen from the following examples:
> > > > >
> > > > > 1. A unidirectiona fiber cut in one of the links used by a
> > > > > co-routed
> > > > > bi-
> > > > directional
> > > > > trail will result in traffic failur in the affected direction
> > > > > but not necessarily in
> > > > the
> > > > > reverse one
> > > > >
> > > > > 2. Consider the case when one of entries the ILM in one of the
> > > > > transit LSRs is corruped. This will result in incorrect failure
> > > > > of a single label, but the rest of
> > > > the
> > > > > labels would be handled correctly. Since co-routed
> > > > > bi-directional trails do not require using the same label in
> > > > > both directions of a trail, the fate sharing
> > > > would
> > > > > be broken.
> > > > > (Actually, in such a way it could be easily broken even if the
> > > > > same label is
> > > > used
> > > > > on each segment of the LSP in both directions...)
> > > > >
> > > > > My 2c,
> > > > >      Sasha
> > > > >
> > > > >
> > > > >
> > > > > ________________________________________
> > > > > From: [e-mail] [[e-mail]] on
> > > > > behalf of Bhatia, Manav (Manav)
> > > > > [[e-mail]]
> > > > > Sent: Sunday, October 13, 2013 5:55 PM
> > > > > To: [e-mail]
> > > > > Cc: [e-mail];
> > > > > [e-mail];
> > > > > [e-mail]
> > > > > Subject: [RTG-DIR] RtgDir review:
> > > > > draft-ietf-mpls-tp-rosetta-stone-12.txt
> > > > >
> > > > > Hello,
> > > > >
> > > > > I have been selected as the Routing Directorate reviewer for
> > > > > this draft. The Routing Directorate seeks to review all routing
> > > > > or routing-related drafts as they pass through IETF last call
> > > > > and IESG review, and sometimes on special request. The purpose
> > > > > of the review is to provide assistance to the Routing ADs. For
> > > > > more information about the Routing Directorate, please
> > > > > seehttp://www.ietf.org/iesg/directorate/routing.html
> > > > >
> > > > > Although these comments are primarily for the use of the Routing
> > > > > ADs, it would be helpful if you could consider them along with
> > > > > any other IETF Last
> > > > Call
> > > > > comments that you receive, and strive to resolve them through
> > > > > discussion or by updating the draft.
> > > > >
> > > > > Document: draft-ietf-mpls-tp-rosetta-stone-12.txt
> > > > > Reviewer: Manav Bhatia
> > > > > Review Date: October 13th, 2013
> > > > > IETF LC End Date: October 16, 2013 Intended Status:
> > > > > Informational
> > > > >
> > > > > Summary:  This document is basically ready for publication, but
> > > > > has nits that should be considered prior to publication.
> > > > >
> > > > > Comments: This document is built on top of terms already defined
> > > > > in different RFCs and ITU-T documents. The terms and definitions
> > > > > have already been reviewed so there is a trifle little that
> > > > > needs to be done there. Overall, the document looks good and
> > > > > ready for publication. Some of my comments can be
> > > > >
> > > > > Nits:
> > > > >
> > > > > o) Please expand PW in either the Abstract or Sec 3.5
> > > > >
> > > > > o) When explaining Control Plane (3.6) should we mention that it
> > > > > is possible
> > > > to
> > > > > operate an MPLS-TP network without using a Control Plane?
> > > > >
> > > > > o) In 3.7, it would be useful to mention that an important
> > > > > property of co-
> > > > routed
> > > > > bidirectional path is that the forward and backward directions share
> fate.
> > > > > Similarly, in 3.1, we should mention that the forward and
> > > > > backward directions don't share fate.
> > > > >
> > > > > o) 3.12 in the current text doesn't look very helpful. Can it be
> > > > > rephrased it to something like, "The equipment management
> > > > > function
> > > > > (EMF) provides the means through which an element management
> > > > > system
> > > > > (EMS) and other managing entities manage the network element
> > > > > function
> > > (NEF)."
> > > > >
> > > > > o) 3.13 talks about Fault cause without explaining what a fault
> > > > > cause is. It
> > > > took
> > > > > me some time to understand what was meant by "fault cause". Can
> > > > > the authors of the draft rephrase 3.13 in their own language to
> > > > > explain what they mean by a Failure. The current definition in
> > > > > the draft has been picked up as-is from ITU-T G.806
> > > > >
> > > > > o) 3.14 talks about "inability of a function to perform a
> > > > > required action". Since this RFC-to-be is in the IETF domain,
> > > > > can this be rephrased to use a term like router/switch instead
> > > > > of a more esoteric "function". This is a general
> > > > comment
> > > > > and applies to most of the definitions that have been copied
> > > > > from the ITU-T documents.
> > > > >
> > > > > o) The last paragraph of 3.17 says the following:
> > > > >
> > > > > "OAM packets are subject to the same forwarding treatment as the
> > > > > data traffic, but they are distinct from the data traffic."
> > > > >
> > > > > In what sense are the OAM packets distinct from the data traffic?
> > > > >
> > > > > o) Please include "T-PE" and "S-PE" in Sec 1.2. These have not
> > > > > been expanded in the document.
> > > > >
> > > > > o) Sec 3.19 uses TCM without expanding it first.
> > > > >
> > > > > o) In Sec 3.23, s/Tandem Connections/Tandem Connection
> > > > >
> > > > > o) In 3.28.3, can the following text be added:
> > > > >
> > > > > An LSP segment comprises one or more continuous hops on the path
> > > > > of the LSP.  [RFC5654] defines two terms.  A "segment" is a
> > > > > single hop along the
> > > > path
> > > > > of an LSP, while a "concatenated segment" is more than one hop
> > > > > along the path of an LSP.
> > > > >
> > > > > o) In 3.31, Isn't Operations Support Systems (OSS) a more common
> > > > > term than Operations Systems (OS)?
> > > > >
> > > > > Cheers, Manav
> > > > >
> > > > > This e-mail message is intended for the recipient only and
> > > > > contains
> > > > information
> > > > > which is CONFIDENTIAL and which may be proprietary to ECI Telecom.
> > > > > If you have received this transmission in error, please inform
> > > > > us by e-mail, phone or fax, and then delete the original and all copies
> thereof.
> > > > >
> > > > >
> > > >
> > >
> > >
> > >
> > > This e-mail message is intended for the recipient only and contains
> > information
> > > which is CONFIDENTIAL and which may be proprietary to ECI Telecom.
> > > If you have received this transmission in error, please inform us by
> > > e-mail, phone or fax, and then delete the original and all copies thereof.
> > >
> > >
> >
> 
> 
> 
> This e-mail message is intended for the recipient only and contains information
> which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you
> have received this transmission in error, please inform us by e-mail, phone or
> fax, and then delete the original and all copies thereof.
> 
> _______________________________________________
> mpls mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls


This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof.