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

Giles Heron <giles.heron@gmail.com> Tue, 08 November 2016 18:57 UTC

Return-Path: <giles.heron@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 984B9129D91; Tue, 8 Nov 2016 10:57:36 -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 EgZgnyXy726k; Tue, 8 Nov 2016 10:57:34 -0800 (PST)
Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (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 97F6D12965E; Tue, 8 Nov 2016 10:57:33 -0800 (PST)
Received: by mail-wm0-x235.google.com with SMTP id a197so264242465wmd.0; Tue, 08 Nov 2016 10:57:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=i6U3v5BoEa5A8qb7BMLBthr5BuEQX3hb+k17zU9/wT4=; b=wBVR20HSJ55W2/IMeCxiGSLfBZW3CN/bM4piLsIJcYE/ZfSGcjXmNj8H8BczxCuAC8 n3Uv1rpmkBu7juIkKH5mNfHM3NNtGzIOs6M9iwXqWzE9JiGNsJnlBDXs12KSZeAR76OA Sl72mGlxisr5NIxE3m7QZjVs1kCJKF1XoXjLFdXXbKfkqGiYDWKy9zqow/IcH8s3in0D QGPkqF1HZ0l7GvJmNyAynWkbRIJm6c5UmoWrBdj6gHOrdwb3wD0txCtmhPlVN9Xs5wN2 yOOyPxA3rFga2wj147TlGtN1wFwTJZwlKEiwXVJvaXm7G26I85pPvcP7PeZMu/tfonKy JWfg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=i6U3v5BoEa5A8qb7BMLBthr5BuEQX3hb+k17zU9/wT4=; b=XpPNOqZDHxqGoO1aAJnwDcgizT/3g9vxDZX3iMueprM2Nf3X194l8L+VeveGGNRJBo MgNPzWLWOv9X5cJAAjx0Uo6IVhNlb8yKKav6rmK5me6lDuB+npSNamOJ14xOKqRMnbTU U8wkMaHNXOtCGSXfVfzFwrrH3uB72x7kdhYm/Pb4jMO6YN9LzqpVZEr8Q0+hLEZ87Sts WkgRjFEKLe6wbNpydgQ/BVWkhPkeUw8Cn0CvqjcuZtBmRaMEAhn1CmZBhLQXFydiZLR4 xNmAVOezc42RAWdDDGtJAyBOWHM5Kg7FKbuJ1QPf+V6KLJLNAlyxfyPsRI70C1QF3H+b xy+g==
X-Gm-Message-State: ABUngveak/UsscZpjc0knysTOQ/9o9EalsK1Qmd4qYUvjZzFD4IKep84hFxk3ImtFMUpvQ==
X-Received: by 10.194.222.105 with SMTP id ql9mr13809441wjc.63.1478631452084; Tue, 08 Nov 2016 10:57:32 -0800 (PST)
Received: from ams-giheron-8915.cisco.com ([173.38.220.41]) by smtp.gmail.com with ESMTPSA id g17sm38633003wjs.38.2016.11.08.10.57.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 08 Nov 2016 10:57:31 -0800 (PST)
From: Giles Heron <giles.heron@gmail.com>
Message-Id: <3337AFD2-754D-4E22-A752-400F5D4CEA35@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_061AAA05-EB2A-4359-9DF8-8C5021EA3FF3"
Mime-Version: 1.0 (Mac OS X Mail 10.0 \(3226\))
Subject: Re: To the attention of PW MIB and/or VPLS configuration experts out there ...
Date: Tue, 8 Nov 2016 18:57:29 +0000
In-Reply-To: <CAA=duU3wDqkWz+6gKZxC3FTENdxC1HR9SVsSN17koQoPVvdJAQ@mail.gmail.com>
To: "Andrew G. Malis" <agmalis@gmail.com>
References: <CAA=duU3wDqkWz+6gKZxC3FTENdxC1HR9SVsSN17koQoPVvdJAQ@mail.gmail.com>
X-Mailer: Apple Mail (2.3226)
Archived-At: <https://mailarchive.ietf.org/arch/msg/l2vpn/dEA2b8cuRRot4C2RM0U3zwOD7p4>
Cc: "l2vpn@ietf.org" <l2vpn@ietf.org>, david.zelig@compassnetworks.com, "pals@ietf.org" <pals@ietf.org>
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 18:57:36 -0000

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