Re: FW: New Version Notification for draft-bonica-6man-comp-rtg-hdr-18.txt

Robert, as you seriously asking "why wasn't the complexity of SRH and 
the TLVs questioned during the WG process?:
It was questioned repeatedly.  Eventually, the chairs concluded that th 
questioners were in the rough.  Which is their job to judge.  But that 
is NOT the same as saying that the quessiton was not raised.

And given that operators are asking for alternatives, no, I do not think 
it is appropriate to say that we will not consider alternatives for 
several years.

If Folks were asking for the withdrawal of SRH (tempting, but the wrong 
answer), then asking for time for deployment experience would seem a 
reasonable response.  But that is not the ask.  No one is asking to 
withdraw or deprecate SRH.

Yours,
Joel

On 5/13/2020 5:50 PM, Robert Raszuk wrote:
> 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.
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 