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

From: Ron Bonica <[email-masked]>
Date: Mon, 17 Feb 2020 00:56:08 +0000

Folks,

Over the last several weeks, customers who have no interest in Segment Routing have expressed interest in the CRH. So, we have updated the CRH draft, removing all references to Segment Routing and letting it stand alone as an IPv6 Routing header.

While Segment Routing may one day be a user of the CRH, it will not be the only user.

Please review this document as a stand-alone piece of work.

                                                                          Ron

Juniper Business Use Only

-----Original Message-----
From: [email-masked] <[email-masked]> 
Sent: Sunday, February 16, 2020 7:46 PM
To: Ron Bonica <[email-masked]>; Ning So <[email-masked]>; Andrew Alston <[email-masked]>; Ning So <[email-masked]>; Tomonobu Niwa <[email-masked]>; Andrew Alston <[email-masked]>; Yuji Kamite <[email-masked]>
Subject: New Version Notification for draft-bonica-6man-comp-rtg-hdr-11.txt

A new version of I-D, draft-bonica-6man-comp-rtg-hdr-11.txt
has been successfully submitted by Ron Bonica and posted to the IETF repository.

Name:		draft-bonica-6man-comp-rtg-hdr
Revision:	11
Title:		The IPv6 Compressed Routing Header (CRH)
Document date:	2020-02-16
Group:		Individual Submission
Pages:		16
URL                      https://tools.ietf.org/html/draft-bonica-6man-comp-rtg-hdr-11
Status:                https://datatracker.ietf.org/doc/draft-bonica-6man-comp-rtg-hdr/
Htmlized:           https://tools.ietf.org/html/draft-bonica-6man-comp-rtg-hdr-11
Htmlized:           https://datatracker.ietf.org/doc/html/draft-bonica-6man-comp-rtg-hdr
Diff:           
Abstract:
   This document defines two new Routing header types.  Collectively,
   they are called the Compressed 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: Andrew Alston <[email-masked]>
Date: Mon, 17 Feb 2020 11:45:49 +0000

As a co-author of this document, I fully support this change.  We have stated many times that we have a need for this technology - and in fact have done significant work internally to use this technology - inclusive of tests to steer traffic between asn's and other things.

Thanks Ron for the work on this.

Andrew

From: ipv6 <[email-masked]> On Behalf Of Ron Bonica
Sent: Monday, 17 February 2020 03:56
To: 6man WG <[email-masked]>
Subject: FW: New Version Notification for draft-bonica-6man-comp-rtg-hdr-11.txt

Folks,

Ron

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Sent: Sunday, February 16, 2020 7:46 PM
To: Ron Bonica <[email-masked]<mailto:[email-masked]>>; Ning So <[email-masked]<mailto:[email-masked]>>; Andrew Alston <[email-masked]<mailto:[email-masked]>>; Ning So <[email-masked]<mailto:[email-masked]>>; Tomonobu Niwa <[email-masked]<mailto:[email-masked]>>; Andrew Alston <[email-masked]<mailto:[email-masked]>>; Yuji Kamite <[email-masked]<mailto:[email-masked]>>
Subject: New Version Notification for draft-bonica-6man-comp-rtg-hdr-11.txt

Name: draft-bonica-6man-comp-rtg-hdr
Revision: 11
Title: The IPv6 Compressed Routing Header (CRH)
Document date: 2020-02-16
Group: Individual Submission
Pages: 16
URL https://tools.ietf.org/html/draft-bonica-6man-comp-rtg-hdr-11<https://tools.ietf.org/html/draft-bonica-6man-comp-rtg-hdr-11>
Status: https://datatracker.ietf.org/doc/draft-bonica-6man-comp-rtg-hdr/<https://datatracker.ietf.org/doc/draft-bonica-6man-comp-rtg-hdr/>
Htmlized: https://tools.ietf.org/html/draft-bonica-6man-comp-rtg-hdr-11<https://tools.ietf.org/html/draft-bonica-6man-comp-rtg-hdr-11>
Htmlized: https://datatracker.ietf.org/doc/html/draft-bonica-6man-comp-rtg-hdr<https://datatracker.ietf.org/doc/html/draft-bonica-6man-comp-rtg-hdr>
Diff:
Abstract:
This document defines two new Routing header types. Collectively,
they are called the Compressed Routing Headers (CRH). Individually,
they are called CRH-16 and CRH-32.

