Subject: Re: [lisp] last call for draft-ietf-lisp-alt-06

From: Terry Manderson <[email-masked]>
Date: Mon, 20 Jun 2011 20:55:08 -0700

We, the Co-Chairs, are calling the LC closed for this item.

It was held open beyond the end date to ensure adequate time was given for
substantive review.

The write-up will commence soon.

Thanks
Terry

On 2/05/11 10:08 AM, "Terry Manderson" <[email-masked]> wrote:

> All,
> 
> The authors of draft-ietf-lisp-alt-06 have requested a work group last call.
> 
> Here starts the last call for this document, Joel and I will end the last
> call on Monday the 16th May, 2011.
> 
> Please review the draft and provide any last comments.
> 
> Cheers
> Terry
> 
> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp

---

From: Vince Fuller <[email-masked]>
Date: Thu, 23 Jun 2011 14:46:57 -0700

On Mon, May 16, 2011 at 06:26:53PM -0400, Alia Atlas wrote:
> This is a very well written and clear document.  I think it is in good
> shape.
> 
> I do have a few questions:
> 
> a) In Sec. 4.1,
>    "This "first hop" ALT Router uses EID-prefix routing information
>    learned from other ALT Routers via BGP to guide the packet to the
>    ETR which "owns" the prefix."
> 
> If an ETR provides more than 1 RLOC for an EID-prefix or multiple ETRs
> provide different RLOCs, how does the ALT Router decide which to use
> to guide the packet to the ETR?  Does the ALT Router determine
> that the ETR is reachable?
>
> Perhaps this is a question better asked of draft-ietf-lisp-ms, but I
> do not see it addressed there either and the guiding of the
> unencapsulated Map-Request appears to be left to the ALT
> infrastructure.

I don't understand this question. The forwarding table on an ALT router is
composed of EID prefixes with next hops over tunnels to other ALT routers.
RLOCs are not used when forwarding ALT Datagrams. If an ETR connects to
the ALT (which is rarely done; ETRs usually register their prefixes with
Map Servers rather than participating in the ALT directly), then it does
so with tunnels to other ALT routers. An ALT Datagram destined to that
ETR (i.e. one which has a destination IP address that matches the EID
prefix advertised into the ALT by the ETR) will be forwarded to a tunnel
endpoint address on that ETR, not to an ETR RLOC.

> 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.

> c) In Sec 7.2, there is a sentence: "Should a receiving ITR decide
> that it does not wish to store such more-specific information, it has
> the option of discarding it as long as a shorter, covering EID-prefix
> exists."  I found this confusing and it seems to violate the prefix
> rules in [LISP], as well as they were described.

If a covering map cache entry exists (i.e. 153.16.0.0/16) and the more-
specific prefixes are discarded (i.e. 153.16.10.0/24), then data traffic
would be LISP-encapsulated and sent to one of the RLOCs for the covering
map cache. This is no different than the way a shorter prefix can be used
for IP forwarding to any more-specifics of that prefix.

> d) In [LISP] sec 5.5., there is discussion of using Instance IDs to
> disambiguate. "When multiple organizations inside of a LISP site are
> using private addresses [RFC1918] as EID-prefixes, their address
> spaces MUST remain segregated due to possible address duplication.  An
> Instance ID in the address encoding can aid in making the entire AFI
> based address unique.  See IANA Considerations Section 14.1 for
> details for possible address encodings."
> 
> I am not suggesting adding explicit support for this at this point, but
> adding a caveat that supporting this is for future study & experimentation
> would provide clarity.

The use of instance IDs is outside of the scope of the ALT document.

> f) Typo in 2nd to last paragraph on p.20:
>   "This is, by no means, and exhaustive list."
>                          ^^^
>                          an

Thanks. Fixed in the -07 draft, which will be published shortly.

	--Vince
	(on behalf of the other co-authors)

---

