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

[Ron Bonica <[e-mail]>]

Jingrong,

The value 97 means that the next header is a depicted in Figure 2 of RFC 3378. It should not be used in any other circumstances.

                                                                 Ron



Juniper Business Use Only

-----Original Message-----
From: ipv6 <[e-mail]> On Behalf Of Xiejingrong
Sent: Tuesday, September 17, 2019 3:29 AM
To: Pablo Camarillo (pcamaril) <[e-mail]>; Joel M. Halpern <[e-mail]>; SPRING WG <[e-mail]>
Cc: [e-mail]
Subject: RE: [spring] draft-ietf-spring-srv6-network-programming: NH=59 action item closure

I think value 97 is quite good and simple.
The Opaque Payload also works for me as you re-written in another email for a more clear and generic usage:
"The value TBD in the Next Header field of an IPv6 header or any extension header indicates that the payload is interpreted via a semantics previously established between the source and destination."

Thanks
Jingrong

-----Original Message-----
From: Pablo Camarillo (pcamaril) [mailto:[e-mail]] 
Sent: Tuesday, September 17, 2019 3:44 AM
To: Xiejingrong <[e-mail]>; Joel M. Halpern <[e-mail]>; SPRING WG <[e-mail]>
Cc: [e-mail]
Subject: Re: [spring] draft-ietf-spring-srv6-network-programming: NH=59 action item closure

Jingrong,

What text do you propose?

Thanks,
Pablo.

-----Original Message-----
From: Xiejingrong <[e-mail]>
Date: Saturday, 14 September 2019 at 05:22
To: "Joel M. Halpern" <[e-mail]>, "Pablo Camarillo (pcamaril)" <[e-mail]>, SPRING WG <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
Subject: 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:[e-mail]] On Behalf Of Joel M. Halpern
    Sent: Friday, September 13, 2019 1:44 AM
    To: Pablo Camarillo (pcamaril) <[e-mail]>; SPRING WG <[e-mail]>
    Cc: [e-mail]
    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" <[e-mail]>
    > Date: Thursday, 12 September 2019 at 19:27
    > To: "Pablo Camarillo (pcamaril)" <[e-mail]>, SPRING WG 
    > <[e-mail]>
    > Cc: "[e-mail]" <[e-mail]>
    > 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
    >      > [e-mail]
    >      > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spring__;!8WoA6RjC81c!WkDtEqBDAAwCnfBXMrhlStqbgB1qtKYw2_Uj7WKV6jFT_69JGl2B8_G5UVBhHPTm$ 
    >      >
    >      
    > 
    
    _______________________________________________
    spring mailing list
    [e-mail]
    https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spring__;!8WoA6RjC81c!WkDtEqBDAAwCnfBXMrhlStqbgB1qtKYw2_Uj7WKV6jFT_69JGl2B8_G5UVBhHPTm$ 
    

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[e-mail]
Administrative Requests: https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6__;!8WoA6RjC81c!WkDtEqBDAAwCnfBXMrhlStqbgB1qtKYw2_Uj7WKV6jFT_69JGl2B8_G5UWhP2aev$ 
--------------------------------------------------------------------