If I were writing these things, I would put the registration for each of
those types in the companion document. That way, a reader could judge
the safety and utility of the proposed usage. Otherwise, the
registration itself is not understandable.
Asked backwards, why is there value in putting a bunch of IDs that are
not needed in base implementation into a spec that does not explain what
they are for?
Yours,
Joel
On 9/10/13 11:01 AM, Dino Farinacci wrote:
Speaking personally, I have some concerns about this.
I think my concerns can be lumped into two related categories. Bother are
about interoperability.
Firstly, I find the registration of LCAFs without any explanation of how or why
they would be used to be awkward. I know that some members of the WG like to
have everything in one document. But this is why we maintain
We have companion documents (that are not working group chartered documents).
Here are some examples:
(1) The draft-ermagen-nat-travesal draft states how to use the NAT-Traversal
LCAF type.
(2) The draft-farinacci-lisp-te draft states how to use the Explicit Locator
Path (ELP) LCAF type.
(3) The draft-codas-lisp-re draft states how to use the Replication List Entry
(RLE) LCAF type.
(4) The draft-ietf-lisp-ddt draft stats how to use the Security LCAF type for
LISP-DDT-sec.
registries. Once we have defined LCAFs, it is quite sensible for documents
which need LCAFs to add them to the registry, with the explanation of how and
why the particular LCAF is beign defined.
So I would suspect that the JSON Data Model Type would have a companion
document.
Note that unlike base protocol mechanisms, the set of LCAFs is not something
that all implementations need to understand. A LISP implementation that is
never going to do 5-tuple lookup does not need to know about LCAFs
Correct.
that are designed to handle that. And conversely defining new LCAFs ought in
my view create an obligation for new behavior in all LISP devices. (I don't
think the authors intend that kind of obligation.)
This is generally true but I am finding more use-cases, where people just want
to store data in the RLOC LCAF encoding for easier management and
network-self-documentation.
On a related note, I find very general LCAFs a cause for concern. Particular
the JSON LCAF, which seems to allow the mapping system to reprogram the packet
processing hardware on the fly seems excessive. I understand it is
The LCAF document doesn't say how the JSON Data Model LCAF will be used so we
can't assume it is for the case you state above.
neat for experimentation. But how does something injecting a JSON LCAF have a
reasonable judgment about whether the ITR which will receive it will be able to
implement the processing required? If we are assuming particular deployment
models, we need to describe that. (Which leads to the question as to why it is
in this document.)
What we have done in two cases for similar compatibility issues is this:
(1) For wanting to store Geo-Coordinates with RLOCs for ITRs that do not
understand it, you encode the Geo-Coordinates LCAF type along with an AFI=1 or
AFI=2 RLOC address in a AFI-List LCAF RLOC record. Then the ITR that doesn't
understand the first AFI in the AFI-List (the Geo-Coordinate encoding), skips
over it and goes to the next AFI in the AFI-List LCAF, where low and behold,
there is an address it can encapsulate to.
(2) The above is done for ELP encodings too.
Dino
I may be in the rough on these concerns.
Yours,
Joel
On 9/10/13 12:35 AM, Dino Farinacci wrote:
Folks, I compiled all the input I received for updates to the LCAF draft. Find
enclosed the updated draft and a diff file.
Deadline is tomorrow but we can have discussion before I post. So if there are
any changes or comments, I can add them into the -03 draft. So I am not that
worried about missing the deadline.
Changes include:
B.1. Changes to draft-ietf-lisp-lcaf-03.txt
o Submitted September 2013.
o Updated references and author's affliations.
o Added Instance-ID to the Multicast Info Type so there is relative
ease in parsing (S,G) entries within a VPN.
o Add port range encodings to the Application Data LCAF Type.
o Add a new JSON LCAF Type.
o Add Address Key/Value LCAF Type to allow attributes to be attached
to an address.
Dino
_______________________________________________
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp
_______________________________________________
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp
