Re: [PWE3] Mail regarding draft-ietf-pwe3-vccv-for-gal
Stewart Bryant <stbryant@cisco.com> Sat, 25 October 2014 12:59 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 1949D1A885D; Sat, 25 Oct 2014 05:59:34 -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 WMX6NhuZ5t8Y; Sat, 25 Oct 2014 05:59:30 -0700 (PDT)
Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE1B71A883F; Sat, 25 Oct 2014 05:59:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=40582; q=dns/txt; s=iport; t=1414241970; x=1415451570; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to; bh=vC1ODBXmcrlY+XP1DSs1HCArR+NFz06lL67I7oPkjXY=; b=WkHNOi/jjKdacb2uVmvR9iWrKfREN8TE252u8iSHQPAS63LWhYriWsxl 2NgUkvG7WaBBGb5Q71hwVWuktFOhLAmUGzugyyk8H+EjTmnPLInBMVjT+ 5/FzYLOxdNbA+ysHpE+TgMbgO4CCaxDZsRQLwoDj754Hypm9bpPlQI0oU 4=;
X-IronPort-AV: E=Sophos; i="5.04,786,1406592000"; d="scan'208,217"; a="90276443"
Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-4.cisco.com with ESMTP; 25 Oct 2014 12:59:29 +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 s9PCxSAN008788; Sat, 25 Oct 2014 12:59:28 GMT
Message-ID: <544B9EB0.5040209@cisco.com>
Date: Sat, 25 Oct 2014 13:59:28 +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: 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>
In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B866564@eusaamb103.ericsson.se>
Content-Type: multipart/alternative; boundary="------------030106010606060106090908"
Archived-At: http://mailarchive.ietf.org/arch/msg/pwe3/I6amJtbf4E5UVrNmvob3dndNlJM
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 12:59:34 -0000
Greg You can mandate new behaviour in the PEs, but not the P routers. If a packet goes through an older P router that does not know about the EL, who knows what it will make of the GAL. Stewart On 25/10/2014 00:48, Gregory Mirsky wrote: > > 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 > *Cc:* pwe3@ietf.org; 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)