Re: [Bier] BIER/IPv6 Requirements and Solutions

[Greg Shepherd <[e-mail]>]

Xuesong,

Inline:

On Thu, Sep 24, 2020 at 8:09 PM Gengxuesong (Geng Xuesong) <
[e-mail]> wrote:

> Just one more comment: Any WG feedback is welcome. All the previous
> comments are carefully considered and discussed among authors[*]. If there
> is something new, raise it up with implementable operations and it will be
> addressed. (Unless I'm missing something, section 3 hasn’t been asked to be
> removed or even considered inappropriate until version 07 was published in
> my knowledge)
>

There was no 'solution comparison' section in rev 0. It appeared in rev1,
and at the end of the doc. Since then that section has been carefully
word-smithed to direct the conversation about the requirements themselves.
It was removed in rev 4 at the request of the WG. Then it reappeared in rev
6 - without any WG request - and promoted to the top of the document, no
longer hiding the authors intent of leading the conversation on
requirements. So yes, nobody asked to remove it since rev 4 since it was no
longer there. As soon as it reappeared, the authors were asked to remove
it. Nothing new here except the authors' increasing pressure to resist
input from the WG.

Please remove that section rev the draft. There is nothing more to discuss
until then.

Thanks,
- Chairs
(Shep)


> Xuesong
>
>
>
> [*]Here are all the comments we have received from WG since IETF 108 (most
> recent comments not inluded). Here are some explanations about how we
> address/consider these comments in version 07.
>
>
>
> 1.      Comments from Greg Shepherd
>
> Section 2 Problem Statement
>
> -        “IPv6 unicast technologies can support multi-point transport”
> seems not clear
>
> [New Version] This sentence has been removed
>
>
>
> Section 3.2 Naive IPv6 Model
>
> -  “BIER is integrated into the IPv6 data plane” is not precise, could be
> considered to modify as “BIER header integrated into the IPv6 header”
>
> [New Version] Similar expressions are maintained in this version,
> including:
>
> “   The second conceptual model is an Integrated Model that integrates
>
>    BIER as part of the IPv6 data plane, making it a "Layer-3 BIER"
>
>    approach.”
>
> “In this model, BIER works as part of the IPv6 data plane.”
>
> This has been discussed among the authors. If we take it narrowly, “IPv6
> data plane” may mean to look up IP routing table and find the next hop, in
> which case, BIER could not be treated as part of it; while if we take it
> broadly, “IPv6 data plane” may include all the forwarding behavior
> happening in IPv6 layer including parsing extension headers, in which case,
> BIER could be treated as part of it.
>
>
>
> 2.      Comments from Sandy Zhang:
>
> Section 2 problem statement
>
> -        Not only non-BFR node scenario should be included
>
> [New version] It has been covered in the new version by
>
> “It may
>
>    also be desirable to not use IPv6 encapsulation except when IPv6
>
>    tunneling (native or GRE/UDP-like) is used to transport BIER packets
>
>    over BIER-incapable routers.”
>
>
>
> Section 3.1
>
> -        There is no fragmentation or IPSEC executed in BFR
>
> [New Version]
>
> An example has been added in section 4.2.1 to clarify the case and fix the
> comments.
>
>
>
> Section 3.2
>
> -        Fast forwarding could not be supported if using IPv6 extension
> header
>
> -        How to deal with the relationship with other extension header,
> e.g., fragmentation header
>
> [New version]
>
> This will be defined in the solution document rather than the requirement
> document.
>
>
>
> 3.      Comments from Jeffrey Zhang:
>
> Section 2  Problem Statement -> Request to remove/modify the descriptions
> that may be considered biased:
>
> -        Inter-domain is not model specific. Reference to individual draft
> should be removed.
>
> [New version]
>
> Descriptions about Inter-domain has been removed.
>
> -        The descriptions of fragmentation is not reasonable because
> fragmentation/reassembly does not happen on each BFR when it is connected
> directly with another BFR.
>
> [New version]
>
> Descriptions about fragmentation in section 3 has been removed.
>
> -        IPv6 native functions should not be requested by Layer2.5
> tunneling, which could be executed in IPv6 layer.
>
> [New version]
>
> Descriptions about other IPv6 functions in section 3 have been removed.
>
> Section 4.1.6  Simple Encapsulation-> Unclear requirement item
>
> [New version]
>
> This requirement has been removed.
>
>
>
> 4.      Comments from Alvaro Retana
>
> Section 2
>
> -        Problem Statement should be straight forward
>
> [New version]
>
> Problem Statement has been modified totally with help of Gyan and Jeffrey.
>
>
>
> Section 3
>
> -        Transport-Independent Model" is not in line with the layering
> model from rfc8279
>
> [New version]
>
> The layering of BIER defined in RFC8279 is not the same as it has been
> discussed in section 3, where layer 3/layer 2.5 means protocol layering of
> TCP/IP.
>
> -        It seems that there is some Bias for native IPv6 Model
>
> [New version]
>
> Section 3.1.  Independent Model has been well modified by Jeffrey as the
> one of the main authors of the document of BIERin6.
>
>
>
> Section 4
>
> -        Three levels: required, recommended, and optional
>
> -        Some mandatory requirements need no explanation, including:
> Support BIER architecture; Conform to existing IPv6 Spec; Support
> deployment with Non-BFR routers)
>
> -        Some of the requirements are not clear, e.g., L2 Agnostic,
> Support Simple Encapsulation, Support Deployment Security
>
> -        Some of the requirements are not included in RFC8279, e.g.,
> Support inter-AS multicast deployment
>
> [New version]
>
> All the requirement items have been reorganized. Well known requirement is
> kept simple and optional requirement is justified with example.
>
>
>
>
>
>
>
> -----Original Message-----
> From: Greg Shepherd [mailto:[e-mail]]
> Sent: Thursday, September 24, 2020 10:44 PM
> To: Jeffrey (Zhaohui) Zhang <[e-mail]>
> Cc: Gyan Mishra <[e-mail]>; Xiejingrong (Jingrong) <
> [e-mail]>; [e-mail];
> [e-mail]; [e-mail]; Alvaro Retana <[e-mail]
> >
> Subject: Re: [Bier] BIER/IPv6 Requirements and Solutions
>
>
>
> The authors were ask to remove the comparison section. I'm asking you
> again. I'll wait for the next rev to comment.
>
>
>
> Thanks,
>
> Greg
>
>
>
> On Thu, Sep 24, 2020 at 2:44 AM Jeffrey (Zhaohui) Zhang <
> [e-mail]>
>
> wrote:
>
>
>
> > Hi Gyan,
>
> >
>
> >
>
> >
>
> > A small clarification – while the requirements draft -07 currently
>
> > does have sections that briefly describe different models/solutions,
>
> > we have avoided discussing which one satisfies which requirements
>
> > intentionally (as the focus is on listing requirements).
>
> >
>
> >
>
> >
>
> > With that, I don’t think we’ve got a conclusion that “BIER-MPLS &
>
> > BIER-Ethernet, as it stands today has a MAJOR gap in being able to
>
> > support
>
> > SRv6 Service Provider core technology requiring an IPv6 data plane”.
>
> >
>
> >
>
> >
>
> > Jeffrey
>
> >
>
> >
>
> >
>
> >
>
> >
>
> > Juniper Business Use Only
>
> >
>
> > *From:* Gyan Mishra <[e-mail]>
>
> > *Sent:* Thursday, September 24, 2020 1:40 AM
>
> > *To:* Greg Shepherd <[e-mail]>
>
> > *Cc:* Xiejingrong (Jingrong) <[e-mail]>;
>
> > [e-mail]; [e-mail];
>
> > [e-mail]; Alvaro Retana <[e-mail]>
>
> > *Subject:* Re: [Bier] BIER/IPv6 Requirements and Solutions
>
> >
>
> >
>
> >
>
> > *[External Email. Be cautious of content]*
>
> >
>
> >
>
> >
>
> > Greg
>
> >
>
> >
>
> >
>
> > With all do respect, the authors welcome the AD and Chairs criticism
>
> > and any feedback, however in this particular case with your response,
>
> > there seems to be a disconnect with the ML discussions we have had
>
> > over the last several months.  Understandably, all of us here in the
>
> > WG realize the criticality of the BIER in an IPv6 environment, and
>
> > that BIER-MPLS & BIER-Ethernet, as it stands today has a MAJOR gap in
>
> > being able to support
>
> > SRv6 Service Provider core technology requiring an IPv6 data plane,
>
> > which will be the end all be all replacement for MPLS.  It is critical
>
> > that the BIER WG come up with a solution(s) that supports an IPv6 data
>
> > plane for
>
> > SRv6 support.  We all don't want BIER to die on the vine in a
>
> > technology graveyard with ATM, Frame Relay and the likes.  We the
>
> > authors are all in agreement and running fast after that goal and
>
> > understand the AD & Chairs now emphasis on the requirements draft.  We
>
> > are with you lock, stock and barrel.
>
> >
>
> >
>
> >
>
> > The authors of the BIER IPv6 Solutions draft
>
> > “draft-xie-bier-ipv6-encapsulation-08”, BIERv6, referred to as the
>
> > “Integrated model”, authors myself, McBride, Xuesong & Jingrong
>
> > collaborated in a joint effort over a month timeframe with the authors
>
> > of the BIER IPv6 Solutions draft “draft-zhang-bier-bierin6-07”,
>
> > BIERin6, referred to as the Independent model , authors Jeffrey &
>
> > Sandy to come up with a holistic solution where both conceptual models
>
> > accurately addressed the problem statement as well as the requirements
>
> > to support IPv6 for SRv6 support.  We wanted to make sure that we had
>
> > complete parity between conceptual models and relationships to the
>
> > problem statement and requirements list.  All authors from both
>
> > solutions worked together to ensure we had all of our “i’s” dotted &
>
> > “t’s” crossed so to speak, putting our best foot forward with this rev
> 7.
>
> >
>
> >
>
> >
>
> > I would like to point out that given the “Integrated model” BIERv6
>
> > Solutions initial draft came out in April 2018, and the “Independent
> model”
>
> > BIERin6 Solution came out in October 2017.  It is only since January
>
> > 2019 initial draft submission has the work to reverse engineer to come
>
> > up with the Requirements draft started a “post mortem” so to speak
>
> > after the Solutions had already been proposed.  To that end in
>
> > IETF108, the requirements draft had positive feedback related to
>
> > Section 3 conceptual framework for the two solutions proposed.  We are
>
> > all at a loss in understanding your comments as to removal of section
>
> > 3.  In order to create a requirements draft as part of any basic
>
> > requirements analysis, you must have some idea or concept or inkling
>
> > of a solutions framework to graft & glean the list of requirements which
> otherwise is not possible in my mind
>