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