The IETF Secretariat
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6<https://www.ietf.org/mailman/listinfo/ipv6>
--------------------------------------------------------------------

---

From: Julian Lucek <[email-masked]>
Date: Mon, 17 Feb 2020 11:58:17 +0000

+1

6man should adopt this draft because:

(i) It has been around for a year
(ii) It has been implemented on experimental code versions: LINUX Server (software-based forwarding) and MX series router (ASIC-based forwarding)
(iii) It has had some experimental deployments, as well as Liquid, in some other, as yet unnamed, networks

Julian

From: ipv6 <[email-masked]> on behalf of Andrew Alston <[email-masked]>
Date: Monday, 17 February 2020 at 11:45
To: Ron Bonica <rbonica=[email-masked]>, 6man WG <[email-masked]>
Subject: RE: New Version Notification for draft-bonica-6man-comp-rtg-hdr-11.txt

As a co-author of this document, I fully support this change.  We have stated many times that we have a need for this technology – and in fact have done significant work internally to use this technology – inclusive of tests to steer traffic between asn’s and other things.

Andrew

Folks,

Ron

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Sent: Sunday, February 16, 2020 7:46 PM
To: Ron Bonica <[email-masked]<mailto:[email-masked]>>; Ning So <[email-masked]<mailto:[email-masked]>>; Andrew Alston <[email-masked]<mailto:[email-masked]>>; Ning So <[email-masked]<mailto:[email-masked]>>; Tomonobu Niwa <[email-masked]<mailto:[email-masked]>>; Andrew Alston <[email-masked]<mailto:[email-masked]>>; Yuji Kamite <[email-masked]<mailto:[email-masked]>>
Subject: New Version Notification for draft-bonica-6man-comp-rtg-hdr-11.txt

Name: draft-bonica-6man-comp-rtg-hdr
Revision: 11
Title: The IPv6 Compressed Routing Header (CRH)
Document date: 2020-02-16
Group: Individual Submission
Pages: 16
URL https://tools.ietf.org/html/draft-bonica-6man-comp-rtg-hdr-11<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-bonica-6man-comp-rtg-hdr-11__;!!NEt6yMaO-gk!XkLwpNbt_lW0zdMC3zBSxB88VXWxHgJ8TnckKpe9_FSeDWas7BKUD1BH05HFYzWY$>
Status: https://datatracker.ietf.org/doc/draft-bonica-6man-comp-rtg-hdr/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-bonica-6man-comp-rtg-hdr/__;!!NEt6yMaO-gk!XkLwpNbt_lW0zdMC3zBSxB88VXWxHgJ8TnckKpe9_FSeDWas7BKUD1BH0w3nJEqm$>
Htmlized: https://tools.ietf.org/html/draft-bonica-6man-comp-rtg-hdr-11<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-bonica-6man-comp-rtg-hdr-11__;!!NEt6yMaO-gk!XkLwpNbt_lW0zdMC3zBSxB88VXWxHgJ8TnckKpe9_FSeDWas7BKUD1BH05HFYzWY$>
Htmlized: https://datatracker.ietf.org/doc/html/draft-bonica-6man-comp-rtg-hdr<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-bonica-6man-comp-rtg-hdr__;!!NEt6yMaO-gk!XkLwpNbt_lW0zdMC3zBSxB88VXWxHgJ8TnckKpe9_FSeDWas7BKUD1BH0_p5lJrd$>
Diff:
Abstract:
This document defines two new Routing header types. Collectively,
they are called the Compressed Routing Headers (CRH). Individually,
they are called CRH-16 and CRH-32.

The IETF Secretariat
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!XkLwpNbt_lW0zdMC3zBSxB88VXWxHgJ8TnckKpe9_FSeDWas7BKUD1BH01zTmF8y$>
--------------------------------------------------------------------

---

From: Xing Li <[email-masked]>
Date: Mon, 17 Feb 2020 20:08:08 +0800

> Please review this document as a stand-alone piece of work.

I fully support this draft as a 6man WG document.

xing

> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6

---

From: Melchior Aelmans <[email-masked]>
Date: Mon, 17 Feb 2020 23:16:21 +1100

+1 The draft looks good and is ready for WG adoption.

On Mon, Feb 17, 2020 at 11:08 PM Xing Li <[email-masked]> wrote:

