Alvaro, The new proposal looks really good. Having this as a registry table makes all this much more clear.
From the two options you propose, I believe keeping the drawing with labels reads a bit easier when trying to implement this, so I’d vote for this option: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |n| Encapsulations |U|G|N|v|V|l|L| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Let us know when you upload the new draft version and I’ll update the relevant section in the documents that depend on this. Thanks! Marc From: Alvaro Retana <[email protected]> Date: Tuesday, June 30, 2026 at 1:58 PM To: Dino Farinacci <[email protected]> Cc: Alberto Rodriguez-Natal (natal) <[email protected]>; [email protected] <[email protected]>; Marc Portoles Comeras (mportole) <[email protected]> Subject: Re: [lisp] I-D Action: draft-ietf-lisp-rfc8060bis-04.txt On June 30, 2026 at 9:42:38 AM, Dino Farinacci wrote: > Alvaro the changes look good. Thanks for making them. Here is one comment. > For the bit allocations: > > Can you include this drawing and the one-character labels in the table in > section 6: Yes...I got rid of the names because they seemed easy to confuse: there's a difference between the v-bit and the V-bit. I can add a short description to each Encapsulation Type: +=====+=================================+===========================+ | Bit | Encapsulation Type | Reference | +=====+=================================+===========================+ | 0 | No Encapsulation (n-bit) | [[this RFC],Section 4.15] | +-----+---------------------------------+---------------------------+ ... +-----+---------------------------------+---------------------------+ | 26 | Geneve (G-bit) | [RFC8926] | +-----+---------------------------------+---------------------------+ | 27 | NV-GRE (N-bit) | [RFC7637] | +-----+---------------------------------+---------------------------+ ... ...and then include the drawing: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |n| Encapsulations |U|G|N|v|V|l|L| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...OR... I can add text to describe the bit positions: "The Bits correspond to the positions in the following drawing:". 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encapsulations | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Any thoughTs on these questions: ... > > I checked the other LCAFs for their AFI support, and have some questions: > > > > - Does it make sense to add support for MAC addresses to The Instance ID > > LCAF and Replication List LCAF? > > > > - Why can't the Security Key LCAF be used with any AFI? Thanks! Alvaro.
_______________________________________________ lisp mailing list -- [email protected] To unsubscribe send an email to [email protected]
