I'm not that happy with
"As the architecture is realized, if a given bit string is both an RLOC
and an EID, it must refer to the same entity in both cases".
In a MESH-architecture the EID of a mobile-node can be the RLOC of a
neighbour mobile-node.
Regards,
Renne
Am 23.10.2017 um 19:55 schrieb Dino Farinacci:
Just stating my personal opinion here…
No prob. Thanks for that. See udpate rfcdiff.html file attached. I will send
another email with the open items, so others can comment.
Working group, what do you think the correct wording should be. I suggest:
o “routable”
o “routable in the underlay”
o “routable in the RLOC space"
[AR2] My personal preference is "routable in the underlay", but any of
the three works for me.
I would prefer “routable in the RLOC space” since this is what is needed.
Done.
The EID-to-RLOC map-cache is a short-lived, on-demand table in an ITR that store
[AR] We probably should remove the note on the map-cache being
“short-lived” since that may not be the case in some deployments.
Response (3).
But it is in other deployments if you don’t want to use any of the update
mapping techniques, like map-versioning, SMRs, pubsub, and Map-Notify messaging.
[AR2] I would suggest that at least we rephrase the sentence to say
something like: "The EID-to-RLOC map-cache is a (generally
short-lived) on-demand table in an ITR that stores…"
I agree with AR, we do not need to state how long the mappings are kept in a
cache, this is a management/implementation issue.
Done.
[AR2] My question was more with regard to the Locator-Set. Let's say
that two different ETRs serving the same site are registering only
their own RLOCs and are leveraging on the merge-semantics capability
of the Map-Server to build a unified mapping. These two ETRs are in a
steady state but their Locator-Set is different for the same
EID-Prefix.
Address Family Identifier (AFI): AFI is a term used to describe an
address encoding in a packet. An address family currently pertains to
an IPv4 or IPv6 address.
[AR] Although in some points the document mentions LCAF or other
address types for EID/RLOC, in most of the cases it assumes only
IPv4/v6. I think we should update the document to be more flexible and
relax those IP-only mentions (specially for EID cases).
Response (1).
I changed to “An address family that pertains to the data-plane, can be an
IPv4, IPv6, or MAC address.”
Why you do not simply state “An address family that pertains to the
data-plane.” and that’s it.
Sure, changed.
Response (1).
Making a reference to private addresses is actually very important. There are a
lot of container and VMs within cloud provider deployments that use it. It is
probably the most popular use-case of LISP.
[AR2] My intention was to state that we should not tie Instance-IDs to
the address duplication problem of private addresses. Indeed,
preventing address duplication is one of the major use-cases for
Instance-IDs but they are applicable beyond that particular use-case.
I agree with AR. private addressing is a use case not the reason. Text should
be more generic.
Then can one of you two suggest text to insert here?
I made a reference to the VPN spec which is now a WG draft.
An ITR SHOULD only set the E-bit in an encapsulated data packet when
it knows the ETR is
enabled for echo-noncing. This is conveyed by the E-bit in the
Map-Reply message.
[AR] There should be probably a mention to merge-semantics and/or
proxy-reply here.
Response (3).
Why? Merge semantics only apply to Map-Registers. Not the Map-Reply an ETR
sends to an ITR. That is when it conveys it can support echo-noncing.
[AR2] My point was that merge-semantics and proxy-reply may affect the
E-bit process. For instance, if the MS is merging different
Map-Registers, (some with the E-bit set, some without), which value
for the E-bit should the MS return in a Map-Reply?
Since the LISP architecture uses a caching scheme to retrieve and
store EID-to-RLOC mappings, the only way an ITR can get a more
up-to-date mapping is to re-request the mapping.
wouldn’t be simpler to change the sentence in “….the only way an ITR can get a
more
recent mapping is to update the mapping by any means available in the control
plane.”
This should be generic enough to cover the pub/sub case.
That is not what the comment is about. The comment is related to how an ETR
tells an ITR that it is echo-nonce capable. And if multiple ETRs register the
same EID-prefix with each of their RLOCs, a proxy Map-Reply has a single E-bit.
So the Map-Server cannot set the bit if one can support echo-noncing and the
other cannot.
Response (1).
Added text to support your suggestion.
It is important to note that a locator address in any LISP control
message MUST be a globally routable address and therefore SHOULD NOT
contain [RFC1918] addresses.
[AR] The Internet use-case is less relevant today, therefore I’d
suggest removing the sentence regarding RFC1918.
Response (1).
I think we should add that there ARE allowed if run in a local environment.
I agree with AR. Sentence should be removed. It is consistent with the very
first comment about RLOCs being routable in the RLOC space.
If your RLOC space is the Internet then you cannot use RFC1918 addresses.
Check the current text to see if the change suffices.
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
