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

[Tom Herbert <[e-mail]>]

On Wed, May 8, 2019 at 11:55 AM Ron Bonica <[e-mail]> wrote:
>
> 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.
>

Ron,

The spring draft states:

"If the outer header is pushed without SRH, then the DA must be a SID
of type End.DX2, End.DX2V, End.DT2U or End.DT2M and the next-header
must be 59 (IPv6 NoNextHeader).  The received Ethernet frame follows
the IPv6 header and its extension headers."

That describes Ethernet over IP encapsulation.

RFC3378 states:

"EtherIP datagrams contain a 16-bit header and a variable-length
encapsulated Ethernet or IEEE 802.3 frame that immediately follows IP
fields."

That also describes Ethernet in IP encapsulation. The only difference
is the presence of the two byte EtherIP header. As already mentioned
this is important for maintaining alignment of the encapslated
Ethernet payload, and is otherwise inconsequential overhead.

So I don't see why EtherIP won't work here. Can you please clarify your concern?

Tom





>                                                      Ron
>
>
>
> Non-Juniper
>
> > -----Original Message-----
> > From: Bob Hinden <[e-mail]>
> > Sent: Wednesday, May 8, 2019 2:45 PM
> > To: Ole Trøan <[e-mail]>
> > Cc: Bob Hinden <[e-mail]>; Ron Bonica
> > <[e-mail]>; Tom Herbert <[e-mail]>; SPRING WG
> > <[e-mail]>; IPv6 List <[e-mail]>
> > Subject: Re: SRv6 Network Programming: ENH = 59
> >
> > Ole,
> >
> > > On May 8, 2019, at 11:13 AM, Ole Troan <[e-mail]> wrote:
> > >
> > > Ron,
> > >
> > >> <adding the SPRING mailing list, because this is a SPRING draft>
> > >>
> > >> 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 next-header value in the SRH must be IP4 (value
> > 4).
> > >> If the payload is IPv6, the next-header value in the SRH must be IPv6 (value
> > 41).
> > >> If the payload is Ethernet, the next-header value in the SRH must be No
> > Next Header (value 59).
> > >>
> > >> In the interest of consistency, we should probably allocate a new next-
> > header value for Ethernet and use it.
> > >
> > > It's a fairly precious name space though.
> >
> > According to https://urldefense.proofpoint.com/v2/url?u=https-
> > 3A__www.iana.org_assignments_protocol-2Dnumbers_protocol-
> > 2Dnumbers.xhtml&d=DwIFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> > ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-
> > AWF2EfpHcAwrDThKP8&m=ZtmZfCpk7bYpJSSTREggt8Xm8yHpWgrVBTFHi5a
> > UtW4&s=Qir8baDHTQf5RGhmFCDSbGShFV8dE_dqL1reoBpkiUE&e=
> >
> > 143-252               Unassigned
> >
> > Seems like a lot left.  Plus there are many that are clearly not used anymore, so
> > there isn’t a shortage.
> >
> >
> >
> > > What would a general IP stack do with an Ethernet frame? It's kind of a neat
> > feature that "IP processing terminates here".
> > > Or are we going to specify Ethernet over IP?
> >
> > Look at the the registry, it looks to me we have already
> >
> > 97    ETHERIP Ethernet-within-IP Encapsulation                [RFC3378]
> >
> > From the abstract:
> >
> >    EtherIP tunnels Ethernet and IEEE 802.3 media access
> >    control frames in IP datagrams so that non-IP traffic can traverse an
> >    IP internet.
> >
> > This be appropriate for SRv6 network programming.
> >
> > Bob
> >
> >
> > >
> >
> >
> > > Cheers,
> > > Ole