> Ron Bonica 写道:
> > Folks,
> >
> > Over the last several weeks, customers who have no interest in Segment
> Routing have expressed interest in the CRH. So, we have updated the CRH
> draft, removing all references to Segment Routing and letting it stand
> alone as an IPv6 Routing header.
> >
> > To: Ron Bonica <[email-masked]>; Ning So <[email-masked]>; Andrew
> Alston <[email-masked]>; Ning So <[email-masked]>;
> Tomonobu Niwa <[email-masked]>; Andrew Alston <
> [email-masked]>; Yuji Kamite <[email-masked]>
> > URL
> https://tools.ietf.org/html/draft-bonica-6man-comp-rtg-hdr-11
> > Status:
> https://datatracker.ietf.org/doc/draft-bonica-6man-comp-rtg-hdr/
> > Htmlized:
> https://tools.ietf.org/html/draft-bonica-6man-comp-rtg-hdr-11
> > Htmlized:
> https://datatracker.ietf.org/doc/html/draft-bonica-6man-comp-rtg-hdr
> > Diff:
> > Abstract:
> > 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: Chris Bowers <[email-masked]>
Date: Mon, 17 Feb 2020 08:11:53 -0600

+1 I think it makes sense for the WG to adopt this draft.

Chris

On Mon, Feb 17, 2020 at 5:58 AM Julian Lucek <jlucek=
[email-masked]> wrote:

> (ii) It has been implemented on experimental code versions: LINUX Server
> (software-based forwarding) and MX series router (ASIC-based forwarding)
>
> *From: *ipv6 <[email-masked]> on behalf of Andrew Alston <
> [email-masked]>
> *Date: *Monday, 17 February 2020 at 11:45
> *To: *Ron Bonica <rbonica=[email-masked]>, 6man WG <
> [email-masked]>
> *Subject: *RE: New Version Notification for
> draft-bonica-6man-comp-rtg-hdr-11.txt
>
>
>
> As a co-author of this document, I fully support this change.  We have
> stated many times that we have a need for this technology – and in fact
> have done significant work internally to use this technology – inclusive of
> tests to steer traffic between asn’s and other things.
>
>
>
> *From:* ipv6 <[email-masked]> *On Behalf Of *Ron Bonica
> *Sent:* Monday, 17 February 2020 03:56
> *To:* 6man WG <[email-masked]>
> *Subject:* FW: New Version Notification for
> draft-bonica-6man-comp-rtg-hdr-11.txt
>
>
>
> Folks,
>
> <https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-bonica-6man-comp-rtg-hdr-11__;!!NEt6yMaO-gk!XkLwpNbt_lW0zdMC3zBSxB88VXWxHgJ8TnckKpe9_FSeDWas7BKUD1BH05HFYzWY$>
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-bonica-6man-comp-rtg-hdr/__;!!NEt6yMaO-gk!XkLwpNbt_lW0zdMC3zBSxB88VXWxHgJ8TnckKpe9_FSeDWas7BKUD1BH0w3nJEqm$>
> <https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-bonica-6man-comp-rtg-hdr-11__;!!NEt6yMaO-gk!XkLwpNbt_lW0zdMC3zBSxB88VXWxHgJ8TnckKpe9_FSeDWas7BKUD1BH05HFYzWY$>
> Htmlized:
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-bonica-6man-comp-rtg-hdr__;!!NEt6yMaO-gk!XkLwpNbt_lW0zdMC3zBSxB88VXWxHgJ8TnckKpe9_FSeDWas7BKUD1BH0_p5lJrd$>
> Diff:
> Abstract:
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!XkLwpNbt_lW0zdMC3zBSxB88VXWxHgJ8TnckKpe9_FSeDWas7BKUD1BH01zTmF8y$>

---

From: Gyan Mishra <[email-masked]>
Date: Mon, 17 Feb 2020 10:32:25 -0500

+1 I agree it makes sense for the WG to adopt the draft.

It provides a solid solution to issues with MSD(maximum sid depth) that
exist and plagues both SR-MPLS and SRv6.  One of major issues with SR-MPLS
is that as long as cSPF constraint based IGP path is used you don’t run
into MSD issues.  However, if SR-TE is employed with ERO-explicit route
object you run into trouble with MSD and the source routed path results in
an PCALC error - and the path cannot be instantiated.  With SRv6 the
problem with MSD is exacerbated since SRv6 can natively source route a TE
ERO path using SRH routing header type 4. So all paths instantiated can
result in SID depth issues.  For both existing SR options you almost have
to use a centralized PCE controller based architecture - as with
distributed and hybrid scenarios can be problematic with static ERO
instantiation.  Static ERO is the main goal of Sping Segment Routing and
not a dynamic cSPF ERO.

