Re: [Pals] Apparent inconsistency between RFC5061 and RFC4762

"Andrew G. Malis" <agmalis@gmail.com> Tue, 08 November 2016 12:05 UTC

Return-Path: <agmalis@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 C71DE126FDC; Tue, 8 Nov 2016 04:05:24 -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 aM8EY-tKan0w; Tue, 8 Nov 2016 04:05:18 -0800 (PST)
Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::22f]) (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 57276129556; Tue, 8 Nov 2016 04:05:18 -0800 (PST)
Received: by mail-yw0-x22f.google.com with SMTP id r204so172187601ywb.0; Tue, 08 Nov 2016 04:05:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=cFyew3okzbivjHg1LIk5Vcx1kVLBXIchCO2IIRWfcV0=; b=rm6mMyinMAgc7PGFtveJiHHOwC4JCa3SMFN4/YMoZuCDbORAaZam1MwmP7Do69+YeN NyDngObRyVd0ZAXTZJP9Dk0XcZuewldiN00pVr1sPCMZw/Ra1QT2Boh+lnyxVeRWXLqd XBfE6QUVMEQUleEnkAJP8Hw2IXBdz5QiiRBQisA1l5ozBpzI5qXV1EJQ5TFJJc5BGjx3 /tIIo6e+hbmhTaqKbrVSv99DRkYeAHrLXvMu11VdpO5MkVcZZqGBIWMm6zTLluSp9AQI jgAc68Zu3IVBQVo+pYo2HoxcS4RheCtQC5S/q5u0OkxOJ4MhPD3119wA5pXAidtYlvlW hoOA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=cFyew3okzbivjHg1LIk5Vcx1kVLBXIchCO2IIRWfcV0=; b=dhrvQpa46FD/KVm/ZC/dGx8X+Ka8qhSUrwuDDbormbfWIDVeWSAyr8mI3CmlERDzAY 9oBUYS1ANTjDqQErPusCBTLszot9oMeCq0lTHKlG6XgRZxk/VEetXUhpY++Q64Sxs/fn kCNyDsOrpXF78xLwODWQbHGSx+Plp2vyw5oxSdSI4t1B/HPNKbOq7EePv2/wLg8W8owW NE5YYHdMlxRtIEGomcEkF9Iu8z/Nlya97GrsxI1OubbJtLcRuBC5Z0S10ZIs/dG+rSUL t4CrGl5PTiixaAh7MNN0Z+p2um3MtMc82lo1wYzd705RsB64l/lref4d/w4ACGQW5HxN LP3w==
X-Gm-Message-State: ABUngveUZXAGg7AEZdTU+BpxkLRZEiRbbz4YBwjVJ1PVuDPAyyL2HBtAuatktnhW0FThxz8W9PGw6kUEilN+bA==
X-Received: by 10.157.45.166 with SMTP id g35mr540844otb.223.1478606717599; Tue, 08 Nov 2016 04:05:17 -0800 (PST)
MIME-Version: 1.0
Received: by 10.182.150.42 with HTTP; Tue, 8 Nov 2016 04:04:57 -0800 (PST)
In-Reply-To: <BN3PR0201MB10732D4090F5541CBEE50A8892A70@BN3PR0201MB1073.namprd02.prod.outlook.com>
References: <BN3PR0201MB10732D4090F5541CBEE50A8892A70@BN3PR0201MB1073.namprd02.prod.outlook.com>
From: "Andrew G. Malis" <agmalis@gmail.com>
Date: Tue, 8 Nov 2016 07:04:57 -0500
Message-ID: <CAA=duU3G_RfXqGnVYRNdTKRRQtH6wc6QVXtb1Mw2skmBU2LPiA@mail.gmail.com>
Subject: Re: [Pals] Apparent inconsistency between RFC5061 and RFC4762
To: Mike Bartlett <Mike.Bartlett@metaswitch.com>
Content-Type: multipart/alternative; boundary=94eb2c04e9302a434c0540c8f4b1
Archived-At: <https://mailarchive.ietf.org/arch/msg/l2vpn/EsZgOkjDZSfRKGHvRFQPukSXis4>
Cc: "l2vpn@ietf.org" <l2vpn@ietf.org>, "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 12:05:25 -0000

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