On Sat, 14 Sep 2019, 13:22 Xiejingrong, <[email protected]> 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:[email protected]] On Behalf Of Joel M. Halpern > Sent: Friday, September 13, 2019 1:44 AM > To: Pablo Camarillo (pcamaril) <[email protected]>; SPRING WG < > [email protected]> > Cc: [email protected] > 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" <[email protected]> > > Date: Thursday, 12 September 2019 at 19:27 > > To: "Pablo Camarillo (pcamaril)" <[email protected]>, SPRING WG > > <[email protected]> > > Cc: "[email protected]" <[email protected]> > > 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 > > > [email protected] > > > https://www.ietf.org/mailman/listinfo/spring > > > > > > > > > _______________________________________________ > spring mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/spring > _______________________________________________ > spring mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/spring >
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
