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, 08 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 > >
- Re: [Pals] Apparent inconsistency between RFC5061… Andrew G. Malis