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

On Sat, 14 Sep 2019, 13:22 Xiejingrong, <xiejingrong@huawei.com> wrote:

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

Wow, this is getting perverse.

Is there any IPv6 packet field that SPRING aren't willing to abuse for a
non-compliant purpose?

> 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
> _______________________________________________
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
>