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

From: Ron Bonica <[email-masked]>
Date: Wed, 13 May 2020 21:16:41 +0000

Folks,

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.

Bob Hinden points out that data compression techniques squeeze redundant information out of a message in manner that the message can be reconstructed by the receiver. CRH doesn't do that kind of compression at all.

                                                                         Ron

Juniper Business Use Only

-----Original Message-----
From: [email-masked] <[email-masked]> 
Sent: Wednesday, May 13, 2020 5:06 PM
To: [email-masked] <[email-masked]>; Yuji Kamite <[email-masked]>; Luay Jalil <[email-masked]>; [email-masked] <[email-masked]>; Ron Bonica <[email-masked]>; Tomonobu Niwa <[email-masked]>
Subject: New Version Notification for draft-bonica-6man-comp-rtg-hdr-18.txt

[External Email. Be cautious of content]

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.

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 13 May 2020 23:50:30 +0200

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

...

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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 13 May 2020 17:59:04 -0400

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:
> 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.
> 
>     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.
> 
> ...
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: "Chengli (Cheng Li)" <[email-masked]>
Date: Thu, 14 May 2020 12:40:28 +0000

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:[email-masked]] On Behalf Of Robert Raszuk
Sent: Thursday, May 14, 2020 5:51 AM
To: Ron Bonica <rbonica=[email-masked]>
Cc: SPRING WG <[email-masked]>; 6man <[email-masked]>
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 ! ;-)

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.

...

Abstract:

---

From: Tom Herbert <[email-masked]>
Date: Thu, 14 May 2020 08:06:15 -0700

> the TLVs questioned during the WG process?:

Yes, there were many questions and objections raised about why TLVs
were needed, why SRH needs its own authentication when AH would
suffice, why SRH in fact breaks AH. Also, there doesn't seem to be any
current support for SR TLVs in implementation. For instance, in
draft-ietf-6man-segment-routing-header-26, with the exception of Linux
(which last time I checked didn't have correct support), every
reported implementation of SR states "no TLV processing".  Given the
forty years of misery we've had trying to use TLVs in the network
layer, first with IPv4 options and then IPv6 Destination and
Hop-by-Hop options, I don't think this is simply an aberration-- it's
not likely there will ever be significant support or deployment of SRH
TLVs. IMO, it would be an improvement to the protocol if TLVs were
simply taken out of SRH. Even if a compelling use case were to
materialize, DestOpts and HBH are sufficient and much more general to
work with any protocol or routing header (including CRH for instance).

Tom