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

From: Terry Manderson <[email-masked]>
Date: Sun, 1 May 2011 17:08:55 -0700

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

---

From: "Flinck, Hannu (NSN - FI/Espoo)" <[email-masked]>
Date: Fri, 6 May 2011 17:09:34 +0300

Hello Vince and the other authors of the alt draft.

Thank you for a good job on developing the ALT concept. 

After reading the draft I have couple of comments to make:

The Introduction section refers to LISP 1.5 model that used to be in the
base LISP spec, but now I am not able to find from the latest document
version. This cloud be a left over from earlier versions, or then I am
overlooking something.

Definition section
"LISP+ALT operates on two name spaces..." It looks to me that LISP ALT
is primarly dealing with the EID space and very remotely (indirectly)
with the RLOC space. Should the definition be more accurate on that?

Overall, the issue of ALT topology continues to bother me. In what kind
of topology the ALT routers should be connected? The draft says the
following about the toplogy:

a) "...roughly-hierarchical mesh in which routers at each level in the
topology are responsible for aggregating..."

b) ... ALT Routers establish BGP sessions with one another...

c) ... roughly hierarchical, partial mesh ...

d) ... such a structure should minimize the number of EID-prefixes
   carried by LISP+ALT nodes near the top of the hierarchy.

e) .. upstream ALT router

f) While related to the global routing database, the ALT serves a very
different purpose and is organized into a very different hierarchy.

g) The ALT BGP peering topology should be arranged in a tree-like
   fashion (with some meshiness), with redundancy to deal with node and
   link failures. 
h) ALT BGP mesh

i) to connect to different parts of the ALT hierarchy if the ETR
   "owns" multiple EID-to-RLOC mappings for EID-prefixes that
   cannot be aggregated by the same ALT Router (i.e. are not
   topologically "close" to each other in the ALT).

Clearly some of the above relates to the EID address space delegation
rather than the topology between the ALT routers. However, I would
suggest a separate section that shows an example of a "reference"
topology. I use the word "reference" here because all real deployments
will have they own constraints which this or any other document cannot
foresee. But such a section about the ALT topology and issues that
should be taken into account when designing it would be useful. What do
you think?

Best regards
Hannu  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
ext Terry Manderson
Sent: Monday, May 02, 2011 3:09 AM
To: [email-masked]
Subject: [lisp] last call for draft-ietf-lisp-alt-06

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.

Cheers
Terry

_______________________________________________
lisp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/lisp

---

From: Alia Atlas <[email-masked]>
Date: Mon, 16 May 2011 18:26:53 -0400

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.

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.

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.

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.

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

Looking forward to your responses,
Alia