Subject: Re: [Bier] BIERv6 and BIERin6 OAM support discussion

From: Gyan Mishra <[email-masked]>
Date: Wed, 25 Nov 2020 23:47:13 -0500

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 A**rchitect *

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

---

From: Gyan Mishra <[email-masked]>
Date: Thu, 26 Nov 2020 00:37:50 -0500

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 <[email-masked]> wrote:

> I just recently read both proposals - BIERin6 and BIERv6. Understandably,
> I was interested in how each solution handles BIER OAM.
> 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.
> 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
>
>
>
> --
>

*Gyan Mishra*

---

From: Gyan Mishra <[email-masked]>
Date: Thu, 26 Nov 2020 00:49:10 -0500

Greg

With BIERv6 the Bier header encoded in DOH, as it is encoded as long as we
include the 2 bit OAM field for PNPM in the DOH encoding, is it possible
that OAM could work with BIERv6?

Kind Regards

Gyan
On Thu, Nov 26, 2020 at 12:37 AM Gyan Mishra <[email-masked]> wrote:

>> RE:  Greg Mirsky start of BIER IPv6 OAM discussion related to the two
>> IPV6 environment solutions
>>
>> Hi Tianran,

*Gyan Mishra*

---

From: Tianran Zhou <[email-masked]>
Date: Thu, 26 Nov 2020 06:52:48 +0000

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:[email-masked]]
Sent: Thursday, November 26, 2020 1:38 PM
To: BIER WG <[email-masked]>; Greg Mirsky <[email-masked]>; Greg Shepherd <[email-masked]>; Gyan Mishra <[email-masked]>; Michael McBride <[email-masked]>; Tianran Zhou <[email-masked]>; Tony Przygienda <[email-masked]>; Xiejingrong (Jingrong) <[email-masked]>
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

Thanks

Gyan

On Wed, Nov 25, 2020 at 11:47 PM Gyan Mishra <[email-masked]<mailto:[email-masked]>> wrote:
RE: BIER in IPV6 environment OAM support

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.

-- tony

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://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]<http://www.verizon.com/>

Gyan Mishra

Network Solutions Architect

M 301 502-1347
13101 Columbia Pike
Silver Spring, MD

--

[http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]<http://www.verizon.com/>

Gyan Mishra

Network Solutions Architect

M 301 502-1347
13101 Columbia Pike
Silver Spring, MD

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 26 Nov 2020 14:12:25 -0800

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 <[email-masked]>
wrote:

> *From:* Gyan Mishra [mailto:[email-masked]]
> *Sent:* Thursday, November 26, 2020 1:38 PM
> *To:* BIER WG <[email-masked]>; Greg Mirsky <[email-masked]>; Greg
> Shepherd <[email-masked]>; Gyan Mishra <[email-masked]>; Michael
> McBride <[email-masked]>; Tianran Zhou <
> [email-masked]>; Tony Przygienda <[email-masked]>;
> Xiejingrong (Jingrong) <[email-masked]>
> *Subject:* Re: BIERv6 and BIERin6 OAM support discussion
>
>
>
> Greg
>
>
>
> *Network Solutions Architect *
>
>
>
> *M 301 502-1347 13101 Columbia Pike  *Silver Spring, MD
>
>
>
> --
>
> *Network Solutions Architect *
>
>
>
> *M 301 502-1347 13101 Columbia Pike  *Silver Spring, MD
>
>
>

---

From: Tianran Zhou <[email-masked]>
Date: Fri, 27 Nov 2020 01:44:10 +0000

Hi Greg,

“How does BIERv6 support BIER OAM”?

I may still not understand your question. But let me try to be clear.
IMO, this question is just about the identifier + oam message. Right?

We can use the same bier oam header/message as you pointed, and for ping, bfd, stamp.
The difference is only the identifier.
Bierv6 use ip/udp encap, and use the udp port to identify the oam header.

Cheers,
Tianran

