search

inband-oam / ietf

IETF drafts
7 stars 15 forks source link

VXLAN GPE Alignment #124

Open cpignata opened 5 years ago

cpignata commented 5 years ago

In draft-ietf-nvo3-vxlan-gpe-07, there's the concept of a Shim protocol type (0x80 - 0xFF), and a single PID for IOAM: https://tools.ietf.org/rfcdiff?url2=draft-ietf-nvo3-vxlan-gpe-07.txt Now, draft-brockners-ioam-vxlan-gpe-00 needs to leverage the generic Shim header defined at the end of S3.2 of draft-ietf-nvo3-vxlan-gpe-07, instead of defining its own, and draft-ietf-nvo3-vxlan-gpe-07 needs to request three (not one) IOAM PIDs.

brockners commented 5 years ago

Carlos, this is an old draft and not maintained any more - check out https://tools.ietf.org/html/draft-brockners-ippm-ioam-vxlan-gpe-01 instead

cpignata commented 5 years ago

Thanks Frank! Outchy, clicked on the wrong draft :-) Something sounded off last night looking at it. But the comment on acknowledging the Shim format still applies.

mickeyspiegel commented 5 years ago

That VXLAN-GPE shim header format seems a little weird to me. I see the need for "Length" and "Next Protocol" to be in positions that are well understood, but it defines "Type" and "Reserved" on behalf of a protocol that is not VXLAN-GPE, with some weasel words:

Type: This field MAY be used to identify different messages of this protocol.

Reserved: The use of this field is reserved to the protocol defined in this message.

Does that mean the protocol can define its own type codepoints? Can the protocol use the "Reserved" field for whatever it wants?