On 4/18/16, 10:12 AM, "lisp on behalf of Dino Farinacci" <[email protected] on behalf of [email protected]> 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 >> _______________________________________________ >> lisp mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/lisp > >_______________________________________________ >lisp mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/lisp _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
