To the attention of PW MIB and/or VPLS configuration experts out there ...

"Andrew G. Malis" <agmalis@gmail.com> Tue, 08 November 2016 12:10 UTC

Return-Path: <agmalis@gmail.com>
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" <agmalis@gmail.com>
Date: Tue, 8 Nov 2016 07:10:34 -0500
Message-ID: <CAA=duU3wDqkWz+6gKZxC3FTENdxC1HR9SVsSN17koQoPVvdJAQ@mail.gmail.com>
Subject: To the attention of PW MIB and/or VPLS configuration experts out there ...
To: "pals@ietf.org" <pals@ietf.org>, "l2vpn@ietf.org" <l2vpn@ietf.org>
Content-Type: multipart/alternative; boundary=001a11413ccc4532d80540c908c2
Archived-At: <https://mailarchive.ietf.org/arch/msg/l2vpn/eWMONzNctcHcdXuVIKVd5bUgx1c>
X-BeenThere: l2vpn@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Layer 2 Virtual Private Networks <l2vpn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/l2vpn>, <mailto:l2vpn-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/l2vpn/>
List-Post: <mailto:l2vpn@ietf.org>
List-Help: <mailto:l2vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/l2vpn>, <mailto:l2vpn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Nov 2016 12:10:58 -0000

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 (“Pseudowire
MIB”) and RFC4762 (“VPLS Using LDP Signaling”).  I would like to hear
people’s views on whether this is indeed the case, or whether I have
misunderstood.



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 = 1, pwGroupAttachmentID = “VPLS1”, pwLocalAttachmentID =
“”, pwRemoteAttachmentID = “”, pwPeerAddr = “2.2.2.2”

·         pwIndex = 2, pwGroupAttachmentID = “VPLS1”, pwLocalAttachmentID =
“”, pwRemoteAttachmentID = “”, pwPeerAddr = “3.3.3.3”



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."

     ::= { 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."

     ::= { pwObjects 7 }



It seems to me that pwGenFecIndexMappingTable 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.  My apologies if this has already been
discussed before.



Thanks,



Mike Bartlett
*mike.bartlett@metaswitch.com* <mike.bartlett@metaswitch.com>;



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