If I am reading the text Alia qutoed below correctly, the text assumes
that an ETR will do something different with a map reply based on the
whether it thinks the source address is an EID.
I think this is basically indeterimnable.
More importantly, that would be an ETR behavior, which the ALT spec
can't change.
I suspect this is a case of the authors, in good faith, trying to leave
in a hook for an idea they have for the future.
However, the effect is to introduce confusion.
Can we not do that?
Thanks,
Joel
PS: I was going to wait longer to give the authors more of a chance to
comment first, but I have a flight shortly.
On 6/24/2011 3:02 AM, Alia Atlas wrote:
b) How can an ETR tell if the outer header Source Address of an ALT
>> datagram is an RLOC or an EID? I do see that using an EID is not
>> supported by initial LISP+ALT implementations (this could be pulled
>> early in the draft where the idea is first proposed), but I also don't
>> see a mechanism to do the disambiguation.
>
> The ETR does not attempt to determine whether the outer header source
> address is an RLOC or an EID; when it sends a Map-Reply to that address,
> it simply forwards it using the contents of its forwarding table. If the
> original source address was an EID and the ETR is connected to the ALT
> (again, this is a rare, degenerate case; ITRs and ETRs do not normally
> connect directly to the ALT), then the Map-Reply will be sent back over
> the ALT, which is not recommended and may or may not acheive the desired
> result.
This question was in reference to the last paragraph in Sec 3:
"The term "ALT Datagram" is short-hand for a Map-Request or Data Probe
to be sent into or forwarded on the ALT. Note that while the outer
header Source Address of an ALT Datagram is currently expected to be
an RLOC, there may be situations (e.g. for experimentation with
caching in intermediate ALT nodes) where an EID would be used to
force a Map-Reply to be routed back through the ALT.
"
I think the base of the question is whether the ETR can just know if a given
bit-pattern is an EID by seeing if it is in the mapping database. This comes
back to the general question that I've been discussing with Joel, Dino& Noel
on the list.
If the ETR can't tell whether a source address is an EID - and
therefore to be routed
back to ALT - or an RLOC - and therefore to be routed across the
current internet,
then there is a problem.
IF the assumption is that a given bit-pattern cannot refer to
different sites/endhosts
by one use being a RLOC and the other an EID, then I think this
concern is partially addressed
- but that assumption NEEDS to be written down into the base LISP draft.
As I understand it, an ETR (not co-located with an ITR) would not have
direct access to
the mapping database& may not even support sending Map-Requests.
This implies that the
ETR would need to send any Map-Replies out via an ITR that would do
this look-up?? Is this
the expected behavior?
I'd prefer to see a short explicit description of rules and behavior
around this. Certainly, the need
for the ETR to route its Map-Replies via an ITR was not clear. The
main confusion, of course, is
differing assumptions about what different name-spaces mean in practice.
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
