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

Looks like a bug in the MIB to me.  Tom/David were the authors so I’ll leave it to them to respond (am guessing here at David’s email), but might be worth raising an erratum.

> 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 <mailto: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 <mailto:pals@ietf.org>" <pals@ietf.org <mailto: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 <mailto:mike.bartlett@metaswitch.com>
>  
> 
> 
> _______________________________________________
> Pals mailing list
> Pals@ietf.org <mailto:Pals@ietf.org>
> https://www.ietf.org/mailman/listinfo/pals <https://www.ietf.org/mailman/listinfo/pals>
> 
> 