Subject: [ippm] draft-weis-ippm-ioam-gre-00 -> draft-weis-ippm-ioam-eth-00

From: "Frank Brockners (fbrockne)" <[email-masked]>
Date: Thu, 25 Oct 2018 14:48:37 +0000

Dear IPPM WG,

given that Brian is currently OOO - I wanted to take the opportunity to point you to draft-weis-ippm-ioam-eth-00: When we reviewed draft-weis-ippm-ioam-gre-00 in our last meeting in Montreal, we concluded that we should treat encapsulations for protocols which use Ethertype and would add IOAM data fields as a header in sequence with other Ethertype-identified header the same (Alia was among those highlighting this point). A very straight forward and obvious ask. As a consequence, Brian took the effort to evolve the draft which was focused on GRE encap - and made it generic to protocols which use Ethertype. We'll discuss the draft as part of the IOAM slot in our meeting in BKK.

Frank

---

From: Haoyu song <[email-masked]>
Date: Mon, 29 Oct 2018 18:21:40 +0000

Hi Frank and Brian,

I read the draft but couldn't figure out how it is related to Ethertype. It's mentioned in the draft but not explained. Maybe I missed something. Could you please clarify it a little it? Thanks!

Haoyu

From: ippm [mailto:[email-masked]] On Behalf Of Frank Brockners (fbrockne)
Sent: Thursday, October 25, 2018 7:49 AM
To: IETF IPPM WG <[email-masked]>
Cc: Brian Weis (bew) <[email-masked]>
Subject: [ippm] draft-weis-ippm-ioam-gre-00 -> draft-weis-ippm-ioam-eth-00

Dear IPPM WG,

Frank

---

From: "Frank Brockners (fbrockne)" <[email-masked]>
Date: Mon, 29 Oct 2018 18:41:45 +0000

Hi Haoyu,

hmm - the draft is very explicit on that, see section 3: "When the IOAM data fields are included within an encapsulation that identifies the next protocol using an EtherType (e.g., GRE or Geneve) the presence of IOAM data fields are identified with TBD_IOAM." - and the draft gives 2 examples in section 4, showing IOAM encapsulation options for Geneve and GRE. Not sure what else would be needed, i.e. what additional description are you looking for? IOAM data fields are of course defined elsewhere, see draft-ietf-ippm-ioam-data-04.

Cheers, Frank

From: Haoyu song <[email-masked]>
Sent: Montag, 29. Oktober 2018 19:22
To: Frank Brockners (fbrockne) <[email-masked]>; IETF IPPM WG <[email-masked]>
Cc: Brian Weis (bew) <[email-masked]>
Subject: RE: draft-weis-ippm-ioam-gre-00 -> draft-weis-ippm-ioam-eth-00

Hi Frank and Brian,

Haoyu

From: ippm [mailto:[email-masked]] On Behalf Of Frank Brockners (fbrockne)
Sent: Thursday, October 25, 2018 7:49 AM
To: IETF IPPM WG <[email-masked]<mailto:[email-masked]>>
Cc: Brian Weis (bew) <[email-masked]<mailto:[email-masked]>>
Subject: [ippm] draft-weis-ippm-ioam-gre-00 -> draft-weis-ippm-ioam-eth-00

Dear IPPM WG,

Frank

---

From: Haoyu song <[email-masked]>
Date: Mon, 29 Oct 2018 19:06:14 +0000

I guess I'm confused because I think Ethertype is used in MAC frame and after the MAC addresses to indicate the type of the upper layer protocol, but in the examples, it is in the GRE or Geneve header. My question is, why does it need to be an Ehtertype here?

Haoyu

From: Frank Brockners (fbrockne) [mailto:[email-masked]]
Sent: Monday, October 29, 2018 11:42 AM
To: Haoyu song <[email-masked]>; IETF IPPM WG <[email-masked]>
Cc: Brian Weis (bew) <[email-masked]>
Subject: RE: draft-weis-ippm-ioam-gre-00 -> draft-weis-ippm-ioam-eth-00

Hi Haoyu,

Cheers, Frank

From: Haoyu song <[email-masked]<mailto:[email-masked]>>
Sent: Montag, 29. Oktober 2018 19:22
To: Frank Brockners (fbrockne) <[email-masked]<mailto:[email-masked]>>; IETF IPPM WG <[email-masked]<mailto:[email-masked]>>
Cc: Brian Weis (bew) <[email-masked]<mailto:[email-masked]>>
Subject: RE: draft-weis-ippm-ioam-gre-00 -> draft-weis-ippm-ioam-eth-00

Hi Frank and Brian,

Haoyu

Dear IPPM WG,

Frank

---

From: "Frank Brockners (fbrockne)" <[email-masked]>
Date: Tue, 30 Oct 2018 08:08:56 +0000

Hi Haoyu,

RFC 7042, section 3 might help clarify things:    "Ethernet protocol parameters provide a means of indicating the contents of a frame -- for example, that its contents are IPv4 or IPv6. The concept has been extended to labeling by "tags".  A tag in this sense is a prefix whose type is identified by an Ethertype that is then followed by either another tag, an Ethertype, or an LSAP (Link- Layer Service Access Point) protocol indicator for the "main" body of the frame, as described below."

Frank

Sent: Montag, 29. Oktober 2018 20:06

Haoyu

To: Haoyu song <[email-masked]<mailto:[email-masked]>>; IETF IPPM WG <[email-masked]<mailto:[email-masked]>>

Hi Haoyu,

Cheers, Frank

Hi Frank and Brian,

Haoyu

Dear IPPM WG,

Frank