Re: Upcoming 6man Adoption Calls

["Zafar Ali (zali)" <[e-mail]>]

Hi Bob,

Re: adoption call for draft-bonica-6man-comp-rtg-hdr-21.

On Feb. 16, 2019, the authors of the draft made a “major” change; they removed normative reference to SRm6 and made CRH as a “standalone” RH.
However, as has been mentioned earlier, architecture, use-cases and applicability are unclear.
Furthermore, there are many outstanding comments (a partial list is provided in the following).

The authors of CRH have multiple drafts for CP extensions, and more will be required.

  *   Changes to ISIS to carry the mapping table (draft-bonica-lsr-crh-isis-extensions)
  *   Data plane changes to carry VPN information (draft-bonica-6man-vpn-dest-opt),
  *   BGP changes to carry VPN info (draft-alston-spring-crh-bgp-signalling),
  *   OSPF changes to carry the mapping table (similar to ISIS)
  *   PCEP extension to program the mapping table (mentioned in the interim slides)
  *   OAM tools to debug the mapping table (there was a document published)
  *   Yang interface to program the mapping table (mentioned in the interim slides)
  *   Interworking with other solutions (MPLS, SRH, etc.)

The scope of CRH is “limited domain” and not the “Internet”.

In short, CRH is a “major” change. I am not sure if such a major change is in 6man charter but request that 6man should keep the same bar that it has kept for other RHs, e.g., in this case architecture documentation must be first.

All other routing header types have had requirements and design from dedicated working groups with expertise in the area.  CRH is no exception.

The following RH types provide context and why CRH is a major change:

  *   SRH requested by SPRING
     *   Today has 50 draft spanning 13 working groups: https://datatracker.ietf.org/doc/draft-ietf-6man-segment-routing-header/referencedby/
  *   RPL requested by ROLL
     *   Today has 18 drafts and RFCs https://datatracker.ietf.org/doc/RFC6554/referencedby/
  *   Type 2 requested by MEXT:
     *   Today MEXT has over 60 drafts and RFCs https://datatracker.ietf.org/doc/RFC6275/referencedby/

Please also see list of open issues in the following.

In summary, the adoption calls for this document is premature, to say the least.
Request you ask authors to first address the concerns.

Open Issues (partial list):

Robert "Drawback of Mapping table"
https://mailarchive.ietf.org/arch/msg/ipv6/g2vrwFO-cjYX0ZeiMxqjWNGfkUU/

Ketan: "All segment types used are as defined in SR architecture RFC8402 (read poor man's job to distance from SRm6)"
https://mailarchive.ietf.org/arch/msg/ipv6/5jDdun2yzwnsJtJE1PzVvj1bjjQ/

Fengwei Qin: "security concerns"
https://mailarchive.ietf.org/arch/msg/ipv6/Vzcojf2mFXdrqW5OYoXf8iwNatQ/

Jingrong: "Limited domain scope and security concerns"
https://mailarchive.ietf.org/arch/msg/ipv6/QyaRQAjPoRExJGWLXaSXWHcMDdQ/

Robert: "How other functions like TI-LFA, uloop avoidance are performed"
https://mailarchive.ietf.org/arch/msg/ipv6/7_aEF5M6owrIqb3t3BNFdCSZ3jM/

Darren: "use-case beyond SRm6"
https://mailarchive.ietf.org/arch/msg/ipv6/emQ3Sj_l4fWXErZY_nhQAbYxr5Y/

Robert: "need for CRH-FIB on all nodes"
https://mailarchive.ietf.org/arch/msg/ipv6/IXlGxvjBBKvTMTA12UaX8jHqQNw/

Shuping: "How to support VPN and HW inefficiency for VPN in DOH and segments in RH."
https://mailarchive.ietf.org/arch/msg/ipv6/aO0MdyDZci2k58cV0W0gzoa1o-c/

Ketan: "Need for clarification for CRH "standalone" proposal"
"https://mailarchive.ietf.org/arch/msg/ipv6/rCZ0HcH009qq4uW4m5VxkT5twNg/"

Robert: "operation complexity"
https://mailarchive.ietf.org/arch/msg/ipv6/LGnbYIv6B4ZoEKrsGp4RHRyO1pA/

Zafar "how to debug the mapping table entry"
During 6man interim session

Darren "clarification for "standalone" CRH architecture use"
https://mailarchive.ietf.org/arch/msg/ipv6/L8kVLCuxNBptiI2cONI32U8jjGM/

Ketan: "CRH is not source routing of RFC791 (use of adj SID and prefix SID RFC8402)"
https://mailarchive.ietf.org/arch/msg/ipv6/Xli0zIUZa53nSbBniOdiRviToqM/

Dan V provided the following list of open issues.

Robert Raszuk on the many extensions required by CRH (IGP, BGP, OAM) https://mailarchive.ietf.org/arch/msg/spring/_V8dsQOeRTuK2r7Lfi77bgICqhE
Robert Raszuk and Dirk Steinberg on CRH being a poor re-engineering of SR-MPLS over IP/UDP
Robert: https://mailarchive.ietf.org/arch/msg/spring/6bdX_gb47uFYnd6ytwFLPYxXCYo
Dirk: https://mailarchive.ietf.org/arch/msg/spring/6Bm4nN5ah8rFb7VutexK30kRUPM
Dan Voyer reminding that SRv6 is a mature technology (deployments, long IETF work), as opposed to CRH https://mailarchive.ietf.org/arch/msg/spring/OB1l41EhhUu8x8XEnKaBTdczDj4
Zhibo Hu on the many advantages of SRv6 https://mailarchive.ietf.org/arch/msg/spring/D7IFJakb5Ew2iMXUfvf1wub7arQ
Cheng Li expressing concerns on the dataplane performance of CRH https://mailarchive.ietf.org/arch/msg/spring/XK0F40oEuZv-3ule-X5685d_6Mc
Zafar summarizing the main issues of CRH https://mailarchive.ietf.org/arch/msg/spring/wFDK_Be7lEt4s191m61WdUOEzL4
Wim Henderickx  https://mailarchive.ietf.org/arch/msg/spring/nX5-1rdXKOw6ks73VYfwvn7iaI8
Darren Dukes  https://mailarchive.ietf.org/arch/msg/spring/v8UAgBGQ0yp0VBwGkZ3RwzH1MME

Thanks

Regards … Zafar

From: ipv6 <[e-mail]> on behalf of Bob Hinden <[e-mail]>
Date: Friday, May 15, 2020 at 2:29 PM
To: IPv6 List <[e-mail]>
Cc: Bob Hinden <[e-mail]>
Subject: Upcoming 6man Adoption Calls

After discussing it with the Internet Area Directors will be starting three 6man adoption calls in the near future.  These are for:

draft-fz-6man-ipv6-alt-mark-09
draft-bonica-6man-comp-rtg-hdr-21
draft-gont-6man-slaac-renum-07

We expect to send the first two later today, the third is delayed a bit waiting for feedback from our AD.

Bob & Ole