I have reviewed this draft. Like the other drafts that I have read, it was well
written and pleasure to read. Thanks for doing good work.
This draft does have some hand waving in some aspects (like exactly how the ALT
is built), but that's acceptable for an experimental specification. I did have
four remaining issues that I would like to talk about though. One is a question
and for the other three I have some suggested way forward. I also have a small
set of editorial suggestions at the end of this mail. Please respond and/or
revise draft so that we can send this one to IETF Last Call.
The question is about the treatment of RLOC source and EID destination
addresses when something bad happens in ALT (no route or some other problem,
say MTU limitation). Do you expect ICMP messages be sent back, and if so, how?
The use of RLOC source addresses seems to have an effect on intermixing IPv4
and IPv6 addresses. It would perhaps be desirable in some cases to allow IPv4
RLOCs while working with IPv6 EIDs, for instance. But those RLOCs cannot be
directly used on IPv6 packets that carry IPv6 destination addresses. (At least
not without agreeing that some form of mapped addresses are used. But that
doesn't work for carrying an IPv6 source address in an IPv4 packet.) My
suggestion is to add some text about this.
As this is an experimental specification and because we do not fully understand
all aspects of its operation, I think it is useful to add some description at
the beginning about the areas where further experience is needed.
Finally, I'm concerned about the Section 6.1 recommendation to use a "new numbering
space that is unrelated to the ASNs used in the global routing system". First of
all, its not clear to me what you are saying here. Are you (a) recommending that the
32-bit ASN space can just be reused and it doesn't matter if ALT uses the same numbers as
someone in the current Internet? Or are you saying (b) that some new allocations (or
perhaps even a small subspace) should be allocated from the existing ASN space and used
for ALT, without colliding with any existing allocations? I think the former would be
problematic, because its hard to prevent accidental leakage. But getting some new numbers
for ALT usage would perfectly fine, IMO. I'm also wondering if we should just allocate a
new SAFI (even if we do not require that legacy router implementations use it).
Here's some suggested text changes for Section 6.1:
OLD:
To avoid confusion, it needs to be stressed that that
these LISP+ALT ASNs use a new numbering space that is unrelated to
the ASNs used by the global routing system.
NEW:
To avoid confusion, it needs to be stressed that that
these LISP+ALT ASNs should use newly allocated ASN numbers that are
unrelated to
the ASNs used by the global routing system.
And some suggested new text for Section 1, to be inserted just before the last
paragraph:
NEW:
This specification is experimental, and there are areas where further
experience is needed
in order to understand the best implementation strategies, operational
models, and impacts to
the rest of the Internet. These areas include:
- application effects of on-demand route map discovery
- the impacts of using map requests versus carrying initial packets in ALT
- the best practical ways to build ALT hierarchies
- effects of route leakage from ALT to the current Internet
- effects of exceptional situations, such as denial-of-service attacks
Experimentation, measurements, and deployment experience on these aspects is
appreciated. While the theoretical impacts are often understood (such as an
ALT
lookup causing a potential delay for the first packet destined to a given
network),
it is less clear what effects, if any, these may have with real world traffic
patterns.
ALT cannot support mixed use of IPv4 and IPv6 addresses, as it requires the
use of the same
address family for both RLOCs and EIDs.
(Feel free to suggest alternate text.)
Editorial:
... little, if any, LISP-specific modifications should be
needed for such devices to be deployed on the ALT.
Perhaps you could add a reference to Section 4.2 that discusses what is
possible and is not possible with pure off-the-shelf routers. Otherwise the
statement feels a little bit fuzzy.
s/on the ALT./on the ALT (see Section 4.2)./
== Outdated reference: A later version (-15) exists of draft-ietf-lisp-14
== Outdated reference: A later version (-11) exists of draft-ietf-lisp-ms-09
(from idnits, please fix)
Endpoint ID (EID): A 32-bit (for IPv4) or 128-bit (for ipv6) value
reachability is carried as IPv4 or ipv6 NLRI without modification
s/ipv6/IPv6/
This might be done minimize packet loss and to
probe for the mapping.
... might be done to minimize ...
low performance expected of a tuneled topology, ALT Routers (and Map
s/tuneled/tunneled/
Jari
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