From: Alia Atlas <[email-masked]>
Date: Fri, 24 Jun 2011 03:02:51 -0400

Vince,

Thanks for the responses - comments in-line.

> endpoint address on that ETR, not to an ETR RLOC.

Thanks - this was my confusion.  I got the question from the [MS] draft and
clearly dropped a bit of context.

> the ALT, which is not recommended and may or may not acheive the desired

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.

> for IP forwarding to any more-specifics of that prefix.

I have pulled my response into a separate email.  As far as I can tell, this
behavior would cause the ETR to drop traffic.

I understand that the context of the section is TE - but do not see
that context resolving
the problem.

> The use of instance IDs is outside of the scope of the ALT document.

OK - it is hard to tell what parts in the base spec are must-implement and what
are the fragments of an undeveloped idea.

Thanks,
Alia

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 24 Jun 2011 14:28:35 -0400

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:
> back to the general question that I've been discussing with Joel, Dino&  Noel
> on the list.
>
> the mapping database&  may not even support sending Map-Requests.
> This implies that the

---

From: Vince Fuller <[email-masked]>
Date: Tue, 28 Jun 2011 11:47:44 -0700

> However, the effect is to introduce confusion.

I am not sure if you are asking for a text change here.

The current ALT document says the following regarding the source IP address
of an ALT datagram:

- the last paragraph in section 3:

   The term "ALT Datagram" is short-hand for a Map-Request or Data Probe

- first paragraph in section 5.1:

  5.1.  Changes to ITR behavior with LISP+ALT

     As previously described, an ITR will usually use the Map Resolver
     interface and will send its Map Requests to a Map Resolver.  When an
     ITR instead connects via tunnels and BGP to the ALT, it sends ALT
     Datagrams to one of its "upstream" ALT Routers; these are sent only
     to obtain new EID-to-RLOC mappings - RLOC probe and cache TTL refresh
     Map-Requests are not sent on the ALT.  As in basic LISP, it should
     use one of its RLOCs as the source address of these queries; it
     should not use a tunnel interface as the source address as doing so
     will cause replies to be forwarded over the tunneled topology and may
     be problematic if the tunnel interface address is not routed
     throughout the ALT.

Are you saying that one of these sections needs to be changed to make it
more clear that the source IP address of an ALT datagram should, in normal
use, be an RLOC? If so, please provide suggested text; IMHO, the existing
text is rather explicit about warning that using an EID as the source of
an ALT Datagram could have undefined consequences. We do not intend for the
infrastructure to test for that situation since the cost of doing so would
be unancceptably high.

	--Vince

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 28 Jun 2011 14:55:16 -0400

Unless we are prepared to modify the base LISP spec ETR behavior, I 
would remove everything from "Note" to the end of of the quoted 
paragraph from section 3.
I think it would be helpful to instead say "Such datagrams carry RLOCs 
as their outer header source addresses, and EIDs as their outer header 
destination addresses."

Yours,
Joel

---

From: Vince Fuller <[email-masked]>
Date: Tue, 28 Jun 2011 12:02:10 -0700

> as their outer header source addresses, and EIDs as their outer header 

OK. Change will appear in ALT 07, to be published later this week when
several other comments are resolved.

	--Vince

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 28 Jun 2011 16:10:07 -0400

Thanks.  Joel

---

From: Alia Atlas <[email-masked]>
Date: Tue, 28 Jun 2011 16:25:25 -0400

Thanks

Alia

---

From: Vince Fuller <[email-masked]>
Date: Tue, 28 Jun 2011 13:37:28 -0700

> rules in [LISP], as well as they were described.

After further consideration and discussion, I agree that such discarding of
more-specific map cache entries would be a bad idea. Even in cases where
it could be done without adverse traffic forwarding impact (such as when the
covering route and the more-specifics share the same set of RLOCs) it would
add complexity to the cache management problem.

This sentence has been removed in the upcoming version 7 of the ALT spec.

	--Vince