Re: [PWE3] Mail regarding draft-ietf-pwe3-vccv-for-gal
Stewart Bryant <stbryant@cisco.com> Sat, 25 October 2014 13:03 UTC
Return-Path: <stbryant@cisco.com>
X-Original-To: pwe3@ietfa.amsl.com
Delivered-To: pwe3@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 454A61A883E; Sat, 25 Oct 2014 06:03:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level:
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cLpQ8wOn5e1p; Sat, 25 Oct 2014 06:03:28 -0700 (PDT)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 485F71A8883; Sat, 25 Oct 2014 06:03:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=46865; q=dns/txt; s=iport; t=1414242207; x=1415451807; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to; bh=WaX919085X4MT9prsdFn3CEcX3Im7bv+jbBJN3jnqBY=; b=KhXVjdfOzSEYuW2ByzVAVoS0qNRzPNghWICuKU3Yijb7s1ks6zGdOY7e lE52LxWil1si43HabnzU+X9R4gmvZNB6s4h0nQehlQQoNfTBdSHvyyqy2 1u7xK3rTPTUJZ+z3Tp/YYCpjweUn7lBeD5vbYPjVEC5BLlv4A/i5dvnlj k=;
X-IronPort-AV: E=Sophos;i="5.04,786,1406592000"; d="scan'208,217";a="366387844"
Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-3.cisco.com with ESMTP; 25 Oct 2014 13:03:26 +0000
Received: from [10.21.75.165] ([10.21.75.165]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s9PD3Q5c010861; Sat, 25 Oct 2014 13:03:26 GMT
Message-ID: <544B9F9E.7090001@cisco.com>
Date: Sat, 25 Oct 2014 14:03:26 +0100
From: Stewart Bryant <stbryant@cisco.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Shahram Davari <davari@broadcom.com>, Gregory Mirsky <gregory.mirsky@ericsson.com>, Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>, "draft-ietf-pwe3-vccv-for-gal@tools.ietf.org" <draft-ietf-pwe3-vccv-for-gal@tools.ietf.org>
References: <7347100B5761DC41A166AC17F22DF1121B865AB6@eusaamb103.ericsson.se> <1414128851884.41935@ecitele.com> <544AE1B0.2040401@cisco.com> <7347100B5761DC41A166AC17F22DF1121B866564@eusaamb103.ericsson.se> <4A6CE49E6084B141B15C0713B8993F2831D5E6DF@SJEXCHMB12.corp.ad.broadcom.com>
In-Reply-To: <4A6CE49E6084B141B15C0713B8993F2831D5E6DF@SJEXCHMB12.corp.ad.broadcom.com>
Content-Type: multipart/alternative; boundary="------------040308090301040204040907"
Archived-At: http://mailarchive.ietf.org/arch/msg/pwe3/nDRNSjD0CXomNkz0n_rJRVd_cM4
Cc: "pwe3@ietf.org" <pwe3@ietf.org>, "pals@ietf.org" <pals@ietf.org>
Subject: Re: [PWE3] Mail regarding draft-ietf-pwe3-vccv-for-gal
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: stbryant@cisco.com
List-Id: Pseudowire Emulation Edge to Edge <pwe3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pwe3>, <mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pwe3/>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:pwe3-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 25 Oct 2014 13:03:32 -0000
On 25/10/2014 01:02, Shahram Davari wrote: > > Hi Greg, > > Good point. We have always assumed the order is PW Label, FAT Label, > GAL (BoS). This seems to be the more logical way of doing it. > Shahram Isn't that what I proposed? However I still don't see how GAL is ECMP safe given that we have no knowledge of the age/type of P router on the path. Stewart > > Thx > Shahram > > *From:*pwe3 [mailto:pwe3-bounces@ietf.org] *On Behalf Of *Gregory Mirsky > *Sent:* Friday, October 24, 2014 4:48 PM > *To:* stbryant@cisco.com; Alexander Vainshtein; > draft-ietf-pwe3-vccv-for-gal@tools.ietf.org > *Cc:* pwe3@ietf.org; pals@ietf.org > *Subject:* Re: [PWE3] Mail regarding draft-ietf-pwe3-vccv-for-gal > > Hi Stewart, > > you’ve said “…when the GAL is that the ECMP path is likely to change …”. > > I think that is the case for legacy nodes that do not support Entropy > Label and RFC 6790 as it states that reserved, a.k.a. special purpose > and extended special purpose, labels MUST NOT be used as keys for > load-balancing by transit LSRs. > > Regards, > > Greg > > *From:*Stewart Bryant [mailto:stbryant@cisco.com] > *Sent:* Friday, October 24, 2014 4:33 PM > *To:* Alexander Vainshtein; Gregory Mirsky; > draft-ietf-pwe3-vccv-for-gal@tools.ietf.org > <mailto:draft-ietf-pwe3-vccv-for-gal@tools.ietf.org> > *Cc:* pwe3@ietf.org <mailto:pwe3@ietf.org>; pals@ietf.org > <mailto:pals@ietf.org> > *Subject:* Re: [PWE3] Mail regarding draft-ietf-pwe3-vccv-for-gal > > On 24/10/2014 06:34, Alexander Vainshtein wrote: > > Greg, > > Lots of thanks for a very careful review of the document. > > All your comments look valid to me and, IMO, should be addressed > in the next revision of the draft. > > In addition, please see below a couple of comments of my own: > > 1. *GAL vs. Flow Label*: > * The draft refers to RFC 5586 for the definition of GAL, and > this document states that GAL MUST be BoS. > * At the same time, RFC 6391 has defined the Flow Label for > flow-aware (a.k.a. "fat") PWs, and specified that it MUST be BoS. > * It is not clear to me whether GAL and Flow Label can be > combined, since they cannot both be BoS. I'd like to remind > the authors that this issue has been raised at the very early > stages of discussion of VCCV Type 4 (even before it has become > a WG document), but it remains unresolved until now. > > Thanks for pointing out the conflict. > > In the original PW design the PW label was always the bottom label. > The FAT label was after the PW label for two reasons firstly because > you needed the context of the PW label to know to pop it and secondly > it had more entropy and so putting it at the bottom seemed like the > best place because you expect entropy to increase as you get closer to > the bottom of the stack. > > Now as I recall the GAL says that the ACH is after the bottom of > stack, which means it could actually be anywhere although it was > convenient to put it at BOS. > > Probably the right things - with suitable update notes is > PW/FAT/GAL/ACH. The PW handler then know to discard the FAT and the > GAL says look for the ACH. > > We have no choice but to include the FAT since it is a property of the > PW and the handler always expects it. We could remove it when the GAL > is present but is a lot more complex. > > What is annoying and hopefully people realize this is that when the > GAL is that the ECMP path is likely to change - something we carefully > avoided with the CW design (which is why we did it like that in the > first place. > > This then takes me to wonder if we should restrict the GAL solely to > the case of a point to point LSP such as we get with RSVP-TE and > MPLS-TP, in which case FAT would never be present. > > I need some WG input on this. > > 1. > 2. *TTL in the PW LSE*: > * The draft contains some Editor remarks regarding this issue, > but eventually suggests setting TTL=1 in the PW LSE for SS-PWs > * To the best of my recollection original Martini drafts have > set the PW LSE TTL to 2, and many implementations follow this, > even if the PW RFCs have relaxed that to any suitable value > * In any case, setting TTL in the PW LSE to 1 would cause many > implementations to trap all PW packets to the CP due to TTL > expiration; so this looks an error to me, > > Yes I remember that. It's an implementation issue in some older h/w > that is unlikely to do this. However it's probably OK to maintain the > old value as the packet is not going to go very far. > > Let me go back and look at the framework RFCs and see if there is > anything I am missing. > > We should discuss this at the next WG meeting to make sure we are all > on the same page. > > - Stewart > > 1. > > Hopefully these comments will be useful. > > Regards, > > Sasha > > ------------------------------------------------------------------------ > > *From:* pwe3 <pwe3-bounces@ietf.org> <mailto:pwe3-bounces@ietf.org> on > behalf of Gregory Mirsky <gregory.mirsky@ericsson.com> > <mailto:gregory.mirsky@ericsson.com> > *Sent:* Friday, October 24, 2014 4:30 AM > *To:* draft-ietf-pwe3-vccv-for-gal@tools.ietf.org > <mailto:draft-ietf-pwe3-vccv-for-gal@tools.ietf.org> > *Cc:* pwe3@ietf.org <mailto:pwe3@ietf.org>; pals@ietf.org > <mailto:pals@ietf.org> > *Subject:* [PWE3] Mail regarding draft-ietf-pwe3-vccv-for-gal > > Dear Authors, Editors, et. al, > > thank you for your work on this document that is very important to PW > OAM. Please kindly consider my comments below: > > ·Abstract > > o"This document describes a unified mode of operation for Virtual > Circuit Connectivity Verification (VCCV) ..." IMHO, agreement of WG > discussion in Paris was to limit document scope to introduction of > Control Channel Type 4 for PW VCCV and address unified operation of CC > VCCV in RFC 5085bis. > > o“It describes new rules requiring this mode to be used as the > default/mandatory mode of operation for VCCV.” I think this statement > is over-reaching. Use of Control Channel Type 4 may be suggested as > preferred in some scenarios, such as CW not being used, SS-PW or e2e > MS-PW. I think that the strongest statement could be “New > implementations of PW VCCV SHOULD support CC Type 4.” > > o"The older types will remain optional." IMHO, the WG agreed to > obsolete Type 2 CC PW VCCV. > > ·Requirements Language and Terminology. > > These acronyms are not used in the document: AVP, L2SS, LCCE, PW-ACH > > ·Introduction > > o"... the ITU-T and IETF have set out to enhance MPLS to make it > suitable as an optical transport protocol ..." Perhaps should be > "packet transport". > > o"In order to support VCCV when an MPLS-TP PSN is in use, the GAL-ACH > had to be created ..." G-ACh was created for MPLS-TP LSP, not PW. PW > VCCV when PSN is MPLS-TP can use any of described in RFC 5085 control > channel types. And RFC 5586 explicitly excluded GAL from being used on > PWs in the first sentence of Section 4.2. > > o"This document defines two modes of operation of VCCV ..." Where the > document leaves CC Type 3? Isn't it valid mode of PW VCCV operation > that the PWE3 WG decided to keep? I believe that only Type 3 can be > used in MS-PW to address S-PE whether CW being used or not. > > o"In either case, it will be mandatory to implement and use that mode > under that scenario." Again, this conclusion is not in sync with what > was agreed at PWE3 WG meeting in Paris. > > ·Section 2 > > "... Associated Channel Types of 21, 07, or 57 are allowed" Firstly, > it should be "0x0021, 0x007, or 0x0057". Secondly, why 0x000A, 0x000B, > 0x000C, 0x000D, 0x000E, 0x0022, 0x0023, 0x0024, 0x0025, 0x0026, > 0x0027, and 0x0058 would not be listed as valid ACH types? > > ·Section 3 > > "In the case of multi-segment pseudo-wires, the PW Label TTL MUST be > set to the correct value to reach the intended destination PE as > described in [RFC6073]" And that would be the case of VCCV CC Type 3 > used in combination with CC Type 4. I think it must be so noted that > VCCV CC Type 3 and CC Type 4 can be used in combination since Section > 5.1.3 of RFC 5085 explicitly allows combination of PW VCCV Control > Channels Type 1 and Type 3. > > ·Section 4 > > "The first nibble of the next field is set to 0001b ..." Perhaps “the > first nibble of the next octet …”. And does that imply that GAL MUST > be BoS label and thus S=1? Should that be explicitly stated? > > ·Section 5 > > o“If the c-bit is set, indicating the use of the control word, type 1 > MUST be advertised and type 4 MUST NOT be advertised.” MUST in > connection to Type 1 implicitly requires support of CC Type 1. I think > that this is too strong statement and propose change it to “Type 1 > MUST be advertised if supported” or just “Type 1 MAY be advertised”. > > o"If the c-bit is not set, indicating that the control word is not in > use, type 4 MUST be advertised, and type 1 MUST NOT be advertised." As > in previous comment, MUST in connection to CC Type 4 is too strong and > implies it being supported. Similar change suggested. > > Regards, > > Greg > > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org <mailto:pwe3@ietf.org> > https://www.ietf.org/mailman/listinfo/pwe3 > > > > -- > For corporate legal information go to: > > http://www.cisco.com/web/about/doing_business/legal/cri/index.html > -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html
- [PWE3] Mail regarding draft-ietf-pwe3-vccv-for-gal Gregory Mirsky
- Re: [PWE3] Mail regarding draft-ietf-pwe3-vccv-fo… Alexander Vainshtein
- Re: [PWE3] Mail regarding draft-ietf-pwe3-vccv-fo… Stewart Bryant
- Re: [PWE3] Mail regarding draft-ietf-pwe3-vccv-fo… Gregory Mirsky
- Re: [PWE3] Mail regarding draft-ietf-pwe3-vccv-fo… Stewart Bryant
- Re: [PWE3] Mail regarding draft-ietf-pwe3-vccv-fo… Shahram Davari
- Re: [PWE3] Mail regarding draft-ietf-pwe3-vccv-fo… Stewart Bryant
- Re: [PWE3] Mail regarding draft-ietf-pwe3-vccv-fo… Stewart Bryant
- Re: [PWE3] [Pals] Mail regarding draft-ietf-pwe3-… Shahram Davari
- Re: [PWE3] Mail regarding draft-ietf-pwe3-vccv-fo… Alexander Vainshtein
- Re: [PWE3] [Pals] Mail regarding draft-ietf-pwe3-… Stewart Bryant (stbryant)