Re: [spring] SRv6 Network Programming: ENH = 59

Should the NextHeader values be a union of all the Link layer protocol types over IPv6, Ethertypes, IP Protocols, Next Headers and Well known ports - maybe, but it seems tough to get into 8 bits... Thank the stars that all those application guys use the well known ports for the correct

Re: [spring] SRv6 Network Programming: ENH = 59

Ole, That's fine, but which ever way the debate ends, the draft should be consistent. IMHO, the two ways to achieve consistency are: - Sections 4.4 - 4.12 all use 59 - Sections 4.4-4.12 all use something other than 59

Re: [spring] SRv6 Network Programming: ENH = 59

Two separate things. First, it clearly is not just about IP processing or we would have no next-headers for TCP, UDP, or tunnels. Which we do. Second, we have a value that means that Ethernet Follows. So clearly it is no-header is no for the Ethernet case. Finally, since we have a value thaqt

Re: [spring] SRv6 Network Programming: ENH = 59

Joel, > No next header means exactly what the original request, and the > documentation, says. There is nothing in the packet past this IP header. It > does not mean that there is some next header defined by some other context. Why allow for payload to follow and a "must" requirement to

Re: [spring] SRv6 Network Programming: ENH = 59

No next header means exactly what the original request, and the documentation, says. There is nothing in the packet past this IP header. It does not mean that there is some next header defined by some other context. Yours, Joel On 5/9/19 8:36 AM, Ole Troan wrote: I think it is equally

Re: [spring] SRv6 Network Programming: ENH = 59

> I think it is equally important to note that given an existing way of > encapsulating Ethernet in IP, one ought to have a good reason for creating a > different one. There is no indication that this use case needs anything > different than next-header 97. > > And Ole, no next-header does

Re: [spring] SRv6 Network Programming: ENH = 59

I think it is equally important to note that given an existing way of encapsulating Ethernet in IP, one ought to have a good reason for creating a different one. There is no indication that this use case needs anything different than next-header 97. And Ole, no next-header does not, as far

Re: [spring] SRv6 Network Programming: ENH = 59

>>> I suspect that we will be far more likely regret this use of 59 in the long >>> term than we will regret changing to 97 at this early stage. >> But it’s not that nh=59 can be used to imply that Ethernet follows. That >> would be very bad. >> It’s that ip processing stops here. >> Then if the

Re: [spring] SRv6 Network Programming: ENH = 59

On 09/05/2019 10:12, Ole Troan wrote: On 9 May 2019, at 11:05, Stewart Bryant wrote: On 08/05/2019 19:13, Ole Troan wrote: Ron, Folks, Sections 4.4 through 4.12 of draft-ietf-spring-srv6-network-programming-00 define a set of SIDs that have the following things in common: - they

Re: [spring] SRv6 Network Programming: ENH = 59

On 08/05/2019 19:34, Sander Steffann wrote: The whole point of these identifies is to tell the reader what the meaning is of what follows. Using value 59 like this looks like "when we say 'no-next-header' we actually mean 'ethernet' (probably)". That's just bad engineering, and reminds me

Re: [spring] SRv6 Network Programming: ENH = 59

> On 9 May 2019, at 11:05, Stewart Bryant wrote: > > > >> On 08/05/2019 19:13, Ole Troan wrote: >> Ron, >>> >>> >>> Folks, >>> >>> Sections 4.4 through 4.12 of draft-ietf-spring-srv6-network-programming-00 >>> define a set of SIDs that have the following things in common: >>> >>> - they

Re: [spring] SRv6 Network Programming: ENH = 59

Ole, Inline Ron Juniper Internal > -Original Message- > From: Ole Troan > Sent: Wednesday, May 8, 2019 3:48 PM > To: Ron Bonica > Cc: Bob Hinden ; Tom Herbert > ; SPRING WG ; 6man WG > > Subject: Re: SRv6 Network Programming: ENH = 59 > > Hi Ron, > > >

Re: [spring] SRv6 Network Programming: ENH = 59

Hi Ron, > Whatever we decide, I will use the same value in > draft-bonica-6man-vpn-dest-opt. Ah, right. Because in your proposal the VPN Context Information contains the forwarding instructions? Seems a little underspecified in the draft, or am I missing something? And that is information

Re: [spring] SRv6 Network Programming: ENH = 59

Tom, If the authors of the network programming draft are willing to impose the two-byte header between the SRH and the Ethernet frame, 97 works. I will let them speak for themselves regarding there willingness to do so. Ron

Re: [spring] SRv6 Network Programming: ENH = 59

Sander, > > The next-header should identify what follows, so that anybody parsing the > packets knows what to expect. Using "No Next Header" should mean "nothing > follows". Once we start using No-next-header for "some stuff may follow" it > will become very hard to make sense of packets.

Re: [spring] SRv6 Network Programming: ENH = 59

Ole, Whatever we decide, I will use the same value in draft-bonica-6man-vpn-dest-opt. Ron Juniper Internal > -Original Message- > From: Ole Troan > Sent: Wednesday, May 8, 2019 3:33 PM > To: Ron Bonica > Cc: Bob Hinden ;

