[Pals] Question regarding RFC7361 implementations (received errata)
"Andrew G. Malis" <agmalis@gmail.com> Sun, 31 May 2015 13:28 UTC
Return-Path: <agmalis@gmail.com>
X-Original-To: pals@ietfa.amsl.com
Delivered-To: pals@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5CAE1A1B4A; Sun, 31 May 2015 06:28:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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, SPF_PASS=-0.001] autolearn=ham
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 biIaVY3L3F0K; Sun, 31 May 2015 06:28:08 -0700 (PDT)
Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (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 AD4E61A1A3E; Sun, 31 May 2015 06:28:07 -0700 (PDT)
Received: by wifw1 with SMTP id w1so74746457wif.0; Sun, 31 May 2015 06:28:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc:content-type; bh=aSdi6kkNT+J6fWJmqR6RslG0Ri5O+VvE0jsK78xuiUU=; b=KL/woJLrUn897iYpH/JrM11uatL81suCApejWGJ4o5fjKS2i/GwcLYoxQ+VmBeZPc9 HS0mh27jWa+yTvKuWcNS2IQS58yKjQlIZnqcqn0eliuuhv6hQviiFP2GBj2KGPfXndyC Q6gj5a1HrJ76e367+EhzBvIZyMw5rHjhead+5f+MMmLgZwCgNvJQpt69kqApcMWLImAm j0uXXyxpTCKgPc28wAMhzRmC+y2kLuyPEpixO1HBSprOx4fZtfF1eFFVjG5g5xEs+E4+ SxymQHVsncMWC0UHdNN2D9B7aUAxVNEvLOyiWfMEtauA32HzC82WcGNpC7L23r/eqTxs HvmQ==
X-Received: by 10.180.14.193 with SMTP id r1mr12073165wic.47.1433078886368; Sun, 31 May 2015 06:28:06 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.28.65.135 with HTTP; Sun, 31 May 2015 06:27:45 -0700 (PDT)
From: "Andrew G. Malis" <agmalis@gmail.com>
Date: Sun, 31 May 2015 09:27:45 -0400
Message-ID: <CAA=duU3GUbzdX5Od+Kpj4wLv7cMyM6sY8yoQ+Px96kLZ6eLmaQ@mail.gmail.com>
To: "pals@ietf.org" <pals@ietf.org>, "bess@ietf.org" <bess@ietf.org>
Content-Type: multipart/alternative; boundary="f46d04138a9df508c4051760adb6"
Archived-At: <http://mailarchive.ietf.org/arch/msg/pals/Z2JNlLlOXVUit8TBNej1XfQEWHk>
X-Mailman-Approved-At: Sun, 31 May 2015 06:40:54 -0700
Cc: "Giles Heron (giheron)" <giheron@cisco.com>, "BRUNGARD, DEBORAH A (ATTLABS)" <db3546@att.com>, rainsword <rainsword.wang@huawei.com>, ostokes@extremenetworks.com, geraldine.calvignac@orange.com, Alia Atlas <akatlas@gmail.com>, "Fedyk, Don" <don.fedyk@hp.com>, florin.balus@alcatel-lucent.com, "Bitar, Nabil N" <nabil.n.bitar@verizon.com>, "Alvaro Retana (aretana)" <aretana@cisco.com>, pranjal.dutta@alcatel-lucent.com, Stewart Bryant <stbryant@cisco.com>
Subject: [Pals] Question regarding RFC7361 implementations (received errata)
X-BeenThere: pals@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Pseudowire And LDP-enabled Services dicussion list." <pals.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pals>, <mailto:pals-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pals/>
List-Post: <mailto:pals@ietf.org>
List-Help: <mailto:pals-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pals>, <mailto:pals-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 31 May 2015 13:28:10 -0000
I'm sending this to the PALS and BESS lists in the hopes that it'll be seen by RFC 7361 implementors. I've forwarded a received errata report regarding RFC 7361 MAC Flush Parameters sub-TLVs. I agree with the errata report in that sub-TLVs can only have an 8-bit type number, as defined in section 5.1.1, which leads me to wonder if there are implementations, and if so, how the sub-TLVs were actually implemented. I'm also concerned about the effect on existing implementations as a result of verifying the errata report. Please respond on the PALS list, we'll try to keep the conversation there. And thanks to Rainsword for spotting the discrepancy and tracking down its source. In the absence of any responses, I plan to verify the errata report. Thanks, Andy ---------- Forwarded message ---------- From: RFC Errata System <rfc-editor@rfc-editor.org> Date: Fri, May 29, 2015 at 7:04 AM Subject: [Technical Errata Reported] RFC7361 (4380) To: pranjal.dutta@alcatel-lucent.com, florin.balus@alcatel-lucent.com, ostokes@extremenetworks.com, geraldine.calvignac@orange.com, don.fedyk@hp.com, akatlas@gmail.com, db3546@att.com, aretana@cisco.com, giheron@cisco.com, nabil.n.bitar@verizon.com Cc: l2vpn@ietf.org, rfc-editor@rfc-editor.org The following errata report has been submitted for RFC7361, "LDP Extensions for Optimized MAC Address Withdrawal in a Hierarchical Virtual Private LAN Service (H-VPLS)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=7361&eid=4380 -------------------------------------- Type: Technical Reported by: rainsword <rainsword.wang@huawei.com> Section: 5.2 Original Text ------------- At least one of the following sub-TLVs MUST be included in the MAC Flush Parameters TLV if the C-flag is set to 1: o PBB B-MAC List Sub-TLV: Type: 0x0407 Length: Value length in octets. At least one B-MAC address MUST be present in the list. Value: One or a list of 48-bit B-MAC addresses. These are the source B-MAC addresses associated with the B-VPLS instance that originated the MAC withdraw message. It will be used to identify the C-MAC(s) mapped to the B-MAC(s) listed in the sub-TLV. o PBB I-SID List Sub-TLV: Type: 0x0408 Length: Value length in octets. Zero indicates an empty I-SID list. An empty I-SID list means that the flushing applies to all the I-SIDs mapped to the B-VPLS indicated by the FEC TLV. Value: One or a list of 24-bit I-SIDs that represent the I-component FIB(s) where the MAC flushing needs to take place. Corrected Text -------------- At least one of the following sub-TLVs MUST be included in the MAC Flush Parameters TLV if the C-flag is set to 1: o PBB B-MAC List Sub-TLV: Type: 0x01 Length: Value length in octets. At least one B-MAC address MUST be present in the list. Value: One or a list of 48-bit B-MAC addresses. These are the source B-MAC addresses associated with the B-VPLS instance that originated the MAC withdraw message. It will be used to identify the C-MAC(s) mapped to the B-MAC(s) listed in the sub-TLV. o PBB I-SID List Sub-TLV: Type: 0x02 Length: Value length in octets. Zero indicates an empty I-SID list. An empty I-SID list means that the flushing applies to all the I-SIDs mapped to the B-VPLS indicated by the FEC TLV. Value: One or a list of 24-bit I-SIDs that represent the I-component FIB(s) where the MAC flushing needs to take place. Notes ----- Type definition was error. The PBB B-MAC List Sub-TLV abd I-SID List Sub-TLV are only support for one byte, as defined in section 5.1.1 MAC flush parameters TLV. This error was imported from draft-ietf-l2vpn-vpls-ldp-mac-opt-12. For this version, it submit the 2 sub-tlv to IANA for alloc id. But the two kinds tlv were sub-tlv, not LDP TLV Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC7361 (draft-ietf-l2vpn-vpls-ldp-mac-opt-13) -------------------------------------- Title : LDP Extensions for Optimized MAC Address Withdrawal in a Hierarchical Virtual Private LAN Service (H-VPLS) Publication Date : September 2014 Author(s) : P. Dutta, F. Balus, O. Stokes, G. Calvignac, D. Fedyk Category : PROPOSED STANDARD Source : Layer 2 Virtual Private Networks Area : Routing Stream : IETF Verifying Party : IESG
- [Pals] Question regarding RFC7361 implementations… Andrew G. Malis