[bess] Question regarding RFC7361 implementations (received errata)

"Andrew G. Malis" <agmalis@gmail.com> Sun, 31 May 2015 13:28 UTC

MIME-Version: 1.0
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/bess/K5DtZL_YNPy9dlNlTRYcnlE_5FY>
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: [bess] Question regarding RFC7361 implementations (received errata)
Precedence: list

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

[bess] Question regarding RFC7361 implementations… Andrew G. Malis