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

["Gengxuesong (Geng Xuesong)" <[e-mail]>]

Hi Jeffery, 

Please find the comments inline.

Best
Xuesong

-----Original Message-----
From: Jeffrey (Zhaohui) Zhang [mailto:[e-mail]] 
Sent: Saturday, November 28, 2020 11:32 AM
To: Gengxuesong (Geng Xuesong) <[e-mail]>; [e-mail]
Cc: Gyan Mishra <[e-mail]>; Alvaro Retana <[e-mail]>; BIER WG <[e-mail]>; [e-mail] <[e-mail]>; Tony Przygienda <[e-mail]>; draft-ietf-bier-ipv6-requirements <[e-mail]>
Subject: RE: draft-ietf-bier-ipv6-requirements-09

Xuesong,

Please see zzh> below.

-----Original Message-----
From: Gengxuesong (Geng Xuesong) <[e-mail]>
Sent: Friday, November 27, 2020 9:06 PM
To: [e-mail]; Jeffrey (Zhaohui) Zhang <[e-mail]>
Cc: Gyan Mishra <[e-mail]>; Alvaro Retana <[e-mail]>; BIER WG <[e-mail]>; [e-mail] <[e-mail]>; Tony Przygienda <[e-mail]>; draft-ietf-bier-ipv6-requirements <[e-mail]>
Subject: RE: draft-ietf-bier-ipv6-requirements-09

[External Email. Be cautious of content]


Hi Greg,

I have followed the thread. And I don't there is consensus about BIER IPv6 requirement and BIERin6 in WG. Here are some my concerns that have been discussed in IETF109:
1. Why we need a new "next header" when the existing IPv6 extension header could satisfy the BIER IPv6 requirement;

Zzh> which existing IPv6 extension header? I hope it's not the DOH that encodes the BIER header as in BIERv6.
Zzh> Otherwise, the questions should be flipped around - since RFC8296 BIER over L2/tunnel works well (with just a new "next header" code point in case of IPv6 tunnel), why we need BIERv6?

【Xuesong】The answer is quite straight forward, because there is no extension header in Ethernet. IPv6 uses extension header for new functions/information. Based on the logic of BIERin6, some new next header code point should be allocated for Fragment Header, Authentication header and any functions that are supposed to be initiated with IPv6, which obviously violating RFC8200. 

2. The comments raised by 6MAN WG and INT area are not addressed, which requests the document to be discussed in transport area;

Zzh> I am surprised to hear this brought up in this BIER session. I must have missed it in last IETF's 6man session. As we briefly talked about in this BIER session, it's strange that tunneling needs to be discussed in transport area, but I will dig into last 6man session's minutes and recording and report back.

【Xuesong】(It's interesting that BIERin6 authors brought the document to 6man in IETF 108 and received some comments but now I'm asked why it should be and what the comments are) please find the detailed discussion in https://www.youtube.com/watch?v=_1MFLec7pSw and the minutes could be found in https://datatracker.ietf.org/meeting/108/materials/minutes-108-6man-05.html .

3. BIERin6 is not an independent solution which uses BIER Ethernet when BFR nodes are connected directly.

Zzh> As have been repeated several times in recent threads, BIERin6 is about supporting BIER in IPv6 networks - it is appropriate and have become critical  given ongoing contention to have a spec to explicitly talk about how existing BIER over L2/tunnel can work nicely in an IPv6 network. With that, the above comment just does not make sense.
Zzh> Jeffrey

【Xuesong】I can't see why some solution is appropriate when it depends on other solutions. It seems like in an IPv6 network with other type of L2 link except for Ethernet, BIERin6 doesn't work.

Best
Xuesong

-----Original Message-----
From: Greg Shepherd [mailto:[e-mail]]
Sent: Friday, November 27, 2020 10:47 PM
To: Jeffrey (Zhaohui) Zhang <[e-mail]>
Cc: Gyan Mishra <[e-mail]>; Alvaro Retana <[e-mail]>; BIER WG <[e-mail]>; [e-mail] <[e-mail]>; Tony Przygienda <[e-mail]>; draft-ietf-bier-ipv6-requirements <[e-mail]>
Subject: Re: draft-ietf-bier-ipv6-requirements-09

