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

[Alexander Vainshtein <[e-mail]>]

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.