Subject: Adoption Call for <draft-previdi-6man-segment-routing-header-07>

From: Bob Hinden <[email-masked]>
Date: Sat, 1 Aug 2015 12:12:28 -0700

This message starts a two week 6MAN call on adopting:

     Title     : IPv6 Segment Routing Header (SRH)
     Authors   : S. Previdi, C. Filsfils, B. Field, I. Leung, E. Aries,
                 E. Vyncke, D. Lebrun
     Filename  : draft-previdi-6man-segment-routing-header-07
     Pages     : 16
     Date      : 2015-07-20

     http://datatracker.ietf.org/doc/draft-previdi-6man-segment-routing-header/

as a working group item. Substantive comments and statements of support
for adopting this document should be directed to the mailing
list. Editorial suggestions can be sent to the authors.  This adoption
call will end on August 15, 2015.

Regards,

Bob Hinden & Ole Trøan

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Mon, 3 Aug 2015 11:37:57 +0000

I obviously support the adoption of this document as a WG document. It is
an important topic to be discussed within 6MAN WG.

Thanks in advance for the continuous flow of comments (leading to
improvements)

-éric

On 1/08/15 21:12, "ipv6 on behalf of Bob Hinden" <[email-masked] on

---

From: "Roberta Maglione (robmgl)" <[email-masked]>
Date: Mon, 3 Aug 2015 11:53:58 +0000

I support the adoption of this document as a WG item.
Regards
Roberta

-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of Bob Hinden
Sent: Saturday, August 01, 2015 9:12 PM
To: IPv6 List
Cc: Bob Hinden
Subject: Adoption Call for <draft-previdi-6man-segment-routing-header-07>

as a working group item. Substantive comments and statements of support for adopting this document should be directed to the mailing list. Editorial suggestions can be sent to the authors.  This adoption call will end on August 15, 2015.

Regards,

Bob Hinden & Ole Trøan

---

From: David Lebrun <[email-masked]>
Date: Mon, 3 Aug 2015 14:07:18 +0200

I support the adoption of this document as a WG document.

David

On 08/01/2015 09:12 PM, Bob Hinden wrote:
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 4 Aug 2015 08:09:47 +0000

I do support the adoption as well. 

SR restores an important tool in the IPv6 arsenal, avoids the original security caveats in routing headers, and is already proven to be useful in the real world.

Cheers,

Pascal

> From: ipv6 [mailto:[email-masked]] On Behalf Of David Lebrun
> Sent: lundi 3 août 2015 14:07
> To: Bob Hinden; IPv6 List
> Subject: Re: Adoption Call for <draft-previdi-6man-segment-routing-header-
> 07>
> 
> > as a working group item. Substantive comments and statements of
> > support for adopting this document should be directed to the mailing

---

From: Ida Leung <[email-masked]>
Date: Tue, 4 Aug 2015 09:57:13 -0400

Support the adoption of this document as a WG document.

Thanks,

...Ida

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 5 Aug 2015 14:58:19 +0200

I'm concerned about adopting this document at this point in time, since 
I don't know what direction the proponents plan to take with the 
concerns around adding/removing extension headers along the path (and 
associated MTU issues).
I can see three different approaches to that area:
1. Only a "buyer beware notice" pointing out the ICMP PTB issue and that 
the protocol will not work correctly if packets exceed the MTU in the SR 
domain
2. Requirement that the SR domain boundary "correct" ICMP errors to 
remove the added SR headers and adjust the MTU in PTB errors. That needs 
to be done to ICMP errors that are not addressed at IP to the SR domain 
boundary router. (I don't know if the original SA would always be in the 
policy list in this case. If so, the ICMP error would actually be 
addressed to the ingress SR which removes then need for promiscuous ICMP 
error handling.)
3. Instead of adding/removing extensions headers, only support 
encaps/decaps (using IPv6 header plus the extension header).

If the choice is #1, then I don't think we should work on this as WG 
document. We have seen that successful protocols tend to get deployed 
outside of their initial target environment, and with documented and 
standardized approach to handle this we point have painted ourselves 
into an architectural corner if that happens.

I think #2 can be made to work, but having a document with the details 
would help analyze if there are any forgotten details.
For ICMP errors #3 doesn't add anything new; we already have documents 
specifying how to (re)generate ICMP errors at encapsulation points.

The document also discusses a Segment Routing Global Block (SRGB). I 
hope this is not piece of IPv6 address space carved out from the 
addressing architecture or the IANA (i.e. "global" across the Internet) 
but instead is "global" to a particular SR domain i.e. an IPv6 address 
prefix configured on the SR routers in that domain. Is that correct?

Thus I'd personally like more clarity from the authors/proponents.

Regards,
    Erik

---

From: Daniel Bernier <[email-masked]>
Date: Thu, 6 Aug 2015 22:38:29 -0400

Hi,

I have fully read the draft and support its adoption as a WG document.

- Dan B