RE: [spring] draft-ietf-spring-srv6-network-programming: NH=59 action item closure

I agree with Joel, and strongly opposed to the proposal text !

"The value TBD in the Next Header field of an IPv6 header or any extension header indicates that the payload content is identified via the segment identifier in the IPv6 Destination Address."

It is a hole digging to exclude other possible ways of indication of 'Opaque Payload format', for example, use IPv6 Source Address, or use options in EH to identify.

As I raise this question in March, I haven't expect the proposal would be so tricky! 

Thanks
Jingrong

-----Original Message-----
From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Joel M. Halpern
Sent: Friday, September 13, 2019 1:44 AM
To: Pablo Camarillo (pcamaril) <pcamaril@cisco.com>; SPRING WG <spring@ietf.org>
Cc: 6man@ietf.org
Subject: Re: [spring] draft-ietf-spring-srv6-network-programming: NH=59 action item closure

1) The way you wrote the text, it would apply to carried IPv4 or carried IPv6.

2) If it is carried Ethernet, us 97.
2') If you insist that you need a new format for carried Ethernet after SRH, get a code point for that.

3) If there is some other use case, document it and get a code point for it.  particularly given that SID meanings may not be registered, removing teh ability to tell what the payload is seems a drawback, not a benefit.

Yours,
Joel

On 9/12/2019 1:39 PM, Pablo Camarillo (pcamaril) wrote:
> Joel,
> 
> This NH value is to be used when the payload does not contain any Internet Protocol.
> 
> Cheers,
> Pablo.
> 
> -----Original Message-----
> From: "Joel M. Halpern" <jmh@joelhalpern.com>
> Date: Thursday, 12 September 2019 at 19:27
> To: "Pablo Camarillo (pcamaril)" <pcamaril@cisco.com>, SPRING WG 
> <spring@ietf.org>
> Cc: "6man@ietf.org" <6man@ietf.org>
> Subject: Re: [spring] draft-ietf-spring-srv6-network-programming: 
> NH=59 action item closure
> 
>      While that proposal does remove the mis-use of next-header 59, it seems
>      a very odd use.
>      It seems to be an effort to avoid needing to register next-header
>      values.  Why?
>      
>      For example, if what is carried after the SRH is an IPv6 packet then the
>      next header value for IPv6 (41) would seem the appropriate thing to use.
>        That would produce consistent parsing and clarity.
>      
>      Yours,
>      Joel
>      
>      On 9/12/2019 1:01 PM, Pablo Camarillo (pcamaril) wrote:
>      > Hi all,
>      >
>      > Following the comments from IETF105, the working group preferred to
>      > allocate a new Next Header value.
>      >
>      > The authors would like to propose this diff. Any feedback is welcome.
>      >
>      > <OLD>
>      >
>      >     9.  IANA Considerations
>      >
>      >        This document requests the following new IANA registries:
>      >
>      > </OLD>
>      >
>      > <NEW>
>      >
>      >     9.  IANA Considerations
>      >
>      > This document requests IANA to allocate a new IP Protocol Number value
>      > for “SRv6 payload” with the following definition:
>      >
>      > The value TBD in the Next Header field of an IPv6 header or any
>      > extension header indicates that the payload content is identified via
>      > the segment identifier in the IPv6 Destination Address.
>      >
>      >        This document requests the following new IANA registries:
>      >
>      > </NEW>
>      >
>      > We would propose to submit a revision with this text on the IANA section
>      > of NET-PGM beginning of next week.
>      >
>      > Thanks,
>      > Pablo.
>      >
>      >
>      > _______________________________________________
>      > spring mailing list
>      > spring@ietf.org
>      > https://www.ietf.org/mailman/listinfo/spring
>      >
>      
> 

_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring