Speaking personally, I find the notion of treating the ITR capability as
a LCAF included in the request message to be very undesirable. It
clearly can work. But it looks like a fairly bad misuse of the tools.
One which will cause us trouble down the road.
Yours,
Joel
On 11/20/13 1:17 PM, Dino Farinacci wrote:
Dino,
Sorry for the delay, I see this proposition just now.
Do you propose this capability in the context of VPN and/or NSC?
I didn't have anything specific in mind. I just wanted an ITR/ETR pair to know
if they could do a feature and what to do if one supported the feature and the
other one did not.
I would have a question, if there is capability, it means that there
is a possibility to meet no capability so in this case what is
replied? An record with 0 locators? no answer? a special answer
Always reply, but state what you support so the capabilities bits can be
compared at the ITR to see what is in common.
saying "bad luck no match for the capability"? If 0 locators then it
There is always a baseline for what you support. That is what is in RFC 6830.
So if an ITR wanted Geo-Coordinates returned in a RLOC-record, and the ETR did
not support that, it would return an RLOC-record with a single-tuple (with just
an AFI-encoded RLOC address) versus the two-tuple (with the AFI-encoded RLOC
address and the LCAF-encoded Geo-Coordinates). And then the ITR would just
encapsulate to the RLOC as it does today.
is a negative reply but conceptually this is not a negative reply. If
no answer, then the requester will keep continuing sending requests.
If a new message, what kind of message?
There is no need for a new message. That would complicate matters and create
more combinations to deal with when receiving responses.
Dino
Thanks,
Damien Saucez
On 12 Sep 2013, at 20:29, Dino Farinacci <[email protected]> wrote:
So wouldn't be useful if an ITR which sends a Map-Request to the mapping system, could
say "I know Mr. ETR that you have registered a bunch of stuff to the mapping system,
but can you return just the stuff I care about and more importantly the stuff I support
in my implementation?".
So I was thinking (and talking to several others about this), if we could have
a Capabilities Type LCAF that is encoded in an address field of the
Map-Request. I would like to propose that it get encoded in the ITR-RLOCs field
of a Map-Request. This way, each ITR in the ITR-RLOCs list could tell a
Map-Replier what they support.
I would propose that the Capabilities Type LCAF be encoded as a bit-string.
Where each bit position indicates the LCAF Type value. We would have 2 fields,
an EID field and a RLOC field so it can be conveyed which Types are supported
for EID encoded fields or RLOC encoded fields in any LISP control message.
It would be required of every implementation to support the Capabilities Type
LCAF if nothing else would be supported. That would get the implementations to
do the general parsing work so they could skip over LCAFs they don't understand
and get to the ones they do understand while conveying what they support.
Also I find that this may be useful for this world of multiple encapsulations.
Rather than register UDP port numbers, a decapsulator could convey what
encapsulations it supports (i.e. L3-LISP, L2-LISP, VXLAN, NVGRE, IPsec, GRE,
whatever-new-thing-nv03-comes-up-with).
The Capabilities Type LCAF could also be used by the mapping system. So when an
ETR sends an Info-Request, an Info-Reply from the map-server could tell the
registering system what LCAFs it supported. Ditto, for asking map-resolvers
what types of EID encodings they could support (maybe the mapping system can
support more LCAF encodings then the map-resolvers, so you can choose a
different map-resolver if you wanted more).
And arguably, the Capabilities Type LCAF could be put in RLOC-probes. It could
go anywhere with the address you wanted to encode as a 2-tuple.
Comments?
If people are interested I can draft up the details for the -03 version. Or if
you think we should post the -03 version just with the current changes, I can
do that. And also comment if you think we should go with the JSON Data Model
Type for -03 or put it into -04 with perhaps this Capabilities LCAF.
Thanks,
Dino
_______________________________________________
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
