> In the particular case of the ELP LCAF individually do you still see a case > for JSON with DN support (and no v4, v6?)
I am not what the question is. Because, if you put a JSON LCAF type in the ELP, it is a distinct type vs putting an AFI encoded DN in the ELP. And if you meant "DN within JSON", that doesn/t make sense because the name encoding would follow JSON encoding rules. So please clarify. > The text in the draft now says: > > The Explicit Locator Path (ELP) LCAF Type (Type 10) is used to carry a list > of locators in an explicit re-encapsulation path. See [I-D.ietf-lisp-te] for > an example. Right, so that implies no other AFI type then MAC, v4, or v6. > (…) > AFI: > as specified in Section 4.1. Only AFI values for IPv4 (1) and IPv6 (2) are > valid in this LCAF Type. Any other AFI value is invalid and the LCAF Type > MUST be silently ignored. All the AFI fields MUST be the same. Otherwise, the > LCAF Type MUST be silently ignored. Right, so DNs and JSON types are not allowed, or at least we haven't found a use for them. I could see a use for it in the mapping system for invenetory purposes but not for forwarding. > Do you have a particular example where JSONs and DNs could be used with ELPs? > In that case, then Alvaro’s suggestion to expand AFI generically to all > types in section 4.1 would seem the way to go. I don't think we need to right now for ELPs. If someone wants to design a feature using ELPs with other types of LCAF Types or AFIs, then that spec will indicate how to do it and for what reason. Then we decide how to modify 8060bis later or if ever. > Alternatively, since this LCAF seems more oriented to be used for routed, we > can still expand the text in the section to include LCAF usage within ELPs > (but skip DNs and MACs). If this limitation applies, we could LCAF use when > to the cases when it complements v4 and v6 hops, using Alberto’s proposal I think MACs should be included. A source routed encapsulataion path for L2 overlays could be a desirable feature. > [AR] “If LCAF is used, the most inner address within the LCAF (or nested > LCAFs) must be v4 or v6” > > Thoughts? Agree on the working but would add "mac". Dino _______________________________________________ lisp mailing list -- [email protected] To unsubscribe send an email to [email protected]
