Subject: Upcoming 6man Adoption Calls

From: Bob Hinden <[email-masked]>
Date: Fri, 15 May 2020 11:27:26 -0700

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

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Fri, 15 May 2020 21:40:50 +0000

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 <[email-masked]> on behalf of Bob Hinden <[email-masked]>
Date: Friday, May 15, 2020 at 2:29 PM
To: IPv6 List <[email-masked]>
Cc: Bob Hinden <[email-masked]>
Subject: Upcoming 6man Adoption Calls

Bob & Ole

---

From: Ron Bonica <[email-masked]>
Date: Fri, 15 May 2020 23:25:01 +0000

Zafar,

Really? So, please explain to me how the CRH will require data plane changes to carry VPN information? BGP changes?

Please consider aiming before pulling the trigger.

                                                               Ron

Juniper Business Use Only
From: ipv6 <[email-masked]> On Behalf Of Zafar Ali (zali)
Sent: Friday, May 15, 2020 5:41 PM
To: Bob Hinden <[email-masked]>; IPv6 List <[email-masked]>
Subject: Re: Upcoming 6man Adoption Calls

[External Email. Be cautious of content]

Hi Bob,

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 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.

  *   RPL requested by ROLL

Thanks

Regards ... Zafar

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

Bob & Ole

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Sat, 16 May 2020 00:40:10 +0000

Ron,

These are your slides,
https://datatracker.ietf.org/meeting/105/materials/slides-105-6man-sessa-ipv6-support-for-segment-routing-srv6-00

Please try to erase the “long” history before trying to fool people.

Thanks

Regards … Zafar

From: Ron Bonica <rbonica=[email-masked]>
Date: Friday, May 15, 2020 at 7:25 PM
To: "Zafar Ali (zali)" <[email-masked]>, Bob Hinden <[email-masked]>, IPv6 List <[email-masked]>
Subject: RE: Upcoming 6man Adoption Calls

Zafar,

                                                               Ron

To: Bob Hinden <[email-masked]>; IPv6 List <ipv6@ietf..org>

Hi Bob,

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.

  *   RPL requested by ROLL

Please also see list of open issues in the following..

Thanks

Regards … Zafar

Bob & Ole

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 16 May 2020 13:22:19 +1200

I hate to repeat something that should be well known, but I think it's something that people often overlook:

"Adoption" of a draft by a WG does *not* mean that the WG is obliged to later approve it for publication. In fact, adopted drafts that do not reach WG rough consensus usually die.

"Adoption" *does* mean that change control of the draft passes from the authors to the WG.

Unfortunately we don't have a BCP that defines this very clearly. If you think that's a problem, please hop over to the gendispatch list and reply to my message there: https://mailarchive.ietf.org/arch/msg/gendispatch/fhU_Z7rrE_XxyLkoGzAFJLQ04hY/

Regards
   Brian Carpenter

On 16-May-20 06:27, Bob Hinden wrote:
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>