Subject: [lisp] last call for draft-ietf-lisp-interwork-01

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

All,

The authors of draft-ietf-lisp-interwork-01 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 16:22:54 +0300

I read the latest version (-01)  of the interworking draft. This lead to
following comments.

- editorial comments:  
Section Definition of terms 
1. Definitions of EID-Prefix Aggregate and Provider Independent (PI)
have been merged. They should be separate.
2. Term EID Sub Namespace is not used in the document. What is
aggregatable locator? Aren't all RLOCs aggregatable by definition? Maybe
this has something to do with the notion of EID-R and EID-NR?

Content related questions for clarification:

It seems that it is assumed that PITRs have integrated BGP capability;
i.e. PITRs are first hop ALT routers as well as a regular BGP router.
Otherwise the sentences such as "A key part of PITR functionality is to
advertise routes for highly aggregated EID prefixes into part of the
global routing system" and " For example, some of the routes being
announced might be tagged with a BGP community and their scope of
announcement limited by the routing policy of the provider." It think
that the draft would benefit from having some explanation how the
advertising should take place if that has been thought out.

The text of this example is confusing:

"The Host 192.168.1.2 sends a packet destined for a non-LISP site to
its default route (the ITR).  The ITR receives the packet and
determines that the destination is a LISP site."

Why would  the Host think that the packet would be for non-LISP site?
Should that be fully transparent to the Host what kind of the site the
destination is?   

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-interwork-01

All,

The authors of draft-ietf-lisp-interwork-01 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: Darrel Lewis <[email-masked]>
Date: Sat, 7 May 2011 02:23:49 -0700

Hi Flinck,

Thank you for your thoughtful comments.  

> i.e. PITRs are first hop ALT routers as well as a regular BGP router.

You are correct.  Though there is no hard requirement for them to be first 
hop ALT routers.  This document was created before the Map-Server
document was created.  I will update the draft and clarify this
distinction.

> advertising should take place if that has been thought out.

Will add some text clarifying this at a high level, but the exact details
should be developed in the deployment document.

> determines that the destination is a LISP site."

I agree this is confusing.  In general ITRs are on-path
for the traffic flowing through them (since they are originating a 
default route (or hosts point the default route to them statically) 
so that is why they get packets from hosts.

> Should that be fully transparent to the Host what kind of the site the

Yes it is, will clarify.  Thanks!

-D

---

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

Here are my review comments:

a) In Sec 2, case 3, the assumption that the ITR is connected to
Internet BGP and directly to the mapping database doesn't match well
to the assumptions in [ALT] and [MS].  If using those drafts
(reasonable since it is the only approach being last-called), the ITR
will get a negative Map-Reply and doesn't need to participate in BGP.
I think this is worth addding as a mechanism.

b) In the LISP-NAT case, I am still not clear on how to handle the DNS
concerns.  It seems like using a EID-R is necessary if, as is said in
Sec. 8, "In the LISP-NAT option the LISP site can manage and control
the interworking on its own."  Using an EID-NR requires a PITR, unless
I'm missing something.  Having this explicitly stated would be useful.

c) Typo in Sec 2., case 3, number 3, line 2: "unencapsualted" ->
  unencapsulated

d) typo, p. 7 2nd line: "tin" -> in

e) typo: p.8 in EID-Prefix Aggregate: "Provider Independent (PI)
Addresses" doesn't start a new paragraph.

f) typo: p.9 5th line from bottom: "unencapsualted" -> unencapsulated

g) typo: p.11, 4.3, bullet 2, 2nd line:  "the the" -> the

h) typo: p. 12, 5th line from bottom: "is is" -> is

i) typo: p. 21, sec 8. line 4: "we the site" -> "the site"

Looking forward to your responses,
Alia