Subject: [lisp] Instance-IDs in draft-ietf-lisp-lcaf-12

From: Florin Coras <[email-masked]>
Date: Mon, 18 Apr 2016 14:40:33 +0200

Hi, 

While reviewing draft-ietf-lisp-lcaf-12 I realized that if we want instance-id support for other LCAF types then we must support recursive LCAFs, i.e., use Type 2 and within it store the type we’re interested in. Wouldn’t it be better to have the instance-id value and mask part of the LCAF header? Apart from simplifying processing on xTR side, this would also help avoid having other types, like Type 9, define their own instace-id fields. 

Thanks, 
Florin

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 18 Apr 2016 10:12:56 -0700

> While reviewing draft-ietf-lisp-lcaf-12 I realized that if we want instance-id support for other LCAF types then we must support recursive LCAFs, i.e., use Type 2 and within it store the type we’re…

Well Florin, the way I look at this is from this perspective. If we want geo-prefix support for all other LCAF types we also have to do nested LCAFs. So be all things to all people would make the encoding a combinatorial problem. So nesting is really the only way to manage it.

I agree that instance-ID may be a popular LCAF to use but I see others that will be just as popular. To name two, AFI-List and RLE.

Dino

> 
> Thanks, 
> Florin
> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp

---

From: "Vina Ermagan (vermagan)" <[email-masked]>
Date: Mon, 18 Apr 2016 18:25:07 +0000

On 4/18/16, 10:12 AM, "lisp on behalf of Dino Farinacci"
<[email-masked] on behalf of [email-masked]> wrote:

>> While reviewing draft-ietf-lisp-lcaf-12 I realized that if we want
>>instance-id support for other LCAF types then we must support recursive
>>LCAFs, i.e., use Type 2 and within it store the type we¹re interested
>>in. Wouldn¹t it be better to have the instance-id value and mask part of
>>the LCAF header? Apart from simplifying processing on xTR side, this
>>would also help avoid having other types, like Type 9, define their own
>>instace-id fields.

I would take Florin¹s point one step further: IID has become a critical
part of an EID, as also obvious from the DDT draft. Even today, when there
is no IID LCAF on wire, we are assuming an IID exists, and the value is 0.
An alternative is to just consider adding it as part of the EID record (in
LISP messages), instead of having it as an LCAF.

Best,
Vina

>> 
>
>Well Florin, the way I look at this is from this perspective. If we want
>geo-prefix support for all other LCAF types we also have to do nested
>LCAFs. So be all things to all people would make the encoding a
>combinatorial problem. So nesting is really the only way to manage it.
>
>I agree that instance-ID may be a popular LCAF to use but I see others
>that will be just as popular. To name two, AFI-List and RLE.
>
>Dino
>
>> 
>> Thanks, 
>> Florin

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 18 Apr 2016 11:36:10 -0700

> LISP messages), instead of having it as an LCAF.

Well the EID-record in a Map-Request looks like this:

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     / |   Reserved    | EID mask-len  |        EID-Prefix-AFI         |
   Rec +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     \ |                       EID-Prefix  ...                         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

And a EID-record in a Map-Reply, Map-Register, and Map-Notify looks like this:

  +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   |                          Record TTL                           |
   |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   R   | Locator Count | EID mask-len  | ACT |A|      Reserved         |
   e   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   c   | Rsvd  |  Map-Version Number   |       EID-Prefix-AFI          |
   o   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   r   |                          EID-Prefix                           |
   d   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  /|    Priority   |    Weight     |  M Priority   |   M Weight    |
   | L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | o |        Unused Flags     |L|p|R|           Loc-AFI             |
   | c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  \|                             Locator                           |
   +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

So finding 24-bits in reserved fields is not only costly, not available and doesn’t allow future single bit allocations, not to mention the huge complex compatibility problem we would have, I wouldn’t suggest going this route.

So one should ask, for an EID lookup, or a lookup key, what else would you want to accompany the EID with? If it is going to be a multi-tuple lookup, you are going to need an AFI-List Type encoding anyways. But for the typical lookup of (<iid>, <eid>) and (<iid, <seid>, <group-eid>) the Instance-ID
Type works for the former and the Multicast-Info Type works for the later.

So I would like to hear why you would use a nested LCAF for an (<iid>, <eid>) lookup?

Dino

---

From: Florin Coras <[email-masked]>
Date: Tue, 19 Apr 2016 00:03:09 +0200

Hi Dino, 

Thanks for the reply! More inline. 

> On Apr 18, 2016, at 8:36 PM, Dino Farinacci <[email-masked]> wrote:
> 
> So one should ask, for an EID lookup, or a lookup key, what else would you want to accompany the EID with? If it is going to be a multi-tuple lookup, you are going to need an AFI-List Type encoding anyways.

I guess you mean this as a fallback mechanism. IMHO this is optional, deployment dependent. 

> But for the typical lookup of (<iid>, <eid>) and (<iid, <seid>, <group-eid>) the Instance-ID

MAC and Source/Dest would be straight forward examples but I think this holds for Types 4, 6 and 14 as well. That is, all types where tenant separation would make sense. Probably it’s not something we’d want for LCAFs meant to be used as RLOCs.

At first sight, this seemed to be a simple improvement that could simplify control plane message processing. But you’re right in that backwards compatibility or support for all useful LCAF combinations make implementing the needed changes rather difficult. 

Thanks, 
Florin

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 18 Apr 2016 15:23:39 -0700

> I guess you mean this as a fallback mechanism. IMHO this is optional, deployment dependent. 

No, since you implied you may need to add other LCAF types to a <iid>,<eid> lookup, they would probably need to be LCAF encoded, so nesting would have happened anyways.

> MAC and Source/Dest would be straight forward examples but I think this holds for Types 4, 6 and 14 as well. That is, all types where tenant separation would make sense. Probably it’s not something…

Expanding what types are so the email can be user-friendly for others to read

True for Type 4 (Applicaiton Data Type) for sure. But for Type 6 (Opaque Key Type), since you are free to format the opaque type anyway you want to regsiter it, you can put the Instance-ID inside of it. But if you want to keep the mapping system simple, doing nested LCAF types is the way to go. As for Type 14 (JSON Data Model Type), how does one use that in an EID-record? You would need quite a bit more justification in a design to make changes for any of these.

> At first sight, this seemed to be a simple improvement that could simplify control plane message processing. But you’re right in that backwards compatibility or support for all useful LCAF combinat…

Yep.

Dino