This draft also provides an alternative source routing option to use case
for RH0 which has security vulnerabilities.

Verizon as Tier 1 SP is very interested in testing CRH as it addresses
major pitfalls with Segment Routing.

Gyan

-- 

Gyan  Mishra

Network Engineering & Technology

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347

Email: [email-masked]

---

From: Srihari Sangli <[email-masked]>
Date: Mon, 17 Feb 2020 15:46:03 +0000

+1

The draft has been around for over an year, it’s a good solution and ASIC friendly. The WG should adopt this draft.

srihari…

On 17/02/20, 9:02 PM ipv6 on behalf of Gyan Mishra from [email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]> said >

It provides a solid solution to issues with MSD(maximum sid depth) that exist and plagues both SR-MPLS and SRv6.  One of major issues with SR-MPLS is that as long as cSPF constraint based IGP path is used you don’t run into MSD issues.  However, if SR-TE is employed with ERO-explicit route object you run into trouble with MSD and the source routed path results in an PCALC error - and the path cannot be instantiated.  With SRv6 the problem with MSD is exacerbated since SRv6 can natively source route a TE ERO path using SRH routing header type 4. So all paths instantiated can result in SID depth issues.  For both existing SR options you almost have to use a centralized PCE controller based architecture - as with distributed and hybrid scenarios can be problematic with static ERO instantiation.  Static ERO is the main goal of Sping Segment Routing and not a dynamic cSPF ERO.

This draft also provides an alternative source routing option to use case for RH0 which has security vulnerabilities.

Verizon as Tier 1 SP is very interested in testing CRH as it addresses major pitfalls with Segment Routing.

Gyan

On Mon, Feb 17, 2020 at 9:14 AM Chris Bowers <[email-masked]<mailto:[email-masked]>> wrote:
+1 I think it makes sense for the WG to adopt this draft.

Chris

On Mon, Feb 17, 2020 at 5:58 AM Julian Lucek <jlucek=[email-masked]<mailto:[email-masked]>> wrote:
+1

Julian

From: ipv6 <[email-masked]<mailto:[email-masked]>> on behalf of Andrew Alston <[email-masked]<mailto:[email-masked]>>
Date: Monday, 17 February 2020 at 11:45
To: Ron Bonica <rbonica=[email-masked]<mailto:[email-masked]>>, 6man WG <[email-masked]<mailto:[email-masked]>>
Subject: RE: New Version Notification for draft-bonica-6man-comp-rtg-hdr-11.txt

Andrew

From: ipv6 <[email-masked]<mailto:[email-masked]>> On Behalf Of Ron Bonica
Sent: Monday, 17 February 2020 03:56
To: 6man WG <[email-masked]<mailto:[email-masked]>>
Subject: FW: New Version Notification for draft-bonica-6man-comp-rtg-hdr-11.txt

Folks,

Ron

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Sent: Sunday, February 16, 2020 7:46 PM
To: Ron Bonica <[email-masked]<mailto:[email-masked]>>; Ning So <[email-masked]<mailto:[email-masked]>>; Andrew Alston <[email-masked]<mailto:[email-masked]>>; Ning So <[email-masked]<mailto:[email-masked]>>; Tomonobu Niwa <[email-masked]<mailto:[email-masked]>>; Andrew Alston <[email-masked]<mailto:[email-masked]>>; Yuji Kamite <[email-masked]<mailto:[email-masked]>>
Subject: New Version Notification for draft-bonica-6man-comp-rtg-hdr-11.txt

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<https://urldefense.com/v3/__http:/tools.ietf.org__;!!NEt6yMaO-gk!WV5WnFFMHYAXMxdz9gSikkZtS2KeAI2HFEgr92SuApHHXR6xrLRt9sWVA0IGPmg$>.

The IETF Secretariat
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!XkLwpNbt_lW0zdMC3zBSxB88VXWxHgJ8TnckKpe9_FSeDWas7BKUD1BH01zTmF8y$>
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!WV5WnFFMHYAXMxdz9gSikkZtS2KeAI2HFEgr92SuApHHXR6xrLRt9sWVx3l9seo$>
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!WV5WnFFMHYAXMxdz9gSikkZtS2KeAI2HFEgr92SuApHHXR6xrLRt9sWVx3l9seo$>
--------------------------------------------------------------------
--
Gyan  Mishra
Network Engineering & Technology
Verizon
Silver Spring, MD 20904
Phone: 301 502-1347
Email: [email-masked]<mailto:[email-masked]>

