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

["Andrew G. Malis" <[e-mail]>]

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

---------- Forwarded message ----------
From: Mike Bartlett <[e-mail]>
Date: Mon, Nov 7, 2016 at 7:01 AM
Subject: [Pals] Apparent inconsistency between RFC5061 and RFC4762
To: "[e-mail]" <[e-mail]>

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
*[e-mail]* <[e-mail]>



_______________________________________________
Pals mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/pals