Re: [spring] SRv6 Network Programming: ENH = 59

Ron, > If you want to conserve space in the registry, you can do one of the > following: I don't think I said I wanted to conserve space outright. But it is an 8-bit number space, so clearly if anyone wants more bits than that, they cannot rely on the protocol field. Note I'm arguing this

Re: [spring] SRv6 Network Programming: ENH = 59

Bob, The value 97 is tempting, but it already has a meaning that is slightly different from what the authors of draft-ietf-spring-srv6-network-programming intend. According to RFC 3378, a value of 97 means that the next header will be as depicted in Figure 2 of RFC 3378.

Re: [spring] SRv6 Network Programming: ENH = 59

Ole, If you want to conserve space in the registry, you can do one of the following: - Update RFC 8200, redefining value 59 to mean "VPN Payload - type unspecified" - Update RFC 8200, redefining value 59 to mean "IP Processing Stops Here" - Allocate a new type called "VPN Payload - type

Re: [spring] SRv6 Network Programming: ENH = 59

Ole, > On May 8, 2019, at 11:13 AM, Ole Troan wrote: > > Ron, > >> >> >> Folks, >> >> Sections 4.4 through 4.12 of draft-ietf-spring-srv6-network-programming-00 >> define a set of SIDs that have the following things in common: >> >> - they are consumed by the egress node (SL == 0) >> -

Re: [spring] SRv6 Network Programming: ENH = 59

On Wed, May 8, 2019 at 11:13 AM Ole Troan wrote: > > Ron, > > > > > > > Folks, > > > > Sections 4.4 through 4.12 of draft-ietf-spring-srv6-network-programming-00 > > define a set of SIDs that have the following things in common: > > > > - they are consumed by the egress node (SL == 0) > > -

Re: [spring] SRv6 Network Programming: ENH = 59

Hi, > Ron, > >> >> >> Folks, >> >> Sections 4.4 through 4.12 of draft-ietf-spring-srv6-network-programming-00 >> define a set of SIDs that have the following things in common: >> >> - they are consumed by the egress node (SL == 0) >> - they tell the egress node how to forward the payload

Re: [spring] SRv6 Network Programming: ENH = 59

Folks, Sections 4.4 through 4.12 of draft-ietf-spring-srv6-network-programming-00 define a set of SIDs that have the following things in common: - they are consumed by the egress node (SL == 0) - they tell the egress node how to forward the payload into a VPN If the payload is IPv4, the

Re: [spring] SRv6 Network Programming: ENH = 59

Pablo, I am not sure that your use of this field is in accordance with Section 4.7 of RFC 8200. Ron Juniper Internal > -Original Message- > From: Pablo Camarillo (pcamaril) > Sent: Tuesday, May 7, 2019 3:09 AM >

Re: [spring] SRv6 Network Programming: ENH = 59

On Tue, May 7, 2019 at 7:17 AM Tom Herbert wrote: > > On Tue, May 7, 2019 at 7:05 AM Mark Smith wrote: > > > > > > > > On Tue., 7 May 2019, 23:39 Joel M. Halpern, wrote: > >> > >> That is not what Next-Header means. > >> Even with this explanation, it is clear that 59 is NOT the right value >

Re: [spring] SRv6 Network Programming: ENH = 59

On Tue, May 7, 2019 at 7:05 AM Mark Smith wrote: > > > > On Tue., 7 May 2019, 23:39 Joel M. Halpern, wrote: >> >> That is not what Next-Header means. >> Even with this explanation, it is clear that 59 is NOT the right value >> for the next header. > > > If the SID value isn't a reserved for this

Re: [spring] SRv6 Network Programming: ENH = 59

On Tue., 7 May 2019, 23:39 Joel M. Halpern, wrote: > That is not what Next-Header means. > Even with this explanation, it is clear that 59 is NOT the right value > for the next header. > If the SID value isn't a reserved for this purpose, permanent and globally unique value, how would a

Re: [spring] SRv6 Network Programming: ENH = 59

That is not what Next-Header means. Even with this explanation, it is clear that 59 is NOT the right value for the next header. Yours, Joel On 5/7/19 3:08 AM, Pablo Camarillo (pcamaril) wrote: Hi Ron, We use the next header value 59 to identify at the receiver that there is no other kind

Re: [spring] SRv6 Network Programming: ENH = 59

On 07-May-19 12:20, Mark Smith wrote: > > > On Tue., 7 May 2019, 06:14 Stewart Bryant, > wrote: > > I agree that implicit payload identity is a bad idea. > > If the payload is Ethernet, then the IANA Protocol Number Registry > suggests that 22 is

Re: [spring] SRv6 Network Programming: ENH = 59