From: Greg Mirsky [mailto:[email-masked]]
Sent: Friday, November 27, 2020 6:12 AM
To: Tianran Zhou <[email-masked]>
Cc: Gyan Mishra <[email-masked]>; BIER WG <[email-masked]>; Greg Shepherd <[email-masked]>; Michael McBride <[email-masked]>; Tony Przygienda <[email-masked]>; Xiejingrong (Jingrong) <[email-masked]>
Subject: Re: BIERv6 and BIERin6 OAM support discussion

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

     |                        OAM Message Length                     |

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 <[email-masked]<mailto:[email-masked]>> wrote:
Hi Greg,

Cheers,
Tianran

From: Gyan Mishra [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Thursday, November 26, 2020 1:38 PM
To: BIER WG <[email-masked]<mailto:[email-masked]>>; Greg Mirsky <[email-masked]<mailto:[email-masked]>>; Greg Shepherd <[email-masked]<mailto:[email-masked]>>; Gyan Mishra <[email-masked]<mailto:[email-masked]>>; Michael McBride <[email-masked]<mailto:[email-masked]>>; Tianran Zhou <[email-masked]<mailto:[email-masked]>>; Tony Przygienda <[email-masked]<mailto:[email-masked]>>; Xiejingrong (Jingrong) <[email-masked]<mailto:[email-masked]>>
Subject: Re: BIERv6 and BIERin6 OAM support discussion

Greg

Jingrong and Xuesong

Thanks

Gyan

-- tony

Dear All,

Regards,
Greg

Hi Tianran,

Regards,
Greg

--

Gyan Mishra

M 301 502-1347
13101 Columbia Pike
Silver Spring, MD

--

Gyan Mishra

M 301 502-1347
13101 Columbia Pike
Silver Spring, MD

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 26 Nov 2020 18:20:50 -0800

Hi Tianran,
thank you for your quick response. Yes, my question was in the relationship
with the note at the closing of Section 3.1:
        How BIER-PING is supported in BIERv6
        encapsulation without using this Proto field is outside the
        scope of this document.
If I understand you correctly, the authors of BIERv6 don't consider
supporting BIER OAM as defined in draft-ietf-bier-ping. Is that the
authors' position?
I agree with you that IP/UDP encapsulation can be used in BIERv6 but I need
to note that because BIER Ping is defined with the use of only BIER OAM
encapsulation, no UDP port has been requested from IANA.

Regards,
Greg

On Thu, Nov 26, 2020 at 5:44 PM Tianran Zhou <[email-masked]> wrote:

> *From:* Greg Mirsky [mailto:[email-masked]]
> *Sent:* Friday, November 27, 2020 6:12 AM
> *To:* Tianran Zhou <[email-masked]>
> *Cc:* Gyan Mishra <[email-masked]>; BIER WG <[email-masked]>; Greg
> Shepherd <[email-masked]>; Michael McBride <
> [email-masked]>; Tony Przygienda <[email-masked]>;
> <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
>
> 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'

---

From: Tianran Zhou <[email-masked]>
Date: Fri, 27 Nov 2020 02:37:53 +0000

Hi Greg,

“I agree with you that IP/UDP encapsulation can be used in BIERv6 but I need to note that because BIER Ping is defined with the use of only BIER OAM encapsulation, no UDP port has been requested from IANA.”

I do not see any problem here.

Best,
Tianran

Sent: Friday, November 27, 2020 10:21 AM

Hi Tianran,
thank you for your quick response. Yes, my question was in the relationship with the note at the closing of Section 3.1:
        How BIER-PING is supported in BIERv6
        encapsulation without using this Proto field is outside the
        scope of this document.
If I understand you correctly, the authors of BIERv6 don't consider supporting BIER OAM as defined in draft-ietf-bier-ping. Is that the authors' position?
I agree with you that IP/UDP encapsulation can be used in BIERv6 but I need to note that because BIER Ping is defined with the use of only BIER OAM encapsulation, no UDP port has been requested from IANA.

Regards,
Greg

On Thu, Nov 26, 2020 at 5:44 PM Tianran Zhou <[email-masked]<mailto:[email-masked]>> wrote:
Hi Greg,

Cheers,
Tianran

From: Greg Mirsky [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Friday, November 27, 2020 6:12 AM
To: Tianran Zhou <[email-masked]<mailto:[email-masked]>>
Cc: Gyan Mishra <[email-masked]<mailto:[email-masked]>>; BIER WG <[email-masked]<mailto:[email-masked]>>; Greg Shepherd <[email-masked]<mailto:[email-masked]>>; Michael McBride <[email-masked]<mailto:[email-masked]>>; Tony Przygienda <[email-masked]<mailto:[email-masked]>>; Xiejingrong (Jingrong) <[email-masked]<mailto:[email-masked]>>
Subject: Re: BIERv6 and BIERin6 OAM support discussion

Hi Tianran,

      0                   1                   2                   3

     |                        OAM Message Length                     |

Regards,
Greg

Cheers,
Tianran

Greg

Jingrong and Xuesong

Thanks

Gyan

-- tony

Dear All,

Regards,
Greg

Hi Tianran,

Regards,
Greg

--

Gyan Mishra

M 301 502-1347
13101 Columbia Pike
Silver Spring, MD

--

Gyan Mishra

M 301 502-1347
13101 Columbia Pike
Silver Spring, MD

---

From: Gyan Mishra <[email-masked]>
Date: Thu, 26 Nov 2020 23:18:50 -0500

Greg

With BIERv6 the format is a bit different as we are encoding in an IPv6
extended header DOH options and not using the RFC 8296 Non MPLS BIER
encapsulation.  So the proto filed changes when we encoding BIER header
into DOH which is why it’s set to 0 and ignored upon transmission since
with IPv6 next header field is used.

See below excerpt that this is being updated in RFC 8296 section 2.1.2.

As BIER OAM is coupled into the BIER architecture, BIERv6 will support BIER
OAM using BIER ping by DOH encoding of BIER header and will fully support
the BIER OAM message format.

https://tools.ietf.org/html/draft-ietf-bier-pmmm-oam-08

https://tools.ietf.org/html/draft-ietf-bier-ping-07

Below is excerpt from section 3.1 top of page 6.

        Proto: SHOULD be set to 0 upon transmission and be ignored upon
        reception.  In BIERv6 encapsulation, the functionality of this
        6-bit Proto field is replaced by the Next Header field in
        Destination Options header or the last IPv6 extension header to
        indicate the type of the payload.  This updates section 2.1.2 of
        [RFC8296] <https://tools.ietf.org/html/rfc8296#section-2.1.2>
about Proto definition.  Next Header value in BIERv6
        encapsulation for common usage includes:

          Value 4 for IPv4 packet as BIERv6 payload.

          Value 41 for IPv6 packet as BIERv6 payload.

          Value 143 for Ethernet packet as BIERv6 payload.

        Multicast VPN (MVPN) service is considered as part of the BIER
        layering mode defined in [RFC8279
<https://tools.ietf.org/html/rfc8279>], and should be supported by
        BIERv6 encapsulation.  [I-D.xie-bier-ipv6-mvpn
<https://tools.ietf.org/html/draft-xie-bier-ipv6-encapsulation-08#ref-I-D.xie-bier-ipv6-mvpn>]
illustrates how
        MVPN is supported in BIERv6 encapsulation without using this
        Proto field.

        BIER-PING [I-D.ietf-bier-ping
<https://tools.ietf.org/html/draft-xie-bier-ipv6-encapsulation-08#ref-I-D.ietf-bier-ping>]
        is considered a useful function
        of the BIER architecture, and should be supported by BIERv6
        encapsulation.  How BIER-PING is supported in BIERv6
        encapsulation without using this Proto field is outside the
        scope of this document.

Kind Regards

Gyan

On Thu, Nov 26, 2020 at 9:21 PM Greg Mirsky <[email-masked]> wrote:

> Hi Tianran,
> thank you for your quick response. Yes, my question was in the
> relationship with the note at the closing of Section 3.1:
> I agree with you that IP/UDP encapsulation can be used in BIERv6 but I
> need to note that because BIER Ping is defined with the use of only BIER
> OAM encapsulation, no UDP port has been requested from IANA.
>
> Regards,
> Greg
>
>> Shepherd <[email-masked]>; Gyan Mishra <[email-masked]>;
>> Michael McBride <[email-masked]>; Tianran Zhou <
>> 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
>>
>>
>>
>> *M 301 502-1347 13101 Columbia Pike
>> <https://www.google.com/maps/search/13101+Columbia+Pike%C2%A0+%0D%0A+Silver+Spring,+MD?entry=gmail&source=g>
>> *Silver Spring, MD
>> <https://www.google.com/maps/search/13101+Columbia+Pike%C2%A0+%0D%0A+Silver+Spring,+MD?entry=gmail&source=g>
>>
>> <https://www.google.com/maps/search/13101+Columbia+Pike%C2%A0+%0D%0A+Silver+Spring,+MD?entry=gmail&source=g>
>>
>>
>>
>> --
>>
>> *M 301 502-1347 13101 Columbia Pike
>> <https://www.google.com/maps/search/13101+Columbia+Pike%C2%A0+%0D%0A+Silver+Spring,+MD?entry=gmail&source=g>
>> *Silver Spring, MD
>> <https://www.google.com/maps/search/13101+Columbia+Pike%C2%A0+%0D%0A+Silver+Spring,+MD?entry=gmail&source=g>
>>
>> <https://www.google.com/maps/search/13101+Columbia+Pike%C2%A0+%0D%0A+Silver+Spring,+MD?entry=gmail&source=g>
>>
>>
>>
>> --

*Gyan Mishra*

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 26 Nov 2020 20:29:26 -0800

Hi Gyan,
thank you for the detailed response. I am not questioning that BIERv6 can
define a mechanism similar to BIER echo request/reply. Also, I'll note that
the same mechanism is used in at least one of BIER Path MTU Discovery
proposals adopted by the WG. I've brought the BIER OAM to the discussion as
I strongly believe that OAM is an essential part of any networking
technology and an ability to support the existing OAM should be
sufficiently demonstrated to make the comparison of the proposals on their
respective technical qualities.

Regards,
Greg

On Thu, Nov 26, 2020 at 8:19 PM Gyan Mishra <[email-masked]> wrote:

> As BIER OAM is coupled into the BIER architecture, BIERv6 will support
> BIER OAM using BIER ping by DOH encoding of BIER header and will fully
> support the BIER OAM message format.
>
>         [RFC8296] <https://tools.ietf.org/html/rfc8296#section-2.1.2> about Proto definition.  Next Header value in BIERv6
>         layering mode defined in [RFC8279 <https://tools.ietf.org/html/rfc8279>], and should be supported by
>         BIERv6 encapsulation.  [I-D.xie-bier-ipv6-mvpn <https://tools.ietf.org/html/draft-xie-bier-ipv6-encapsulation-08#ref-I-D.xie-bier-ipv6-mvpn>] illustrates how
>         BIER-PING [I-D.ietf-bier-ping <https://tools.ietf.org/html/draft-xie-bier-ipv6-encapsulation-08#ref-I-D.ietf-bier-ping>]         is considered a useful function
>>> *Cc:* Gyan Mishra <[email-masked]>; BIER WG <[email-masked]>;
>>> Greg Shepherd <[email-masked]>; Michael McBride <
>>> *To:* BIER WG <[email-masked]>; Greg Mirsky <[email-masked]>;
>>> Greg Shepherd <[email-masked]>; Gyan Mishra <[email-masked]>;
>>> 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
>>> I just recently read both proposals - BIERin6 and BIERv6.
>>> Understandably, I was interested in how each solution handles BIER OAM.
>>>

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 27 Nov 2020 01:19:25 -0500

Thank you Greg for bringing up the topic on BIER OAM in IPv6 environment as
I completely agree with you that both solutions are a MUST requirement to
support BIER ping for the in-band BIER OAM for PM.

I completely agree with you that OAM is an essential part of any technology.

Once we get further down the road with the requirements and move to
solutions space it maybe warranted to have a draft on BIERv6 OAM support
details.

Kind Regards

Gyan

On Thu, Nov 26, 2020 at 11:29 PM Greg Mirsky <[email-masked]> wrote:

>>>> 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
>>>> 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'
>>>> 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
>>>> 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.
>>>>
>> *M 301 502-134713101 Columbia Pike
>> <https://www.google.com/maps/search/13101+Columbia+Pike%C2%A0+%0D%0A+Silver+Spring,+MD?entry=gmail&source=g>*Silver
>> Spring, MD

*Gyan Mishra*