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

[John E Drake <[e-mail]>]

Sasha,

>From RFC 5654:

"Associated bidirectional path: A path that supports traffic flow in both directions but that is constructed from a pair of unidirectional
   paths (one for each direction) that are associated with one another at the path's ingress/egress points.  The forward and backward
   directions are setup, monitored, and protected independently.  As a consequence, they may or may not follow the same route (links
   and nodes) across the network."

Please pay special attention to the last two sentences. 

Yours Irrespectively,

John

> -----Original Message-----
> From: Alexander Vainshtein [mailto:[e-mail]]
> Sent: Monday, October 14, 2013 7:58 AM
> To: John E Drake; Gregory Mirsky
> Cc: [e-mail]; Bhatia, Manav (Manav); [e-mail]; draft-ietf-mpls-
> [e-mail]; [e-mail]
> Subject: RE: RtgDir review: draft-ietf-mpls-tp-rosetta-stone-12.txt
> 
> John,
> RFC 5654 states that both directions of a co-routed bi-directional LSP are
> protected as a whole.
> Hence I do not see how they may participate in a unidirectional protection
> scheme.
> 
> Regards,
>      Sasha
> 
> 
> > -----Original Message-----
> > From: John E Drake [mailto:[e-mail]]
> > Sent: Monday, October 14, 2013 5:55 PM
> > To: Alexander Vainshtein; Gregory Mirsky
> > 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
> >
> >
> >
> > Yours Irrespectively,
> >
> > John
> >
> > > -----Original Message-----
> > > From: [e-mail] [mailto:[e-mail]] On
> > > Behalf
> > Of
> > > Alexander Vainshtein
> > > Sent: Monday, October 14, 2013 1:08 AM
> > > To: Gregory Mirsky
> > > 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
> > >
> > > Greg,
> > > Lots of thanks for an important comment.
> > >
> > > Regarding your example: my personal interpretation of 5654 is like
> following:
> > > - Co-routed bidirectional LSPs MAY be protected using bi-directional
> > protection
> > > schemes but MUST NOT be protected using unidirectional ones
> >
> > [JD]  I don't think that is true for a pair of co-routed associated
> > unidirectional LSPs.
> >
> > > - Associated bidirectional LSPs MAY be protected using both
> > > unidirectional
> > and
> > > bi-directional protection schemes
> >
> > [JD]  Conversely, if a pair of associated unidirectional LSPs are
> > diversely routed, it may be difficult to apply bidirectional
> > protection to them.
> >
> > >
> > > Does this match your understanding?
> > >
> > > Regards,
> > >      Sasha
> > >
> > > > -----Original Message-----
> > > > From: Gregory Mirsky [mailto:[e-mail]]
> > > > Sent: Monday, October 14, 2013 9:23 AM
> > > > To: Bhatia, Manav (Manav); Alexander Vainshtein
> > > > 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
> > > >
> > > > Hi Manav,
> > > > I do feel that "fate sharing" already has certain interpretation
> > > > in the
> > > industry.
> > > > Difference in, for example, protection between co-routed and
> > > > associated bi- directional LSPs doesn't seem not to be described
> > > > by "fate sharing". I think of it as in co-routed case LSP
> > > > protected as a single entity while in associated case each
> > > > direction of LSP is protected
> > > independently of the other.
> > > >
> > > > 	Regards,
> > > > 		Greg
> > > >
> > > > -----Original Message-----
> > > > From: [e-mail] [mailto:[e-mail]] On
> > > > Behalf Of Bhatia, Manav (Manav)
> > > > Sent: Sunday, October 13, 2013 10:26 PM
> > > > To: Alexander Vainshtein
> > > > Cc: [e-mail]; [e-mail];
> > > > draft-ietf-mpls-tp-rosetta- [e-mail];
> > > > [e-mail]
> > > > Subject: Re: [mpls] RtgDir review:
> > > > draft-ietf-mpls-tp-rosetta-stone-12.txt
> > > >
> > > > Sasha,
> > > >
> > > > I think the confusion is over what we mean by "fate sharing".
> > > >
> > > > To me, if the forward path is torn down for some reason, and that
> > > > results in the backward path being torn down as well, then they
> > > > inextricably
> > > "share the fate".
> > > >
> > > > If the path of the forward LSP changes because of an IGP trigger,
> > > > then the backward LSP changes too in case of co-routed bidirectional
> LSPs.
> > > > However, this isn't true in case of Associated bidirectional LSPs.
> > > > Similarly, an IGP change (or a network event -- link/node flap,
> > > > link/node down) will always result in both directions changing
> > > > their path in case of co-routed bidirectional LSPs. This doesn't
> > > > happen in case of Associated bidirectional LSPs. Its this
> > > > difference that I wanted the
> > > authors to highlight as part of my review comment.
> > > >
> > > > If you think "fate sharing" is not the most appropriate term then
> > > > you can suggest something else as long as you believe its
> > > > something that ought to be mentioned.
> > > >
> > > > Cheers, Manav
> > > >
> > > > > -----Original Message-----
> > > > > From: Alexander Vainshtein
> > > > > [mailto:[e-mail]]
> > > > > Sent: Monday, October 14, 2013 9:37 AM
> > > > > To: Bhatia, Manav (Manav)
> > > > > Cc: [e-mail];
> > > > > [e-mail];
> > > > > [e-mail]; [e-mail]
> > > > > Subject: RE: RtgDir review:
> > > > > draft-ietf-mpls-tp-rosetta-stone-12.txt
> > > > >
> > > > >
> > > > > Manav,
> > > > > Lots of thanks for a prompt response.
> > > > >
> > > > > I must admit that I've mssed the text in 5960 to which you refer.
> > > > >
> > > > > The original definition, to the best of my understanding, is in
> > > > > Section 1.2.2. of RFC 5654 and says something else:
> > > > >
> > > > >
> > > > >    Co-routed Bidirectional path: A path where the forward and backward
> > > > >    directions follow the same route (links and nodes) across the
> > > > >    network.  Both directions are setup, monitored and protected as a
> > > > >    single entity.  A transport network path is typically co-routed.
> > > > >
> > > > > To me this means that if one of the directions of the co-routed
> > > > > bi-directional path fails to convey traffic, the monitoring
> > > > > mechanisms will report the entire bi-directional path as failed.
> > > > >
> > > > > To the best of my recollection when I=D to become RFC 5960 has
> > > > > been discussed I've asked the authors of RFC 5960 whether the
> > > > > pairing between two directions of a co-routed bi-directional
> > > > > MPLS-TP LSP in a transit LSR is limited to OAM processing, and
> > > > > they (or one of
> > > > > them) have confirmed that this is indeed so.
> > > > >
> > > > > I wonder whether this can be interpreted as "fate-sharing".
> > > > >
> > > > > Regards,
> > > > >      Sasha
> > > > >
> > > > > ________________________________________
> > > > > From: Bhatia, Manav (Manav) [[e-mail]]
> > > > > Sent: Monday, October 14, 2013 4:21 AM
> > > > > To: Alexander Vainshtein
> > > > > Cc: [e-mail];
> > > > > [e-mail];
> > > > > [e-mail]; [e-mail]
> > > > > Subject: RE: RtgDir review:
> > > > > draft-ietf-mpls-tp-rosetta-stone-12.txt
> > > > >
> > > > > Hi Sasha,
> > > > >
> > > > > RFC 5960 that describes the MPLS-TP data plane says the following:
> > > > >
> > > > > A point-to-point co-routed bidirectional LSP is a point-to-point
> > > > > associated bidirectional LSP with the additional constraint that
> > > > > its two unidirectional component LSPs in each direction follow
> > > > > the same path (in terms of both nodes and links).  An important
> > > > > property of co-routed bidirectional LSPs is that their
> > > > > unidirectional component LSPs share fate.
> > > > >
> > > > > Am I missing something?
> > > > >
> > > > > Cheers, Manav
> > > > >
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Alexander Vainshtein
> > > > > > [mailto:[e-mail]]
> > > > > > Sent: Sunday, October 13, 2013 9:46 PM
> > > > > > To: Bhatia, Manav (Manav)
> > > > > > Cc: [e-mail];
> > > > > > [e-mail];
> > > > > > [e-mail]; [e-mail]
> > > > > > Subject: RE: 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.
> > > > >
> > > > >
> > > > _______________________________________________
> > > > 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.
> > >
> > >
> >
> 
> 
> 
> 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.
> 
>