On Tue., 7 May 2019, 06:14 Stewart Bryant, wrote: > I agree that implicit payload identity is a bad idea. > > If the payload is Ethernet, then the IANA Protocol Number Registry > suggests that 22 is allocated for that purpose: > > 22 > > XNS-IDP XEROX NS IDP > > ["The Ethernet, A Local Area

Re: [spring] SRv6 Network Programming: ENH = 59

I agree that implicit payload identity is a bad idea. If the payload is Ethernet, then the IANA Protocol Number Registry suggests that 22 is allocated for that purpose: 22 XNS-IDP XEROX NS IDP ["The Ethernet, A Local Area Network: Data Link Layer and Physical Layer Specification",

Re: [spring] SRv6 Network Programming: ENH = 59

Ron, > On May 5, 2019, at 5:47 PM, Ron Bonica > wrote: > > Folks, > > According to Section 4.4 of draft-ietf-spring-srv6-network-programming-00, > when processing the End.DX2 SID, the Next Header must be equal to 59. > Otherwise, the packet will be dropped. > > In the words of the draft,

Re: [spring] SRv6 Network Programming: ENH = 59

h ; Xiejingrong > ; SPRING WG ; 6man > > Subject: Re: [spring] SRv6 Network Programming: ENH = 59 > > On Sun, May 5, 2019 at 7:49 PM Ron Bonica wrote: > > > > Mark, > > > > As the header chain (including encapsulations) get longer, the packet > becomes less ASIC f

Re: [spring] SRv6 Network Programming: ENH = 59

9 9:37 PM > > To: Xiejingrong > > Cc: Tom Herbert ; Ron Bonica > > ; SPRING WG ; 6man > > > > Subject: Re: [spring] SRv6 Network Programming: ENH = 59 > > > > On Mon, 6 May 2019 at 11:15, Xiejingrong > > wrote: > > > > > > Hi Tom, >

Re: [spring] SRv6 Network Programming: ENH = 59

cing a new encapsulation. > >Ron > > > > Juniper Internal > > > -Original Message- > > From: Mark Smith > > Sent: Sunday, May 5, 2019 9:37 PM > > To: Xiejingrong > > Cc: Tom Herbert ; Ron Bonica > > ; SPRING WG ; 6man > > > &

Re: [spring] SRv6 Network Programming: ENH = 59

> -Original Message- > From: Mark Smith > Sent: Sunday, May 5, 2019 9:37 PM > To: Xiejingrong > Cc: Tom Herbert ; Ron Bonica > ; SPRING WG ; 6man > > Subject: Re: [spring] SRv6 Network Programming: ENH = 59 > > On Mon, 6 May 2019 at 11:15, Xiejin

Re: [spring] SRv6 Network Programming: ENH = 59

Hi Tom, Ethernet Over IP (97) was created by RFC 3378. It indicates that the next header is an Ethernet over IP encapsulation header (see Figure 1 of RFC 3378). That is different from an actual Ethernet header. In SRv6, the next header is an Ethernet header.

Re: [spring] SRv6 Network Programming: ENH = 59

On Mon, 6 May 2019 at 11:15, Xiejingrong wrote: > > Hi Tom, > > > > Number 97 is a choice but it has 2 bytes wasting. > > It seems strange to me that as bandwidth is constantly getting cheaper, people seem to be trying harder and harder to use less of it. The trade-off is increased code

Re: [spring] SRv6 Network Programming: ENH = 59

On Mon, 6 May 2019 at 10:48, Ron Bonica wrote: > > Folks, > > According to Section 4.4 of draft-ietf-spring-srv6-network-programming-00, > when processing the End.DX2 SID, the Next Header must be equal to 59. > Otherwise, the packet will be dropped. > > In the words of the draft, "We

Re: [spring] SRv6 Network Programming: ENH = 59

On Sun, May 5, 2019, 6:15 PM Xiejingrong wrote: > Hi Tom, > > > > Number 97 is a choice but it has 2 bytes wasting. > Jingrong, To the contrary, those two bytes are critical, they maintain proper alignment of network and transport layers. Ask the SPARC engineers about how much fun it is to

Re: [spring] SRv6 Network Programming: ENH = 59

Hi Tom, Number 97 is a choice but it has 2 bytes wasting. Jingrong From: ipv6 [mailto:ipv6-boun...@ietf.org] On Behalf Of Tom Herbert Sent: Monday, May 06, 2019 9:11 AM To: Ron Bonica Cc: SPRING WG ; 6man Subject: Re: SRv6 Network Programming: ENH = 59 On Sun, May 5, 2019, 5:47 PM Ron

Re: [spring] SRv6 Network Programming: ENH = 59

On Sun, May 5, 2019, 5:47 PM Ron Bonica wrote: > Folks, > > According to Section 4.4 of draft-ietf-spring-srv6-network-programming-00, > when processing the End.DX2 SID, the Next Header must be equal to 59. > Otherwise, the packet will be dropped. > > In the words of the draft, "We conveniently

Re: [spring] SRv6 Network Programming: ENH = 59

Using "No next header" to mean "next header Ethernet" seems to me to be flat wrong. This also brings up another problem. Having the SID specify the next header, over-riding the next header value, seems to me to be a recipe for fragility, likely leading to mis-implementation. Yours, Joel

[spring] SRv6 Network Programming: ENH = 59

Folks, According to Section 4.4 of draft-ietf-spring-srv6-network-programming-00, when processing the End.DX2 SID, the Next Header must be equal to 59. Otherwise, the packet will be dropped. In the words of the draft, "We conveniently reuse the next-header value 59 allocated to IPv6 No Next