Agree. I definitely needs time to go through the documents, seems some revision are updated.
If we want to solve the overhead of SRv6, we may have some options to be discussed. Like G-SRv6[1][2], please focus on the SRv6 compression part, if you need to understand it very soon. For sure, a brand new solution that is not compatible with SRH should be discussed further. Best regards, Cheng [1].https://tools.ietf.org/html/draft-cl-spring-generalized-srv6-np-01 [2]. https://tools.ietf.org/html/draft-lc-6man-generalized-srh-00 From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Robert Raszuk Sent: Thursday, May 14, 2020 5:51 AM To: Ron Bonica <rbonica=40juniper....@dmarc.ietf.org> Cc: SPRING WG <spring@ietf.org>; 6man <6...@ietf.org> Subject: Re: [spring] FW: New Version Notification for draft-bonica-6man-comp-rtg-hdr-18.txt WGs, If someone is to judge a document's maturity level by the number of its version iterations with three new versions within the last 3 hours this draft is getting really stable pretty fast ! ;-) But seriously 6man just published SRH RFC8754. Shouldn't we first get some decent and real operational experience with SRH for a year or two before starting a new proposal with a subset of its capabilities ? If SRH is just too complex, why during the IETF WG process and IETF review that was not questioned and addressed ? In my books use of TLVs is a feature not a bug. New proposal to essentially do the same should not be taken on right now - instead pragmatic approach would be to take out those elements which are not operationally needed or add those which are missing should be worked on after some time and RFC8754-bis could be then issued. Note that if we are just about shorter SIDs like 16 or 32 bits that is possible today with the vSID proposal and current SRH format. https://tools.ietf.org/html/draft-decraene-spring-srv6-vlsid-03 Last - can anyone imagine operational complexity when a network would consist of some routers which can only do CRH and some which can only process SRH ? Leave alone the fact that both headers are completely incompatible with each other. Many thx, Robert. In this draft version, I rename the Routing header type. It was called the Compressed Routing Header. Now it is called the Compact Routing Header. ... A new version of I-D, draft-bonica-6man-comp-rtg-hdr-18.txt has been successfully submitted by Ron Bonica and posted to the IETF repository. Name: draft-bonica-6man-comp-rtg-hdr Revision: 18 Title: The IPv6 Compact Routing Header (CRH) Document date: 2020-05-13 Group: Individual Submission Pages: 14 URl: https://www.ietf.org/internet-drafts/draft-bonica-6man-comp-rtg-hdr-18.txt Status: https://datatracker.ietf.org/doc/draft-bonica-6man-comp-rtg-hdr Htmlized: https://tools.ietf.org/html/draft-bonica-6man-comp-rtg-hdr-18 Htmlized: https://datatracker.ietf.org/doc/html/draft-bonica-6man-comp-rtg-hdr Diff: https://www.ietf.org/rfcdiff?url2=draft-bonica-6man-comp-rtg-hdr-18 Abstract: This document defines two new Routing header types. Collectively, they are called the Compact Routing Headers (CRH). Individually, they are called CRH-16 and CRH-32.
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
