Re: Adoption Call for "The IPv6 Compact Routing Header (CRH)"

["Kamran Raza (skraza)" <[e-mail]>]

Hello 6man WG/chairs,
 
I do not support the WG adoption of this document.
 
In addition to numerous technical and other points made by others on the list already, I would like to highlight the tax this proposal puts on ASICs/hardware:
 
1) Additional mapping table and lookup:
Firstly, the CRH SID mapping requires an "additional" table for SID lookup. This incurs additional resources in hardware.
Secondly, in addition to original lookup on packet's DA, another lookup is needed in the above table, which will burn precious NPU cycles and impact performance (pps).

2) VPN Service's DOH header processing:
For CRH based solution, the VPN context is encoded in a Dest Opt header located after the CRH which adds the following challenges:
- At the egress PE, the packet arrives with both CRH and Dest Opt headers. The egress PE first needs to process the CRH to see whether SL = 0 and ignore the rest of it. 
- Then, it needs to process DoH and the options within it. This overall combination will be challenging for many ASICs.

Note that RFC6554 already defines a routing EH to perform compressed IPv6 source routing.
RFC6554 has the same compression/overhead as the CRH, and it does not rely on a mapping mechanism, and hence it does not suffer the challenges described above.
Hence, the authors should also document why their use-cases (which remain bit unclear at this point) cannot be achieved with RFC6554.

Rgds
--
Kamran

On 2020-05-15, 6:13 PM, "ipv6 on behalf of Bob Hinden" <[e-mail] on behalf of [e-mail]> wrote:

    This message starts a two-week 6MAN call on adopting:

     Title:          The IPv6 Compact Routing Header (CRH)
     Authors:        R. Bonica, Y. Kamite, T. Niwa, A. Alston, L. Jalil
     File Name:      draft-bonica-6man-comp-rtg-hdr-21
     Document date:  2020-05-14

     https://tools.ietf.org/html/draft-bonica-6man-comp-rtg-hdr

    as a working group item. Substantive comments regarding adopting this document should be directed to the mailing list.  Editorial suggestions can be sent to the authors.

    Please note that this is an adoption call, it is not a w.g. last call for advancement, adoption means that it will become a w.g. draft.  As the working group document, the w.g. will decide how the document should change going forward.

    This adoption call will end on 29 May 2020.

    The chairs note there has been a lot of discussions on the list about this draft.   After discussing with our area directors, we think it is appropriate to start a working group adoption call.  The authors have been active in resolving issues raised on the list.

    Could those who are willing to work on this document, either as contributors, authors or reviewers please notify the list.   That gives us an indication of the energy level in the working group
    to work on this.

    Regards,
    Bob and Ole