Re: [Pals] Apparent inconsistency between RFC5061 and RFC4762

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 <Mike.Bartlett@metaswitch.com>
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.
>
>
>
>    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
>
>