Re: [Pals] Candidate draft-ietf-pals-vccv-for-gal-01
Alexander Vainshtein <Alexander.Vainshtein@ecitele.com> Thu, 15 January 2015 10:03 UTC
Return-Path: <Alexander.Vainshtein@ecitele.com>
X-Original-To: pals@ietfa.amsl.com
Delivered-To: pals@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8C3B1B2BC8 for <pals@ietfa.amsl.com>; Thu, 15 Jan 2015 02:03:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.799
X-Spam-Level:
X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 gD5AK7vDRuxL for <pals@ietfa.amsl.com>; Thu, 15 Jan 2015 02:03:37 -0800 (PST)
Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0723.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::723]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEE5B1B2BC7 for <pals@ietf.org>; Thu, 15 Jan 2015 02:03:36 -0800 (PST)
Received: from DB3PR03MB0812.eurprd03.prod.outlook.com (25.161.55.144) by DB3PR03MB0811.eurprd03.prod.outlook.com (25.161.55.143) with Microsoft SMTP Server (TLS) id 15.1.53.17; Thu, 15 Jan 2015 10:03:13 +0000
Received: from DB3PR03MB0812.eurprd03.prod.outlook.com ([25.161.55.144]) by DB3PR03MB0812.eurprd03.prod.outlook.com ([25.161.55.144]) with mapi id 15.01.0053.000; Thu, 15 Jan 2015 10:03:13 +0000
From: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>
To: "stbryant@cisco.com" <stbryant@cisco.com>
Thread-Topic: [Pals] Candidate draft-ietf-pals-vccv-for-gal-01
Thread-Index: AQHQMA/5i86hJmZ/40iD4uDijbPVfJzA7i+Q
Date: Thu, 15 Jan 2015 10:03:13 +0000
Message-ID: <DB3PR03MB08125BCBFD6DC35A5BA62A439D4E0@DB3PR03MB0812.eurprd03.prod.outlook.com>
References: <54B68D13.9000707@cisco.com>
In-Reply-To: <54B68D13.9000707@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [147.234.56.21]
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Alexander.Vainshtein@ecitele.com;
x-dmarcaction-test: None
x-microsoft-antispam: BCL:0;PCL:0;RULEID:(3005004);SRVR:DB3PR03MB0811;
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:DB3PR03MB0811;
x-forefront-prvs: 0457F11EAF
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(189002)(199003)(252514010)(52044002)(377454003)(14971765001)(15975445007)(110136001)(19580405001)(19580395003)(102836002)(87936001)(76576001)(68736005)(97736003)(16236675004)(575784001)(64706001)(92566002)(19617315012)(2351001)(86362001)(230783001)(19625215002)(101416001)(40100003)(561944003)(122556002)(46102003)(33656002)(19300405004)(2950100001)(2900100001)(2501002)(106116001)(54356999)(62966003)(77156002)(66066001)(2656002)(105586002)(54206007)(74316001)(106356001)(54606007)(50986999)(76176999)(6055255003)(120695007); DIR:OUT; SFP:1102; SCL:1; SRVR:DB3PR03MB0811; H:DB3PR03MB0812.eurprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
received-spf: None (protection.outlook.com: ecitele.com does not designate permitted sender hosts)
Content-Type: multipart/alternative; boundary="_000_DB3PR03MB08125BCBFD6DC35A5BA62A439D4E0DB3PR03MB0812eurp_"
MIME-Version: 1.0
X-OriginatorOrg: ecitele.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jan 2015 10:03:13.1124 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2c514a61-08de-4519-b4c0-921fef62c42a
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR03MB0811
Archived-At: <http://mailarchive.ietf.org/arch/msg/pals/zGf-W-mHuTeWQLNcp09k4lg9dv8>
Cc: "draft-ietf-pals-vccv-for-gal@tools.ietf.org" <draft-ietf-pals-vccv-for-gal@tools.ietf.org>, "pals@ietf.org" <pals@ietf.org>
Subject: Re: [Pals] Candidate draft-ietf-pals-vccv-for-gal-01
X-BeenThere: pals@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Pseudowire And LDP-enabled Services dicussion list." <pals.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pals>, <mailto:pals-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pals/>
List-Post: <mailto:pals@ietf.org>
List-Help: <mailto:pals-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pals>, <mailto:pals-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 15 Jan 2015 10:03:44 -0000
Stewart, Lots of thanks for a very nice re-write of the draft that, from my POV, resolves all outstanding technical issues raised so far and moved discussion of operational issues ( consolidation of VCCV Types, migration strategy etc.) out of scope of a clear-cut technical specification. I have added a couple of minor comments inline below that hopefully could be useful. Please feel free to use (or not to use) them as you see fit. Regards, Sasha Email: Alexander.Vainshtein@ecitele.com Mobile: 054-9266302 From: Pals [mailto:pals-bounces@ietf.org] On Behalf Of Stewart Bryant Sent: Wednesday, January 14, 2015 5:37 PM To: draft-ietf-pals-vccv-for-gal@tools.ietf.org; pals@ietf.org Subject: [Pals] Candidate draft-ietf-pals-vccv-for-gal-01 Working Group/Co-authors Following discussion on the list I have edited draft-ietf-pals-vccv-for-gal to just define the GAL VCCV CC Type 4. As suggested the plan will then be to write a new draft describing the migration strategy to type 1 and 4 only. There is some text in here on migration and I am torn between taking it out and leaving it in to explain why we are introducing the new CC type. Because of the extensive changes I thought it best to post this candidate to the list to make sure we are all on the same page. If this is going in the right direction I will upload it as a draft replacing draft-ietf-pals-vccv-for-gal-00. I took Sasha's proposal of making FAT and GAL mutually exclusive which in my view usefully simplified that aspect of the design. I did quite a lot of work on the Capability Advertisment section which will need to be checked very carefully, in particular the handling of the error processing. I would appreciate a quick review to see whether this is what the WG was expecting, and then I can upload it ready for a detailed review if it is on the right lines. - Stewart PWE3 T. Nadeau Internet-Draft lucidvision Intended status: Standards Track L. Martini Expires: July 18, 2015 S. Bryant Cisco Systems January 14, 2015 Candidate for Using GAL as a VCCV Channel Indicator draft-ietf-pals-vccv-for-gal-01 Abstract This document specifies a new Virtual Circuit Connectivity Verification (VCCV) (RFC5085) control channel type for use with pseudowires (PW) carried over an MPLS network. This new channel type uses the Generic Associated Channel Label (GAL) (RFC5586) to distinguish VCCV packets from packets carrying user data. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on July 18, 2015. Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of Nadeau, et al. Expires July 18, 2015 [Page 1] Internet-Draft GAL as a VCCV Channel January 2015 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 3. GAL VCCV Control Channel Type . . . . . . . . . . . . . . . . 3 4. FAT PWs . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 5. VCCV Capability Advertisement . . . . . . . . . . . . . . . . 4 6. Manageability Considerations . . . . . . . . . . . . . . . . 5 7. Security Considerations . . . . . . . . . . . . . . . . . . . 5 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 8.1. MPLS VCCV Control Channel (CC) Type 4 . . . . . . . . . . 5 8.2. LDP Status Code . . . . . . . . . . . . . . . . . . . . . 6 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 10.1. Normative References . . . . . . . . . . . . . . . . . . 6 10.2. Informative References . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction This document specifies a new Virtual Circuit Connectivity Verification (VCCV) [RFC5085] control channel (CC) type for use with pseudowires (PW) carried over an MPLS network that do not use the PW Control Word (CW) [RFC4385]. This new VCCV CC type uses the Generic Associated Channel Label (GAL) [RFC5586] to distinguish VCCV packets from packets carrying user data. This new VCCV CC type introduces compatibility with the method of MPLS Label Switched Path (LSP) Operations, Administration, and Maintenance (OAM) identification, particularly in MPLS-TP networks [RFC5921]. VCCV currently specifies three CC types. VCCV CC Type 1 uses the PW Control Word (CW) to distinguish VCCV packets from packets carrying user data. VCCV CC Types 2 and 3 require IP encapsulation for OAM packets they carry. This was not an issue when [RFC5085] was designed, but is in conflict with the design goals of MPLS-TP [RFC5921] which does not otherwise require the availability of IP. VCCV CC Type 2 is not supported by[[Sasha]] not applicable to? multi-segment PWs (MS-PWs) [RFC6073]. A MS-PW operating without the CW therefore has to use VCCV CC Type 3 which identifies VCCV packets on the basis of TTL expiry. Whilst less of an issue with a single segment PW (SS-PW), on an MS-PW this need to be accurately set to cause TTL expiry at the egress Terminating Provider Edge (T-PE) [RFC6073]. In the event of a error in the setting of the PW LSE TTL this can result in VCCV packets leaking into the attachment circuit which may disrupt the operation of the PW, or the user service, and is a security risk. [[Sasha]] Maybe you could add that VCCV Type 3 remains mandatory for segment OAM of MS-PWs and that it is combined with VCCV Type 1 for MS-PWs that use the CW – this is explicitly stated in RFC 6073. Nadeau, et al. Expires July 18, 2015 [Page 2] Internet-Draft GAL as a VCCV Channel January 2015 The new VCCV CC type defined in this specification addresses these problems for PWs that do not use the CW. For reasons of network efficiency and due to hardware constraints it is not possible to address these issue by mandating that all PWs use the PW CW, hence the introduction of this new VCCV CC type. [[Sasha]] Maybe you could add that PWs without the CW are already widely deployed, and this is one of the reasons why mandating all PWs use the CW is not realistic. 2. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 3. GAL VCCV Control Channel Type When the PW CW is not used, the GAL VCCV Control Channel (CC) type defined in this section MAY be used. This is referred to as VCCV CC Type4 throughout the rest of this of this document. VCCV Type 4 uses the encapsulation shown in Figure 1. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PW LSE | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | GAL LSE | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 1|Version| Reserved | Channel Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ VCCV Message Body ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1 The VCCV message body is preceded by a Generic Associated Channel Header as defined in [RFC5586], in which the Channel Type identifies the type and format of the OAM message carried in the VCCV message body. The GAL LSE MUST contain the GAL reserved label as defined in [RFC5586]. Nadeau, et al. Expires July 18, 2015 [Page 3] Internet-Draft GAL as a VCCV Channel January 2015 The PW LSE is constructed according to the existing procedures that apply to the type of pseudowire that is in use. Note that the inclusion of a GAL following the PW LSE over a label switched path subject to Equal-Cost Multi-path (ECMP) load balancing can cause the OAM packet to take a different path through the network from the corresponding PW data packets. If that is not acceptable, then an alternative VCCV type must be used.[[Sasha]] Is this not a MUST? 4. FAT PWs [RFC6391] specifies that when the flow-aware transport (FAT) of pseudowires over an MPLS packet switched network has been signalled or configured, the Flow LSE MUST be present. It further specifies that "the flow label MUST NOT be an MPLS reserved label (values in the range 0..15) [RFC3032]", and that "If a flow LSE is present, it MUST be checked to determine whether it carries a reserved label. If it is a reserved label, the packet is processed according to the rules associated with that reserved label; otherwise, the LSE is discarded." This document specifies that if the flow-aware transport of pseudowires over an MPLS packet switched network has been signalled or configured then the presence of VCCV message is indicated by the use of a GAL in place of the flow LSE. This is consistent with [RFC6391], and the packet structure is identical to that shown in Figure 1. Note that the use of a GAL in place of the flow label over a label switched path subject to ECMP can cause the OAM packet to take a different path through the network from the corresponding PW data packets. If that is not acceptable, then an alternative VCCV type must be used.[[Sasha]] is it not MUST? 5. VCCV Capability Advertisement The VCCV capability advertisement MUST match the c-bit setting that is advertised in the PW FEC element [RFC4447]. If the c-bit is set, indicating the use of the PW CW, then VCCV CC Type 4 MUST NOT be advertised. If the c-bit is not set, indicating that the PW CW is not in use, then an equipment supporting this specification MUST advertise VCCV CC Type 4. Advertisement of VCCV CC Types 1 and 4 are therefore mutually exclusive. A PE supporting VCCV CC Type 4 MAY advertise other VCCV CC types as defined in [RFC5085] . Nadeau, et al. Expires July 18, 2015 [Page 4] Internet-Draft GAL as a VCCV Channel January 2015 If the remote PE supports VCCV CC Type 4, and the PW CW is not in use, then the following capability advertisement precedence rules supersede those defined in Section 7 of [RFC5085] : 1. Type 4: GAL VCCV Control Channel. 2. Type 2: MPLS Router Alert Label. 3. Type 3: MPLS PW Label with TTL == 1. If the remote PE finds that VCCV CC Types 1 and 4 are both advertised, or that c-bit is set and VCCV CC Type 4 is advertised, then it should report the error to the operator through the management interface in use, and send a Label Release Message with a status code "VCCV Type Error". 6. Manageability Considerations Whilst the introduction of this additional VCCV CC type increases the number of VCCV CC types that the operator needs to manage, it addresses the issues with VCCV CC Types 2 and 3 described in Section 1, and is a necessary per-requisite [[Sasha]] pre-requisite? of the long term strategy of the PALS working group to consolidate the VCCV channel types down to only VCCV CC Types 1 and 4. This consolidation and[[Sasha]]? Migration strategy? Something seems to be missing here. will be the subject of future work by the PALS working group. [[Sasha]] I am not sure that discussion of the PALS WG long-term strategy in a standards track document is appropriate. The rationale for introducing VCCV Type 4 is quite clear since it resolves specific issues with VCCV Type 2 and VCCV Type 3. Maybe it is worth mentioning that, just as VCCV Type 1, VCCV Type 4 can be combined with VCCV Type 3 for segment OAM of MS-PWs. In the event of a misconfiguration of this VCCV CC type, the PW is taken out of service and the operator advised as described in Section 5. Attention is drawn to the possible absence of fate sharing between PW data packets and VCCV CC Type 4 packets described in Section 3 and Section 4. 7. Security Considerations This document does not by itself raise any new security considerations beyond those described in [RFC5085]. It addresses the possibility of packet leaking that can occur with VCCV CC Type 3. 8. IANA Considerations 8.1. MPLS VCCV Control Channel (CC) Type 4 IANA is requested to assign a new bit from the MPLS VCCV Control Channel (CC) Types registry in the PWE3-parameters name space in order to identify VCCV type 4. It is recommended that Bit 3 be assigned to this purpose which would have a value of 0x08. Nadeau, et al. Expires July 18, 2015 [Page 5] Internet-Draft GAL as a VCCV Channel January 2015 MPLS VCCV Control Channel (CC) Types Bit (Value) Description Reference ============ =========== ================== Bit X (0x0Y) Type 4 This Specification 8.2. LDP Status Code IANA is requested to assign a new Status Code from the Label Distribution Protocol (LDP) Parameters name space: Status Code Name Space Range/Value E Description Reference =========== = =============== ========= 0x000000xx 0 VCCV Type Error This Specification 9. Acknowledgments The authors wish to thank Alexander (Sasha) Vainshtein for his review comments and for his proposal to make the GAL and Flow labels mutually exclusive. This proposal let to a significant simplification of this design. 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over an MPLS PSN", RFC 4385, February 2006. [RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. Heron, "Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)", RFC 4447, April 2006. [RFC5085] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires", RFC 5085, December 2007. [RFC5586] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic Associated Channel", RFC 5586, June 2009. Nadeau, et al. Expires July 18, 2015 [Page 6] Internet-Draft GAL as a VCCV Channel January 2015 [RFC6073] Martini, L., Metz, C., Nadeau, T., Bocci, M., and M. Aissaoui, "Segmented Pseudowire", RFC 6073, January 2011. [RFC6391] Bryant, S., Filsfils, C., Drafz, U., Kompella, V., Regan, J., and S. Amante, "Flow-Aware Transport of Pseudowires over an MPLS Packet Switched Network", RFC 6391, November 2011. 10.2. Informative References [RFC5921] Bocci, M., Bryant, S., Frost, D., Levrau, L., and L. Berger, "A Framework for MPLS in Transport Networks", RFC 5921, July 2010. Authors' Addresses Thomas D. Nadeau lucidvision Email: tnadeau@lucidvision.com<mailto:tnadeau@lucidvision.com> Luca Martini Cisco Systems Email: lmartini@cisco.com<mailto:lmartini@cisco.com> Stewart Bryant Cisco Systems Email: stbryant@cisco.com<mailto:stbryant@cisco.com> Nadeau, et al. Expires July 18, 2015 [Page 7]
- [Pals] Candidate draft-ietf-pals-vccv-for-gal-01 Stewart Bryant
- Re: [Pals] Candidate draft-ietf-pals-vccv-for-gal… Andrew G. Malis
- Re: [Pals] Candidate draft-ietf-pals-vccv-for-gal… Alexander Vainshtein
- Re: [Pals] Candidate draft-ietf-pals-vccv-for-gal… Stewart Bryant
- Re: [Pals] Candidate draft-ietf-pals-vccv-for-gal… Alexander Vainshtein