From nobody Fri Nov 4 13:43:54 2016 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19F78129546 for ; Fri, 4 Nov 2016 13:43:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no 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 Me9OepoZISBf for ; Fri, 4 Nov 2016 13:43:50 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A39F12954E for ; Fri, 4 Nov 2016 13:43:49 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id uA4KhlWR032182 for ; Fri, 4 Nov 2016 20:43:47 GMT Received: from 950129200 (248.206.189.80.dyn.plus.net [80.189.206.248]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id uA4Khj8s032169 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Fri, 4 Nov 2016 20:43:46 GMT From: "Adrian Farrel" To: Date: Fri, 4 Nov 2016 20:43:39 -0000 Message-ID: <02bb01d236dc$1fb2c400$5f184c00$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_02BC_01D236DC.1FB66D80" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdI23BzvDhplW9v1TxOJ+2FLlpC6zw== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-22680.002 X-TM-AS-Result: No--21.014-10.0-31-10 X-imss-scan-details: No--21.014-10.0-31-10 X-TMASE-MatchedRID: 5H0h97/a1s7ALP4z28FkP/AjkTMkRNNUj0hFbSgsWhy1eX0jEQ9c6gRW BGU/x3ROc7qzI+uYRDhshkKbIj3wIhjNRuD6vS9UYPK6HbWWX3CzWETBQPV38sFKCo95h/aQmYj 1tygCsCIJmBYKaaumQgx3TdLVUpfM+zoAW8R15l8c8J6ZrWP/q39oOiiWbcZdcVdapPIqr6gGvz VmOA+OnTFn1ScbWur/tENQtfL3NaFilqzDH4WynCjQ4osdfamB9CFB7klVg4eNTnqOMBIJ4ZkK+ RzzEeMFV+GW41yBauc3dvsqMljastUEA09P1mY/hrs6JAEL1u56+kbfvkL9WjLV70E8IIkOZt5J i8N2KmZczJ2DyxDKXYYdA0Eke7Y66ntfdlS/7+BIRA38P/dwbmKaLwu81+av47E6rstCUYua1xD avWicTDeVCF007uCsmzhDp71/Sg1thJ7IXRIqNmivjLE8DPtZXccelkX/ubBLgo8+IIHbcFftmx SrheQ1FKBZTg0OGReUrpyoAlRMVDpXLKF/7kPI71Wx2uUbPLf9sV9Tla1qi1cbfIj2Ta9s5NS4Q OzMK7t7CjyP3UZ5MbpGAQ2wD/3Qyx6w4CJ+2uX2Ii0VSfdeQzuvYa1v2IFhTx0U/40+rr7a6BBk IrnTcudLZPVW5sDNedxyf/baQ0eb2ohNz0F+pNT+TcIhUUCBZJAk04EAz2Un+p552csI1Y/sYBB J7n+d9sFE6GfY4gY8LuP+bOkMWp8voPxO05mszzuzg6dga4IDYMDMBThLyRPuWwH3mlrqVD4IX3 GhzkucTZGiBUd8fawQUp5/xlTG2ygMnPk4DNyeAiCmPx4NwGmRqNBHmBve1B0Hk1Q1KyI+8FJNG dxYq2WKAuw8W/Il8pOev45XRKxNNwevGadoDxZpPgjDEgahOBDLLg30iDk= Archived-At: Subject: [Pals] FW: WG Action: Formed L2VPN Service Model (l2sm) X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2016 20:43:53 -0000 This is a multipart message in MIME format. ------=_NextPart_000_02BC_01D236DC.1FB66D80 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I guess PALS will be interested in this as well. Adrian =20 From: BESS [mailto:bess-bounces@ietf.org] On Behalf Of Alvaro Retana = (aretana) Sent: 04 November 2016 20:29 To: bess@ietf.org Subject: [bess] FW: WG Action: Formed L2VPN Service Model (l2sm) =20 FYI=E2=80=A6 =20 On 11/4/16, 1:58 PM, "iesg on behalf of The IESG" wrote: =20 A new IETF WG has been formed in the Operations and Management Area. For additional information, please contact the Area Directors or the WG Chairs. =20 L2VPN Service Model (l2sm) ----------------------------------------------------------------------- Current status: Proposed WG =20 Chairs: Adrian Farrel Qin Wu =20 Assigned Area Director: Benoit Claise =20 Operations and Management Area Directors: Benoit Claise Joel Jaeggli Mailing list: Address: l2sm@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/l2sm Archive: https://mailarchive.ietf.org/arch/browse/l2sm/ =20 Charter: https://datatracker.ietf.org/doc/charter-ietf-l2sm/ =20 The IETF and the industry in general is currently specifying a set of YANG models for network element and protocol configuration. This is an essential first step, but the end goal is a full system configuration that enables service agility to speed service creation and delivery and allows the deployment of innovative new services across networks. Services are built from a combination of network element and protocol configuration, but are specified to service users in more abstract = terms. =20 The Layer Two Virtual Private Network Service Model (L2SM) working group is a short-lived WG. It is tasked to create a YANG data model that describes a L2VPN service (a L2VPN customer service model). The model = can be used for communication between customers and network operators, and = to provide input to automated control and configuration applications. =20 It is recognized that it would be beneficial to have a common base model that addresses multiple popular L2VPN service types. The working group will derive a single data model that includes support for the following: - point-to-point Virtual Private Wire Services (VPWS), - multipoint Virtual Private LAN services (VPLS) that use LDP-signaled Pseudowires - multipoint Virtual Private LAN services (VPLS) that use a Border Gateway Protocol (BGP) control plane as described in RFC4761 and RFC6624 - Ethernet VPNs specified in RFC 7432. Other L2VPN service types may be included if there is consensus in the working group. =20 It needs to be clearly understood that this L2VPN customer service model is not an L2VPN configuration model. That is, it does not provide = details for configuring network elements or protocols: that work is expected to be carried out in other protocol-specific working groups. Instead, the L2VPN customer service model contains the characteristics of the service as discussed between the operators and their customers. A separate process is responsible for mapping this customer service model onto the protocols and network elements depending on how the network operator chooses to realise the service. =20 The deliverable from this working group will provide information that other working groups can use to evaluate the set of YANG models that = they have already developed or that are under development. This will help = them to identify any missing models or details. Thus, the deliverable can be viewed as driving requirements for service delivery models so that the customer service parameters can be mapped into inputs used by the protocol configuration models. =20 The working group will learn from the experience of the L3SM working group and it is expected that the L2SM data model will have similar structure to the L3SM data model to enable benefits of common code, provide shared user experience, and leverage discussions that took place during the L3SM development. =20 The working group should consider draft-wen-l2sm-l2vpn-service-model as = a starting point. =20 The working group will coordinate with other working groups responsible for L2VPN protocol work (most notably with BESS and PALS). It will also coordinate with other organizations working on related L2VPN data models (such as the MEF). =20 Milestones: Dec 2016 - Adopt WG draft for data model Oct 2017 - Request publication of data model as Standards Track RFC Dec 2017 - Close working group =20 =20 =20 ------=_NextPart_000_02BC_01D236DC.1FB66D80 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

I guess PALS will be = interested in this as well.

Adrian

 

From: BESS = [mailto:bess-bounces@ietf.org] On Behalf Of Alvaro Retana = (aretana)
Sent: 04 November 2016 20:29
To: = bess@ietf.org
Subject: [bess] FW: WG Action: Formed L2VPN = Service Model (l2sm)

 

FYI=E2=80=A6

 

On 11/4/16, 1:58 PM, "iesg on behalf of The IESG" = <iesg-bounces@ietf.org = on behalf of iesg-secretary@ietf.org> = wrote:

 

=

A new IETF WG has been formed in the Operations and = Management Area. For

additional information, please contact the Area Directors or = the WG

Chairs.

 

L2VPN Service Model (l2sm)

--------------------------------------------------------------= ---------

Current status: Proposed = WG

 

Chairs:

  Adrian Farrel <adrian@olddog.co.uk>

  Qin Wu <bill.wu@huawei.com><= /span>

 

Assigned Area Director:

  Benoit Claise <bclaise@cisco.com>

 

Operations and Management Area = Directors:

  Benoit Claise <bclaise@cisco.com>

  Joel Jaeggli <joelja@bogus.com>

Mailing list:

The IETF and the industry in general is currently specifying = a set of

YANG models for network element and protocol configuration. = This is an

essential first step, but the end goal is a full system = configuration

that enables service agility to speed service creation and = delivery and

allows the deployment of innovative new services across = networks.

Services are built from a combination of network element and = protocol

configuration, but are specified to service users in more = abstract terms.

 

The Layer Two Virtual Private Network Service Model (L2SM) = working group

is a short-lived WG. It is tasked to create a YANG data model = that

describes a L2VPN service (a L2VPN customer service model). = The model can

be used for communication between customers and network = operators, and to

provide input to automated control and configuration = applications.

 

It is recognized that it would be beneficial to have a common = base model

that addresses multiple popular L2VPN service types. The = working group

will derive a single data model that includes support for the = following:

- point-to-point Virtual Private Wire Services = (VPWS),

- multipoint Virtual Private LAN services (VPLS) that use = LDP-signaled

Pseudowires

- multipoint Virtual Private LAN services (VPLS) that use a = Border

Gateway Protocol (BGP) control plane as described in RFC4761 = and RFC6624

- Ethernet VPNs specified in RFC = 7432.

Other L2VPN service types may be included if there is = consensus in the

working group.

 

It needs to be clearly understood that this L2VPN customer = service model

is not an L2VPN configuration model. That is, it does not = provide details

for configuring network elements or protocols: that work is = expected to

be carried out in other protocol-specific working groups. = Instead, the

L2VPN customer service model contains the characteristics of = the service

as discussed between the operators and their customers. A = separate

process is responsible for mapping this customer service = model onto the

protocols and network elements depending on how the network = operator

chooses to realise the = service.

 

The deliverable from this working group will provide = information that

other working groups can use to evaluate the set of YANG = models that they

have already developed or that are under development. This = will help them

to identify any missing models or details. Thus, the = deliverable can be

viewed as driving requirements for service delivery models so = that the

customer service parameters can be mapped into inputs used by = the

protocol configuration = models.

 

The working group will learn from the experience of the L3SM = working

group and it is expected that the L2SM data model will have = similar

structure to the L3SM data model to enable benefits of common = code,

provide shared user experience, and leverage discussions that = took place

during the L3SM = development.

 

The working group should consider = draft-wen-l2sm-l2vpn-service-model as = a

starting point.

 

The working group will coordinate with other working groups = responsible

for L2VPN protocol work (most notably with BESS and PALS). It = will also

coordinate with other organizations working on related L2VPN = data models

(such as the MEF).

 

Milestones:

  Dec 2016 - Adopt WG draft for data = model

  Oct 2017 - Request publication of data model as = Standards Track RFC

  Dec 2017 - Close working = group

 

 

 

------=_NextPart_000_02BC_01D236DC.1FB66D80-- From Mike.Bartlett@metaswitch.com Mon Nov 7 04:02:10 2016 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FFB7129AC2 for ; Mon, 7 Nov 2016 04:02:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 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_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=metaswitch.com 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 RiGZFDEA_pMG for ; Mon, 7 Nov 2016 04:02:08 -0800 (PST) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0123.outbound.protection.outlook.com [104.47.34.123]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86EC412984C for ; Mon, 7 Nov 2016 04:02:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=metaswitch.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=XkVVCGDoeslERYBTQUKD2D8ydTI9J4ujkf5YSjw06os=; b=pdac8peqJTA6SejN76hGGMOngmB9DHAocl1sKxNe8DMZQIykF7QioHesk9/Ovpfti8Ml3vbKCaAtCK4rLKGumT1bWk1NvBdZhpTOpF/jN0wFh1shnORgOrzQBTAVVLj58z2uBIoy9wDQoMOht4TnUK2LILf8/gZ+L2NOOThbR6k= Received: from BN3PR0201MB1073.namprd02.prod.outlook.com (10.161.209.141) by BN3PR0201MB1075.namprd02.prod.outlook.com (10.161.209.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.707.6; Mon, 7 Nov 2016 12:02:07 +0000 Received: from BN3PR0201MB1073.namprd02.prod.outlook.com ([10.161.209.141]) by BN3PR0201MB1073.namprd02.prod.outlook.com ([10.161.209.141]) with mapi id 15.01.0707.006; Mon, 7 Nov 2016 12:02:07 +0000 From: Mike Bartlett To: "pals@ietf.org" Thread-Topic: Apparent inconsistency between RFC5061 and RFC4762 Thread-Index: AdI47eerQX3hiIEnSy+ntaQWxOz3CQ== Date: Mon, 7 Nov 2016 12:01:45 +0000 Deferred-Delivery: Mon, 7 Nov 2016 12:00:53 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Mike.Bartlett@metaswitch.com; x-originating-ip: [2620:104:4001:72:65eb:116c:2b97:4fe] x-ms-office365-filtering-correlation-id: fe7b01a0-e01a-42de-b09b-08d40705e565 x-microsoft-exchange-diagnostics: 1; BN3PR0201MB1075; 7:y8qYvqQZsQWfCsoTEWSxDtrrU94jGh6XMRsljm9bMwR7QSKbqSg1ZqjHB2jIzshd1fC4ohbmJOJHv2UnlMXmz7mAac8A+0mLkAdVXL/Bp9lxBzf6Epw5xJGNgjp8LM048LO912mCfYCUAA+9RqqXemzFxZc4fROJf/NGRHbx63vwyKGJ9+Nqq0u6qtVzfdvrNsObFMLZniIxnl851ueBlVGvtiKQ0Vk+m2uXs0euXwN8UWS98u5NePv4G6JoBO1ZSy2n9Phpri2ZVMsRRB3WbMrjcD0jtbnTEZ7O1d8363wkUUi6mzm0+tRfeWcJCf9vXNuO1hgNQ+kAFBGBLtQ2DXP2pZzRpFitNU22EsLseT4= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0201MB1075; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:BN3PR0201MB1075; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0201MB1075; x-forefront-prvs: 0119DC3B5E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(76104003)(189002)(199003)(2900100001)(5640700001)(11100500001)(229853001)(3280700002)(6666003)(107886002)(586003)(2351001)(10400500002)(92566002)(54356999)(50986999)(790700001)(101416001)(74316002)(6916009)(105586002)(189998001)(99286002)(7846002)(5660300001)(7736002)(110136003)(106356001)(6116002)(7696004)(102836003)(5630700001)(77096005)(16236675004)(5890100001)(19300405004)(8936002)(81166006)(81156014)(1730700003)(19625215002)(8676002)(5002640100001)(33656002)(19580395003)(3660700001)(19580405001)(450100001)(2906002)(68736007)(97736004)(9686002)(2501003)(76576001)(15975445007)(86362001)(122556002)(87936001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0201MB1075; H:BN3PR0201MB1073.namprd02.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: metaswitch.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN3PR0201MB10732D4090F5541CBEE50A8892A70BN3PR0201MB1073_" MIME-Version: 1.0 X-OriginatorOrg: metaswitch.com X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Nov 2016 12:02:06.8758 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9d9e56eb-f613-4ddb-b27b-bfcdf14b2cdb X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0201MB1075 Archived-At: Subject: [Pals] Apparent inconsistency between RFC5061 and RFC4762 X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2016 12:07:10 -0000 --_000_BN3PR0201MB10732D4090F5541CBEE50A8892A70BN3PR0201MB1073_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, It seems to me that there is an inconsistency between RFC5601 ("Pseudowire = MIB") and RFC4762 ("VPLS Using LDP Signaling"). I would like to hear peopl= e's views on whether this is indeed the case, or whether I have misundersto= od. Let's say I have 3 PEs "PE1", "PE2" and "PE3", with IP addresses 1.1.1., 2.= 2.2.2 and 3.3.3.3 respectively. I want to create a full-mesh VPLS service = with the pwTable specified in RFC5601, using the Generalized PWid FEC (i.e.= FEC type 129). The question is - how do I configure the 2 pwTable rows on= PE1? According to RFC4762, section 6.1.1, the AGI is the unique name of the VPLS= (e.g. "VPLS1"), and the TAII and SAII are both null. Attachment Group Identifier (AGI), Length, Value: The unique name of this VPLS. The AGI identifies a type of name, and Length denotes the length of Value, which is the name of the VPLS. We use the term AGI interchangeably with VPLS identifier. Target Attachment Individual Identifier (TAII), Source Attachment Individual Identifier (SAII): These are null because the mesh of PWs in a VPLS terminates on MAC learning tables, rather than on individual attachment circuits. The use of non-null TAII and SAII is reserved for future enhancements. This suggests that the pwTable configuration on PE1 should look like this: * pwIndex =3D 1, pwGroupAttachmentID =3D "VPLS1", pwLocalAttachment= ID =3D "", pwRemoteAttachmentID =3D "", pwPeerAddr =3D "2.2.2.2" * pwIndex =3D 2, pwGroupAttachmentID =3D "VPLS1", pwLocalAttachment= ID =3D "", pwRemoteAttachmentID =3D "", pwPeerAddr =3D "3.3.3.3" However, this contradicts RFC5601, specifically its definition in section 1= 2 of the reverse-lookup table pwGenFecIndexMappingTable, which states that = the {AGI, SAII, TAII} triplet must be unique for a PW using the generalized= PWid FEC (type 129). pwGenFecIndexMappingTable OBJECT-TYPE SYNTAX SEQUENCE OF PwGenFecIndexMappingEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table enables the reverse mapping of the unique PWid parameters [GroupAttachmentID, LocalAttachmentID, and PeerAttachmentID] and the pwIndex. The table is only applicable for PW using the generalized FEC." ::=3D { pwObjects 12 } Note that the corresponding reverse lookup table pwIndexMappingTable for ty= pe-128 FECs has a critical difference, in that it includes the peer IP Addr= ess as one of the unique PW identifiers: pwIndexMappingTable OBJECT-TYPE SYNTAX SEQUENCE OF PwIndexMappingEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table enables the reverse mapping of the unique PWid parameters [peer IP, PW type, and PW ID] and the pwIndex. The table is not applicable for PWs created manually or by using the generalized FEC." ::=3D { pwObjects 7 } It seems to me that pwGenFecIndexMappingTable should have the peer IP addre= ss as a 4th "unique PWid parameter". Otherwise, these parameters cannot un= iquely identify a PW that belongs to an RFC4762-compliant VPLS. Please let me know what you think. My apologies if this has already been d= iscussed before. Thanks, Mike Bartlett mike.bartlett@metaswitch.com --_000_BN3PR0201MB10732D4090F5541CBEE50A8892A70BN3PR0201MB1073_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All,

 

It seems to me that there is an inconsiste= ncy between RFC5601 (“Pseudowire MIB”) and RFC4762 (“VPLS= Using LDP Signaling”).  I would like to hear people’s vie= ws on whether this is indeed the case, or whether I have misunderstood.

 

Let’s say I have 3 PEs “PE1= 221;, “PE2” and “PE3”, with IP addresses 1.1.1., 2.= 2.2.2 and 3.3.3.3 respectively.  I want to create a full-mesh VPLS ser= vice with the pwTable specified in RFC5601, using the Generalized PWid FEC (i.e. FEC type 129).&= nbsp; The question is – how do I configure the 2 pwTable rows on PE1?=

 

According to RFC4762, section 6.1.1, the A= GI is the unique name of the VPLS (e.g. “VPLS1”), and the TAII = and SAII are both null. 

 

   Attachment Group Identifier (AGI),= Length, Value: The unique name of

   this VPLS.  The AGI identifie= s a type of name, and Length denotes the

   length of Value, which is the name= of the VPLS.  We use the term AGI

   interchangeably with VPLS identifi= er.

 

   Target Attachment Individual Ident= ifier (TAII), Source Attachment

   Individual Identifier (SAII): Thes= e are null because the mesh of PWs

   in a VPLS terminates on MAC learni= ng tables, rather than on

   individual attachment circuits.&nb= sp; The use of non-null TAII and SAII is

   reserved for future enhancements.<= o:p>

 

This suggests that the pwTable configurati= on on PE1 should look like this:

 

·       &nbs= p; pwIndex =3D 1, pwGroupAttachmentID= =3D “VPLS1”, pwLocalAttachmentID =3D “”, pwRemoteA= ttachmentID =3D “”, pwPeerAddr =3D “2.2.2.2”

·       &nbs= p; pwIndex =3D 2, pwGroupAttachmentID= =3D “VPLS1”, pwLocalAttachmentID =3D “”, pwRemoteA= ttachmentID =3D “”, pwPeerAddr =3D “3.3.3.3”

 

However, this contradicts RFC5601, specifi= cally its definition in section 12 of the reverse-lookup table pwGenFecInde= xMappingTable, which states that the {AGI, SAII, TAII} triplet must be unique for a PW using the generalized PWid FEC (type= 129).

 

  pwGenFecIndexMappingTable  OBJ= ECT-TYPE

     SYNTAX   &nb= sp;    SEQUENCE OF PwGenFecIndexMappingEntry=

     MAX-ACCESS  =   not-accessible

     STATUS  &nbs= p;     current

     DESCRIPTION=

        = ;  "This table enables the reverse mapping of the unique

        = ;   PWid parameters [GroupAttachmentID, LocalAttachmentID,

        &nbs= p;  and PeerAttachmentID] and the pwIndex.  The table is

        = ;   only applicable for PW using the generalized FEC."<= /o:p>

     ::=3D { pwObjects 12 }=

 

Note that the corresponding reverse lookup= table pwIndexMappingTable for type-128 FECs has a critical difference, in = that it includes the peer IP Address as one of the unique PW identifiers:

 

  pwIndexMappingTable  OBJECT-TYPE

     SYNTAX  &nbs= p;     SEQUENCE OF PwIndexMappingEntry

     MAX-ACCESS  =   not-accessible

     STATUS  &nbs= p;     current

     DESCRIPTION=

        = ;  "This table enables the reverse mapping of the unique

        = ;   PWid parameters [peer IP, PW type, and PW ID] and the

        = ;   pwIndex.  The table is not applicable for PWs created

        = ;   manually or by using the generalized FEC."

     ::=3D { pwObjects 7 }<= o:p>

 

It seems to me that pwGenFecIndexMappingTa= ble should have the peer IP address as a 4th “unique PWid = parameter”.  Otherwise, these parameters cannot uniquely identify a PW that belongs to an RFC4762-compliant VPLS.=

 

Please let me know what you think.  M= y apologies if this has already been discussed before.

 

Thanks,

 

Mike Bartlett mike.bartlett@metaswitch.com=

 

--_000_BN3PR0201MB10732D4090F5541CBEE50A8892A70BN3PR0201MB1073_-- From nobody Tue Nov 8 04:05:29 2016 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C71DE126FDC; Tue, 8 Nov 2016 04:05:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 aM8EY-tKan0w; Tue, 8 Nov 2016 04:05:18 -0800 (PST) Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57276129556; Tue, 8 Nov 2016 04:05:18 -0800 (PST) Received: by mail-yw0-x22f.google.com with SMTP id r204so172187601ywb.0; Tue, 08 Nov 2016 04:05:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=cFyew3okzbivjHg1LIk5Vcx1kVLBXIchCO2IIRWfcV0=; b=rm6mMyinMAgc7PGFtveJiHHOwC4JCa3SMFN4/YMoZuCDbORAaZam1MwmP7Do69+YeN NyDngObRyVd0ZAXTZJP9Dk0XcZuewldiN00pVr1sPCMZw/Ra1QT2Boh+lnyxVeRWXLqd XBfE6QUVMEQUleEnkAJP8Hw2IXBdz5QiiRBQisA1l5ozBpzI5qXV1EJQ5TFJJc5BGjx3 /tIIo6e+hbmhTaqKbrVSv99DRkYeAHrLXvMu11VdpO5MkVcZZqGBIWMm6zTLluSp9AQI jgAc68Zu3IVBQVo+pYo2HoxcS4RheCtQC5S/q5u0OkxOJ4MhPD3119wA5pXAidtYlvlW hoOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=cFyew3okzbivjHg1LIk5Vcx1kVLBXIchCO2IIRWfcV0=; b=dhrvQpa46FD/KVm/ZC/dGx8X+Ka8qhSUrwuDDbormbfWIDVeWSAyr8mI3CmlERDzAY 9oBUYS1ANTjDqQErPusCBTLszot9oMeCq0lTHKlG6XgRZxk/VEetXUhpY++Q64Sxs/fn kCNyDsOrpXF78xLwODWQbHGSx+Plp2vyw5oxSdSI4t1B/HPNKbOq7EePv2/wLg8W8owW NE5YYHdMlxRtIEGomcEkF9Iu8z/Nlya97GrsxI1OubbJtLcRuBC5Z0S10ZIs/dG+rSUL t4CrGl5PTiixaAh7MNN0Z+p2um3MtMc82lo1wYzd705RsB64l/lref4d/w4ACGQW5HxN LP3w== X-Gm-Message-State: ABUngveUZXAGg7AEZdTU+BpxkLRZEiRbbz4YBwjVJ1PVuDPAyyL2HBtAuatktnhW0FThxz8W9PGw6kUEilN+bA== X-Received: by 10.157.45.166 with SMTP id g35mr540844otb.223.1478606717599; Tue, 08 Nov 2016 04:05:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.150.42 with HTTP; Tue, 8 Nov 2016 04:04:57 -0800 (PST) In-Reply-To: References: From: "Andrew G. Malis" Date: Tue, 8 Nov 2016 07:04:57 -0500 Message-ID: To: Mike Bartlett Content-Type: multipart/alternative; boundary=94eb2c04e9302a434c0540c8f4b1 Archived-At: Cc: "l2vpn@ietf.org" , "pals@ietf.org" Subject: Re: [Pals] Apparent inconsistency between RFC5061 and RFC4762 X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2016 12:05:25 -0000 --94eb2c04e9302a434c0540c8f4b1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Mike, Thanks for the report. I think everyone is busy on IETF prep this week (I know I am :-) but we=E2=80=99ll remind people of your email if there aren= =E2=80=99t any replies in a bit. I=E2=80=99m also going to forward it to the old l2vpn lis= t. Cheers, Andy On Mon, Nov 7, 2016 at 7:01 AM, Mike Bartlett wrote: > All, > > > > It seems to me that there is an inconsistency between RFC5601 (=E2=80=9CP= seudowire > MIB=E2=80=9D) and RFC4762 (=E2=80=9CVPLS Using LDP Signaling=E2=80=9D). = I would like to hear > people=E2=80=99s views on whether this is indeed the case, or whether I h= ave > misunderstood. > > > > Let=E2=80=99s say I have 3 PEs =E2=80=9CPE1=E2=80=9D, =E2=80=9CPE2=E2=80= =9D and =E2=80=9CPE3=E2=80=9D, with IP addresses 1.1.1., > 2.2.2.2 and 3.3.3.3 respectively. I want to create a full-mesh VPLS > service with the pwTable specified in RFC5601, using the Generalized PWid > FEC (i.e. FEC type 129). The question is =E2=80=93 how do I configure th= e 2 > pwTable rows on PE1? > > > > According to RFC4762, section 6.1.1, the AGI is the unique name of the > VPLS (e.g. =E2=80=9CVPLS1=E2=80=9D), and the TAII and SAII are both null. > > > > Attachment Group Identifier (AGI), Length, Value: The unique name of > > this VPLS. The AGI identifies a type of name, and Length denotes the > > length of Value, which is the name of the VPLS. We use the term AGI > > interchangeably with VPLS identifier. > > > > Target Attachment Individual Identifier (TAII), Source Attachment > > Individual Identifier (SAII): These are null because the mesh of PWs > > in a VPLS terminates on MAC learning tables, rather than on > > individual attachment circuits. The use of non-null TAII and SAII is > > reserved for future enhancements. > > > > This suggests that the pwTable configuration on PE1 should look like this= : > > > > =C2=B7 pwIndex =3D 1, pwGroupAttachmentID =3D =E2=80=9CVPLS1=E2= =80=9D, pwLocalAttachmentID > =3D =E2=80=9C=E2=80=9D, pwRemoteAttachmentID =3D =E2=80=9C=E2=80=9D, pwPe= erAddr =3D =E2=80=9C2.2.2.2=E2=80=9D > > =C2=B7 pwIndex =3D 2, pwGroupAttachmentID =3D =E2=80=9CVPLS1=E2= =80=9D, pwLocalAttachmentID > =3D =E2=80=9C=E2=80=9D, pwRemoteAttachmentID =3D =E2=80=9C=E2=80=9D, pwPe= erAddr =3D =E2=80=9C3.3.3.3=E2=80=9D > > > > However, this contradicts RFC5601, specifically its definition in section > 12 of the reverse-lookup table pwGenFecIndexMappingTable, which states th= at > the {AGI, SAII, TAII} triplet must be unique for a PW using the generaliz= ed > PWid FEC (type 129). > > > > pwGenFecIndexMappingTable OBJECT-TYPE > > SYNTAX SEQUENCE OF PwGenFecIndexMappingEntry > > MAX-ACCESS not-accessible > > STATUS current > > DESCRIPTION > > "This table enables the reverse mapping of the unique > > PWid parameters [GroupAttachmentID, LocalAttachmentID, > > and PeerAttachmentID] and the pwIndex. The table is > > only applicable for PW using the generalized FEC." > > ::=3D { pwObjects 12 } > > > > Note that the corresponding reverse lookup table pwIndexMappingTable for > type-128 FECs has a critical difference, in that it includes the peer IP > Address as one of the unique PW identifiers: > > > > pwIndexMappingTable OBJECT-TYPE > > SYNTAX SEQUENCE OF PwIndexMappingEntry > > MAX-ACCESS not-accessible > > STATUS current > > DESCRIPTION > > "This table enables the reverse mapping of the unique > > PWid parameters [peer IP, PW type, and PW ID] and the > > pwIndex. The table is not applicable for PWs created > > manually or by using the generalized FEC." > > ::=3D { pwObjects 7 } > > > > It seems to me that pwGenFecIndexMappingTable should have the peer IP > address as a 4th =E2=80=9Cunique PWid parameter=E2=80=9D. Otherwise, the= se parameters > cannot uniquely identify a PW that belongs to an RFC4762-compliant VPLS. > > > > Please let me know what you think. My apologies if this has already been > discussed before. > > > > Thanks, > > > > Mike Bartlett > *mike.bartlett@metaswitch.com* > > > > _______________________________________________ > Pals mailing list > Pals@ietf.org > https://www.ietf.org/mailman/listinfo/pals > > --94eb2c04e9302a434c0540c8f4b1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Mike,

Thanks for the report. I think ev= eryone is busy on IETF prep this week (I know I am :-) but we=E2=80=99ll re= mind people of your email if there aren=E2=80=99t any replies in a bit. I= =E2=80=99m also going to forward it to the old l2vpn list.

Cheers,
Andy


On Mon, Nov 7, 2016 at 7:01 AM, Mi= ke Bartlett <Mike.Bartlett@metaswitch.com> wrote:=

All,

=C2=A0

It seems to me that there is an inconsiste= ncy between RFC5601 (=E2=80=9CPseudowire MIB=E2=80=9D) and RFC4762 (=E2=80= =9CVPLS Using LDP Signaling=E2=80=9D).=C2=A0 I would like to hear people=E2= =80=99s views on whether this is indeed the case, or whether I have misunderstood.

=C2=A0

Let=E2=80=99s say I have 3 PEs =E2=80=9CPE= 1=E2=80=9D, =E2=80=9CPE2=E2=80=9D and =E2=80=9CPE3=E2=80=9D, with IP addres= ses 1.1.1., 2.2.2.2 and 3.3.3.3 respectively.=C2=A0 I want to create a full= -mesh VPLS service with the pwTable specified in RFC5601, using the Generalized PWid FEC (i.e. FEC type 129).= =C2=A0 The question is =E2=80=93 how do I configure the 2 pwTable rows on P= E1?

=C2=A0

According to RFC4762, section 6.1.1, the A= GI is the unique name of the VPLS (e.g. =E2=80=9CVPLS1=E2=80=9D), and the T= AII and SAII are both null.=C2=A0

=C2=A0

=C2=A0=C2=A0 Attachment Group Identifier (AGI),= Length, Value: The unique name of

=C2=A0=C2=A0 this VPLS.=C2=A0 The AGI identifie= s a type of name, and Length denotes the

=C2=A0=C2=A0 length of Value, which is the name= of the VPLS.=C2=A0 We use the term AGI

=C2=A0=C2=A0 interchangeably with VPLS identifi= er.

=C2=A0

=C2=A0=C2=A0 Target Attachment Individual Ident= ifier (TAII), Source Attachment

=C2=A0=C2=A0 Individual Identifier (SAII): Thes= e are null because the mesh of PWs

=C2=A0=C2=A0 in a VPLS terminates on MAC learni= ng tables, rather than on

=C2=A0=C2=A0 individual attachment circuits.=C2= =A0 The use of non-null TAII and SAII is

=C2=A0=C2=A0 reserved for future enhancements.<= u>

=C2=A0

This suggests that the pwTable configurati= on on PE1 should look like this:

=C2=A0

=C2=B7=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 pwIndex =3D 1, pwGroupAttachmentID = =3D =E2=80=9CVPLS1=E2=80=9D, pwLocalAttachmentID =3D =E2=80=9C=E2=80=9D, pw= RemoteAttachmentID =3D =E2=80=9C=E2=80=9D, pwPeerAddr =3D =E2=80=9C2.2.2.2= =E2=80=9D

=C2=B7=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 pwIndex =3D 2, pwGroupAttachmentID = =3D =E2=80=9CVPLS1=E2=80=9D, pwLocalAttachmentID =3D =E2=80=9C=E2=80=9D, pw= RemoteAttachmentID =3D =E2=80=9C=E2=80=9D, pwPeerAddr =3D =E2=80=9C3.3.3.3= =E2=80=9D

=C2=A0

However, this contradicts RFC5601, specifi= cally its definition in section 12 of the reverse-lookup table pwGenFecInde= xMappingTable, which states that the {AGI, SAII, TAII} triplet must be unique for a PW using the generalized PWid FEC (type= 129).

=C2=A0

=C2=A0=C2=A0pwGenFecIndexMappingTable=C2=A0 OBJ= ECT-TYPE

=C2=A0=C2=A0=C2=A0=C2=A0 SYNTAX=C2=A0=C2=A0 =C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0SEQUENCE OF PwGenFecIndexMappingEntry<= /u>

=C2=A0=C2=A0=C2=A0=C2=A0 MAX-ACCESS=C2=A0=C2=A0= =C2=A0 not-accessible

=C2=A0=C2=A0=C2=A0=C2=A0 STATUS=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 current

=C2=A0=C2=A0=C2=A0=C2=A0 DESCRIPTION<= /u>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 "This table enables the reverse mapping of the unique=

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 PWid parameters [GroupAttachmentID, LocalAttachmentID,

=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0and PeerAttachmentID] and the pwIndex.=C2=A0 The table is=

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 only applicable for PW using the generalized FEC."<= /u>

=C2=A0=C2=A0=C2=A0=C2=A0 ::=3D { pwObjects 12 }=

=C2=A0

Note that the corresponding reverse lookup= table pwIndexMappingTable for type-128 FECs has a critical difference, in = that it includes the peer IP Address as one of the unique PW identifiers:

=C2=A0

=C2=A0 pwIndexMappingTable=C2=A0 OBJECT-TYPE=

=C2=A0=C2=A0=C2=A0=C2=A0 SYNTAX=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 SEQUENCE OF PwIndexMappingEntry

=C2=A0=C2=A0=C2=A0=C2=A0 MAX-ACCESS=C2=A0=C2=A0= =C2=A0 not-accessible

=C2=A0=C2=A0=C2=A0=C2=A0 STATUS=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 current

=C2=A0=C2=A0=C2=A0=C2=A0 DESCRIPTION<= /u>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 "This table enables the reverse mapping of the unique=

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 PWid parameters [peer IP, PW type, and PW ID] and the

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 pwIndex.=C2=A0 The table is not applicable for PWs created<= u>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 manually or by using the generalized FEC."

=C2=A0=C2=A0=C2=A0=C2=A0 ::=3D { pwObjects 7 }<= u>

=C2=A0

It seems to me that pwGenFecIndexMappingTa= ble should have the peer IP address as a 4th =E2=80=9Cunique PWi= d parameter=E2=80=9D.=C2=A0 Otherwise, these parameters cannot uniquely identify a PW that belongs to an RFC4762-compliant VPLS.

=C2=A0

Please let me know what you think.=C2=A0 M= y apologies if this has already been discussed before.=

=C2=A0

Thanks,

=C2=A0

Mike Bartlett
mike.bartlett@metaswitch.com

=C2=A0


_______________________________________________
Pals mailing list
Pals@ietf.org
https://www.ietf.org/mailman/listinfo/pals


--94eb2c04e9302a434c0540c8f4b1-- From nobody Tue Nov 8 04:11:02 2016 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A9AB129613; Tue, 8 Nov 2016 04:10:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 jDTwelKaOG2r; Tue, 8 Nov 2016 04:10:55 -0800 (PST) Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B327812985C; Tue, 8 Nov 2016 04:10:55 -0800 (PST) Received: by mail-yw0-x22e.google.com with SMTP id l124so170196211ywb.3; Tue, 08 Nov 2016 04:10:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=DfnE72GZoFGjJh1cIm+x+GTSBRn2vjZ52AkOU9o9YZU=; b=C1sELwDphhRBo4gR9TidS84ZBpxsVO/QKDAWrHrloWGZWBZsk9xYWFng5snxKY8TcD HaWSjqIcNp3kyeJYp2je6mOseP7NBtjgeDmj7QfTyCkMkBgCtxwLKaK9xv7w8fPGLnVQ O0L+/IVj51BPmHYK1iNccl8fTeJtAOiYJxXNKj6LgWHOCTkAVlfdufx4VZtmuUjBKiFJ a1B0REAjlZzrG4RuuIjzzX0tNxdgDI5TYF7FSGcVRGgazGTBML101j8IR+tHG3fvbRVE ukHfNUuIX3kBVoAdTxmhIzlOF5B8d1M4jfATe7jQZbljvvXE6owRoknob+5aBNkstm3J yWhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=DfnE72GZoFGjJh1cIm+x+GTSBRn2vjZ52AkOU9o9YZU=; b=fgdj+QYuCfac3V/zlA7MltTpItUNjsQpqUuJ4Ud5Ze++foBLBW4xRxOAl4aT8HWMn8 7Lo5P8M9GSxNYQd2096BffjKMnKr3QFvmtAbTq2FJASaUWbvjWgNGz+kD6+kKMFHWAkf yQbJzolyprsId+qFUHgYkIjk/odiJMKa1a27fsVmL8F4x5v7gQOrPLQ04xxaQe9PckUE jnMdhHuCzX3uGNaQJ2NEZqiP8JJ6DwB7D/OoO0bd5mMVqi6UTYqqncypH9jX4W/ps4Hc fND8LwOL7g/Jk6ERaTrEA7LkbD8uh5+zk+c6sbskwywk4xaj9kPRs6QWc2ucEEVSIxmh loAQ== X-Gm-Message-State: ABUngvc/H6Ezgf9AQAt52lY7yfBzWRlEuvf6irotbP0A3oMZ0qETCMRkFWofJ7Vgs1e1XNnpycza9WWRR95npQ== X-Received: by 10.157.16.70 with SMTP id o6mr5617060oto.101.1478607054908; Tue, 08 Nov 2016 04:10:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.150.42 with HTTP; Tue, 8 Nov 2016 04:10:34 -0800 (PST) From: "Andrew G. Malis" Date: Tue, 8 Nov 2016 07:10:34 -0500 Message-ID: To: "pals@ietf.org" , "l2vpn@ietf.org" Content-Type: multipart/alternative; boundary=001a11413ccc4532d80540c908c2 Archived-At: Subject: [Pals] To the attention of PW MIB and/or VPLS configuration experts out there ... X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2016 12:10:58 -0000 --001a11413ccc4532d80540c908c2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable In case you missed this email on the PALS list ... ---------- Forwarded message ---------- From: Mike Bartlett Date: Mon, Nov 7, 2016 at 7:01 AM Subject: [Pals] Apparent inconsistency between RFC5061 and RFC4762 To: "pals@ietf.org" All, It seems to me that there is an inconsistency between RFC5601 (=E2=80=9CPse= udowire MIB=E2=80=9D) and RFC4762 (=E2=80=9CVPLS Using LDP Signaling=E2=80=9D). I = would like to hear people=E2=80=99s views on whether this is indeed the case, or whether I hav= e misunderstood. Let=E2=80=99s say I have 3 PEs =E2=80=9CPE1=E2=80=9D, =E2=80=9CPE2=E2=80=9D= and =E2=80=9CPE3=E2=80=9D, with IP addresses 1.1.1., 2.2.2.2 and 3.3.3.3 respectively. I want to create a full-mesh VPLS service with the pwTable specified in RFC5601, using the Generalized PWid FEC (i.e. FEC type 129). The question is =E2=80=93 how do I configure the = 2 pwTable rows on PE1? According to RFC4762, section 6.1.1, the AGI is the unique name of the VPLS (e.g. =E2=80=9CVPLS1=E2=80=9D), and the TAII and SAII are both null. Attachment Group Identifier (AGI), Length, Value: The unique name of this VPLS. The AGI identifies a type of name, and Length denotes the length of Value, which is the name of the VPLS. We use the term AGI interchangeably with VPLS identifier. Target Attachment Individual Identifier (TAII), Source Attachment Individual Identifier (SAII): These are null because the mesh of PWs in a VPLS terminates on MAC learning tables, rather than on individual attachment circuits. The use of non-null TAII and SAII is reserved for future enhancements. This suggests that the pwTable configuration on PE1 should look like this: =C2=B7 pwIndex =3D 1, pwGroupAttachmentID =3D =E2=80=9CVPLS1=E2=80= =9D, pwLocalAttachmentID =3D =E2=80=9C=E2=80=9D, pwRemoteAttachmentID =3D =E2=80=9C=E2=80=9D, pwPeerAddr= =3D =E2=80=9C2.2.2.2=E2=80=9D =C2=B7 pwIndex =3D 2, pwGroupAttachmentID =3D =E2=80=9CVPLS1=E2=80= =9D, pwLocalAttachmentID =3D =E2=80=9C=E2=80=9D, pwRemoteAttachmentID =3D =E2=80=9C=E2=80=9D, pwPeerAddr= =3D =E2=80=9C3.3.3.3=E2=80=9D However, this contradicts RFC5601, specifically its definition in section 12 of the reverse-lookup table pwGenFecIndexMappingTable, which states that the {AGI, SAII, TAII} triplet must be unique for a PW using the generalized PWid FEC (type 129). pwGenFecIndexMappingTable OBJECT-TYPE SYNTAX SEQUENCE OF PwGenFecIndexMappingEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table enables the reverse mapping of the unique PWid parameters [GroupAttachmentID, LocalAttachmentID, and PeerAttachmentID] and the pwIndex. The table is only applicable for PW using the generalized FEC." ::=3D { pwObjects 12 } Note that the corresponding reverse lookup table pwIndexMappingTable for type-128 FECs has a critical difference, in that it includes the peer IP Address as one of the unique PW identifiers: pwIndexMappingTable OBJECT-TYPE SYNTAX SEQUENCE OF PwIndexMappingEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table enables the reverse mapping of the unique PWid parameters [peer IP, PW type, and PW ID] and the pwIndex. The table is not applicable for PWs created manually or by using the generalized FEC." ::=3D { pwObjects 7 } It seems to me that pwGenFecIndexMappingTable should have the peer IP address as a 4th =E2=80=9Cunique PWid parameter=E2=80=9D. Otherwise, these= parameters cannot uniquely identify a PW that belongs to an RFC4762-compliant VPLS. Please let me know what you think. My apologies if this has already been discussed before. Thanks, Mike Bartlett *mike.bartlett@metaswitch.com* _______________________________________________ Pals mailing list Pals@ietf.org https://www.ietf.org/mailman/listinfo/pals --001a11413ccc4532d80540c908c2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
In case you missed this email on the PALS list ...

---------- Forwarded message -= ---------
From: Mike Bartlett <Mike.Bartlett= @metaswitch.com>
Date: Mon, Nov 7, 2016 at 7:01 AM
Subj= ect: [Pals] Apparent inconsistency between RFC5061 and RFC4762
To: "= ;pals@ietf.org" <pals@ietf.org>

All,

=C2=A0

It seems to me that there is an inconsiste= ncy between RFC5601 (=E2=80=9CPseudowire MIB=E2=80=9D) and RFC4762 (=E2=80= =9CVPLS Using LDP Signaling=E2=80=9D).=C2=A0 I would like to hear people=E2= =80=99s views on whether this is indeed the case, or whether I have misunderstood.

=C2=A0

Let=E2=80=99s say I have 3 PEs =E2=80=9CPE= 1=E2=80=9D, =E2=80=9CPE2=E2=80=9D and =E2=80=9CPE3=E2=80=9D, with IP addres= ses 1.1.1., 2.2.2.2 and 3.3.3.3 respectively.=C2=A0 I want to create a full= -mesh VPLS service with the pwTable specified in RFC5601, using the Generalized PWid FEC (i.e. FEC type 129).= =C2=A0 The question is =E2=80=93 how do I configure the 2 pwTable rows on P= E1?

=C2=A0

According to RFC4762, section 6.1.1, the A= GI is the unique name of the VPLS (e.g. =E2=80=9CVPLS1=E2=80=9D), and the T= AII and SAII are both null.=C2=A0

=C2=A0

=C2=A0=C2=A0 Attachment Group Identifier (AGI),= Length, Value: The unique name of

=C2=A0=C2=A0 this VPLS.=C2=A0 The AGI identifie= s a type of name, and Length denotes the

=C2=A0=C2=A0 length of Value, which is the name= of the VPLS.=C2=A0 We use the term AGI

=C2=A0=C2=A0 interchangeably with VPLS identifi= er.

=C2=A0

=C2=A0=C2=A0 Target Attachment Individual Ident= ifier (TAII), Source Attachment

=C2=A0=C2=A0 Individual Identifier (SAII): Thes= e are null because the mesh of PWs

=C2=A0=C2=A0 in a VPLS terminates on MAC learni= ng tables, rather than on

=C2=A0=C2=A0 individual attachment circuits.=C2= =A0 The use of non-null TAII and SAII is

=C2=A0=C2=A0 reserved for future enhancements.<= u>

=C2=A0

This suggests that the pwTable configurati= on on PE1 should look like this:

=C2=A0

=C2=B7=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 pwIndex =3D 1, pwGroupAttachmentID = =3D =E2=80=9CVPLS1=E2=80=9D, pwLocalAttachmentID =3D =E2=80=9C=E2=80=9D, pw= RemoteAttachmentID =3D =E2=80=9C=E2=80=9D, pwPeerAddr =3D =E2=80=9C2.2.2.2= =E2=80=9D

=C2=B7=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 pwIndex =3D 2, pwGroupAttachmentID = =3D =E2=80=9CVPLS1=E2=80=9D, pwLocalAttachmentID =3D =E2=80=9C=E2=80=9D, pw= RemoteAttachmentID =3D =E2=80=9C=E2=80=9D, pwPeerAddr =3D =E2=80=9C3.3.3.3= =E2=80=9D

=C2=A0

However, this contradicts RFC5601, specifi= cally its definition in section 12 of the reverse-lookup table pwGenFecInde= xMappingTable, which states that the {AGI, SAII, TAII} triplet must be unique for a PW using the generalized PWid FEC (type= 129).

=C2=A0

=C2=A0=C2=A0pwGenFecIndexMappingTable=C2=A0 OBJ= ECT-TYPE

=C2=A0=C2=A0=C2=A0=C2=A0 SYNTAX=C2=A0=C2=A0 =C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0SEQUENCE OF PwGenFecIndexMappingEntry<= /u>

=C2=A0=C2=A0=C2=A0=C2=A0 MAX-ACCESS=C2=A0=C2=A0= =C2=A0 not-accessible

=C2=A0=C2=A0=C2=A0=C2=A0 STATUS=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 current

=C2=A0=C2=A0=C2=A0=C2=A0 DESCRIPTION<= /u>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 "This table enables the reverse mapping of the unique=

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 PWid parameters [GroupAttachmentID, LocalAttachmentID,

=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0and PeerAttachmentID] and the pwIndex.=C2=A0 The table is=

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 only applicable for PW using the generalized FEC."<= /u>

=C2=A0=C2=A0=C2=A0=C2=A0 ::=3D { pwObjects 12 }=

=C2=A0

Note that the corresponding reverse lookup= table pwIndexMappingTable for type-128 FECs has a critical difference, in = that it includes the peer IP Address as one of the unique PW identifiers:

=C2=A0

=C2=A0 pwIndexMappingTable=C2=A0 OBJECT-TYPE=

=C2=A0=C2=A0=C2=A0=C2=A0 SYNTAX=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 SEQUENCE OF PwIndexMappingEntry

=C2=A0=C2=A0=C2=A0=C2=A0 MAX-ACCESS=C2=A0=C2=A0= =C2=A0 not-accessible

=C2=A0=C2=A0=C2=A0=C2=A0 STATUS=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 current

=C2=A0=C2=A0=C2=A0=C2=A0 DESCRIPTION<= /u>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 "This table enables the reverse mapping of the unique=

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 PWid parameters [peer IP, PW type, and PW ID] and the

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 pwIndex.=C2=A0 The table is not applicable for PWs created<= u>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 manually or by using the generalized FEC."

=C2=A0=C2=A0=C2=A0=C2=A0 ::=3D { pwObjects 7 }<= u>

=C2=A0

It seems to me that pwGenFecIndexMappingTa= ble should have the peer IP address as a 4th =E2=80=9Cunique PWi= d parameter=E2=80=9D.=C2=A0 Otherwise, these parameters cannot uniquely identify a PW that belongs to an RFC4762-compliant VPLS.

=C2=A0

Please let me know what you think.=C2=A0 M= y apologies if this has already been discussed before.=

=C2=A0

Thanks,

=C2=A0

Mike Bartlett
mike.bartlett@metaswitch.com

=C2=A0


_______________________________________________
Pals mailing list
Pals@ietf.org
https://www.ietf.org/mailman/listinfo/pals


--001a11413ccc4532d80540c908c2-- From nobody Tue Nov 8 10:57:38 2016 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 984B9129D91; Tue, 8 Nov 2016 10:57:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 EgZgnyXy726k; Tue, 8 Nov 2016 10:57:34 -0800 (PST) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97F6D12965E; Tue, 8 Nov 2016 10:57:33 -0800 (PST) Received: by mail-wm0-x235.google.com with SMTP id a197so264242465wmd.0; Tue, 08 Nov 2016 10:57:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=i6U3v5BoEa5A8qb7BMLBthr5BuEQX3hb+k17zU9/wT4=; b=wBVR20HSJ55W2/IMeCxiGSLfBZW3CN/bM4piLsIJcYE/ZfSGcjXmNj8H8BczxCuAC8 n3Uv1rpmkBu7juIkKH5mNfHM3NNtGzIOs6M9iwXqWzE9JiGNsJnlBDXs12KSZeAR76OA Sl72mGlxisr5NIxE3m7QZjVs1kCJKF1XoXjLFdXXbKfkqGiYDWKy9zqow/IcH8s3in0D QGPkqF1HZ0l7GvJmNyAynWkbRIJm6c5UmoWrBdj6gHOrdwb3wD0txCtmhPlVN9Xs5wN2 yOOyPxA3rFga2wj147TlGtN1wFwTJZwlKEiwXVJvaXm7G26I85pPvcP7PeZMu/tfonKy JWfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=i6U3v5BoEa5A8qb7BMLBthr5BuEQX3hb+k17zU9/wT4=; b=XpPNOqZDHxqGoO1aAJnwDcgizT/3g9vxDZX3iMueprM2Nf3X194l8L+VeveGGNRJBo MgNPzWLWOv9X5cJAAjx0Uo6IVhNlb8yKKav6rmK5me6lDuB+npSNamOJ14xOKqRMnbTU U8wkMaHNXOtCGSXfVfzFwrrH3uB72x7kdhYm/Pb4jMO6YN9LzqpVZEr8Q0+hLEZ87Sts WkgRjFEKLe6wbNpydgQ/BVWkhPkeUw8Cn0CvqjcuZtBmRaMEAhn1CmZBhLQXFydiZLR4 xNmAVOezc42RAWdDDGtJAyBOWHM5Kg7FKbuJ1QPf+V6KLJLNAlyxfyPsRI70C1QF3H+b xy+g== X-Gm-Message-State: ABUngveak/UsscZpjc0knysTOQ/9o9EalsK1Qmd4qYUvjZzFD4IKep84hFxk3ImtFMUpvQ== X-Received: by 10.194.222.105 with SMTP id ql9mr13809441wjc.63.1478631452084; Tue, 08 Nov 2016 10:57:32 -0800 (PST) Received: from ams-giheron-8915.cisco.com ([173.38.220.41]) by smtp.gmail.com with ESMTPSA id g17sm38633003wjs.38.2016.11.08.10.57.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 08 Nov 2016 10:57:31 -0800 (PST) From: Giles Heron Message-Id: <3337AFD2-754D-4E22-A752-400F5D4CEA35@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_061AAA05-EB2A-4359-9DF8-8C5021EA3FF3" Mime-Version: 1.0 (Mac OS X Mail 10.0 \(3226\)) Date: Tue, 8 Nov 2016 18:57:29 +0000 In-Reply-To: To: "Andrew G. Malis" References: X-Mailer: Apple Mail (2.3226) Archived-At: Cc: "l2vpn@ietf.org" , Nadeau Thomas , david.zelig@compassnetworks.com, "pals@ietf.org" Subject: Re: [Pals] To the attention of PW MIB and/or VPLS configuration experts out there ... X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2016 18:57:36 -0000 --Apple-Mail=_061AAA05-EB2A-4359-9DF8-8C5021EA3FF3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Looks like a bug in the MIB to me. Tom/David were the authors so I=E2=80=99= ll leave it to them to respond (am guessing here at David=E2=80=99s = email), but might be worth raising an erratum. > On 8 Nov 2016, at 12:10, Andrew G. Malis wrote: >=20 > In case you missed this email on the PALS list ... >=20 > ---------- Forwarded message ---------- > From: Mike Bartlett > > Date: Mon, Nov 7, 2016 at 7:01 AM > Subject: [Pals] Apparent inconsistency between RFC5061 and RFC4762 > To: "pals@ietf.org " > >=20 > All, >=20 > =20 >=20 > It seems to me that there is an inconsistency between RFC5601 = (=E2=80=9CPseudowire MIB=E2=80=9D) and RFC4762 (=E2=80=9CVPLS Using LDP = Signaling=E2=80=9D). I would like to hear people=E2=80=99s views on = whether this is indeed the case, or whether I have misunderstood. >=20 > =20 >=20 > Let=E2=80=99s say I have 3 PEs =E2=80=9CPE1=E2=80=9D, =E2=80=9CPE2=E2=80= =9D and =E2=80=9CPE3=E2=80=9D, with IP addresses 1.1.1., 2.2.2.2 and = 3.3.3.3 respectively. I want to create a full-mesh VPLS service with = the pwTable specified in RFC5601, using the Generalized PWid FEC (i.e. = FEC type 129). The question is =E2=80=93 how do I configure the 2 = pwTable rows on PE1? >=20 > =20 >=20 > According to RFC4762, section 6.1.1, the AGI is the unique name of the = VPLS (e.g. =E2=80=9CVPLS1=E2=80=9D), and the TAII and SAII are both = null.=20 >=20 > =20 >=20 > Attachment Group Identifier (AGI), Length, Value: The unique name = of >=20 > this VPLS. The AGI identifies a type of name, and Length denotes = the >=20 > length of Value, which is the name of the VPLS. We use the term = AGI >=20 > interchangeably with VPLS identifier. >=20 > =20 >=20 > Target Attachment Individual Identifier (TAII), Source Attachment >=20 > Individual Identifier (SAII): These are null because the mesh of = PWs >=20 > in a VPLS terminates on MAC learning tables, rather than on >=20 > individual attachment circuits. The use of non-null TAII and SAII = is >=20 > reserved for future enhancements. >=20 > =20 >=20 > This suggests that the pwTable configuration on PE1 should look like = this: >=20 > =20 >=20 > =C2=B7 pwIndex =3D 1, pwGroupAttachmentID =3D =E2=80=9CVPLS1=E2=80= =9D, pwLocalAttachmentID =3D =E2=80=9C=E2=80=9D, pwRemoteAttachmentID =3D = =E2=80=9C=E2=80=9D, pwPeerAddr =3D =E2=80=9C2.2.2.2=E2=80=9D >=20 > =C2=B7 pwIndex =3D 2, pwGroupAttachmentID =3D =E2=80=9CVPLS1=E2=80= =9D, pwLocalAttachmentID =3D =E2=80=9C=E2=80=9D, pwRemoteAttachmentID =3D = =E2=80=9C=E2=80=9D, pwPeerAddr =3D =E2=80=9C3.3.3.3=E2=80=9D >=20 > =20 >=20 > However, this contradicts RFC5601, specifically its definition in = section 12 of the reverse-lookup table pwGenFecIndexMappingTable, which = states that the {AGI, SAII, TAII} triplet must be unique for a PW using = the generalized PWid FEC (type 129). >=20 > =20 >=20 > pwGenFecIndexMappingTable OBJECT-TYPE >=20 > SYNTAX SEQUENCE OF PwGenFecIndexMappingEntry >=20 > MAX-ACCESS not-accessible >=20 > STATUS current >=20 > DESCRIPTION >=20 > "This table enables the reverse mapping of the unique >=20 > PWid parameters [GroupAttachmentID, LocalAttachmentID, >=20 > and PeerAttachmentID] and the pwIndex. The table is >=20 > only applicable for PW using the generalized FEC." >=20 > ::=3D { pwObjects 12 } >=20 > =20 >=20 > Note that the corresponding reverse lookup table pwIndexMappingTable = for type-128 FECs has a critical difference, in that it includes the = peer IP Address as one of the unique PW identifiers: >=20 > =20 >=20 > pwIndexMappingTable OBJECT-TYPE >=20 > SYNTAX SEQUENCE OF PwIndexMappingEntry >=20 > MAX-ACCESS not-accessible >=20 > STATUS current >=20 > DESCRIPTION >=20 > "This table enables the reverse mapping of the unique >=20 > PWid parameters [peer IP, PW type, and PW ID] and the >=20 > pwIndex. The table is not applicable for PWs created >=20 > manually or by using the generalized FEC." >=20 > ::=3D { pwObjects 7 } >=20 > =20 >=20 > It seems to me that pwGenFecIndexMappingTable should have the peer IP = address as a 4th =E2=80=9Cunique PWid parameter=E2=80=9D. Otherwise, = these parameters cannot uniquely identify a PW that belongs to an = RFC4762-compliant VPLS. >=20 > =20 >=20 > Please let me know what you think. My apologies if this has already = been discussed before. >=20 > =20 >=20 > Thanks, >=20 > =20 >=20 > Mike Bartlett > mike.bartlett@metaswitch.com > =20 >=20 >=20 > _______________________________________________ > Pals mailing list > Pals@ietf.org > https://www.ietf.org/mailman/listinfo/pals = >=20 >=20 --Apple-Mail=_061AAA05-EB2A-4359-9DF8-8C5021EA3FF3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Looks like a bug in the MIB to me.  Tom/David were the = authors so I=E2=80=99ll leave it to them to respond (am guessing here at = David=E2=80=99s email), but might be worth raising an erratum.= --Apple-Mail=_061AAA05-EB2A-4359-9DF8-8C5021EA3FF3-- From nobody Tue Nov 8 15:53:10 2016 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAD62129622 for ; Tue, 8 Nov 2016 15:53:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 Mjoghx_ypGhX for ; Tue, 8 Nov 2016 15:53:07 -0800 (PST) Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2F921293FC for ; Tue, 8 Nov 2016 15:53:06 -0800 (PST) Received: by mail-oi0-x22f.google.com with SMTP id 62so219853233oif.1 for ; Tue, 08 Nov 2016 15:53:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=uzSdQeVnL7evcZsk2/8ayuVApvdRzocgiSWI7ZALrhQ=; b=jyMMivz48AdmeaNAG1jUoRrWYHXM7N/fRFtfP6IYeCQig9udpi42VAnp/rHj4KQ0nm y9L1CNeX59+fithEtJcCzW6LTpqcWlaiN2onglBibjklBq3TCQu/0GGtSpafCJ7kGM5F femVzSwoYvcNdwcoAlHf7zCdX7lAKUq5hNhtQ0mDSFFrdrYhVY5PXygpVIWO4gQOG0QP hSJCpljxb648xUpOaLiLoAnlKVKqw/Zf7TLxtYb/6/LhzaZ/ew7IwmlIuBg1NX9xdusj NxydCYXlh9KZtJMGt8uSHWZEfRXA8Gf77krcWT+4GDe0v+DaXfM7CGLesLJrRqWwklKb axEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=uzSdQeVnL7evcZsk2/8ayuVApvdRzocgiSWI7ZALrhQ=; b=XTzwHB+bfPl+56DDy6Ba0Am6qOJPoK3g60VeNLq/HA/i+rqY66O9r1HdBnURumJkmC mwHsHulWmw2zESEYqMx+8uQvTQSqfEma2ft/kVB35S6+FUyOQ4a5Eb4dLvTni0WZBG4G 2G7xuja1kavIemo6vswjPnVp1IR8mOpOwcKBc4eaWz1z/cuU4iFHECKaQCFCM+fw9Hh9 FitW5b7daae53oWJ5f4r4oVH4PRDm25BLuamc2M4KDOJpPkSenaIKBDlp46eg5x/aocu EEiQA6Adcien9DbTD1k8fZpVgSmnPGadorSceD18qPUyUtcAOfV8rYLaD1jsv1xlABlW mTnA== X-Gm-Message-State: ABUngvfeJ0htWHxVk6mv+Lpq8z5WcHeCKM+1rD0mW8L26N+5B10HjFvYYAY3JNZMy0KRx7K9UBdPt/PxQIvVnQ== X-Received: by 10.157.35.59 with SMTP id j56mr5178428otb.55.1478649185961; Tue, 08 Nov 2016 15:53:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.150.42 with HTTP; Tue, 8 Nov 2016 15:52:45 -0800 (PST) In-Reply-To: <20161108192447.69548B817D3@rfc-editor.org> References: <20161108192447.69548B817D3@rfc-editor.org> From: "Andrew G. Malis" Date: Tue, 8 Nov 2016 18:52:45 -0500 Message-ID: To: "pals@ietf.org" Content-Type: multipart/alternative; boundary=001a113dca767a0b620540d2d71e Archived-At: Subject: [Pals] Fwd: [Errata Held for Document Update] RFC4762 (4834) X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2016 23:53:09 -0000 --001a113dca767a0b620540d2d71e Content-Type: text/plain; charset=UTF-8 FYI. ---------- Forwarded message ---------- From: RFC Errata System Date: Tue, Nov 8, 2016 at 2:24 PM Subject: [Errata Held for Document Update] RFC4762 (4834) To: prakash.ragunathan@yahoo.com, mlasserre@alcatel-lucent.com, vach.kompella@alcatel-lucent.com Cc: l2vpn@ietf.org, iesg@ietf.org, db3546@att.com, rfc-editor@rfc-editor.org The following errata report has been held for document update for RFC4762, "Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=4762&eid=4834 -------------------------------------- Status: Held for Document Update Type: Editorial Reported by: Prakash Ragunathan Date Reported: 2016-10-18 Held by: Deborah Brungard (IESG) Section: 9.1 Original Text ------------- For example, if a customer site A, is shut down, eventually the other PEs should unlearn A's MAC address. Corrected Text -------------- For example, if a customer site is shut down, eventually the other PEs should unlearn the MAC address(es) of this site. Notes ----- Prakash noted the customer site name is not mentioned in example. Suggested naming the site (A1) gives clear info than just stating "customer site A". After discussion with the Chairs and Authors, the above text was agreed. -------------------------------------- RFC4762 (draft-ietf-l2vpn-vpls-ldp-09) -------------------------------------- Title : Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling Publication Date : January 2007 Author(s) : M. Lasserre, Ed., V. Kompella, Ed. Category : PROPOSED STANDARD Source : Layer 2 Virtual Private Networks INT Area : Internet Stream : IETF Verifying Party : IESG --001a113dca767a0b620540d2d71e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
FYI.

---------- Forward= ed message ----------
From: RFC Errata Sys= tem <= rfc-editor@rfc-editor.org>
Date: Tue, Nov 8, 2016 at 2:24 = PM
Subject: [Errata Held for Document Update] RFC4762 (4834)
To: prakash.ragunathan@yahoo.com, mlasserre@alcatel-lucent= .com, vach.kompella= @alcatel-lucent.com
Cc: l2vpn@ietf= .org, iesg@ietf.org, db3546@att.com, rfc-editor@rfc-editor.org


The following errata re= port has been held for document update
for RFC4762, "Virtual Private LAN Service (VPLS) Using Label Distribut= ion Protocol (LDP) Signaling".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=3D4762&eid=3D4834

--------------------------------------
Status: Held for Document Update
Type: Editorial

Reported by: Prakash Ragunathan <prakash.ragunathan@yahoo.com>
Date Reported: 2016-10-18
Held by: Deborah Brungard (IESG)

Section: 9.1

Original Text
-------------
For
=C2=A0 =C2=A0example, if a customer site A, is shut down, eventually the ot= her PEs
=C2=A0 =C2=A0should unlearn A's MAC address.

Corrected Text
--------------
For example, if a customer site is shut down, eventually the other PEs
should unlearn the MAC address(es) of this site.

Notes
-----
Prakash noted the customer site name is not mentioned in example. Suggested= naming the site (A1) gives clear info than just stating "customer sit= e A".
After discussion with the Chairs and Authors, the above text was agreed.
--------------------------------------
RFC4762 (draft-ietf-l2vpn-vpls-ldp-09)
--------------------------------------
Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Virtual Priva= te LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling
Publication Date=C2=A0 =C2=A0 : January 2007
Author(s)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: M. Lasserre, Ed., V. Ko= mpella, Ed.
Category=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : PROPOSED STANDARD
Source=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Layer 2 Virtual Pr= ivate Networks INT
Area=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Internet
Stream=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : IETF
Verifying Party=C2=A0 =C2=A0 =C2=A0: IESG


--001a113dca767a0b620540d2d71e-- From nobody Sun Nov 13 14:40:45 2016 Return-Path: X-Original-To: pals@ietf.org Delivered-To: pals@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9575A12958D; Sun, 13 Nov 2016 14:40:43 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.37.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147907684360.5643.193663114375005293.idtracker@ietfa.amsl.com> Date: Sun, 13 Nov 2016 14:40:43 -0800 Archived-At: Cc: pals@ietf.org Subject: [Pals] I-D Action: draft-ietf-pals-endpoint-fast-protection-04.txt X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2016 22:40:43 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Pseudowire And LDP-enabled Services of the IETF. Title : PW Endpoint Fast Failure Protection Authors : Yimin Shen Rahul Aggarwal Wim Henderickx Yuanlong Jiang Filename : draft-ietf-pals-endpoint-fast-protection-04.txt Pages : 37 Date : 2016-11-13 Abstract: This document specifies a fast mechanism for protecting pseudowires against egress endpoint failures, including egress attachment circuit failure, egress PE failure, multi-segment PW terminating PE failure, and multi-segment PW switching PE failure. Operating on the basis of multi-homed CE, redundant PWs, upstream label assignment and context specific label switching, the mechanism enables local repair to be performed by the router upstream adjacent to a failure. The router can restore a PW in the order of tens of milliseconds, by rerouting traffic around the failure to a protector through a pre-established bypass tunnel. Therefore, the mechanism can be used to reduce traffic loss before global repair reacts to the failure and the network converges on the topology changes due to the failure. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pals-endpoint-fast-protection/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-pals-endpoint-fast-protection-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-pals-endpoint-fast-protection-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Nov 21 20:20:18 2016 Return-Path: X-Original-To: pals@ietf.org Delivered-To: pals@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 091EA129460; Mon, 21 Nov 2016 20:20:12 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.38.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147978841201.16176.4638381497808723724.idtracker@ietfa.amsl.com> Date: Mon, 21 Nov 2016 20:20:12 -0800 Archived-At: Cc: pals@ietf.org Subject: [Pals] I-D Action: draft-ietf-pals-p2mp-pw-lsp-ping-01.txt X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Nov 2016 04:20:12 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Pseudowire And LDP-enabled Services of the IETF. Title : Definition of P2MP PW TLV for LSP-Ping Mechanisms Authors : Parag Jain Sami Boutros Sam Aldrin Filename : draft-ietf-pals-p2mp-pw-lsp-ping-01.txt Pages : 8 Date : 2016-11-21 Abstract: LSP-Ping is a widely deployed Operation, Administration, and Maintenance (OAM) mechanism in MPLS networks. This document describes a mechanism to verify connectivity of Point-to-Multipoint (P2MP) Pseudowires (PW) using LSP Ping. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pals-p2mp-pw-lsp-ping/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-pals-p2mp-pw-lsp-ping-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-pals-p2mp-pw-lsp-ping-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Nov 22 10:19:28 2016 Return-Path: X-Original-To: pals@ietf.org Delivered-To: pals@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 087EE129A7F; Tue, 22 Nov 2016 10:19:24 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.38.1 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <147983876402.30355.4280121178887690319.idtracker@ietfa.amsl.com> Date: Tue, 22 Nov 2016 10:19:24 -0800 Archived-At: Cc: draft-ietf-pals-endpoint-fast-protection@ietf.org, pals-chairs@ietf.org, pals@ietf.org, db3546@att.com, stewart.bryant@gmail.com Subject: [Pals] Last Call: (PW Endpoint Fast Failure Protection) to Proposed Standard X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.17 Reply-To: ietf@ietf.org List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Nov 2016 18:19:24 -0000 The IESG has received a request from the Pseudowire And LDP-enabled Services WG (pals) to consider the following document: - 'PW Endpoint Fast Failure Protection' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2016-12-06. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document specifies a fast mechanism for protecting pseudowires against egress endpoint failures, including egress attachment circuit failure, egress PE failure, multi-segment PW terminating PE failure, and multi-segment PW switching PE failure. Operating on the basis of multi-homed CE, redundant PWs, upstream label assignment and context specific label switching, the mechanism enables local repair to be performed by the router upstream adjacent to a failure. The router can restore a PW in the order of tens of milliseconds, by rerouting traffic around the failure to a protector through a pre-established bypass tunnel. Therefore, the mechanism can be used to reduce traffic loss before global repair reacts to the failure and the network converges on the topology changes due to the failure. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-pals-endpoint-fast-protection/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-pals-endpoint-fast-protection/ballot/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/2825/ https://datatracker.ietf.org/ipr/2243/ https://datatracker.ietf.org/ipr/2805/ https://datatracker.ietf.org/ipr/2262/ From nobody Mon Nov 28 06:51:47 2016 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9973E1295D4; Mon, 28 Nov 2016 06:51:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 rwGQYSwQhiYF; Mon, 28 Nov 2016 06:51:25 -0800 (PST) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A1581295F4; Mon, 28 Nov 2016 06:51:24 -0800 (PST) Received: by mail-wm0-x234.google.com with SMTP id f82so157686199wmf.1; Mon, 28 Nov 2016 06:51:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:subject:to:message-id:date:user-agent:mime-version; bh=VvD1etdTca7/h0yH9eMulvJz9ut0HX5utj3sxepz44Y=; b=N9LKH6i9lAYDEYPFe1ZwDMYoLMOz1KP9bugyCUMQSx1BER0K3nioByOtVDRwQUKP2/ S0rkyhDacqbZLfIef3RRLNtmePibRcqpoiYWytFsVAy2TpeDSqztzih+lj5eBrnp/JU7 gNGNHoY4BYSYOrZjtMLjlPltTEgBXFfP6a4VsMuI6EidHtszeQhiViC40VuJJxLZbYva pHzLjn6/mYTlcmfwg1RCsIG/AyFfPNmLOGXpowBL31/XLHodN8kJjrc9dcXLjLwFs0Mj ZVliw9ufZfgbBLkh5L5wb7z5J+BxsMPzRrJsaKoUOHWNn+k/xydU2RplmJEQXRl1DseR SMZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:subject:to:message-id:date:user-agent :mime-version; bh=VvD1etdTca7/h0yH9eMulvJz9ut0HX5utj3sxepz44Y=; b=kk4b+TSEM1WN+vK9q5XxLqCMbWynY6E2spgH1vFP9fgTIyAvHmO7kcQyHsDu01rCWq w87Uf746aJ44O3IpQcij2g5kYyyzsYu4gs+JkCo1twjoJxewpgs51rXn3mKy/14Z0Qxj +xatU8ENRJoJSut7mgqJhrxIxF0h8yFm2ZNLcyNB50M8oZo1ewOyXzrXq+m8fOIvER2C Yl8jdllPILtcDzf84U73CcVJRwybS8p1ldDcFoQpqXbcyjKxU3Ul26afMdEONbilaAko 6a5ujPVL5RdcYWN5aRkAVCcpkKFO/l/dxG3zbwWX21ya8jTtbNfnqN8FhffTB81OJTy/ kLOg== X-Gm-Message-State: AKaTC03Wzwf7BWYYpBqUV4FY25aJ1k0cAEwMOu33ALQJ3t8Kv+UbwjUuBy74xUGBKeXsLA== X-Received: by 10.28.13.9 with SMTP id 9mr18506331wmn.50.1480344682209; Mon, 28 Nov 2016 06:51:22 -0800 (PST) Received: from [192.168.2.131] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id l67sm29069872wmf.20.2016.11.28.06.51.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 28 Nov 2016 06:51:21 -0800 (PST) From: Stewart Bryant To: draft-ietf-pals-p2mp-pw@ietf.org, "pals-chairs@tools.ietf.org" , "pals@ietf.org" Message-ID: <1a68cc18-9ef8-e427-d625-f3b140fe3753@gmail.com> Date: Mon, 28 Nov 2016 14:51:16 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------42BAD071E420D5F4D077FBA0" Archived-At: Subject: [Pals] Last call review of draft-ietf-pals-p2mp-pw-01.txt X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2016 14:51:46 -0000 This is a multi-part message in MIME format. --------------42BAD071E420D5F4D077FBA0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Here are some last call comments on draft-ietf-pals-p2mp-pw-01.txt written from the perspective of the document shepherd and Chair. I think the process from here on needs to be for you to produce a new version, discussing any of these comments with the list as appropriate. Then, given the number of comments and the fact that I have seen no discussion on the list, for me to try to persuade some others to thoroughly review the text. Firstly there are too many front page authors. I suggest that the two editors Sami and Siva as editors remain on the front page and all other's are moved to a "Contributing Authors" section at the end of the document. If you can agree amongst yourselves that some others of you should remain on the front then I am fine, but remember that any more than five needs a very strong case to be made to the IESG, and I need text supporting that case for inclusion in the shepherd's writeup. ID-Nits makes the following complaint about references == Missing Reference: 'P2MP-PW-REQ' is mentioned on line 143, but not defined == Missing Reference: 'L3VPN-MCAST' is mentioned on line 352, but not defined == Missing Reference: 'PW-TWC-FEC' is mentioned on line 466, but not defined == Missing Reference: 'P2MP-LSP-PING' is mentioned on line 575, but not defined == Unused Reference: 'RFC6514' is defined on line 669, but no explicit reference was found in the text == Unused Reference: 'RFC 6667' is defined on line 679, but no explicit reference was found in the text == Unused Reference: 'RFC7338' is defined on line 690, but no explicit reference was found in the text == Unused Reference: 'RFC6425' is defined on line 693, but no explicit reference was found in the text I think that this is because you have symbolic references in the text but only RFCs in the reference section. Please correct this. ==================== 1 Introduction A reference model for P2MP PW is depicted in Figure 1 below. A transport LSP associated with a P2MP SS-PW SHOULD be a P2MP MPLS LSP (i.e., P2MP TE tunnel established via RSVP-TE [RFC4875] or P2MP LSP established via mLDP [RFC6388]) SB> nit "or a P2MP" =================== spanning from the Root-PE to the Leaf-PE(s) of the P2MP SS-PW tree. For example, in Figure 1, PW1 can be associated with a P2MP TE tunnel or P2MP LSP setup using mLDP originating from PE1 and terminating at PE2 and PE3. SB> True, but a little confusing since PW1 also goes to PE4. I think SB> you need to say something about that. |<--------------P2MP PW---------------->| Native | | Native Service | |<--PSN1->| |<--PSN2->| | Service (AC) V V V V V V (AC) | +-----+ +------+ +------+ | | | | | P1 |=========|T-PE2 |AC3 | +---+ | | | | .......PW1.........>|-------->|CE3| | |T-PE1|=========| . |=========| | | +---+ | | .......PW1........ | +------+ | | | . |=========| . | +------+ | | | . | | . |=========|T-PE3 |AC4 | +---+ +---+ |AC1 | . | | .......PW1.........>|-------->|CE4| |CE1|------->|... | | |=========| | | +---+ +---+ | | . | +------+ +------+ | | | . | +------+ +------+ | | | . |=========| P2 |=========|T-PE4 |AC5 | +---+ | | .......PW1..............PW1.........>|-------->|CE5| | | |=========| |=========| | | +---+ | +-----+ +------+ +------+ | Figure 1: P2MP PW Mechanisms for establishing P2P SS-PW using LDP are described in [RFC4447]. In this document, we specify a method to signal P2MP PW SB> nit "a method of signalling" (I think) using LDP. In particular, we define new FEC, TLVs, parameters, and status codes to facilitate LDP to signal and maintain P2MP PWs. As outlined in [P2MP-PW-REQ], even though the traffic flow from a Root-PE (R-PE) to Leaf-PE(s) (L-PEs) is P2MP in nature, it may be desirable for any L-PE to send unidirectional P2P traffic destined only to the R-PE. The proposed mechanism takes such option into consideration. The P2MP PW requires an MPLS LSP to carry the PW traffic, and the MPLS packets carried over the PW will be encapsulated according to the methods described in [RFC5332]. SB> I do not understand. I looked in RFC5332, and could find nothing SB> about PWs. I think you need to expand on how PW is layered over SB> MPLS if it is other than as described in the PW encapsulation SB> RFCs. SB> SB> My assumption is that the PW is encapulated as normal and the SB> resultant MPLS labeled payload (the PW identifier + PW payload) SB> is carried over the P2MP LSP in the same way as any other SB> MPLS payload. =================== 2. Signaling P2MP PW A P2MP PW signaling is initiated by the R-PE simply by sending a SB> nit no need for "A" P2MP-PW LDP label mapping message to the L-PE(s) belonging to that P2MP PW. SB> This needs to be unicast sent one at a time doesn't it? SB> That should be made clear to avoid anyone thinking they can SB> send it over the P2MP LSP This label mapping message will contain the following: 1. A FEC TLV containing P2MP PW Upstream FEC element that includes Transport LSP sub TLV. 2. An Interface Parameters TLV, as described in [RFC4447]. 3. A PW Grouping TLV, as described in [RFC4447]. 4. A label TLV for the upstream-assigned label used by R-PE for the traffic going from R-PE to L-PE(s). The R-PE imposes the upstream-assigned label on the outbound packets SB> That should be upstream-assigned PW label ================== When an L-PE receives a PW Label Mapping Message, it MUST verify the associated P2MP PSN LSP is in place. If the associated P2MP PSN LSP is not in place, and its type is LDP P2MP LSP, the L-PE SHOULD SB> Why is that not MUST? attempt to join the P2MP LSP associated with the P2MP PW. If the associated P2MP PSN LSP is not in place, and its type is RSVP-TE P2MP LSP, the L-PE SHOULD wait till the P2MP transport LSP is signaled. SB> So what happens if there is a failure to set up the P2MP transport SB> LSP? ============================ 2.2 P2MP PW FEC [RFC4447] specifies two types of LDP FEC elements called "PWid FEC Element" and "Generalized PWid FEC Element" used to signal P2P PWs. We define two new types of FEC elements called "P2MP PW Upstream FEC Element" and "P2P PW Downstream FEC Element". These FEC elements are associated with a mandatory upstream assigned label and an optional downstream assigned label respectively. FEC type of the P2MP PW Upstream FEC Element is 0x82 (pending IANA allocation) and is encoded as follows: SB> This is bad practise since it amounts to code point squatting. SB> It needs to be symbolic here and in the IANA section although SB> you may request a particular value in the IANA section. Sivabalan & Boutros Expires April 24, 2017 [Page 7] INTERNET DRAFT P2MP PW October 21, 2016 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | P2MP PW Up |C| PW Type | PW Info Length| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AGI Type | Length | AGI Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ AGI Value (contd.) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AII Type | Length | SAII Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ SAII Value (contd.) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |PMSI Tunnel typ| Length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + ~ Transport LSP ID ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Optional Parameters | ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: P2MP PW Upstream FEC Element SB> Where is P2MP PW Up defined? * PW Type: 15-bit representation of PW type, and the assigned values are assigned by IANA. * C bit: A value of 1 or 0 indicates whether control word is present or absent for the P2MP PW. * PW Info Length: Sum of the lengths of AGI, SAII, PMSI Tunnel info, and Optional Parameters field in octets. If this value is 0, then it references all PWs using the specified grouping ID. In this case, there are neither other FEC element fields (AGI, SAII, etc.) present, nor any interface parameters TLVs. Alternatively, we can use typed WC FEC SB> WC? Presumably wildcard? ============= * Transport LSP ID: This is the Tunnel Identifier which is defined in [L3VPN-MCAST]. An R-PE sends Label Mapping Message as soon as the transport LSP ID associated with the P2MP PW is known (e.g., via configuration) regardless of the operational state of that transport LSP. Similarly, an R-PE does not withdraw the labels when the corresponding transport LSP goes down. Furthermore, an L-PE retains the P2MP PW labels regardless of the operational status of the transport LSP. Note that a given transport LSP can be associated with more than one P2MP PWs and all P2MP PWs will be sharing the same R-PE and L-PE(s). SB> s/and all/in which case/ SB> Do you want to clarify that an R-PE may have many P2MP PWs with SB> disjoint L-P sets. In the case of LDP P2MP LSP, when an L-PE receives the Label Mapping Message, it can initiate the process of joining the P2MP LSP tree associated with the P2MP PW. In the case of RSVP-TE P2MP LSP, only the R-PE initiates the signaling of P2MP LSP. * Optional Parameters: The Optional Parameter field can contain some TLVs that are not part of the FEC, but are necessary for the operation of the PW. This proposed mechanism uses two such TLVs: Interface Parameters TLV, and Group ID TLV. The Interface Parameters TLV and Group ID TLV specified in [RFC4447] can also be used in conjunction with P2MP PW FEC in alabel message. SB> nit s/alable/a label/ SB> Throughout the text you should call up rfc4447bis The value of the sub-TLV contains the source and the group for a given multicast tree as shown in Figure 3. SB> It is conventional to show the T, L and V in a TLV Also, if a P2MP PW is associated with multiple selective trees, the corresponding label mapping message will carry more than one instance of this Sub-TLV. Furthermore, in the absence of this sub-TLV, the P2MP PW is associated with all multicast traffic stream originating from the root. +----------------------------------------- + | Multicast Source Length (1 Octet) | +----------------------------------------- + | Multicast Source (variable length) | +----------------------------------------- + | Multicast Group Length (1 Octet) | +----------------------------------------- + | Multicast Group (variable length) | +----------------------------------------- + Figure 3: Selective Tree Interface Parameter Sub-TLV Value Note that since the LDP label mapping message is only sent by the R- PE to all the L-PEs, it is not possible to negotiate any interface parameters. The type of optional P2P PW Downstream FEC Element is 0x83 (pending IANA allocation), and is encoded as follows: SB> Again bad practise to but the value in the body of the text. ] 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | P2P PW Down |C| PW Type | PW Info Length| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AGI Type | Length | AGI Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ AGI Value (contd.) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AII Type | Length | SAII Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ SAII Value (contd.) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: P2P PW Downstream FEC Element The definition of the fields in the P2P PW Downstream FEC Element is the same as those of P2MP PW Upstream FEC Element. SB> ... shown in Figure 3. 2.3 Typed Wildcard FEC Format for new FEC [RFC5918] defines the general notion of a "Typed Wildcard" FEC Element, and requires FEC designer to specify a typed wildcard FEC element for newly defined FEC element types. This document defines two new FEC elements, "P2MP PW Upstream" and "P2P PW Downstream" FEC element, and hence requires us to define their Typed Wildcard format. [PW-TWC-FEC] defines Typed Wildcard FEC element format for other PW FEC Element types (PWid and Gen. PWid FEC Element) in section 2 as follows: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Typed Wcard=0x5|Type=PW FEC| Len = 3 |R| PW type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . . . | PMSI Tun Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ SB> It might be my cut and paste, it may be a layout error in the original. Sivabalan & Boutros Expires April 24, 2017 [Page 11] INTERNET DRAFT P2MP PW October 21, 2016 Figure 5: Typed Wildcard Format for P2MP PW FEC Elements [PW-TWC-FEC] specifies that "Type" field can be either "PWid" (0x80) or "Generalized PWid" (0x81) FEC element type. This document reuses the existing typed wildcard format as specified in [PW-TWC-FEC] and illustrated in Figure 5. We extend the definition of "Type" field to also include "P2MP PW Upstream" and "P2P PW Downstream" FEC element types, as well as add an additional field "PMSI Tun Type". We reserve PMSI tunnel Type 0xFF to mean "wildcard" transport tunnel type. This "wildcard" transport tunnel type can be used in a typed wildcard p2mp FEC for further filtering. This field only applies to Typed wildcard P2MP PW Upstream FEC and MUST be set to "wildcard" for "P2P PW Downstream FEC" typed wildcard element. SB> These are changes to an MPLS data structure, so I think that we need to SB> ask the MPLS WG to review. ================== 3. LDP Capability Negotiation In line with requirements listed in [RFC5561], the following TLV is defined to indicate the P2MP PW capability: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U|F| P2MP PW Capability (0x703)| Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |S| Reserved | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7: LDP P2MP PW Capability TLV SB> Same comment about draft text including assumed codepoint values. 703 might SB> have gone before you get published! ================= 4. P2MP PW Status In order to support the proposed mechanism, a node MUST be capable of handling PW status. As such, PW status negotiation procedure described in [RFC4447] is not applicable to P2MP PW. SB> So is there a protocol action on discovering that a peer does not SB> support this? Once an L-PE successfully processes a Label Mapping Message for a P2MP PW, it MUST send appropriate PW status according to the procedure specified [RFC4447] to notify the PW status. If there is no PW status notification required, then no PW status notification is sent (for example if the P2MP PW is established and operational with a status code of Success (0x00000000), pw status message is not necessary). PW status message sent from any L-PE to R-PE contains P2P PW Downstream FEC to identify the PW. SB> I could not parse the sentence above. An R-PE also sends PW status to L-PE(s) to reflect its view of a P2MP PW state. Such PW status message contains P2MP PW Upstream FEC to identify the PW. Connectivity status of the underlying P2MP LSP that P2MP PW is associated with, can be verified using LSP Ping and Traceroute procedures described in [P2MP-LSP-PING]. 5 Security Considerations The security measures described in [RFC4447] is adequate for the proposed mechanism. SB> You really need to point at the security section in draft-ietf-pals-rfc4447bis SB> This has had a more recent security review and will replace RFC4447 SB> by the time this draft becomes an RFC. ============== 7 IANA Considerations 7.1. FEC Type Name Space This document uses two new FEC element types, number 0x82 and 0x83 will be requested as an allocation from the registry "FEC Type Name Space" for the Label Distribution Protocol (LDP RFC5036): Value Hex Name Reference ------- ----- ----------------------------- --------- 130 0x82 P2MP PW Upstream FEC Element RFCxxxx 131 0x83 P2P PW Downstream FEC Element RFCxxxx SB> The text is not correct. You have requested an early allocation of these SB> values, and you need to ask that although the early allocation has technically SB> expired they be allocated to this RFC. 7.2. LDP TLV Type This document uses a new LDP TLV types, IANA already maintains a registry of name "TLV TYPE NAME SPACE" defined by RFC5036. The Sivabalan & Boutros Expires April 24, 2017 [Page 14] INTERNET DRAFT P2MP PW October 21, 2016 following values are suggested for assignment: TLV type Description: 0x0703 P2MP PW Capability TLV 7.3. mLDP Opaque Value Element TLV Type This document requires allocation of a new mLDP Opaque Value Element Type from the LDP MP Opaque Value Element type name space defined in [mLDP]. SB> You should give the name of the namespace directly rather than through a reference SB> Because IANA are such nice people, I prefer to request that they do things. The following value is suggested for assignment: TLV type Description 0x3 L2VPN-MCAST application TLV 7.4. Selective Tree Interface Parameter sub-TLV Type This document requires allocation of a sub-TLV from the registry "Pseudowire Interface Parameters Sub-TLV Type". The following value is suggested for assignment: TLV type Description 0x0D Selective Tree Interface Parameter. SB> 0x0d is already taken! SB. 0x0D up to 256 bytes ROHC over MPLS configuration [RFC3241 ] [RFC4901 ] SB> How much of this is deployed? Because if you have deployed SB> we have a problem. 7.5. WildCard PMSI tunnel type. This document requires the allocation of PMSI tunnel Type 0xFF to mean wildcard transport tunnel type SB> You need to ask IANA to allocate a specific code point in a specific SB> registry. Please use the the format of the registry. SB> SB> Taking the FF value can be a big deal, and needs to be SB> co-ordinated with the registry "owner", who I think is MPLS. Has SB> this been discussed by the MPLS WG? 8 References 8.1. Normative References ====================== [RFC4447] "Transport of Layer 2 Frames Over MPLS", Martini, L., et al., RFC 4447, April 2006. SB> This needs to point to RFC4447bis which will be an RFC in the next few weeks. - Stewart --------------42BAD071E420D5F4D077FBA0 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit 
  
Here are some last call comments on draft-ietf-pals-p2mp-pw-01.txt
written from the perspective of the document shepherd and Chair.

I think the process from here on needs to be for you to produce a new
version, discussing any of these comments with the list as appropriate.
Then, given the number of comments and the fact that I have seen 
no discussion on the list, for me to try to persuade some others
to thoroughly review the text.
 
Firstly there are too many front page authors. I suggest that the two
editors Sami and Siva as editors remain on the front page and all other's are
moved to a "Contributing Authors" section at the end of the document.
If you can agree amongst yourselves that some others of you should remain
on the front then I am fine, but remember that any more than five needs
a very strong case to be made to the IESG, and I need text supporting
that case for inclusion in the shepherd's writeup.

ID-Nits makes the following complaint about references

  == Missing Reference: 'P2MP-PW-REQ' is mentioned on line 143, but not
     defined

  == Missing Reference: 'L3VPN-MCAST' is mentioned on line 352, but not
     defined

  == Missing Reference: 'PW-TWC-FEC' is mentioned on line 466, but not defined

  == Missing Reference: 'P2MP-LSP-PING' is mentioned on line 575, but not
     defined

  == Unused Reference: 'RFC6514' is defined on line 669, but no explicit
     reference was found in the text

  == Unused Reference: 'RFC 6667' is defined on line 679, but no explicit
     reference was found in the text

  == Unused Reference: 'RFC7338' is defined on line 690, but no explicit
     reference was found in the text

  == Unused Reference: 'RFC6425' is defined on line 693, but no explicit
     reference was found in the text

I think that this is because you have symbolic references in the text but
only RFCs in the reference section. Please correct this.

====================


1  Introduction

   A reference model for P2MP PW is
   depicted in Figure 1 below. A transport LSP associated with a P2MP
   SS-PW SHOULD be a P2MP MPLS LSP (i.e., P2MP TE tunnel established via
   RSVP-TE [RFC4875] or P2MP LSP established via mLDP [RFC6388])
 
SB> nit "or a P2MP"

=================== 
 
   spanning from the Root-PE to the Leaf-PE(s) of the P2MP SS-PW tree.
   For example, in Figure 1, PW1 can be associated with a P2MP TE tunnel
   or P2MP LSP setup using mLDP originating from PE1 and terminating at
   PE2 and PE3.


SB> True, but a little confusing since PW1 also goes to PE4. I think
SB> you need to say something about that.

                 |<--------------P2MP PW---------------->|
          Native |                                       |  Native
         Service |     |<--PSN1->|      |<--PSN2->|      |  Service
          (AC)   V     V         V      V         V      V   (AC)
            |    +-----+         +------+         +------+    |
            |    |     |         |   P1 |=========|T-PE2 |AC3 |    +---+
            |    |     |         |   .......PW1.........>|-------->|CE3|
            |    |T-PE1|=========|   .  |=========|      |    |    +---+
            |    |  .......PW1........  |         +------+    |
            |    |  .  |=========|   .  |         +------+    |
            |    |  .  |         |   .  |=========|T-PE3 |AC4 |    +---+
    +---+   |AC1 |  .  |         |   .......PW1.........>|-------->|CE4|
    |CE1|------->|...  |         |      |=========|      |    |    +---+
    +---+   |    |  .  |         +------+         +------+    |
            |    |  .  |         +------+         +------+    |
            |    |  .  |=========|   P2 |=========|T-PE4 |AC5 |    +---+
            |    |  .......PW1..............PW1.........>|-------->|CE5|
            |    |     |=========|      |=========|      |    |    +---+
            |    +-----+         +------+         +------+    |

                                 Figure 1: P2MP PW

   Mechanisms for establishing P2P SS-PW using LDP are described in
   [RFC4447]. In this document, we specify a method to signal P2MP PW

SB> nit "a method of signalling" (I think)

   using LDP. In particular, we define new FEC, TLVs, parameters, and
   status codes to facilitate LDP to signal and maintain P2MP PWs.

   As outlined in [P2MP-PW-REQ], even though the traffic flow from a
   Root-PE (R-PE) to Leaf-PE(s) (L-PEs) is P2MP in nature, it may be
   desirable for any L-PE to send unidirectional P2P traffic destined
   only to the R-PE. The proposed mechanism takes such option into
   consideration.

   The P2MP PW requires an MPLS LSP to carry the PW traffic, and the
   MPLS packets carried over the PW will be encapsulated according to
   the methods described in [RFC5332].

SB> I do not understand. I looked in RFC5332, and could find nothing 
SB> about PWs. I think you need to expand on how PW is layered over
SB> MPLS if it is other than as described in the PW encapsulation 
SB> RFCs.
SB>
SB> My assumption is that the PW is encapulated as normal and the 
SB> resultant MPLS labeled payload (the PW identifier + PW payload)
SB> is carried over the P2MP LSP in the same way as any other 
SB> MPLS payload.

===================


2. Signaling P2MP PW
 

   A P2MP PW signaling is initiated by the R-PE simply by sending a

SB> nit no need for "A"

   P2MP-PW LDP label mapping message to the L-PE(s) belonging to that
   P2MP PW. 

SB> This needs to be unicast sent one at a time doesn't it?
SB> That should be made clear to avoid anyone thinking they can
SB> send it over the P2MP LSP

     This label mapping message will contain the following:
         1. A FEC TLV containing P2MP PW Upstream FEC element that
            includes Transport LSP sub TLV.
         2. An Interface Parameters TLV, as described in [RFC4447].
         3. A PW Grouping TLV, as described in [RFC4447].
         4. A label TLV for the upstream-assigned label used by R-PE
            for the traffic going from R-PE to L-PE(s).

   The R-PE imposes the upstream-assigned label on the outbound packets

SB> That should be upstream-assigned PW label

==================

   When an L-PE receives a PW Label Mapping Message, it MUST verify the
   associated P2MP PSN LSP is in place. If the associated P2MP PSN LSP
   is not in place, and its type is LDP P2MP LSP, the L-PE SHOULD

SB> Why is that not MUST?

   attempt to join the P2MP LSP associated with the P2MP PW. If the
   associated P2MP PSN LSP is not in place, and its type is RSVP-TE P2MP
   LSP, the L-PE SHOULD wait till the P2MP transport LSP is signaled.

SB> So what happens if there is a failure to set up the P2MP transport
SB> LSP?

============================


2.2 P2MP PW FEC

   [RFC4447] specifies two types of LDP FEC elements called "PWid FEC
   Element" and "Generalized PWid FEC Element" used to signal P2P PWs.
   We define two new types of FEC elements called "P2MP PW Upstream FEC
   Element" and "P2P PW Downstream FEC Element". These FEC elements are
   associated with a mandatory upstream assigned label and an optional
   downstream assigned label respectively.

   FEC type of the P2MP PW Upstream FEC Element is 0x82 (pending IANA
   allocation) and is encoded as follows:


SB> This is bad practise since it amounts to code point squatting.
SB> It needs to be symbolic here and in the IANA section although
SB> you may request a particular value in the IANA section.

 Sivabalan & Boutros      Expires April 24, 2017                 [Page 7]

INTERNET DRAFT                  P2MP PW                 October 21, 2016


       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | P2MP PW Up    |C|           PW Type           | PW Info Length|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    AGI Type   |     Length    |         AGI Value             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ~                       AGI Value (contd.)                      ~
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    AII Type   |     Length    |         SAII Value            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ~                       SAII Value (contd.)                     ~
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |PMSI Tunnel typ|     Length    |                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
      +                                                               +
      ~                   Transport LSP ID                            ~
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      |                       Optional Parameters                     |
      ~                                                               ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                   Figure 2: P2MP PW Upstream FEC Element

SB> Where is P2MP PW Up defined?

        * PW Type:

         15-bit representation of PW type, and the assigned values are
         assigned by IANA.

        * C bit:

         A value of 1 or 0 indicates whether control word is present or
         absent for the P2MP PW.

        * PW Info Length:

   Sum of the lengths of AGI, SAII, PMSI Tunnel info, and Optional
   Parameters field in octets. If this value is 0, then it references
   all PWs using the specified grouping ID. In this case, there are
   neither other FEC element fields (AGI, SAII, etc.) present, nor any
   interface parameters TLVs. Alternatively, we can use typed WC FEC

SB> WC? Presumably wildcard?


=============


   * Transport LSP ID: This is the Tunnel Identifier which is defined in
   [L3VPN-MCAST].

   An R-PE sends Label Mapping Message as soon as the transport LSP ID
   associated with the P2MP PW is known (e.g., via configuration)
   regardless of the operational state of that transport LSP. Similarly,
   an R-PE does not withdraw the labels when the corresponding transport
   LSP goes down. Furthermore, an L-PE retains the P2MP PW labels
   regardless of the operational status of the transport LSP.

   Note that a given transport LSP can be associated with more than one
   P2MP PWs and all P2MP PWs will be sharing the same R-PE and L-PE(s).
SB> s/and all/in which case/

SB> Do you want to clarify that an R-PE may have many P2MP PWs with
SB> disjoint L-P sets.

   In the case of LDP P2MP LSP, when an L-PE receives the Label Mapping
   Message, it can initiate the process of joining the P2MP LSP tree
   associated with the P2MP PW.

   In the case of RSVP-TE P2MP LSP, only the R-PE initiates the
   signaling of P2MP LSP.

   * Optional Parameters:

   The Optional Parameter field can contain some TLVs that are not part
   of the FEC, but are necessary for the operation of the PW. This
   proposed mechanism uses two such TLVs: Interface Parameters TLV, and
   Group ID TLV.

   The Interface Parameters TLV and Group ID TLV specified in [RFC4447]
   can also be used in conjunction with P2MP PW FEC in alabel message.
SB> nit s/alable/a label/


SB> Throughout the text you should call up rfc4447bis




   The
   value of the sub-TLV contains the source and the group for a given
   multicast tree as shown in Figure 3. 

SB> It is conventional to show the T, L and V in a TLV

   Also, if a P2MP PW is associated
   with multiple selective trees, the corresponding label mapping
   message will carry more than one instance of this Sub-TLV.
   Furthermore, in the absence of this sub-TLV, the P2MP PW is
   associated with all multicast traffic stream originating from the
   root.

                      +----------------------------------------- +
                      | Multicast Source Length (1 Octet)        |
                      +----------------------------------------- +
                      | Multicast Source (variable length)       |
                      +----------------------------------------- +
                      | Multicast Group Length (1 Octet)         |
                      +----------------------------------------- +
                      | Multicast Group (variable length)        |
                      +----------------------------------------- +


              Figure 3: Selective Tree Interface Parameter Sub-TLV Value

   Note that since the LDP label mapping message is only sent by the R-
   PE to all the L-PEs, it is not possible to negotiate any interface
   parameters.

   The type of optional P2P PW Downstream FEC Element is 0x83 (pending
   IANA allocation), and is encoded as follows:

SB> Again bad practise to but the value in the body of the text.
]
       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | P2P PW Down   |C|           PW Type           | PW Info Length|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    AGI Type   |     Length    |         AGI Value             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ~                       AGI Value (contd.)                      ~
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    AII Type   |     Length    |         SAII Value            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ~                       SAII Value (contd.)                     ~
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 4: P2P PW Downstream FEC Element

   The definition of the fields in the P2P PW Downstream FEC Element is
   the same as those of P2MP PW Upstream FEC Element.

SB> ... shown in Figure 3.

 2.3 Typed Wildcard FEC Format for new FEC 

   [RFC5918] defines the general notion of a "Typed Wildcard" FEC
   Element, and requires FEC designer to specify a typed wildcard FEC
   element for newly defined FEC element types. This document defines
   two new FEC elements, "P2MP PW Upstream" and "P2P PW Downstream" FEC
   element, and hence requires us to define their Typed Wildcard format.


   [PW-TWC-FEC] defines Typed Wildcard FEC element format for other PW
   FEC Element types (PWid and Gen. PWid FEC Element) in section 2 as
   follows:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |Typed Wcard=0x5|Type=PW FEC|   Len = 3    |R|   PW type   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    . . .      | PMSI Tun Type |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
SB> It might be my cut and paste, it may be a layout error in the original.


 Sivabalan & Boutros      Expires April 24, 2017                [Page 11]

INTERNET DRAFT                  P2MP PW                 October 21, 2016


            Figure 5: Typed Wildcard Format for P2MP PW FEC Elements

   [PW-TWC-FEC] specifies that "Type" field can be either "PWid" (0x80)


 or "Generalized PWid" (0x81) FEC element type. This document reuses
   the existing typed wildcard format as specified in [PW-TWC-FEC] and
   illustrated in Figure 5. We extend the definition of "Type" field to
   also include "P2MP PW Upstream" and "P2P PW Downstream" FEC element
   types, as well as add an additional field "PMSI Tun Type". We reserve
   PMSI tunnel Type 0xFF to mean "wildcard" transport tunnel type. This
   "wildcard" transport tunnel type can be used in a typed wildcard p2mp
   FEC for further filtering. This field only applies to Typed wildcard
   P2MP PW Upstream FEC and MUST be set to "wildcard" for "P2P PW
   Downstream FEC" typed wildcard element.


SB> These are changes to an MPLS data structure, so I think that we need to
SB> ask the MPLS WG to review.

==================


3. LDP Capability Negotiation


   In line with requirements listed in [RFC5561], the following TLV is
   defined to indicate the P2MP PW capability:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |U|F| P2MP PW Capability (0x703)|            Length             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |S| Reserved    |    Reserved   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



                     Figure 7: LDP P2MP PW Capability TLV

SB> Same comment about draft text including assumed codepoint values. 703 might
SB> have gone before you get published! 

=================

4. P2MP PW Status 

   In order to support the proposed mechanism, a node MUST be capable of
   handling PW status. As such, PW status negotiation procedure
   described in [RFC4447] is not applicable to P2MP PW.

SB> So is there a protocol action on discovering that a peer does not
SB> support this?

   Once an L-PE successfully processes a Label Mapping Message for a
   P2MP PW, it MUST send appropriate PW status according to the
   procedure specified [RFC4447] to notify the PW status. If there is no
   PW status notification required, then no PW status notification is
   sent (for example if the P2MP PW is established and operational with
   a status code of Success (0x00000000), pw status message is not
   necessary). PW status message sent from any L-PE to R-PE contains P2P
   PW Downstream FEC to identify the PW.

SB> I could not parse the sentence above.

   An R-PE also sends PW status to L-PE(s) to reflect its view of a P2MP
   PW state. Such PW status message contains P2MP PW Upstream FEC to
   identify the PW.

   Connectivity status of the underlying P2MP LSP that P2MP PW is
   associated with, can be verified using LSP Ping and Traceroute
   procedures described in [P2MP-LSP-PING].

5 Security Considerations

   The security measures described in [RFC4447] is adequate for the  
   proposed mechanism.

SB> You really need to point at the security section in draft-ietf-pals-rfc4447bis
SB> This has had a more recent security review and will replace RFC4447
SB> by the time this draft becomes an RFC.

==============

 7  IANA Considerations

7.1. FEC Type Name Space

   This document uses two new FEC element types, number 0x82 and 0x83
   will be requested as an allocation from the registry "FEC Type Name
   Space" for the Label Distribution Protocol (LDP RFC5036):

      Value    Hex    Name                               Reference
      -------  -----  -----------------------------      ---------
       130     0x82   P2MP PW Upstream FEC Element       RFCxxxx
       131     0x83   P2P PW Downstream FEC Element      RFCxxxx

SB> The text is not correct. You have requested an early allocation of these
SB> values, and you need to ask that although the early allocation has technically
SB> expired they be allocated to this RFC.

7.2. LDP TLV Type

   This document uses a new LDP TLV types, IANA already maintains a
   registry of name "TLV TYPE NAME SPACE" defined by RFC5036. The
 


Sivabalan & Boutros      Expires April 24, 2017                [Page 14]

INTERNET DRAFT                  P2MP PW                 October 21, 2016


   following values are suggested for assignment:

         TLV type  Description:

         0x0703   P2MP PW Capability TLV

7.3. mLDP Opaque Value Element TLV Type

   This document requires allocation of a new mLDP Opaque Value Element
   Type from the LDP MP Opaque Value Element type name space defined in
   [mLDP].

SB> You should give the name of the namespace directly rather than through a reference
SB> Because IANA are such nice people, I prefer to request that they do things.

   The following value is suggested for assignment:

         TLV type  Description
         0x3       L2VPN-MCAST application TLV

7.4. Selective Tree Interface Parameter sub-TLV Type

   This document requires allocation of a sub-TLV from the registry
   "Pseudowire Interface Parameters Sub-TLV Type".


   The following value is suggested for assignment:

         TLV type  Description
         0x0D      Selective Tree Interface Parameter.

SB> 0x0d is already taken!
SB.
0x0D up to 256 bytes ROHC over MPLS configuration [RFC3241] [RFC4901] 
SB> How much of this is deployed? Because if you have deployed
SB> we have a problem.


 7.5. WildCard PMSI tunnel type.

      This document requires the allocation of PMSI tunnel Type 0xFF to 
    mean wildcard transport tunnel type


SB> You need to ask IANA to allocate a specific code point in a specific
SB> registry. Please use the the format of the registry.
SB>
SB> Taking the FF value can be a big deal, and needs to be 
SB> co-ordinated with the registry "owner", who I think is MPLS. Has
SB> this been discussed by the MPLS WG?

 8  References

8.1. Normative References

======================

   [RFC4447] "Transport of Layer 2 Frames Over MPLS", Martini, L., et
   al., RFC 4447, April 2006.
SB> This needs to point to RFC4447bis which will be an RFC in the next few weeks.



- Stewart
--------------42BAD071E420D5F4D077FBA0-- From nobody Mon Nov 28 06:53:55 2016 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAEA1129F0E for ; Mon, 28 Nov 2016 06:53:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 n5RBNerOXqxT for ; Mon, 28 Nov 2016 06:53:52 -0800 (PST) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 591721295FF for ; Mon, 28 Nov 2016 06:53:52 -0800 (PST) Received: by mail-wm0-x231.google.com with SMTP id t79so157219824wmt.0 for ; Mon, 28 Nov 2016 06:53:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=to:cc:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding; bh=7dihVzqkmOQeYYJG4IAoVly/I5o0FbAX932zAhgh69s=; b=o2I+DIrSX3KpI+WP7/jaK+d8LisiOZaA1cV7QP8U+k2e3nV1CmmJNlKeeUBEbfmcjk 29fbw9hkutNb1y6kH40EAnhy1UYF1OB9oqwt3v+LVOnPDgzjeeUZN6Qjm5KQEYTj1tiX 1uN2cFYwYfql8vXhqfWV2fGuMIiXN8aWhY7QO2qnJ+2VrMDouij1n9uUCF/NnvyA+pf/ 4AJ1qlhlBFTGmW+kGUxEgWEoQMo0zF5TTJiQNzFWSyLJLjJBm+68zI9jfCMAINmVId3C p2YE38LxY6CTXBXkbRGuM60tK3y2vKAVb1EV0HLqs4d4M/VDJPpeQ23YdJhTaBGr6o7L yb4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:to:cc:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=7dihVzqkmOQeYYJG4IAoVly/I5o0FbAX932zAhgh69s=; b=XdFFetDXKDKeIjqh+vvQMbGLtGFwExrD/+7q7IYwiVVpQgJHM1DhAMJHUHyqNOCjSt gEjjLiOu7LCd89f+CL5xVekk2K7fZNvxeyVVerVCgtkXzHD4t3m1CoZq7BwZaRg4s5yO x5y90dzG1HhMdAHzOy33BTdfGAbagzkkSHnoeVw4vctxItsTbd5+Eq+s36QYMulaD5s8 TWTqTXPiVBfbJWcdhqhCLraFUrHOgwqMSAl7o1qW4UkQ058Dv7vYwdr6Vg5G6jbUa+3n /Qs6ht0UHX5zNUCoicTwNc+TM9sgoalNxPjshv0KfYoIm8IUfo6MobEhG1Gw5+9YfJuF oPLw== X-Gm-Message-State: AKaTC009EH6a/nid2d6zGinX04X/Sn6i0cPBZz1uq+z8qXGzP2xuzWG1FeVUZCgaHpvNaA== X-Received: by 10.28.126.11 with SMTP id z11mr20996978wmc.87.1480344830925; Mon, 28 Nov 2016 06:53:50 -0800 (PST) Received: from [192.168.2.131] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id ba10sm62831087wjb.32.2016.11.28.06.53.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 28 Nov 2016 06:53:50 -0800 (PST) To: "pals@ietf.org" From: Stewart Bryant Message-ID: Date: Mon, 28 Nov 2016 14:53:46 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "pals-chairs@tools.ietf.org" Subject: [Pals] Volunteer(s) required to review draft-ietf-pals-p2mp-pw X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2016 14:53:53 -0000 I have not seen any comments on draft-ietf-pals-p2mp-pw-01.txt The draft needs a revised version. Please can I have on or two volunteers to -02 in detail. Thanks Stewart From nobody Tue Nov 29 11:10:55 2016 Return-Path: X-Original-To: pals@ietf.org Delivered-To: pals@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E6C841294A2; Tue, 29 Nov 2016 10:41:32 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.38.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148044489290.11776.7642468053154640710.idtracker@ietfa.amsl.com> Date: Tue, 29 Nov 2016 10:41:32 -0800 Archived-At: X-Mailman-Approved-At: Tue, 29 Nov 2016 11:10:54 -0800 Cc: db3546@att.com, draft-ietf-pals-rfc4447bis.all@ietf.org, pals-chairs@ietf.org, The IESG , pals@ietf.org, stewart.bryant@gmail.com, draft-ietf-pals-rfc4447bis@ietf.org, rfc-editor@rfc-editor.org Subject: [Pals] Protocol Action: 'Pseudowire Setup and Maintenance using the Label Distribution Protocol' to Internet Standard (draft-ietf-pals-rfc4447bis-05.txt) X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Nov 2016 18:41:33 -0000 The IESG has approved the following document: - 'Pseudowire Setup and Maintenance using the Label Distribution Protocol' (draft-ietf-pals-rfc4447bis-05.txt) as Internet Standard This document is the product of the Pseudowire And LDP-enabled Services Working Group. The IESG contact persons are Alvaro Retana, Alia Atlas and Deborah Brungard. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-pals-rfc4447bis/ Technical Summary Layer 2 services (such as Frame Relay, Asynchronous Transfer Mode, and Ethernet) can be "emulated" over an MPLS backbone by encapsulating the Layer 2 Protocol Data Units (PDU) and then transmitting them over "pseudowires". It is also possible to use pseudowires to provide low-rate Time Division Multiplexed and Synchronous Optical NETworking circuit emulation over an MPLS-enabled network. This document specifies a protocol for establishing and maintaining the pseudowires, using extensions to the Label Distribution Protocol (LDP). Procedures for encapsulating Layer 2 PDUs are specified in a set of companion documents. This document has been written to address errata in a previous version of this standard. Working Group Summary This was reviewed by the WG. There is nothing contentious. Document Quality This document addresses errata in previous versions of RFC 6723, RFC 4447. There are many implementations of this protocol. Refer to Section 10 of document. Personnel Who is the Document Shepherd for this document? Stewart Bryant Who is the Responsible Area Director? Deborah Brungard IANA Note Changes for the IANA section: OLD: 8. IANA Considerations The authors request that IANA remove this section before publication and that IANA update any references to [RFC4447] in their registries to refer to this document. NEW: 8. IANA Considerations 8.1. LDP TLV TYPE This document uses several new LDP TLV types; IANA already maintains a registry of name "TLV TYPE NAME SPACE" defined by RFC 5036. The following values are suggested for assignment: TLV type Description ===================================== 0x096A PW Status TLV 0x096B PW Interface Parameters TLV 0x096C Group ID TLV 8.2. LDP Status Codes This document uses several new LDP status codes; IANA already maintains a registry of name "STATUS CODE NAME SPACE" defined by RFC 5036. The following values are suggested for assignment: Range/Value E Description Reference ------------- ----- ---------------------- --------- 0x00000024 0 Illegal C-Bit [RFC4447] 0x00000025 0 Wrong C-Bit [RFC4447] 0x00000026 0 Incompatible bit-rate [RFC4447] 0x00000027 0 CEP-TDM mis-configuration [RFC4447] 0x00000028 0 PW Status [RFC4447] 0x00000029 0 Unassigned/Unrecognized TAI [RFC4447] 0x0000002A 0 Generic Misconfiguration Error [RFC4447] 0x0000002B 0 Label Withdraw PW Status Method [RFC4447] 8.3. FEC Type Name Space This document uses two new FEC element types, 0x80 and 0x81, from the registry "FEC Type Name Space" for the Label Distribution Protocol (LDP RFC 5036). NOTE TO IANA: IANA needs to update any references to [RFC4447] in their registries to refer to this document. No other action is needed. RFC Editor Notes: Figure 2 appears to be missing a couple of forward/backslashes in the ASCII art drawing. Please add them. OLD: +-------+---------+ ___________ +---------+-------+ | / | +===============/ PSN ===============+ / _____________/ NEW: +-------+---------+ ____________ +---------+-------+ | / \ | +===============/ PSN \===============+ \ / \____________/ At the end of the Abstract: OLD: This document has been written to address errata in a previous version of this standard. NEW: This document is a rewrite of RFC 4447 for publication as an Internet Standard In section 9.1: OLD: When an MPLS PSN is used to provide pseudowire service, there is a perception that security MUST be at least equal to the currently deployed Layer 2 native protocol networks that the MPLS/PW network NEW: When an MPLS PSN is used to provide pseudowire service, there is a perception that security must be at least equal to the currently deployed Layer 2 native protocol networks that the MPLS/PW network OLD: 14. Author Information Luca Martini Cisco Systems, Inc. 1899 Wynkoop Street Suite 600 Denver, CO, 80202 e-mail: lmartini@cisco.com NEW: 14. Author Information Luca Martini Cisco Systems, Inc. 1899 Wynkoop Street Suite 600 Denver, CO, 80202 e-mail: lmartini@monoski.com Please update all references to RFC4447 in the IANA section to the correct RFC number for this document. Note: While this document obsoletes RFC6723 and RFC4447, it does not update RFC6073. From nobody Wed Nov 30 15:52:45 2016 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A0C2129C07; Wed, 30 Nov 2016 15:52:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.098 X-Spam-Level: X-Spam-Status: No, score=-107.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no 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 EgDDd5Y5XPXN; Wed, 30 Nov 2016 15:52:23 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06FC9129BE7; Wed, 30 Nov 2016 15:52:05 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id E400EB808B5; Wed, 30 Nov 2016 15:52:04 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20161130235204.E400EB808B5@rfc-editor.org> Date: Wed, 30 Nov 2016 15:52:04 -0800 (PST) Archived-At: Cc: drafts-update-ref@iana.org, pals@ietf.org, rfc-editor@rfc-editor.org Subject: [Pals] RFC 8024 on Multi-Chassis Passive Optical Network (MC-PON) Protection in MPLS X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2016 23:52:35 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8024 Title: Multi-Chassis Passive Optical Network (MC-PON) Protection in MPLS Author: Y. Jiang, Ed., Y. Luo, E. Mallette, Ed., Y. Shen, W. Cheng Status: Standards Track Stream: IETF Date: November 2016 Mailbox: jiangyuanlong@huawei.com, dennis.luoyong@huawei.com, edwin.mallette@gmail.com, yshen@juniper.net, chengweiqiang@chinamobile.com Pages: 16 Characters: 33671 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-pals-mc-pon-05.txt URL: https://www.rfc-editor.org/info/rfc8024 DOI: 10.17487/RFC8024 Multiprotocol Label Switching (MPLS) is being extended to the edge of operator networks including the network access nodes. Separately, network access nodes such as Passive Optical Network (PON) Optical Line Terminations (OLTs) have evolved to support first-mile access protection, where one or more physical OLTs provide first-mile diversity to the customer edge. Multihoming support is needed on the MPLS-enabled PON OLT to provide resiliency for provided services. This document describes the Multi-Chassis PON (MC-PON) protection architecture in MPLS and also specifies the Inter-Chassis Communication Protocol (ICCP) extension to support it. This document is a product of the Pseudowire And LDP-enabled Services Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC

On 8 Nov 2016, at 12:10, Andrew G. Malis = <agmalis@gmail.com> wrote:

In case you missed this email on the PALS = list ...

---------- Forwarded message ----------
From: Mike Bartlett <Mike.Bartlett@metaswitch.com>
Date: Mon, Nov 7, 2016 at 7:01 AM
Subject: = [Pals] Apparent inconsistency between RFC5061 and RFC4762
To: "pals@ietf.org" <pals@ietf.org>

All,

 

It seems to me that there is an inconsistency between = RFC5601 (=E2=80=9CPseudowire MIB=E2=80=9D) and RFC4762 (=E2=80=9CVPLS = Using LDP Signaling=E2=80=9D).  I would like to hear people=E2=80=99s= views on whether this is indeed the case, or whether I have misunderstood.

 

Let=E2=80=99s say I have 3 PEs =E2=80=9CPE1=E2=80=9D, = =E2=80=9CPE2=E2=80=9D and =E2=80=9CPE3=E2=80=9D, with IP addresses = 1.1.1., 2.2.2.2 and 3.3.3.3 respectively.  I want to create a = full-mesh VPLS service with the pwTable specified in RFC5601, using the Generalized PWid FEC (i.e. FEC type = 129).  The question is =E2=80=93 how do I configure the 2 pwTable = rows on PE1?

 

According to RFC4762, section 6.1.1, the AGI is the = unique name of the VPLS (e.g. =E2=80=9CVPLS1=E2=80=9D), and the TAII and = SAII are both null. 

 

   Attachment Group Identifier (AGI), = Length, Value: The unique name of

   this = VPLS.  The AGI identifies a type of name, and Length denotes the

   length of Value, which is the name of the = VPLS.  We use the term AGI

   = interchangeably with VPLS identifier.

 

   Target = Attachment Individual Identifier (TAII), Source Attachment

   Individual Identifier (SAII): These are null = because the mesh of PWs

   in a VPLS terminates on MAC learning = tables, rather than on

   individual attachment circuits.  The = use of non-null TAII and SAII is

   reserved for = future enhancements.

 

This suggests that the pwTable configuration on PE1 = should look like this:

 

=C2=B7         pwIndex =3D 1, pwGroupAttachmentID =3D =E2=80=9CVPLS1=E2=80= =9D, pwLocalAttachmentID =3D =E2=80=9C=E2=80=9D, pwRemoteAttachmentID =3D = =E2=80=9C=E2=80=9D, pwPeerAddr =3D =E2=80=9C2.2.2.2=E2=80=9D

=C2=B7         pwIndex =3D 2, pwGroupAttachmentID =3D =E2=80=9CVPLS1=E2=80= =9D, pwLocalAttachmentID =3D =E2=80=9C=E2=80=9D, pwRemoteAttachmentID =3D = =E2=80=9C=E2=80=9D, pwPeerAddr =3D =E2=80=9C3.3.3.3=E2=80=9D

 

However, this contradicts RFC5601, specifically its = definition in section 12 of the reverse-lookup table = pwGenFecIndexMappingTable, which states that the {AGI, SAII, TAII} triplet must be unique for a PW using the generalized PWid FEC = (type 129).

 

  pwGenFecIndexMappingTable  = OBJECT-TYPE

     SYNTAX   =      SEQUENCE OF PwGenFecIndexMappingEntry

     MAX-ACCESS    = not-accessible

     = STATUS        current

     DESCRIPTION

          "This = table enables the reverse mapping of the unique

           = PWid parameters [GroupAttachmentID, LocalAttachmentID,

     =       and PeerAttachmentID] and the = pwIndex.  The table is

           = only applicable for PW using the generalized FEC."

     = ::=3D { pwObjects 12 }

 

Note that the corresponding reverse lookup table = pwIndexMappingTable for type-128 FECs has a critical difference, in that = it includes the peer IP Address as one of the unique PW identifiers:

 

  pwIndexMappingTable  OBJECT-TYPE

     = SYNTAX        SEQUENCE OF = PwIndexMappingEntry

     MAX-ACCESS    = not-accessible

     = STATUS        current

     DESCRIPTION

          "This = table enables the reverse mapping of the unique

           = PWid parameters [peer IP, PW type, and PW ID] and the

           = pwIndex.  The table is not applicable for PWs created

           = manually or by using the generalized FEC."

     = ::=3D { pwObjects 7 }

 

It seems to me that pwGenFecIndexMappingTable should = have the peer IP address as a 4th =E2=80=9Cunique = PWid parameter=E2=80=9D.  Otherwise, these parameters cannot = uniquely identify a PW that belongs to an RFC4762-compliant VPLS.

 

Please let me know what you think.  My apologies if = this has already been discussed before.

 

Thanks,

 

Mike Bartlett
mike.bartlett@metaswitch.com

 


_______________________________________________
Pals mailing list
Pals@ietf.org
https://www.ietf.org/mailman/listinfo/pals