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

Alexander Vainshtein <Alexander.Vainshtein@ecitele.com> Mon, 14 October 2013 04:07 UTC

Return-Path: <Alexander.Vainshtein@ecitele.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDE1421E80C5 for <mpls@ietfa.amsl.com>; Sun, 13 Oct 2013 21:07:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.203
X-Spam-Level:
X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8eWvX7rGZ7Mo for <mpls@ietfa.amsl.com>; Sun, 13 Oct 2013 21:07:04 -0700 (PDT)
Received: from ilptbmg01-out.ecitele.com (ilptbmg01-out.ecitele.com [147.234.242.234]) by ietfa.amsl.com (Postfix) with ESMTP id 55BBD11E8101 for <mpls@ietf.org>; Sun, 13 Oct 2013 21:06:54 -0700 (PDT)
X-AuditID: 93eaf2e7-b7f596d000004d89-63-525b6dd3a0e6
Received: from ILPTWPVEXCA02.ecitele.com ( [172.31.244.232]) by ilptbmg01-out.ecitele.com (Symantec Messaging Gateway) with SMTP id 10.A1.19849.3DD6B525; Mon, 14 Oct 2013 06:06:43 +0200 (IST)
Received: from ILPTWPVEXMB01.ecitele.com ([fe80::f152:8eaf:8fb0:a5da]) by ILPTWPVEXCA02.ecitele.com ([fe80::c473:490d:3a7e:e34a%12]) with mapi id 14.03.0123.003; Mon, 14 Oct 2013 07:06:43 +0300
From: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>
To: "Bhatia, Manav (Manav)" <manav.bhatia@alcatel-lucent.com>
Thread-Topic: RtgDir review: draft-ietf-mpls-tp-rosetta-stone-12.txt
Thread-Index: AQHOxYUSjv9ovtIJkkW6NPBEAjYZSJny0cn5gACRRiCAADQ0BQ==
Date: Mon, 14 Oct 2013 04:06:42 +0000
Message-ID: <F9336571731ADE42A5397FC831CEAA02151563F2@ILPTWPVEXMB01.ecitele.com>
References: <20211F91F544D247976D84C5D778A4C32E4DB390@SG70YWXCHMBA05.zap.alcatel-lucent.com> <F9336571731ADE42A5397FC831CEAA0215156390@ILPTWPVEXMB01.ecitele.com>, <20211F91F544D247976D84C5D778A4C32E4DE7C1@SG70YWXCHMBA05.zap.alcatel-lucent.com>
In-Reply-To: <20211F91F544D247976D84C5D778A4C32E4DE7C1@SG70YWXCHMBA05.zap.alcatel-lucent.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [147.234.1.1]
Content-Type: text/plain; charset="us-ascii"
content-transfer-encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrAJsWRmVeSWpSXmKPExsUy+dWnL7pXcqODDN7/4LGYc+8eq8WtpStZ LZ7PmcniwOzR+mwvq8eSJT+ZPL5c/swWwBzVwGiTmJeXX5JYkqqQklqcbKsUUJRZlphcqaSQ mWKrZKikUJCTmJyam5pXYquUWFCQmpeiZMelgAFsgMoy8xRS85LzUzLz0m2VPIP9dS0sTC11 DZXs1JQNja25QjIyixVSdXMTM3MUclOLixPTUxWAIglbmDOO7H7MUnDVvuJvn0UD4ybjLkZO DgkBE4nZ27YwQ9hiEhfurWfrYuTiEBI4yChx4MENKOcoo8TuDUvZQarYBGwlNq2+ywZiiwDZ zzfvYgEpYhb4wCjxoeEBK0hCWMBZ4vTNA4wQRS4Ss86cYepi5ACynSRObKsDCbMIqEq0/VoG tplXIEDizbTprBDLvjBK3Ok4yQSS4BSIlZj6bCbYTEag876fWgMWZxYQl7j1ZD4TxNkCEkv2 nId6QVTi5eN/rBC2vMTFDw+g6nUkFuz+xAZha0ssW/gaarGgxMmZT1gg6iUlDq64wTKBUXwW khWzkLTPQtI+C0n7AkaWVYyimTkFJUm56QaGeqnJmSWpOal6yfm5mxghyeX5DsZf81UOMQpw MCrx8Ga4RAcJsSaWFVfmHmKU5GBSEuW9nQMU4kvKT6nMSCzOiC8qzUktPsQowcGsJMK7G6Sc NyWxsiq1KB8m5QoMwonMUtzJ+cCEmVcSb2xggJujJM67vCHcX0ggHZgEs1NTC1KLYObIcHAo SfAaABOzkGBRanpqRVpmTglCmomDE+QMHqAz/oGcyFtckJhbnJkOkT/FqCglzmsE0iwAksgo zYPrhWWUV4ziQE8L8zKBVPEAsxFc9yugwUxAg3++jQAZDMwecCmpBkaxGn3x6rbK6fYtBVkJ /avP89eJCcToddeujln7w2LdFPXWe+2bluiWsn43OVfy7Nekc3xnZa08SxZ2u5T7JuQbLMm5 slPj+LepXgWn23tuLu5laT/VW8T81SQ0Vujiwxgbs7XTV+y8ZpB41Hni9lt5m/c/bDx4/Nln tqVH57/r+dLfo7plro8SS3FGoqEWc1FxIgCCn/3cAwQAAA==
Cc: "rtg-dir@ietf.org" <rtg-dir@ietf.org>, "rtg-ads@tools.ietf.org" <rtg-ads@tools.ietf.org>, "draft-ietf-mpls-tp-rosetta-stone.all@tools.ietf.org" <draft-ietf-mpls-tp-rosetta-stone.all@tools.ietf.org>, "mpls@ietf.org" <mpls@ietf.org>
Subject: Re: [mpls] RtgDir review: draft-ietf-mpls-tp-rosetta-stone-12.txt
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mpls>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 14 Oct 2013 04:07:09 -0000

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) [manav.bhatia@alcatel-lucent.com]
Sent: Monday, October 14, 2013 4:21 AM
To: Alexander Vainshtein
Cc: rtg-dir@ietf.org; draft-ietf-mpls-tp-rosetta-stone.all@tools.ietf.org; mpls@ietf.org; rtg-ads@tools.ietf.org
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:Alexander.Vainshtein@ecitele.com]
> Sent: Sunday, October 13, 2013 9:46 PM
> To: Bhatia, Manav (Manav)
> Cc: rtg-dir@ietf.org;
> draft-ietf-mpls-tp-rosetta-stone.all@tools.ietf.org;
> mpls@ietf.org; rtg-ads@tools.ietf.org
> 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: rtg-dir-bounces@ietf.org [rtg-dir-bounces@ietf.org] on
> behalf of Bhatia, Manav (Manav) [manav.bhatia@alcatel-lucent.com]
> Sent: Sunday, October 13, 2013 5:55 PM
> To: rtg-ads@tools.ietf.org
> Cc: rtg-dir@ietf.org;
> draft-ietf-mpls-tp-rosetta-stone.all@tools.ietf.org; mpls@ietf.org
> 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.