---

From: John Scudder <[email-masked]>
Date: Mon, 17 Feb 2020 16:48:12 +0000

I’ve reviewed this document several times at different points in its evolution. It’s clearly benefited from implementation experience and is a solid and clearly-written piece of work. Given that there’s demonstrated community interest in deployment, it’s time for the WG to pick it up.

—John

> On Feb 16, 2020, at 7:56 PM, Ron Bonica <rbonica=[email-masked]> wrote:
> 
> Folks,
> 
...

---

From: Krzysztof Grzegorz Szarkowicz <[email-masked]>
Date: Mon, 17 Feb 2020 18:49:00 +0100

+1,

The draft is ready for WG adoption.

//Krzysztof

> On 2020 -Feb-17, at 17:48, John Scudder <jgs=[email-masked]> wrote:
>

---

From: Sander Steffann <[email-masked]>
Date: Mon, 17 Feb 2020 18:53:09 +0100

Hi,

> I’ve reviewed this document several times at different points in its evolution. It’s clearly benefited from implementation experience and is a solid and clearly-written piece of work. Given that th…

Same for me, +1.
Sander

---

From: Tony Przygienda <[email-masked]>
Date: Mon, 17 Feb 2020 11:11:55 -0800

+1 support

mature/implemented/deployed/scratches a real itch, what's not to like ...

--- tony

On Mon, Feb 17, 2020 at 9:53 AM Sander Steffann <[email-masked]> wrote:

> Hi,
>
> > I’ve reviewed this document several times at different points in its
> evolution. It’s clearly benefited from implementation experience and is a
> solid and clearly-written piece of work. Given that there’s demonstrated
> community interest in deployment, it’s time for the WG to pick it up.
>
> Same for me, +1.
> Sander
>

---

From: Bilal Shahid <[email-masked]>
Date: Mon, 17 Feb 2020 20:04:51 +0000

+1

Efficient/protoryped and deployed.

6man should adopt this draft.

-------- Original message --------
From: Srihari Sangli <ssangli=[email-masked]>
Date: 2/17/20 7:46 AM (GMT-08:00)
To: Gyan Mishra <[email-masked]>, Chris Bowers <[email-masked]>
Cc: Ron Bonica <rbonica=[email-masked]>, Julian Lucek <jlucek=[email-masked]>, 6man WG <[email-masked]>
Subject: Re: New Version Notification for draft-bonica-6man-comp-rtg-hdr-11.txt

+1

srihari…

Gyan

Chris

Julian

Andrew

Folks,

Ron

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Sent: Sunday, February 16, 2020 7:46 PM
To: Ron Bonica <[email-masked]<mailto:[email-masked]>>; Ning So <[email-masked]<mailto:[email-masked]>>; Andrew Alston <[email-masked]<mailto:[email-masked]>>; Ning So <[email-masked]<mailto:[email-masked]>>; Tomonobu Niwa <[email-masked]<mailto:[email-masked]>>; Andrew Alston <[email-masked]<mailto:[email-masked]>>; Yuji Kamite <[email-masked]<mailto:[email-masked]>>
Subject: New Version Notification for draft-bonica-6man-comp-rtg-hdr-11.txt

The IETF Secretariat

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Tue, 18 Feb 2020 04:24:53 +0000

Support this work and the change to standalone IPv6 work.
Like a couple of other works, some solutions are a perfect match for an SR network yet they are not tied to SR and it's better to make it generic.

Given that it's been around for a while and with implementations and deployments, it's good for 6man to adopt this.

Jeffrey

-----Original Message-----
From: ipv6 <[email-masked]> On Behalf Of Ron Bonica
Sent: Sunday, February 16, 2020 7:56 PM
To: 6man WG <[email-masked]>
Subject: FW: New Version Notification for draft-bonica-6man-comp-rtg-hdr-11.txt

Folks,

                                                                          Ron

-----Original Message-----
From: [email-masked] <[email-masked]> 
Sent: Sunday, February 16, 2020 7:46 PM
To: Ron Bonica <[email-masked]>; Ning So <[email-masked]>; Andrew Alston <[email-masked]>; Ning So <[email-masked]>; Tomonobu Niwa <[email-masked]>; Andrew Alston <[email-masked]>; Yuji Kamite <[email-masked]>
Subject: New Version Notification for draft-bonica-6man-comp-rtg-hdr-11.txt

