From nobody Tue Nov 8 04:05:26 2016 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@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: Subject: Re: [Pals] Apparent inconsistency between RFC5061 and RFC4762 To: Mike Bartlett Content-Type: multipart/alternative; boundary=94eb2c04e9302a434c0540c8f4b1 Archived-At: Cc: "l2vpn@ietf.org" , "pals@ietf.org" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Layer 2 Virtual Private Networks 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:10:59 2016 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@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: Subject: To the attention of PW MIB and/or VPLS configuration experts out there ... To: "pals@ietf.org" , "l2vpn@ietf.org" Content-Type: multipart/alternative; boundary=001a11413ccc4532d80540c908c2 Archived-At: X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Layer 2 Virtual Private Networks 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:41 2016 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@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\)) Subject: Re: To the attention of PW MIB and/or VPLS configuration experts out there ... 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" , david.zelig@compassnetworks.com, "pals@ietf.org" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Layer 2 Virtual Private Networks 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 11:24:56 2016 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A847F1296C6; Tue, 8 Nov 2016 11:24:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.699 X-Spam-Level: X-Spam-Status: No, score=-105.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497, 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 m9qN4KRbknDW; Tue, 8 Nov 2016 11:24:47 -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 7F3A51295A0; Tue, 8 Nov 2016 11:24:47 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 69548B817D3; Tue, 8 Nov 2016 11:24:47 -0800 (PST) To: prakash.ragunathan@yahoo.com, mlasserre@alcatel-lucent.com, vach.kompella@alcatel-lucent.com Subject: [Errata Held for Document Update] RFC4762 (4834) X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Message-Id: <20161108192447.69548B817D3@rfc-editor.org> Date: Tue, 8 Nov 2016 11:24:47 -0800 (PST) Archived-At: Cc: l2vpn@ietf.org, iesg@ietf.org, db3546@att.com, rfc-editor@rfc-editor.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2016 19:24:49 -0000 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

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