Subject: [Pals] Apparent inconsistency between RFC5061 and RFC4762

From: Mike Bartlett <[email-masked]>
Date: Mon, 7 Nov 2016 12:01:45 +0000

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
[email-masked]<mailto:[email-masked]>

---

From: "Andrew G. Malis" <[email-masked]>
Date: Tue, 8 Nov 2016 07:04:57 -0500

Mike,

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

Cheers,
Andy

On Mon, Nov 7, 2016 at 7:01 AM, Mike Bartlett <[email-masked]>
wrote:

> 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.
>
>
>
> ·         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).
>
>
>
> 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:
>
>
>
> 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.
>
>
>
> [email-masked]* <[email-masked]>
>
>
>
> _______________________________________________
> Pals mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pals
>
>