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

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Wed, 2 Dec 2020 14:10:17 +0000

Zhaohui (Jeffrey) contacted me last week about the Geng's point #2 as I was one of the people raising the comment during IETF-108 6MAN session while wearing *no hat*. Please also note that I am *not* a BIER expert and not a member of the BIER list.

Here is my reply to Zhaohui:

EV> First, please note that my comment at IETF-108 was without any AD hat and that Erik Kline is the responsible AD for 6MAN.

EV> Then, please note that the current state of IPv6 extension headers is that no new extension header (HE) may be specified 
EV> but the door is wide open to add options into existing EH  (e.g., in hop-by-hop options or destination options headers).

EV> HEs are followed by either another EH or by a transport layer header or by 'no more EH'. While a transport 
EV> header is followed by an 'application' payload: TCP payload, ICMP payload, GRE/IPinIP encapsulated packet (that could be of course  also BIER payload).

EV> IF the IPv6 packets are sent with a destination address that is NOT the next BIER router AND 
EV> IF the intermediate routers must process the BIER header, then a BIER option in the Hop-by-Hop extension header sounds more suitable to me.

EV> If the IPv6 packets are sent with a destination address that is the next BIER router, 
EV> then this BIER over IPv6 looks more like a GRE/IP-in-IP to me, this means BIER not as extension header 
EV> but more like a 'transport' header (pretty much like GRE or IP-in-IP). Else, a destination option header may also fit.

EV> After reviewing the slides that you presented at IETF-108, you were right by asking for a 'protocol number' but, to be pedantic, 
EV> this is not an extension header but rather a 'transport' header. It will also have the added benefit to work with the legacy IPv4 protocol. 
EV> The alternative would be an option for the destination options header.  So, based on the BIER WG/authors' choice, the relevant WGs are 
EV> either 6MAN (to add a destination/HbH option) or INTAREA (to request a protocol number).

The last sentence above is with my IESG hat though ;-)

Hope this clarifies

-éric

-----Original Message-----
From: "Gengxuesong (Geng Xuesong)" <[email-masked]>
Date: Saturday, 28 November 2020 at 03:05
To: "[email-masked]" <[email-masked]>, "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Cc: Gyan Mishra <[email-masked]>, Alvaro Retana <[email-masked]>, BIER WG <[email-masked]>, "[email-masked]" <[email-masked]>, Tony Przygienda <[email-masked]>, draft-ietf-bier-ipv6-requirements <[email-masked]>
Subject: Re: [Bier] draft-ietf-bier-ipv6-requirements-09

    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;
    2. The comments raised by 6MAN WG and INT area are not addressed, which requests the document to be discussed in transport area;
    3. BIERin6 is not an independent solution which uses BIER Ethernet when BFR nodes are connected directly.

    Best
    Xuesong