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

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

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.
> 
>