Thank you Jeffrey and Gyan for sticking with the thread of the conversation to advance the discussion. It's clear now that all of the requirements discussed so far can be addressed by the BIERin6 draft if we flesh out the discussed gaps.

I would like to see Jeffrey and Gyan take over as primary authors of
BIERin6 to include the gaps discussed here so that it fully encompases the requirements so far described, for WG adoption.

Thanks,
Shep

On Mon, Nov 23, 2020 at 4:56 AM Jeffrey (Zhaohui) Zhang <[e-mail]>
wrote:

> Hi Gyan,
>
>
>
> Great that we reached consensus on BIERin6.
>
> Now there are two lingering points alluded to in this thread, but 
> given it’s been such a long and deeply nested tread, I’ll start a new 
> thread about it.
>
>
>
> Thanks.
>
> Jeffrey
>
>
>
> *From:* Gyan Mishra <[e-mail]>
> *Sent:* Monday, November 23, 2020 1:32 AM
> *To:* Jeffrey (Zhaohui) Zhang <[e-mail]>
> *Cc:* Alvaro Retana <[e-mail]>; BIER WG <[e-mail]>; 
> [e-mail] <[e-mail]>; Tony Przygienda < 
> [e-mail]>; draft-ietf-bier-ipv6-requirements < 
> [e-mail]>; [e-mail]
> *Subject:* Re: draft-ietf-bier-ipv6-requirements-09
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
> Hi Jeffrey
>
>
>
> That’s the last of my questions related to BIERin6.
>
>
>
> I thank you for taking the time to go over the BIERin6 draft in detail.
>
>
>
> We have reached consensus as well as are in sync,  and I now have a 
> better understanding of BIERin6.
>
>
>
> During the discussions I did mention that maybe in BIERin6 optional
> IPv6 tunneling should be removed, as it seemed to create some 
> confusion, but now I am clear and as both the L2/tunnel and IPv6 
> L3/tunnel encapsulation single hop or multi hop tunnel both have the 
> clean BIER layering and complement each other I agree they belong together in the same draft.
>
> Even though L2/tunnel exists today as part of RFC8296 it makes sense 
> to be part of the overall BIERin6 solution.
>
>
>
> I am clear on the two IANA code points requests required for the 
> optional
> IPV6 encapsulation option.
>
>
>
> Over the course of this thread we did touch on some technical reasons 
> why
> IPV6 encapsulation is necessary which I you mentioned in some of your 
> responses.
>
>
>
> Overall throughout the discussions I agree that BIERin6 IPV6 tunnel 
> option and BIERv6 are not transitional and are long term solutions and 
> there are reasons why that we can add to the requirements draft as to 
> why IPV6 encapsulation is necessary below:
>
>
>
> - Operator requirement for IPV6 encapsulated packets  and not L2 
> encapsulation.
>
> -FRR
>
>
>
> I think we are all set to start updating the Requirements draft.
>
>
>
> In-line Gyan6>
>
>
>
> Kind Regards
>
>
>
> Gyan
>
>
>
> On Sun, Nov 22, 2020 at 10:39 PM Jeffrey (Zhaohui) Zhang < 
> [e-mail]> wrote:
>
> Gyan,
>
>
>
> Please see zzh6> below.
>
>
>
> *From:* Gyan Mishra <[e-mail]>
> *Sent:* Sunday, November 22, 2020 9:49 PM
> *To:* Jeffrey (Zhaohui) Zhang <[e-mail]>
> *Cc:* Alvaro Retana <[e-mail]>; BIER WG <[e-mail]>; 
> [e-mail] <[e-mail]>; Tony Przygienda < 
> [e-mail]>; draft-ietf-bier-ipv6-requirements < 
> [e-mail]>; [e-mail]
> *Subject:* Re: draft-ietf-bier-ipv6-requirements-09
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
>
>
> Hi Jeffrey
>
>
>
> Agreed we have reached a consensus.
>
>
>
>
>
> Few more questions to iron out understanding.
>
>
>
> In line gyan4>
>
>
>
> Zzh6> Apparently there are still disconnects 😊
>
>  Gyan> Thank you for all the detailed responses.  We are in sync now!
>
> On Sun, Nov 22, 2020 at 8:06 PM Jeffrey (Zhaohui) Zhang < 
> [e-mail]> wrote:
>
> Hi Gyan,
>
>
>
> Yes I believe we’ve reached consensus.
>
>
>
> Please see zzh5> below about some details.
>
>
>
> *From:* Gyan Mishra <[e-mail]>
> *Sent:* Sunday, November 22, 2020 4:19 PM
> *To:* Jeffrey (Zhaohui) Zhang <[e-mail]>
> *Cc:* Alvaro Retana <[e-mail]>; BIER WG <[e-mail]>; 
> [e-mail] <[e-mail]>; Tony Przygienda < 
> [e-mail]>; draft-ietf-bier-ipv6-requirements < 
> [e-mail]>; [e-mail]
> *Subject:* Re: draft-ietf-bier-ipv6-requirements-09
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
> Hi Jeffrey
>
>
>
> This has been a very informative exchange and extremely helpful for 
> all of us to get onto the same page from a basic understanding POV.
>
>
>
> Much appreciated all your help and feedback helping clarify my confusion.
>
>
>
> I am answering in-line but now connecting the dots how is in today’s 
> RFC
> 8296 Non MPLS BIER Ethernet going to transport IPv6?
>
>
>
> From your answers below it cannot work as we need two IANA code point 
> one for IPv6 next header type and ICMPv6.
>
>
>
> Zzh5> The existing model/concept works except that we need to two code
> points if IPv6 tunneling is used for either getting over non-BFRs or 
> for FRR. One may deem non-BFR as a short-term scenario but FRR will be 
> here for the long run.
>
>
>
>     Gyan4>I am a little confused here with the code points.  For
> BIERin6 “L2” BIER scenario RFC 8296 Non MPLS BIER Ethernet Ether type 0xAB37.
>
>
>
> Ethernet -0xAB37 l BIER | IPv6 | payload
>
>
>
> Zzh6> Note that IPv6 header is not needed – it should be Ethernet
> Zzh6> -0xAB37
> l BIER | payload. Of course, if SRv6 style VPN must be used, then IPv6 
> header may be inserted between BIER and payload, only for the SRv6 
> style VPN purpose.
>
> Gyan> Understood
>
> Ethernet -0xAB37 l BIER l ICMPv6 | payload
>
>
>
> Zzh6> ICMP was mentioned not for encapsulation but for the following:
>
>  Gyan6>Understood
>
> Zzh6> 2.1.  IPv6 Options Considerations
>
>
>
>    For directly connected BIER routers, IPv6 Hop-by-Hop or Destination
>
>    options are irrelevant and SHOULD NOT be inserted by BFIR on the
>
>    BIERin6 packet.  In this case IPv6 header, Next Header field should
>
>    be set to TBD.  Any IPv6 packet arriving on BFRs and BFERs, with
>
>    multiple extension header where the last extension header has a 
> Next
>
>    Header field set to TBD, SHOULD be discard and the node should
>
>    transmit an ICMP Parameter Problem message to the source of the
>
>    packet (BFIR) with an ICMP code value of TBD10 ('invalid options 
> for
>
>    BIERin6').
>
>
>
> In this particular scenario where adjacent BFRs support Ethernet link 
> layer in an IPV6 environment and  IPv6 or ICMPv6 encapsulation and the 
> need for the next header code point above is the packet format:
>
>
>
> Excerpt from RFC 8296
>
>
>
>    Therefore, if a non-MPLS BIER packet is encapsulated in an Ethernet
>
>    header, the Ethertype MUST NOT be 0x8847 or 0x8848 [RFC5332 
> <https://urldefense.com/v3/__https:/tools.ietf.org/html/rfc5332__;!!NE
> t6yMaO-gk!TVpj_z-fpnhYihjYO4kRLRrvHGFDKTzS09SdN8jA-VKR14p1w2ObtXPqQ84s
> sHlj$>].  IEEE
>
>    has assigned Ethertype 0xAB37 for non-MPLS BIER packets.
>
>
>
>
>
> In the case of BIERin6 optional encapsulation option, in case where 
> operators requires packets forwarded in IPv6 or tunneling over Non BFR 
> packet format below:
>
>
>
> IPv6 outer header l BIER l Data
>
>
>
> So here the next header is BIER so corresponding next header code point.
>
>
>
>
>
> So below is for both cases IANA code point allocation for “L2” next 
> header where next header is IPv6 or ICMPV6, and then the optional IPv6 
> encapsulation option where the next header is BIER.
>
>
>
> Would those be two separate IANA code point requests I what I see from 
> the packet format.
>
>
>
> IANA L2 scenario:
>
> 2 code point requests for L2 for next header IPv6 and ICMP
>
>
>
> Zzh6> I don’t follow what you’re talking about. If BIER header follows
> Zzh6> L2
> header directly, no new code point is needed. It’s just “Ethernet
> 0xAB37 | BIER | payload”.
>
>
>
>     Gyan6> Agreed.
>
>
>
> IANA optional IPv6 scenario:
>
> 1 code point request for IPv6 for next header BIER
>
>
>
> Zzh6> If IPv6 encapsulation is used, either on between directly 
> Zzh6> connected
> BFRs or indirectly connected BFRs, a new “next header” code point is 
> needed for BIER.
>
>  Gyan6>Understood
>
>
> 5
> <https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-zhang-bier-bierin6-07*section-5__;Iw!!NEt6yMaO-gk!TVpj_z-fpnhYihjYO4kRLRrvHGFDKTzS09SdN8jA-VKR14p1w2ObtXPqQ_dVL5sH$>.
> IANA Considerations
>
>
>
>
>
>    IANA is requested to assign a new "BIER" type for "Next Header" in
>
>    the "Assigned Internet Protocol Numbers" registry.
>
>
>
>    IANA is requested to assign a new "BIERin6" type for "invalid
>
>    options" in the "ICMP code value" registry.
>
>
>
>    IANA is requested to assign a new "BIER IPv6 transportation
> Sub-sub-
>
>    TLV" type in the "OSPFv3 BIER Ethernet Encapsulation sub-TLV"
>
>    Registry.
>
>
>
>    IANA is requested to set up a new "BIER IPv6 transportation
> Sub-sub-
>
>    sub-TLV" type in the "IS-IS BIER Ethernet Encapsulation sub-sub-TLV"
>
>    Registry.
>
>
>
>
>
> My point is that the IANA allocation is different as the next header 
> is different for the L2 scenario where next header is IPv6 or ICMPV6, 
> and IPv6 encapsulation scenario where the next header is BIER.
>
>
>
> Zzh6> If BIER header follows L2 header directly, BIER Ethertype is 
> Zzh6> used
> (assuming Ethernet is the L2).
>
>  Gyan>Understood
>
> Based on this point I am making could we just do a RFC8296 bis version 
> and add the IANA code points for IPv6 and ICMPv6.
>
>
>
> Zzh6> Given the confusion/contention that have happened in the last 
> Zzh6> two
> years, it is much better to specifically have a spec dedicated to 
> supporting BIER in IPv6.
>
>  Gyan6> I think now looking at it holistically speaking I can now see 
> parity between the L2/tunnel and L3/tunnel both also having the clean 
> layering.  So I can see why adding existing L2/tunnel to BIERin6 even 
> though it already exists made sense to bundle into BIERin6 total 
> solution

Juniper Business Use Only