Name:		draft-bonica-6man-comp-rtg-hdr
Revision:	11
Title:		The IPv6 Compressed Routing Header (CRH)
Document date:	2020-02-16
Group:		Individual Submission
Pages:		16
URL                      https://urldefense.com/v3/__https://tools.ietf.org/html/draft-bonica-6man-comp-rtg-hdr-11__;!!NEt6yMaO-gk!XUarDeMbPwKiwm2y8vDbWaR0FSJpEu7t-k660_1iuPIG9nwBgZjnN_9Nrq5fuRdE$ 
Status:                https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-bonica-6man-comp-rtg-hdr/__;!!NEt6yMaO-gk!XUarDeMbPwKiwm2y8vDbWaR0FSJpEu7t-k660_1iuPIG9nwBgZjnN_9Nrg593WfL$ 
Htmlized:           https://urldefense.com/v3/__https://tools.ietf.org/html/draft-bonica-6man-comp-rtg-hdr-11__;!!NEt6yMaO-gk!XUarDeMbPwKiwm2y8vDbWaR0FSJpEu7t-k660_1iuPIG9nwBgZjnN_9Nrq5fuRdE$ 
Htmlized:           https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-bonica-6man-comp-rtg-hdr__;!!NEt6yMaO-gk!XUarDeMbPwKiwm2y8vDbWaR0FSJpEu7t-k660_1iuPIG9nwBgZjnN_9NrnDoZDQO$ 
Diff:           
Abstract:
   This document defines two new Routing header types.  Collectively,
   they are called the Compressed Routing Headers (CRH).  Individually,
   they are called CRH-16 and CRH-32.

The IETF Secretariat
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!XUarDeMbPwKiwm2y8vDbWaR0FSJpEu7t-k660_1iuPIG9nwBgZjnN_9Nrg0ihiqf$ 
--------------------------------------------------------------------

---

From: Tom Herbert <[email-masked]>
Date: Tue, 18 Feb 2020 09:21:56 -0800

+1 on making this WG item

The protocol is straightforward and well aligned with the rest of the
IPv6 protocol.

Tom

---

From: Jeff Tantsura <[email-masked]>
Date: Tue, 18 Feb 2020 13:12:46 -0800

I support progress of the draft in its new form, I’d encourage the authors to address concerns about the process expressed on the list.

Cheers,
Jeff

---

From: Fernando Gont <[email-masked]>
Date: Thu, 20 Feb 2020 03:08:38 -0300

> Please review this document as a stand-alone piece of work.

I support this document. It does the right thing in trying to reduce 
overhead in how waypoints/segments are encoded, as opposed to wasting 
space there and then trying to cover up elsewhere.

Specific comments below:

* Intro:

OLD:
RH0 [RFC5095] was the first to be
    defined and was deprecated because of security vulnerabilities.

NEW:
    RH0 was the first to be defined [RFC2460]  and was deprecated 
RFC5095 because of security vulnerabilities.

(RFC5095] is about the deprecation, not the specification)

* Section 3:
OLD:
    In all cases, the CRH MUST end on a 64-bit boundary.  So, the Type-
    specific data field MAY be padded with zeros.

NEW:
    In all cases, the CRH MUST end on a 64-bit boundary.  So, the Type-
    specific data field MUST be padded with zeros if the CRH would
    otherwise not end on a 64-bit boundary.

* Section 11:
s/LINUX/Linux/

Thanks!

Cheers,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Ron Bonica <[email-masked]>
Date: Mon, 24 Feb 2020 15:46:59 +0000

Fernando,

I have just posted a new version with these changes. 

                                               Thanks,
                                                  Ron

-----Original Message-----
From: Fernando Gont <[email-masked]> 
Sent: Thursday, February 20, 2020 1:09 AM
To: Ron Bonica <[email-masked]>; 6man WG <[email-masked]>
Subject: Re: FW: New Version Notification for draft-bonica-6man-comp-rtg-hdr-11.txt

> Please review this document as a stand-alone piece of work.

I support this document. It does the right thing in trying to reduce overhead in how waypoints/segments are encoded, as opposed to wasting space there and then trying to cover up elsewhere.

Specific comments below:

* Intro:

OLD:

NEW:

* Section 3:
OLD:

NEW:

* Section 11:
s/LINUX/Linux/

Thanks!

Cheers,