Re: [Bier] BIERv6 and BIERin6 OAM support discussion

[Greg Mirsky <[e-mail]>]

Hi Tianran,
you are right, IP/UDP encapsulation is one of the options to encapsulate
BIER active OAM messages and it was considered when we've worked on
draft-ietf-bier-ping
<https://www.ietf.org/archive/id/draft-ietf-bier-ping-07.txt> (the updated
version is coming soon). But we've decided to not use it and define BIER
OAM header (Section 3.1 of the draft-ietf-bier-ping):

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Ver  | Message Type  | Proto |             Reserved          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                        OAM Message Length                     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ~                  Message Type Dependent Data                  ~
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

BIER WG has agreed and that is now the encapsulation of BIER OAM whether it
is BIER Echo Request/Reply, a BFD Control message, or a STAMP'
Session-Sender's message. Hope that clarifies the context of my question
How does BIERv6 support BIER OAM?

Regards,
Greg

On Wed, Nov 25, 2020 at 10:52 PM Tianran Zhou <[e-mail]>
wrote:

> Hi Greg,
>
>
>
> Thanks for your interest on OAM. Let me reply your question here.
>
>
>
> @Gyan, thanks for folking this thread.
>
>
>
> The way to encapsulate OAM message is very generic, just like MPLS ping
> and MPLS p2mp ping.
>
> OAM message is in IP+UDP after Bier.
>
> A highlight of this way is it could also apply to draft-ietf-bier-php.
>
>
>
> Cheers,
>
> Tianran
>
>
>
>
>
>
>
>
>
> *From:* Gyan Mishra [mailto:[e-mail]]
> *Sent:* Thursday, November 26, 2020 1:38 PM
> *To:* BIER WG <[e-mail]>; Greg Mirsky <[e-mail]>; Greg
> Shepherd <[e-mail]>; Gyan Mishra <[e-mail]>; Michael
> McBride <[e-mail]>; Tianran Zhou <
> [e-mail]>; Tony Przygienda <[e-mail]>;
> Xiejingrong (Jingrong) <[e-mail]>
> *Subject:* Re: BIERv6 and BIERin6 OAM support discussion
>
>
>
> Greg
>
>
>
> With RFC 8296 Non MPLS BIER Ethernet next header 0xAB37  and optIonal
> BIERin6 encapsulation single hop or multi hop tunnel the BIER header is
> present either after Ethernet header in the latter or after the IPv6 header
> in BIERin6 and is present to encode OAM value for proto fied.
>
>
>
> With BIERv6 there is not any “BIER” encapsulation layer as the BIER header
> is encoded in IPV6 extension header DOH header.  As it is not encoded in
> the IPV6 packet header and is part of IPv6 header as is an extension
> header, OAM will not work natively with BIERv6.
>
>
>
>
>
> Jingrong and Xuesong
>
>
>
> Please shed some light on how OAM would work with BIERv6?
>
>
>
> Thanks
>
>
>
> Gyan
>
>
>
> On Wed, Nov 25, 2020 at 11:47 PM Gyan Mishra <[e-mail]>
> wrote:
>
> RE: BIER in IPV6 environment OAM support
>
>
>
> ***Tonys email related to OAM requirement***
>
>
>
> 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
>
>
>
> Greg Mirsky update request to BIER IPv6 Requirements draft:
>
>
>
> 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
>
>
>
>
>
> RE:  Greg Mirsky start of BIER IPv6 OAM discussion related to the two IPV6
> environment solutions
>
>
>
> Hi Tianran,
>
> I just recently read both proposals - BIERin6 and BIERv6. Understandably,
> I was interested in how each solution handles BIER OAM.
>
> draft-zhang-bier-bierin6 explains that:
>
>    BIER has its own OAM function, so generally the IPv6 OAM function is
>    not needed.
>
> And I agree with that conclusion. BIER OAM will work because BIER header
> is used as defined in RFC 8296, including using OAM value in the Proto
> field.
>
> draft-xie-bier-ipv6-encapsulation states that:
>
>         How BIER-PING is supported in BIERv6
>         encapsulation without using this Proto field is outside the
>         scope of this document.
>
> That left me with many questions. Thus, from my point of view, BIERv6
> needs to demonstrate how BIER OAM, as defined in numerous WG drafts, works
> in BIERv6 domain. Without that, I cannot compare the two proposals fairly.
>
>
>
> Regards,
>
> Greg
>
>
>
>
>
>
>
> --
>
> <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> *Network Solutions Architect *
>
>
>
> *M 301 502-1347 13101 Columbia Pike  *Silver Spring, MD
>
>
>
> --
>
> <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> *Network Solutions Architect *
>
>
>
> *M 301 502-1347 13101 Columbia Pike  *Silver Spring, MD
>
>
>