[Bier] Re: Ketan Talaulikar's Discuss on draft-ietf-bier-ping-18: (with DISCUSS and COMMENT)

[Greg Mirsky <[e-mail]>]

Hi Tony,
thank you for reviewing updates. I uploaded the updated version, so it is
available for the WG review and comments.

Regards,
Greg

On Mon, Apr 6, 2026 at 7:14 AM Tony Przygienda <[e-mail]> wrote:

> diff looks good to me and AFAIS the doc _is_ MPLS specific at this point
> in time while generic enough the according sub-TLVs for entropy around
> other technologies can be trivially added later when the needs arise. all I
> worried about
>
>
>
>
>
>
> On Tue, Mar 24, 2026 at 3:08 AM Greg Mirsky <[e-mail]> wrote:
>
>> Hi Tony,
>> Thank you so much for sharing your thoughts and suggestions to improve
>> the document. Please find my notes below, tagged GIM>>. I attached the TXT
>> copy of the working version, and the diff highlighting the proposed updates.
>>
>> Regards,
>> Greg
>>
>> On Sat, Mar 21, 2026 at 2:36 AM Tony Przygienda <[e-mail]>
>> wrote:
>>
>>> okey, I scanned the -20 version and tried to parse the conversation as
>>> far as possible. so in fact it seems we really do have some stuff that
>>> makes the draft in pieces MPLS encaps specific and I would argue along the
>>> lines of  Ketan that we should preferrably have _one_ OAM rfc covering any
>>> encaps even if it delays the publication somewhat or at least include
>>> enough "clear hooks" everywhere so future documents can easily refer to the
>>> according RFC sections
>>>
>>> so far we have
>>> * mpls and non-mpls (basically label not being label ;-) which can be
>>> stuck into
>>>    * mpls label stack
>>>    * ether type
>>>    * v4/v6 bierin6
>>>
>>> and the OAM will work AFAIS for all except pieces around entropy which
>>> seem to me quite MPLS specific
>>>
>>> "
>>> Multipath Entropy Data sub-TLV is applicable for BIER Echo Request
>>> packets encapsulated in MPLS. Encoding of multipath information for other
>>> data planes, e.g., IPv6, is for further study. If the Multipath Entropy
>>> Data sub-TLV is present in the BIER Echo Request packet encapsulated in a
>>> non-MPLS data plane, it MUST be ignored by the responding BFR.
>>> "
>>>
>>> so yes, this is MPLS specific entropy and I think the TLV should be
>>> called accordingly MPLS Multipath entropy data but it does not make the
>>> document "MPLS encaps only" AFAIS
>>>
>>> AFAIS we can easily add stuff for v6 entropy and so on later as the
>>> document says
>>>
>>> However, the section 4.2 worries me. on one hand it seems to imply that
>>> we can stick "BIER entropy value" into the multipath entropy sub-tlv", on
>>> the other hand it seems to refer back to 8029 which is MPLS specific? I
>>> think this needs to be clarified
>>>
>>> As suggestion: call the multipath entropy data sub-tlv "MPLS entropy"
>>> and allow other sub-TLVs with other entropy types since e.g. v6 flow label
>>> may interact with the bier entropy and you may want to report both back or
>>> set them both on request ?
>>>
>> GIM>> Thank you for the suggestion to clarify the sub-TLV name. Would the
>> following update throughout the draft work s/Multipath Entropy Data/MPLS
>> Multipath Entropy Data/? Furthermore, I propose clarify in the draft that
>> all actions of the ECMP discovery defined in the draft are applicable to
>> "ECMP discovery within a BIER domain with MPLS underlay". Please check the
>> diff file to review how this is applied in the document.
>>
>>>
>>> Brings up the question, what about he BIER entropy stuff being reported
>>> back and correlated? is it assumed that the sender knows what it put in the
>>> entropy field and can correlate it e.g. via the seq# of the message or that
>>> the sender will set the entropy on response?  The last paragraph of 4.2
>>> somehow seems to imply that the entropy sub-TLV can be set on reply as well
>>> which seems confirmed by
>>>
>>> "
>>> Set the Best-return-code to "Replying router is one of the BFERs in BIER
>>> header BitString", and include Downstream Mapping TLV if the responder is
>>> BFER and there are more bits in BitString left for forwarding. Also,
>>> include the Multipath information as defined in Section 4.2
>>> <https://datatracker.ietf.org/doc/html/draft-ietf-bier-ping-20#sect-4.2>
>>> if the received Echo Request carries Multipath Entropy Data Sub-TLV. Go to Section
>>> 4.5
>>> <https://datatracker.ietf.org/doc/html/draft-ietf-bier-ping-20#sect-4.5>
>>> .
>>> "
>>>
>>> and again here, I think we need to report back _all_ entropy, i.e. v6
>>> flow (which should be copied from bier entropy , bier entropy, mpls entropy
>>>
>> GIM>> Good question. I think that ECMP queries can be scoped to the
>> specific underlay, i.e., MPLS, v6, or Ethernet.
>>
>>>
>>> Otherwise I see
>>>
>>> "If the BIER-MPLS label in the received Echo Request is not the one
>>> assigned for SI in Original SI-BitString TLV, "Set-Identifier Mismatch" is
>>> set in order to report the mismatch."
>>>
>>> this applies to other encaps as well so I don't know why we'd call it
>>> BIER MPLS label, it's really BIFT-ID, isn't it?
>>>
>> GIM>> As I understand it, yes. Although in non-MPLS underlay BIER-MPLS
>> Label should be referred to as BIFT-id, according to Section 2 of RFC
>> 8296 <https://datatracker.ietf.org/doc/html/rfc8296#section-2>.
>>
>>>
>>> OAM, just like security is hard work and often unexciting but both
>>> matter a lot in long term at scale deployments and thus thanks for the
>>> effort, Greg ;-)
>>>
>> GIM>> Thanks.
>>
>>>
>>> -- tony
>>>
>>>
>>> On Sun, Mar 1, 2026 at 9:56 PM Greg Mirsky <[e-mail]>
>>> wrote:
>>>
>>>> Sorry, now with the diff
>>>>
>>>> On Sun, Mar 1, 2026 at 12:55 PM Greg Mirsky <[e-mail]>
>>>> wrote:
>>>>
>>>>> Hi Ketan,
>>>>> thank you for your thoughtful consideration and the great discussion.
>>>>> I am glad that we're converging on many points. For the remaining issues,
>>>>> please see my follow-up notes tagged GIM3>>. Also, thank you for helping to
>>>>> clarify the "IPv6 Unnumbered" issue. I read the Errata to RFC 8029 filed by
>>>>> Adrian and updated our draft accordingly. I attached the working version
>>>>> and diff highlighting applied updates.
>>>>>
>>>>> Regards,
>>>>> Greg
>>>>>
>>>>> On Thu, Feb 26, 2026 at 11:23 PM Ketan Talaulikar <
>>>>> [e-mail]> wrote:
>>>>>
>>>>>> Hi Greg,
>>>>>>
>>>>>> Thanks for sharing your responses and the proposed changes. Please
>>>>>> check inline with KT2 for follow-ups and consider the ones without
>>>>>> responses as having been addressed by your updates and/or clarifications.
>>>>>>
>>>>>>
>>>>>> On Tue, Feb 24, 2026 at 5:03 AM Greg Mirsky <[e-mail]>
>>>>>> wrote:
>>>>>>
>>>>>>> Hi Ketan,
>>>>>>> thank you for your kind consideration of proposed updates and
>>>>>>> further clarifications of your concerns. Please find my follow up notes
>>>>>>> below tagged GIM2>>. I attached the working version of the draft and the
>>>>>>> diff highlighting applied updates.
>>>>>>>
>>>>>>> Regards,
>>>>>>> Greg
>>>>>>>
>>>>>>> On Tue, Jan 27, 2026 at 7:08 AM Ketan Talaulikar <
>>>>>>> [e-mail]> wrote:
>>>>>>>
>>>>>>>> Hi Greg,
>>>>>>>>
>>>>>>>> Thanks for your response and sharing the proposed update.
>>>>>>>>
>>>>>>>> Please check inline below for responses with KT.
>>>>>>>>
>>>>>>>>
>>>>>>>> On Mon, Jan 26, 2026 at 6:54 AM Greg Mirsky <[e-mail]>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Hi Ketan,
>>>>>>>>> thank you for your comments. Please find my notes below tagged
>>>>>>>>> GIM>>. I attached the new working version of the draft and the diff
>>>>>>>>> highlighting the updates applied.
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> Greg
>>>>>>>>>
>>>>>>>>> On Thu, Jan 22, 2026 at 6:16 AM Ketan Talaulikar via Datatracker <
>>>>>>>>> [e-mail]> wrote:
>>>>>>>>>
>>>>>>>>>> Ketan Talaulikar has entered the following ballot position for
>>>>>>>>>> draft-ietf-bier-ping-18: Discuss
>>>>>>>>>>
>>>>>>>>>> When responding, please keep the subject line intact and reply to
>>>>>>>>>> all
>>>>>>>>>> email addresses included in the To and CC lines. (Feel free to
>>>>>>>>>> cut this
>>>>>>>>>> introductory paragraph, however.)
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Please refer to
>>>>>>>>>> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
>>>>>>>>>> for more information about how to handle DISCUSS and COMMENT
>>>>>>>>>> positions.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> The document, along with other ballot positions, can be found
>>>>>>>>>> here:
>>>>>>>>>> https://datatracker.ietf.org/doc/draft-ietf-bier-ping/
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ----------------------------------------------------------------------
>>>>>>>>>> DISCUSS:
>>>>>>>>>>
>>>>>>>>>> ----------------------------------------------------------------------
>>>>>>>>>>
>>>>>>>>>> Thanks to the authors and the WG for their work on this document.
>>>>>>>>>>
>>>>>>>>>> I have a number of points that I would like to DISCUSS on this
>>>>>>>>>> document that I
>>>>>>>>>> am providing inline in the idnits o/p of v16 of this document.
>>>>>>>>>>
>>>>>>>>>> Note: This is an updated ballot for v18. The points that are
>>>>>>>>>> resolved are
>>>>>>>>>> deleted but the previous number has been retained.
>>>>>>>>>>
>>>>>>>>>> 177     3.  BIER OAM
>>>>>>>>>>
>>>>>>>>>> 179        BIER OAM is defined to stay within the BIER layer by
>>>>>>>>>> directly
>>>>>>>>>> 180        following the BIER header without mandating the need
>>>>>>>>>> for an IP
>>>>>>>>>> 181        header.  [RFC8296] defines a 4-bit field as "Proto" to
>>>>>>>>>> identify the
>>>>>>>>>> 182        payload following the BIER header.  When the payload
>>>>>>>>>> is BIER OAM, the
>>>>>>>>>> 183        "Proto" field will be set to 5 as defined in [RFC8296]
>>>>>>>>>>
>>>>>>>>>> <discuss-1> I do not find the specification for setting the other
>>>>>>>>>> fields in the
>>>>>>>>>> BIER header for OAM packets besides the Proto field. I find
>>>>>>>>>> something about the
>>>>>>>>>> Entropy field usage further and about the use of BFIR-id and
>>>>>>>>>> BitString but it
>>>>>>>>>> was not clear to me. Perhaps some specification in this section
>>>>>>>>>> that covers
>>>>>>>>>> how the BIER header fields are set for BIER OAM packets would
>>>>>>>>>> help clarify
>>>>>>>>>> along with forward reference to the respective sections that
>>>>>>>>>> describe their
>>>>>>>>>> usage in further details?
>>>>>>>>>>
>>>>>>>>> GIM>> Would the following update make setting parameters in BIER
>>>>>>>>> header of a BIER OAM packet clearer:
>>>>>>>>> OLD TEXT:
>>>>>>>>>    BIER OAM is defined to stay within the BIER layer by directly
>>>>>>>>>    following the BIER header without mandating the need for an IP
>>>>>>>>>    header.  [RFC8296] defines a 4-bit field as "Proto" to identify
>>>>>>>>> the
>>>>>>>>>    payload following the BIER header.  When the payload is BIER
>>>>>>>>> OAM, the
>>>>>>>>>    "Proto" field will be set to 5 as defined in [RFC8296].
>>>>>>>>> NEW TEXT:
>>>>>>>>>    BIER OAM is defined to stay within the BIER layer by directly
>>>>>>>>>    following the BIER header without mandating the need for an IP
>>>>>>>>>    header.  To produce information that is useful to an operator,
>>>>>>>>>    information that statistically reflects conditions experienced
>>>>>>>>> by the
>>>>>>>>>    monitored data flow, the operator must be able to ensure that
>>>>>>>>> active
>>>>>>>>>    OAM packets, e.g., BIER Echo Request, traverse the set of links
>>>>>>>>> and
>>>>>>>>>    nodes and receive the same forwarding treatment as the monitored
>>>>>>>>>    flow.  Hence, all fields in the BIER header that affect packet
>>>>>>>>>    forwarding (e.g., BFIR-id, BitString) must be set to the values
>>>>>>>>>    applied to the monitored data flow.  [RFC8296] defines a 4-bit
>>>>>>>>> field
>>>>>>>>>    as "Proto" to identify the payload following the BIER header.
>>>>>>>>> When
>>>>>>>>>    the payload is BIER OAM, the "Proto" field will be set to 5 as
>>>>>>>>>    defined in [RFC8296].
>>>>>>>>>
>>>>>>>>
>>>>>>>> KT> That clarifies and clears this discussion point. Thanks.
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>>> 209           Message Type - a six-bit field that identifies OAM
>>>>>>>>>> protocol.
>>>>>>>>>> 210           Values defined in this document are as follows:
>>>>>>>>>>
>>>>>>>>>> 212                        Value      Description
>>>>>>>>>> 213                        --------  ---------------
>>>>>>>>>> 214                          1        Echo Request
>>>>>>>>>> 215                          2        Echo Reply
>>>>>>>>>>
>>>>>>>>>> <discuss-2> The handling of unknown types is undefined in this
>>>>>>>>>> base
>>>>>>>>>> specification. E.g., how are implementations expected to handle a
>>>>>>>>>> new Type 3
>>>>>>>>>> message defined by as future specification that it does not
>>>>>>>>>> recognize? While I
>>>>>>>>>> am raising the point for the message types, it also applies to
>>>>>>>>>> all levels of
>>>>>>>>>> TLVs/sub-TLVs as well. For some TLVs, when unrecognized are
>>>>>>>>>> present, the
>>>>>>>>>> operation has been specified to error out and I wanted to confirm
>>>>>>>>>> that was
>>>>>>>>>> intended given that it restricts extensions.
>>>>>>>>>>
>>>>>>>>> GIM>> In the version 18 of the draft, addressing comments from
>>>>>>>>> Med, we added the following text in Section 4.1:
>>>>>>>>>    Processing of the received BIER OAM packet with unknown value
>>>>>>>>> of the
>>>>>>>>>    Message Type field (Figure 1) is stopped and the event SHOULD be
>>>>>>>>>    logged although through the rate-controlling system.
>>>>>>>>> Do you find the text addressing your concern?
>>>>>>>>>
>>>>>>>>
>>>>>>>> KT> It does, but only partially. Btw, there is also some text on
>>>>>>>> similar lines in section 3.4. My point was there we have
>>>>>>>> several layers of message types and TLVs/sub-TLVs in this spec.
>>>>>>>> Since this document sets the "base" for BIER OAM
>>>>>>>> and defines a totally new messaging system, we need to cover
>>>>>>>> handling of unknown message types and TLVs
>>>>>>>> at all these layers. I am wondering if we can have the same error
>>>>>>>> handling at all levels. Choices are - return error and
>>>>>>>> drop the message, drop the message without error, ignore the
>>>>>>>> unknown (can be an option for optional TLVs?) and process
>>>>>>>> the message, ... anything else?
>>>>>>>>
>>>>>>> GIM2>> In version 18, we introduced the new TLV, Erroneous Echo
>>>>>>> Request. The Responder must use a TLV that cannot process a TLV in the
>>>>>>> received BIER Echo Request. I believe that returning an error with as much
>>>>>>> of the message that caused the error as possible is the most informative
>>>>>>> option for an operator. I think that must be a common handling for all
>>>>>>> unrecognized types in TLV/sub-TLV processing. Do you see anywhere in the
>>>>>>> draft that we missed specifying the handling policy?
>>>>>>>
>>>>>>
>>>>>> KT2> Fair enough. I was only bringing up the options. I would have
>>>>>> personally recommended the option to drop by default so that this does not
>>>>>> become an attack vector (especially given this is multicast), but I see how
>>>>>> the handling that you proposed may help the operator determine the error.
>>>>>> Which one is better in the field operationally, is debatable. Having had
>>>>>> the discussion on this error handling, I will leave it to the authors and
>>>>>> WG to make their choice. We can consider this discussion closed.
>>>>>>
>>>>> GIM3>> Do you think that both approaches can be controlled via a BFER
>>>>> local policy? For example, if no policy enabled, the default, as you
>>>>> suggested, is to drop unrecognized packet. If the Respond to an erroneous
>>>>> BIER Echo request enabled, then BFER sends BIER Echo Reply with the
>>>>> Erroneous Echo Request TLV. WDYT?
>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>>> <discuss-5> Regarding section 3.2. Is it possible that more than
>>>>>>>>>> one error
>>>>>>>>>> code is applicable at the responder for a given echo request? If
>>>>>>>>>> so, I assume
>>>>>>>>>> these are supposed to be an ordered set rules (called "steps" in
>>>>>>>>>> section 4.4)
>>>>>>>>>> that need to be followed by an implementation in determining the
>>>>>>>>>> Return Code?
>>>>>>>>>> Please check for redundancy between the text in this section and
>>>>>>>>>> 4.4 - best to
>>>>>>>>>> specify in one place. I am guessing the purpose of the text in
>>>>>>>>>> this section
>>>>>>>>>> was to describe those error codes, but the description includes
>>>>>>>>>> normative
>>>>>>>>>> procedures - best to do so in one place like section 4.4? This
>>>>>>>>>> still leaves
>>>>>>>>>> the part that what is needed in section 4.4 is ordering (with a
>>>>>>>>>> numbered list?)
>>>>>>>>>> - this also allows for further specifications that introduce more
>>>>>>>>>> TLVs or
>>>>>>>>>> verification checks to introduce their error codes/handling in an
>>>>>>>>>> appropriate
>>>>>>>>>> position in the sequence by updating this specification.
>>>>>>>>>>
>>>>>>>>>> <v18> The multiple error codes part is clarified, but the
>>>>>>>>>> discussion on
>>>>>>>>>> the use of a numbered list in section 4.4 remains open.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>> KT> This one seems to have been skipped. You are very familiar with
>>>>>>>> https://datatracker.ietf.org/doc/html/rfc8029#section-4.4
>>>>>>>> and how that has helped other documents to extend these procedures
>>>>>>>> for newer features.
>>>>>>>>
>>>>>>> GIM2>> Sorry, I missed this one. Moved QTF exception handling to
>>>>>>> Section 4.4; simplified RTF. Please let me know if these updates address
>>>>>>> your concern.
>>>>>>>
>>>>>>
>>>>>> KT2> Looks good.
>>>>>>
>>>>> GIM3>> Thank you.
>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>>> 558                    Type     Addr. Type       DA Length    DIA
>>>>>>>>>> Length
>>>>>>>>>> 559                   -------  ---------------   ----------
>>>>>>>>>>  ----------
>>>>>>>>>> 560                       1       IPv4 Numbered        4
>>>>>>>>>>     4
>>>>>>>>>> 561                       2       IPv4 Unnumbered      4
>>>>>>>>>>     4
>>>>>>>>>> 562                       3       IPv6 Numbered        16
>>>>>>>>>>     16
>>>>>>>>>> 563                       4       IPv6 Unnumbered      16
>>>>>>>>>>      4
>>>>>>>>>>
>>>>>>>>>> <discuss-6> What is IPv6 Unnumbered? I am not familiar with that
>>>>>>>>>> term. Could you
>>>>>>>>>> please provide a reference? Or, is this a reference to an
>>>>>>>>>> interface that
>>>>>>>>>> only has IPv6 link-local address and no IPv6 global address?
>>>>>>>>>>
>>>>>>>>> GIM>> As the result of addressing Med's comments, this list in
>>>>>>>>> version 18 was split into two:
>>>>>>>>>                Value     Address Type
>>>>>>>>>               -------    ---------------
>>>>>>>>>                   1       IPv4 Numbered
>>>>>>>>>                   2       IPv4 Unnumbered
>>>>>>>>>                   3       IPv6 Numbered
>>>>>>>>>                   4       IPv6 Unnumbered
>>>>>>>>> and
>>>>>>>>>                   Value     DA Length     DIA Length
>>>>>>>>>                  -------   ------------  ------------
>>>>>>>>>                      1           4           4
>>>>>>>>>                      2           4           4
>>>>>>>>>                      3          16          16
>>>>>>>>>                      4          16           4
>>>>>>>>> Does the new format address your concern?
>>>>>>>>> Use of IPv6 unnumbered is analogous to how IPv4 unnumbered address
>>>>>>>>> is used, i.e., on a point-to-point interface re-using another IP address,
>>>>>>>>> usually a loopback, as a source address. One of common uses is BGP
>>>>>>>>> unnumbered.
>>>>>>>>>
>>>>>>>>
>>>>>>>> KT> AFAIK the unnumbered only applies to IPv4 (i.e., an interface
>>>>>>>> w/o any IPv4 addresses of its own and so it "borrows" from the loopback).
>>>>>>>> When it comes to IPv6, we really never have an interface without an IPv6
>>>>>>>> address - there is always the link-local address. When you say
>>>>>>>> IPv6 unnumbered, are you referring to links with only IPv6
>>>>>>>> link-local addresses? Is there any RFC that uses the term IPv6 unnumbered?
>>>>>>>>
>>>>>>> GIM2>> One that comes to mind is RFC 8029. I added the reference.
>>>>>>>
>>>>>>
>>>>>> KT2> That explains where this error is originating from. However, it
>>>>>> is still wrong and let me start a separate thread on this topic.
>>>>>>
>>>>> GIM3>> Thnak you for clarifying this with the 6man WG. I updated draft
>>>>> removing IPv6 Unnumbered. Also, it seems like re-naming IPv6 Numbered as
>>>>> IPv6 Address will remove any confusion. WDYT?
>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>>> 737     3.3.7.  Upstream Interface TLV
>>>>>>>>>>
>>>>>>>>>> 739        The BFR replying to the request MUST include the
>>>>>>>>>> Upstream Interface
>>>>>>>>>> 740        TLV.  This TLV identifies the incoming interface and
>>>>>>>>>> the BIER-MPLS
>>>>>>>>>> 741        label in the incoming Echo Request.  This TLV has the
>>>>>>>>>> following
>>>>>>>>>> 742        format:
>>>>>>>>>>
>>>>>>>>>> <discuss-7> I don't see the BIER-MPLS label being carried in this
>>>>>>>>>> TLV. Am I
>>>>>>>>>> missing something? Also, I see that the ping but more so the
>>>>>>>>>> traceroute
>>>>>>>>>> procedures in this document work only for MPLS and not for other
>>>>>>>>>> data planes.
>>>>>>>>>> Am I correct? If so, perhaps this needs to be called out in the
>>>>>>>>>> abstract
>>>>>>>>>> and introduction?
>>>>>>>>>>
>>>>>>>>> GIM>> In addressing Med's comments, this section was changed as
>>>>>>>>> follows:
>>>>>>>>>
>>>>>>>>> 3.4.7.  Ingress Interface TLV
>>>>>>>>>
>>>>>>>>>    The BFR replying to the request MUST include the Ingress
>>>>>>>>> Interface
>>>>>>>>>    TLV.  This TLV identifies the incoming interface on which the
>>>>>>>>> Echo
>>>>>>>>>    Request was received.
>>>>>>>>> Do you find the text in version 18 addresses your concern?
>>>>>>>>>
>>>>>>>>
>>>>>>>> KT> It does not. There are two aspects here. The first is that I
>>>>>>>> found the TLVs missing the forwarding
>>>>>>>> information - this specific TLV is an example. Should it not
>>>>>>>> include the MPLS label (for BIER MPLS)
>>>>>>>> to provide diagnostic information? The second point is that I find
>>>>>>>> coverage for BIER MPLS in the
>>>>>>>> procedures, but the same is not there for IPv6 or native BIER. If
>>>>>>>> this document is focussing on
>>>>>>>> BIER MPLS, it can be called out and other data planes can be
>>>>>>>> specified in future documents?
>>>>>>>>
>>>>>>> GIM2>> As I understand it, the BIER WG agreed with the document and
>>>>>>> the level of diagnostic that it provides. Also, I am not familiar with
>>>>>>> "native BIER". Can you please give me an example or a reference to the
>>>>>>> document that specifies it?
>>>>>>>
>>>>>>
>>>>>> KT2> I will not further debate the utility of inclusion of the MPLS
>>>>>> Label if this has been discussed by the WG. By "native BIER" (sorry for the
>>>>>> use of an inaccurate term), I am referring to Ethernet -
>>>>>> https://www.rfc-editor.org/rfc/rfc8296.html#section-2.2 and then for
>>>>>> IPv6 there is
>>>>>> https://datatracker.ietf.org/doc/draft-ietf-bier-bierin6/ which has
>>>>>> completed WGLC. One option to resolve this point is for this document to
>>>>>> scope itself only to BIER MPLS and leave the others for future documents.
>>>>>>
>>>>> GIM3>> Thank you for pointing me to Section 2.2 of RFC 8296. After
>>>>> comparing it with the BIERin6 draft, I think that there's ambiguity in
>>>>> regard to use of Ethertype 0xAB37. Consider that IEEE assigned this value
>>>>> for non-MPLS encapsulation of BIER, as explained in RFC 8296. But in
>>>>> BIERin6, this Ethertype value is optionally used if BFRs are directly
>>>>> connected.
>>>>> But turning back to the use of the Ingress Interface TLV. It returns
>>>>> IP address of the interface the responding BFR received the BIER Echo
>>>>> Request. Would you agree that the interface IP address is unambiguous
>>>>> information that doesn't depend on the type of the underlay (MPLS, IPv6, or
>>>>> Ethernet) that transports BIER?
>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>>> 770     3.4.  Multipath Entropy Data Encoding
>>>>>>>>>>
>>>>>>>>>> 772        The size of the Entropy field in the BIER header is 20
>>>>>>>>>> bits, as
>>>>>>>>>> 773        defined in Section 2 of [RFC8296].  This encoding is
>>>>>>>>>> the same as the
>>>>>>>>>> 774        Multipath Type 9 encoding, defined in Section
>>>>>>>>>> 3.4.1.1.1 of [RFC8029].
>>>>>>>>>>
>>>>>>>>>> <discuss-8> RFC8029 talks about MPLS and how the IP destination
>>>>>>>>>> address for an
>>>>>>>>>> LSP Ping packet is encoded. I don't see how that applies to BIER
>>>>>>>>>> Echo Request.
>>>>>>>>>> What is required is perhaps the entropy encoding but I don't
>>>>>>>>>> follow how that
>>>>>>>>>> would work. Please clarify.
>>>>>>>>>>
>>>>>>>>> GIM>> As result of addressing Med's comments, this text in version
>>>>>>>>> 18 chged to:
>>>>>>>>>       The interpretaion of the Multipath Type field and Multipath
>>>>>>>>>       Entropy Data encoding options are the same defined in
>>>>>>>>>       Section 3.4.1.1 of [RFC8029].
>>>>>>>>> Do you find the latest version addresses your concern?
>>>>>>>>>
>>>>>>>>
>>>>>>>> KT> It is not clear to me. The BIER header has its own Entropy
>>>>>>>> field.
>>>>>>>> There is also the case of different data planes than just MPLS. Can
>>>>>>>> you explain how what
>>>>>>>> is defined for LSP Ping (RFC8029) multipath would work with not
>>>>>>>> just BIER MPLS but BIER
>>>>>>>> in general?
>>>>>>>>
>>>>>>> GIM2>> As I understand BIER specification and its processing in MPLS
>>>>>>> and non-MPLS networks, Section 6.7 of RFC 8279
>>>>>>> <https://datatracker.ietf.org/doc/html/rfc8279#section-6.7> discusses
>>>>>>> ECMP in a BIER domain. Section 2.1.2 of RFC 8296 specifies Entropy field
>>>>>>> and its relation with underlay encapsulations, e.g., MPLS. In regard to
>>>>>>> IPv6 tunnel transporting BIER, draft-ietf-bier-bierin6
>>>>>>> <https://datatracker.ietf.org/doc/draft-ietf-bier-bierin6/>
>>>>>>> explains that:
>>>>>>>    BIERin6 being a solution based on [RFC8279] and [RFC8296], ECMP is
>>>>>>>    inherently supported by BFRs using the the 20-bit entropy field in
>>>>>>>    the BIER header for the load balancing hash.  When a BIER packet
>>>>>>> is
>>>>>>>    transported over an IPv6 tunnel, the entropy value is copied into
>>>>>>> the
>>>>>>>    20-bit IPv6 Flow Label [RFC6437], so that routers along the tunnel
>>>>>>>    can do ECMP based on Flow Labels (instead of hashing based on
>>>>>>> 5-tuple
>>>>>>>    of an IP packet).  For a router along the tunnel doing deep packet
>>>>>>>    inspection for ECMP purpose, if it understands BIER header it can
>>>>>>> go
>>>>>>>    past the BIER header to look for the 5-tuple input key to a hash
>>>>>>>    function.  Otherwise, it stops at the BIER header.  In either case
>>>>>>>    the router will not mistake the BIER header as an IP header so no
>>>>>>>    misordering should happen.
>>>>>>> BIER Echo Request can be transmitted in the same IPv6 tunnel as data
>>>>>>> packets with BIER headers to trace the paths traversed using particular
>>>>>>> combinations in BitString and Entropy fields.
>>>>>>>
>>>>>>
>>>>>> KT2> Right. So my point is that the proposal for encoding multipath
>>>>>> in
>>>>>> https://www.ietf.org/archive/id/draft-ietf-bier-ping-18.html#section-3.4.4.1.1
>>>>>> via essentially a reference to RFC8029 (which is MPLS specific) does not
>>>>>> cover the gamut of all encapsulations/data plane that BIER works over. More
>>>>>> specifically, the multipath types (see
>>>>>> https://www.iana.org/assignments/mpls-lsp-ping-parameters/mpls-lsp-ping-parameters.xhtml#multipath-type)
>>>>>> does not cover the encoding of the entropy field in the BIER header.
>>>>>>
>>>>> GIM3>> Thank you for the clarification. I agree to explicitly scoping
>>>>> Multipath Entropy Data sub-TLV to MPLS underlay only and adding note that
>>>>> other underlay types are for further study. Would the following update
>>>>> address your concern:
>>>>> NEW TEXT:
>>>>>    Multipath Entropy Data sub-TLV is applicable for BIER Echo Request
>>>>>    packets encapsulated in MPLS.  Encoding of multipath information for
>>>>>    other data planes, e.g., IPv6, is for further study.  If the
>>>>>    Multipath Entropy Data sub-TLV is present in the BIER Echo Request
>>>>>    packet encapsulated in a non-MPLS data plane, it MUST be ignored by
>>>>>    the responding BFR.
>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>>> 814     4.3.  Sending BIER Echo Request
>>>>>>>>>>
>>>>>>>>>> 816        The Initiator MUST set the Message Type as 1 and
>>>>>>>>>> Return Code as 0.
>>>>>>>>>> 817        The Proto field in the OAM packet MUST be set to 0.
>>>>>>>>>> The choice of
>>>>>>>>>>
>>>>>>>>>> <discuss-9> Does this precludes the use of any padding or such to
>>>>>>>>>> increase the
>>>>>>>>>> size of the BIER OAM packet to debug issues with specific packet
>>>>>>>>>> sizes? I don't
>>>>>>>>>> see a padding TLV and neither do I see the ability to carry some
>>>>>>>>>> other payload.
>>>>>>>>>> Has this been discussed/considered by the WG?
>>>>>>>>>>
>>>>>>>>> GIM>> Padding for BIER Echo Request can be provided using Data TLV
>>>>>>>>> that is defined in
>>>>>>>>> https://www.ietf.org/archive/id/draft-ietf-bier-path-mtu-discovery-18.txt
>>>>>>>>> .
>>>>>>>>>
>>>>>>>>
>>>>>>>> KT> Thanks for that pointer - it clarifies that this is coming
>>>>>>>> potentially in a separate document.
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>>> 1031    5.1.  UDP Port Number
>>>>>>>>>>
>>>>>>>>>> 1033       This document requests a UDP port TBD1 to be allocated
>>>>>>>>>> by IANA for
>>>>>>>>>> 1034       BIER Echo.
>>>>>>>>>>
>>>>>>>>>> <discuss-10> Should this not be BIER OAM in general and not just
>>>>>>>>>> for a specific
>>>>>>>>>> message types?
>>>>>>>>>>
>>>>>>>>> GIM>> I think that the requested for BIER Echo Reply UDP port
>>>>>>>>> number should have specific application as other OAM protocols, e.g., BFD
>>>>>>>>> and STAMP, already have their port numbers assigned.
>>>>>>>>>
>>>>>>>>
>>>>>>>> KT> I was still referring to BIER. Can this be called BIER OAM?
>>>>>>>> Where Echo is one of the OAM functions with the potential to
>>>>>>>> add more OAM functions for BIER. Since the message is called BIER
>>>>>>>> OAM message and Echo request/reply are two message
>>>>>>>> types, then I am assuming more OAM message types could be added in
>>>>>>>> the future?
>>>>>>>>
>>>>>>> GIM2>> Naming this UDP port as BIER OAM might be confusing. Consider
>>>>>>> how it relates to other active OAM functions in BIER. For example, a BFER
>>>>>>> encapsulates the BFD control message in BIER while BFIRs may use IP/IDP
>>>>>>> encapsulation to transmit BFD control messages to that BFER. None of the
>>>>>>> actors will use the UDP port number that we're discussing. Similar
>>>>>>> situation with measuring performance using STAMP - Session-Reflectors may
>>>>>>> use UDP port 862 assigned for TWAMP test plane.
>>>>>>>
>>>>>>
>>>>>> KT2> I am confused by your response. None of BFD, STAMP, or TWAMP are
>>>>>> BIER OAM - they have their own independent protocols. I can understand
>>>>>> these protocols encapsulated in BIER headers, but I cannot understand why
>>>>>> they would be sent as BIER OAM messages.
>>>>>>
>>>>> GIM3>> BIER OAM type acts as Associated channel, for example, as VCCV
>>>>> in PW  (RFC 5085 <https://datatracker.ietf.org/doc/html/rfc5085>). It
>>>>> allows using non-IP encapsulation for OAM packets. Of course, OAM packets
>>>>> can be encapsulated in IP/UDP, then BIER, not as BIER OAM, but as IPv4 or
>>>>> IPv6 packt identified in the Proto field of the BIER header according to
>>>>> values in IANA BIER Next Protocol Identifiers registry.
>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>>> <discuss-13> This is in general for all the IANA registries
>>>>>>>>>> created and their
>>>>>>>>>> allocation rules. I would be interested in understanding the
>>>>>>>>>> rationale for this
>>>>>>>>>> very complicated scheme with mix of various allocation policies
>>>>>>>>>> and the WG
>>>>>>>>>> discussion around why this was necessary as opposed to a much
>>>>>>>>>> simpler scheme
>>>>>>>>>> that is IETF Review + experimental/private use ?
>>>>>>>>>>
>>>>>>>>>> <v18> FCFS has changed to RFC Required but the discussion point
>>>>>>>>>> still remains.
>>>>>>>>>> <v18> Perhaps the 2 unassigned rows in Table 3 were meant to fall
>>>>>>>>>> on the
>>>>>>>>>> boundaries of these different allocation schemes?
>>>>>>>>>>
>>>>>>>>> GIM>> Thank you for the catch. Updated Table 3 as follows:
>>>>>>>>>      | 4 - 191   |             Unassigned            | This
>>>>>>>>> document |
>>>>>>>>>
>>>>>>>>>  +-----------+-----------------------------------+---------------+
>>>>>>>>>      | 192 - 247 |             Unassigned            | This
>>>>>>>>> document |
>>>>>>>>>
>>>>>>>>
>>>>>>>> KT> Thanks for fixing that. My question was really trying to
>>>>>>>> understand the reason behind such a complicated
>>>>>>>> set of allocation policies. I am trying to understand why the
>>>>>>>> authors/WG could not just pick IETF Review
>>>>>>>> instead of IETF Review + RFC Required? Is the expectation that RFCs
>>>>>>>> for BIER OAM be published via
>>>>>>>> the Independent Stream outside of the IETF?
>>>>>>>>
>>>>>>>>
>>>>>>>>    - 0 - 191 - IETF Review
>>>>>>>>    - 192 - 247 - RFC Required
>>>>>>>>    - 248 - 251 - Experimental Use (Reserved, not to be assigned)
>>>>>>>>    - 252 - 255 - Private Use (Reserved, not to be assigned)
>>>>>>>>
>>>>>>>> GIM2>> Thank you for the clarification. To better understand it, I
>>>>>>> refreshed my memory of RFC 8126
>>>>>>> <https://datatracker.ietf.org/doc/rfc8126/>, and I agree with your
>>>>>>> point that IETF Review sufficiently reflects the WG's intention and
>>>>>>> expectation for the future assignments of code points from all newly
>>>>>>> created IANA registries. I updated the draft accordingly.
>>>>>>>
>>>>>>
>>>>>> KT2> Thanks and the updates look good to me.
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ----------------------------------------------------------------------
>>>>>>>>>> COMMENT:
>>>>>>>>>>
>>>>>>>>>> ----------------------------------------------------------------------
>>>>>>>>>>
>>>>>>>>>> I would also like to share some comments inline in the idnits o/p
>>>>>>>>>> of v16 of this document.
>>>>>>>>>>
>>>>>>>>>> I support the DISCUSS from Roman and some of the DISCUSS points
>>>>>>>>>> raised by Med.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 285                        Value      Description
>>>>>>>>>> 286                        --------  ---------------
>>>>>>>>>> 287                          1        Do not Reply
>>>>>>>>>> 288                          2        Reply via IPv4/IPv6 UDP
>>>>>>>>>> packet
>>>>>>>>>> 289                          3        Reply via BIER packet
>>>>>>>>>>
>>>>>>>>>> 291           When Reply Mode is set to 1, the receiver will not
>>>>>>>>>> send any reply.
>>>>>>>>>> 292           This mode can be used for unidirectional path
>>>>>>>>>> validation.  When
>>>>>>>>>> 293           the Reply Mode is set to 2, the Responder
>>>>>>>>>> Bit-Forwarding Router
>>>>>>>>>> 294           (BFR) encapsulates the Echo reply payload with the
>>>>>>>>>> IP/UDP header.
>>>>>>>>>>
>>>>>>>>>> <major> How does the responder choose whether to use IPv4 or IPv6
>>>>>>>>>> if is running
>>>>>>>>>> dual/stack?
>>>>>>>>>>
>>>>>>>>> GIM>> Although a dual-stack support on a router is common, I am
>>>>>>>>> not familiar with deployments of IPv4 and IPv6 in the same BIER domain. As
>>>>>>>>> I understand it, only one address family is associated with BFR-id. If that
>>>>>>>>> is the case, a BFR will use mapping of BFR-id when consructing BIER Echo
>>>>>>>>> Reply is IP/UDP encapsulation.
>>>>>>>>>
>>>>>>>>
>>>>>>>> KT> I am not very familiar with BIER deployments either. It might
>>>>>>>> be helpful to crosscheck and clarify in the text that the BFR-ID is used to
>>>>>>>> determine whether to use IPv4 or IPv6 in a dual stack scenario?
>>>>>>>>
>>>>>>> GIM2>> I propose the following update:
>>>>>>> OLD TEXT:
>>>>>>>       When
>>>>>>>       the Reply Mode is set to 2, the Responder Bit-Forwarding Router
>>>>>>>       (BFR) encapsulates the Echo reply payload with the IP/UDP
>>>>>>> header.
>>>>>>> NEW TEXT:
>>>>>>>       When
>>>>>>>       the Reply Mode is set to 2, the Responder Bit-Forwarding Router
>>>>>>>       (BFR) encapsulates the Echo reply payload with the IP/UDP
>>>>>>> header.
>>>>>>>       The Responder BFR uses the BFIR-id field in the BIER header to
>>>>>>>       determine which IP address family to use in the IP/UDP
>>>>>>>       encaspulation.
>>>>>>>
>>>>>>
>>>>>> KT2> Looks good to me.
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>>> 443        Any Initiator MUST include this TLV in the Echo
>>>>>>>>>> Request packet.
>>>>>>>>>>
>>>>>>>>>> <major> Is this only supposed to be present in the request and
>>>>>>>>>> not in the response?
>>>>>>>>>> Please clarify.
>>>>>>>>>>
>>>>>>>>> GIM>> Original SI-BitString TLV carries a copy of the BitString in
>>>>>>>>> BIER header of thr BIER Echo Request. It is recommended that the responder
>>>>>>>>> includes Incoming SI-BitString TLV  that carries the BitString as received
>>>>>>>>> in the BIER Echo Request.
>>>>>>>>>
>>>>>>>>
>>>>>>>> KT> Right. My question was should there be a text that says "A
>>>>>>>> Responder MUST NOT include this TLV in Echo Response." on the
>>>>>>>> lines of a similar text in section 3.4.3 for the Incoming SI-Bitrsing TLV ?
>>>>>>>>
>>>>>>> GIM2>> Thank you for the suggestion. I added this clarification as
>>>>>>> follows:
>>>>>>> NEW TEXT:
>>>>>>>    Any Initiator MUST include this TLV in the Echo Request packet.  A
>>>>>>>    Responder MUST NOT include this TLV in the Echo Reply packet.
>>>>>>>
>>>>>>
>>>>>> KT2> Thanks.
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>>> 481        the BFER responding to the Echo Request.  This TLV
>>>>>>>>>> MUST be included
>>>>>>>>>> 482        by Initiator in the BIER OAM packet if the Downstream
>>>>>>>>>> Mapping TLV
>>>>>>>>>> 483        (Section 3.3.4) is included.
>>>>>>>>>>
>>>>>>>>>> <major> Is this allowed in both request and response? i.e., if
>>>>>>>>>> present in the
>>>>>>>>>> request, should the responder also copy it in the response?
>>>>>>>>>>
>>>>>>>>> GIM>> Target SI-BitString TLV is used by the Initiator to control
>>>>>>>>> which BFER responds with the BIER Echo Reply.
>>>>>>>>>
>>>>>>>>
>>>>>>>> KT> My question was on similar lines as the previous response. Can
>>>>>>>> it be specified which TLVs are not to be used besides where they are used?
>>>>>>>> Also, the error handling if they are used probably should be to ignore them?
>>>>>>>>
>>>>>>> GIM2>> Thank you for the clarification. The draft already specifies
>>>>>>> for Incoming SI-BitString TLV " An Initiator MUST NOT include this TLV in
>>>>>>> Echo Request." I propose adding similar requirements for Responder BFER TLV
>>>>>>> and Responder BFR TLV.As for the error handling when the Responder receives
>>>>>>> a BIER Echo Request with unexpected TLV, e.g., Incoming SI-BitString TLV,
>>>>>>> it must use the Erroneous Echo Request TLV.
>>>>>>>
>>>>>>
>>>>>> KT2> Sounds good. Thanks.
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 609        This section defines the optional Sub-TLVs that can be
>>>>>>>>>> included in
>>>>>>>>>> 610        Downstream Mapping TLV.
>>>>>>>>>>
>>>>>>>>>> 612                        Sub-TLV Type     Value
>>>>>>>>>> 613                        ------------  -------------
>>>>>>>>>> 614                            1         Multipath Entropy Data
>>>>>>>>>> 615                            2         Egress BitString
>>>>>>>>>>
>>>>>>>>>> <major> What is the handling for unknown/unrecognized sub-TLVs?
>>>>>>>>>>
>>>>>>>>> GIM>> Thank you for pointing this out to me. Added the following
>>>>>>>>> text to clarify handling of the undefined Type value:
>>>>>>>>> NEW TEXT:
>>>>>>>>>    Any other value MUST be considered as invalid, the Return Code
>>>>>>>>> set to
>>>>>>>>>    Malformed Echo Request received (1).  Also, the Erroneous Echo
>>>>>>>>>    Request TLV (Section 3.4.8) SHOULD be included in the BIER Echo
>>>>>>>>>    Reply.
>>>>>>>>>
>>>>>>>>
>>>>>>>> KT> Perfect. Thanks. This is also related to discuss-2. Could you
>>>>>>>> please check at other "levels"?
>>>>>>>>
>>>>>>> GIM2>> It seems like we now covered all error handling with the new
>>>>>>> Erroneous Echo Request TLV.
>>>>>>>
>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>>> 767        Upstream Address
>>>>>>>>>> 768           As defined in Section 3.3.4
>>>>>>>>>>
>>>>>>>>>> <major> What is defined in 3.3.4 is very different. Please
>>>>>>>>>> specify here again
>>>>>>>>>> even if the concept is similar for clarity.
>>>>>>>>>>
>>>>>>>>> GIM>> Updated to the following text:
>>>>>>>>>    Ingress Interface Address
>>>>>>>>>       A four or sixteen-octet-long field.  It lists an address
>>>>>>>>>       associated with the interface on which the BIER Echo Request
>>>>>>>>>       received.
>>>>>>>>>
>>>>>>>>
>>>>>>>> KT> Thanks.
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>>> 780     4.1.  BIER OAM Processing
>>>>>>>>>>
>>>>>>>>>> 782        A BIER OAM packet MUST be sent to the BIER control
>>>>>>>>>> plane for OAM
>>>>>>>>>> 783        processing if one of the following conditions is true:
>>>>>>>>>>
>>>>>>>>>> 785        *  The receiving BFR is a BFER.
>>>>>>>>>>
>>>>>>>>>> 787        *  TTL of BIER-MPLS Label (Section 2.1.1.1 [RFC8296])
>>>>>>>>>> expired.
>>>>>>>>>>
>>>>>>>>>> <major> What about IPv6 or natively over Ethernet? If traceroute
>>>>>>>>>> is not supported
>>>>>>>>>> or not specified for those data planes then perhaps this should
>>>>>>>>>> be called
>>>>>>>>>> out in the abstract and introduction sections. This is related to
>>>>>>>>>> discuss-7.
>>>>>>>>>>
>>>>>>>>>> <v18> IPv6 is covered. I am still trying to understand (for my
>>>>>>>>>> own learning) how
>>>>>>>>>> this works for natively over Ethernet.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>> KT> This one seems to have been missed. This is related to discuss-7
>>>>>>>>
>>>>>>> GIM2>> I'm confused about the applicability of "natively over
>>>>>>> Ethernet" in the BIER layer. Of course, IPv6 or MPLS are encapsulated in
>>>>>>> Ethernet, but, to the best of my knowledge, BIER in Ethernet encapsulation
>>>>>>> has not been specified. Am I missing something here?
>>>>>>>
>>>>>>
>>>>>> KT2> Please see
>>>>>> https://www.rfc-editor.org/rfc/rfc8296.html#section-2.2 and
>>>>>> https://www.rfc-editor.org/rfc/rfc8296.html#section-5 for Ethernet.
>>>>>> Am I mistaken?
>>>>>>
>>>>> GIM3>> As I understand it, TTL value in the BIER header is present
>>>>> whether BIER packet is encapsulated in MPLS, IPv6, or Ethernet. Would
>>>>> removing reference to BIER-MPLS label address your concern?
>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>> Ketan
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 1036    5.2.  BIER OAM Parameters
>>>>>>>>>>
>>>>>>>>>> 1038       IANA is requested to create and maintain the "BIER OAM
>>>>>>>>>> Parameters"
>>>>>>>>>> 1039       registry containing the sub-registries listed below.
>>>>>>>>>>
>>>>>>>>>> <major> Why would this not be placed under the existing BIER
>>>>>>>>>> Parameters
>>>>>>>>>> registry-group?
>>>>>>>>>>
>>>>>>>>> GIM>> IANA expert reviewed and agreed with the proposed
>>>>>>>>> heierachcy.
>>>>>>>>>
>>>>>>>>
>>>>>>>> KT> Sure. However, this is not a question that IANA is expert on,
>>>>>>>> but for the WG to decide.
>>>>>>>> Let's consider this closed.
>>>>>>>>
>>>>>>> GIM2>> Thank you.
>>>>>>>
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Ketan
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> <EoRv16>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>> BIER mailing list -- [e-mail]
>>>> To unsubscribe send an email to [e-mail]
>>>>
>>>