Hi Jari-
Thanks for the review, comments, and suggestions. Here are my thoughts
in response.
> 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?
An ALT node can attempt to return an ICMP message in response to an error
condition (next hop unreachable, etc.) but there is obviously no guarantee
that it will be received since the RLOC destination may not be reachable
by a device which can only route on the ALT EID numbering space. Such a
failure will result in the sender of the Map-Request (and MR or ETR) giving
up after several retransmissions and treating the destination as unreachable
via LISP. Depending on how the source is configured, it may then try to use
LISP Interworking mechanisms to route "natively" to the destination.
> 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.
This situation is supposed to be covered by use of the ITR RLOC field. Use
of an ITR-provided RLOC is mentioned in section 5 and is further described
in [LISP] section 6.1.2 (where the field is shown in the Map-Request
message format) and section 6.2 (Routing Locator Section).
I will add appropriate references to [LISP] regarding ITR RLOC usage and
will explicitly mention the mixed-AF use case. Will that resolve this issue?
Keep in mind that the ALT exists for one purpose: so that a Map-Request for
an EID can be forwarded toward the ETR that can provide a Map-Reply. Traffic
is not bi-directional and the ITR RLOC information is included in the
Map-Request so that a responding ETR or MS can return a Map-Reply directly
to the Map-Request originator, bypassing the ALT.
> 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.
Thanks for the suggested text; I'll add to draft-ietf-lisp-alt-08.
> 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.)
Again, thanks for the suggestion. I'll start with this and re-work it a bit
for incorporation into section 1 of the -08 draft.
> 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)./
Thanks, will fix in -08.
> > == 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)
Thanks, will fix in -08.
Of course, creating -08 will result in an idnit for those documents, since
they reference ALT-08; will plan to fix those as part of their AD reviews.
> >This might be done minimize packet loss and to
> > probe for the mapping.
>
> ... might be done to minimize ...
Thanks, will fix in -08.
> > low performance expected of a tuneled topology, ALT Routers (and Map
> >
>
> s/tuneled/tunneled/
Thanks, will fix in -08.
--Vince
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
