Re: [Bier] draft-ietf-bier-ipv6-requirements-09

[Gyan Mishra <[e-mail]>]

Hi Greg

Much appreciated your jumping into the discussion and most welcome.

As Tony mentioned the OAM tight coupling to BIER architecture for P2MP
trees.

I will get the OAM section updated with the new text.

Kind Regards

Gyan

On Wed, Nov 25, 2020 at 4:14 PM Greg Mirsky <[e-mail]> wrote:

> Dear All,
> I apologize for jumping into this discussion but have someone said "OAM"?
> :)
> I much appreciate what our co-chair (and contributor to BIER OAM) had to
> say about the state of BIER OAM work. I agree with Tony's summary that our
> joint efforts already created the toolset of the distinctive solutions for
> BIER OAM. We've followed draft-ietf-bier-oam-requirements
> <https://datatracker.ietf.org/doc/draft-ietf-bier-oam-requirements/> to
> define the comprehensive set of OAM mechanisms that support proactive and
> on-demand failure detection and localization using both BFD and echo
> request/reply. Also, as Tony mentioned, we have drafts on path MTU
> discovery in the BIER environment and application of the Alternate Marking
> method for the packet delay and packet loss measurement in a BIER domain.
> In my opinion, the section on OAM in draft-ietf-bier-ipv6-requirements is
> helpful. I have a question on the intention of the following wording:
>
> .... by specifying a new method for the same functionality.
>
> If there's, for example, WG draft on proactive failure detection in the
> BIER network using p2mp BFD with unsolicited notifications, why would we
> entertain the idea of defining a new protocol or method for the same
> purpose? I think that the ability to use BIER OAM solutions as defined in
> their respective drafts already accepted by the WG (and some even passed
> WGLC) is the litmus test for any proposed method of realizing BIER in IPv6
> network. Thus I propose the following change of Section 3.1.4
> <https://tools.ietf.org/html/draft-ietf-bier-ipv6-requirements-09#section-3.1.4>
> :
> OLD TEXT:
>    BIER OAM tools like [I-D.ietf-bier-ping] and [I-D.ietf-bier-pmmm-oam]
>    should be supported, either directly using existing methods, or by
>    specifying a new method for the same functionality.  They are likely
>    to be needed in normal BIER deployment for diagnostics.
> NEW TEXT:
>    BIER OAM tools defined in WG document, for example,
>    [I-D.ietf-bier-ping] and [I-D.ietf-bier-pmmm-oam],
>    must be supported as defined in the respective specifications.
> Consistency
>    of OAM BIER tools is essential for the productive operation of BIER
> networks.
>
>
> Regards,
> Greg
>
> On Wed, Nov 18, 2020 at 11:09 PM Tony Przygienda <[e-mail]>
> wrote:
>
>> Quick correction here as to OAM. OAM is worked on and multiple quite
>> extensive & well-written drafts dealing with OAM aspects are adopted/in
>> flight since quite a while (I count 4 adopted & 1 individual). BIER has
>> been specifically architected with multicast OAM in mind which is
>> non-trivial such as MTU discovery (we have 2 drafts for a good reason &
>> discussion is pending) and dealing with OAM when we're dealing with mp2mp
>> trees (which BIER basically is or can be used at). One of the reasons BIER
>> found interest in the set of people that need/like it is that they were
>> looking for very tight OAM guarantees in orders of microseconds and that
>> without highly specific hardware designed for it is very difficult (and
>> packet format, that's why OAM is first order citizen in BIER in terms of
>> bits provided e.g. for marking purposes and can be found in a very specific
>> offset. to support the OAM desired HW has to process and generate
>> sub-microseconds trains.
>>
>> As far as I saw there was not much on the radar in terms of anything
>> comparable in SRv6 OAM work beside "SID-ping" if the intention is to rely
>> on SRv6 to deal with that problem. But of course I may have missed some
>> draft. Even if they work on unicast OAM I may express my profound doubts
>> there will be interest or focus to solve OAM for SRv6 becoming a L3
>> multicast transport with the type of OAM BIER needs on top.
>>
>> As to desired OAM, I think we have an OAM requirements draft adopted with
>> quite a list of industry authors since quite a bit. this draft has WG
>> consensus and has to be satisfied.
>>
>>
>> https://datatracker.ietf.org/doc/draft-ietf-bier-oam-requirements/?include_text=1
>>
>> -- tony
>>
>> On Wed, Nov 18, 2020 at 7:50 PM Alvaro Retana <[e-mail]>
>> wrote:
>>
>>> On November 19, 2020 at 3:18:58 AM, Gyan Mishra wrote:
>>>
>>>
>>> Hi!
>>>
>>> Just a couple of comments.
>>>
>>>
>>> > On Wed, Nov 18, 2020 at 11:29 AM Jeffrey (Zhaohui) Zhang wrote:
>>> ..
>>> > > From: Gyan Mishra
>>> > > Sent: Wednesday, November 18, 2020 10:14 AM
>>> ...
>>> > > > Alvaro mentioned as far as the list of requirements that they were
>>> > > > fairly basic but maybe needed some more meat behind it such as the
>>> > > > “support various L2 link types” but we did not specify. In previous
>>> > > > versions we stated L2 agnostic and then switched to various but
>>> being
>>> > > > vague on which L2. Alvaro also mentioned why OAM should be a
>>> > > > requirement. We may want to add a sentence on justification as to
>>> why we
>>> > > > picked BIER IPv6 requirements as required versus optional.
>>> > >
>>> > > Zzh> I actually don’t think L2 link types is a key issue. Whatever
>>> modern
>>> > > L2 links that an operator wants to use, it’ll need to be supported
>>> both by
>>> > > IPv6 and BIER, and it is as simple as adding a codepoint for the L2
>>> header
>>> > > to indicate whether the next header is IP/MPLS/BIER/whatever (again
>>> – the
>>> > > beauty of clear and independent layering).
>>> > >
>>> > Gyan> I don’t think Alvaro was saying there was any issue but just
>>> pointing
>>> > out that we did not specify which link types. We can discuss with
>>> authors
>>> > what link types we should add explicitly.
>>>
>>> <individual hat on>
>>>
>>> It was Loa, not me, who raised the point about the L2 requirement
>>> being vague.  I do agree with him.  I also agree with Jeffrey on his
>>> point that "modern L2 links that an operator wants to use, it’ll need
>>> to be supported".  To me, this then becomes another general
>>> requirement -- unless there's a special reason to add or exclude
>>> something.
>>>
>>> I did say that the mandatory requirements are general and broad.  For
>>> example, "support the BIER architecture" is obvious, and I assume both
>>> solutions do.  BTW, "deployments with BIER-incapable routers" is also
>>> covered in rfc8279.
>>>
>>> My comment about OAM was along the lines of the fact that there is no
>>> standard BIER OAM mechanism defined.  It seems like a stretch to
>>> require BIER functionality that has not been defined.  A better
>>> approach might be to explain the required functionality (for example,
>>> continuity, liveliness, etc.).
>>>
>>>
>>>
>>> ...
>>> > > Zzh> With the above consideration, I would say the “suggested next
>>> steps”
>>> > > in my presentation is quite reasonable.
>>> > >
>>> > Gyan> Let’s have the chairs and AD chime in on this thread.
>>>
>>> <AD hat on.>
>>>
>>> As I mentioned on the call, my opinions on this thread are as an
>>> individual.  The Chairs are more than capable of providing direction
>>> and don't need me for that.
>>>
>>>
>>> Thanks!
>>>
>>> Alvaro.
>>>
>> _______________________________________________
>
>
>> BIER mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/bier
>>
> --

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *



*M 301 502-134713101 Columbia Pike *Silver Spring, MD