RE: [RRG] Comments on draft-lewis-lisp-interworking

["Darrel Lewis (darlewis)" <darlewis@cisco.com>]

Jari,

I'd like to add to a few of Dino's comments about PTRs.  Please see
below.

Thanks again for the feedback on the draft, its very much appreciated.


> 
> >>> Comment on Section 5: The document should talk about what is the 
> >>> motivation for deploying PTRs.
> >>
> >> Will add to it, but you probably guess the motivation is 
> so you can 
> >> pull PI addresses out of the core as soon as possible 
> without using 
> >> NATs on the edges.
> >
> > This is a motivation from the point of view of the Internet, not a 
> > motivation for me as an business person to buy a new box 
> that serves 
> > some other people.
> 
> You don't buy it just because it *only serves* another 
> person. You, as a site, want LISP so you can get portable EID 
> prefixes and that you can do multihoming cheaper and get 
> ingress TE on your links.


I'd also like to add that an ISP can benefit by deploying PTRs.  Post
encapsulation, the outer header is the destination RLOC.  A provider who
doesn't deploy a PTR will have to route all LISP destined traffic to
someone who does.  One could imagine a scenario where providers could
end up sending more traffic to expensive transit links rather than to
RLOC addresses to which they may have settlement-free peering.  For
large transit providers, deploying PTRs may attract more traffic, and
therefore more revenue, from their customers.


> 
> > As I said above, I think there are reasons for doing this. For 
> > instance, I could imagine a business where I'm selling PTR 
> > connectivity to LISP sites. However, this appears to work only if I 
> > can choose the LISP sites that I'm serving. This seems to 
> imply that I 
> > can only advertise part of the identifier space with anycast. I'm 
> > wondering how that's better than advertising PI space... but maybe 
> > your responses below on aggregation will shed some light on this.
> 
> That is not the way it should work, or else you'll have EIDs 
> for each island of support.
> 
> Is your point that there is no motivation for anyone to deploy a PTR?
> 
> >>> Comment on Section 5: I don't understand how we distinguish 
> >>> advertising the EIDs vs. larger prefixes. Given the 
> >>> non-aggregability of EIDs, can
> >>
> >> Don't assume EIDs are not aggregatable, they could be very much 
> >> aggregatable in IPv6 down to a /16. In IPv4, we'll have to 
> use a few 
> >> prefixes, hopefully just 10 or so and not in the 100s and 
> definitely 
> >> won't deploy it if in the 1000s. But many think this is 
> still a very 
> >> small price to pay (in the 1000s) to be able to suppress more 
> >> specific PA advertisements of PI advertisements from the 10^6 
> >> multi-homed sites we expect to come.
> >
> > I'm sorry, but I don't understand why you believe the EIDs are 
> > aggregatable. Sure, we can choose a /4 which holds the EID 
> space. But 
> > the question is whether a PTR can advertise all of this, or 
> if due to 
> > business reasons you want to be able to switch between PTR 
> providers. 
> > If this is needed, I don't see how you can aggregate EID space.
> 
> Not just one PTR. A bunch of them will advertise it for 
> compatibility sake. But if I had to choose I would error on 
> using NAT as the solution because I don't want any additional 
> infrastructure if I can avoid it.
> 
> We put PTRs in there to allow a solution that doesn't use NAT.  
> Possibly for IPv6 which could be NAT-free.


PTRs also solve the case where a non lisp site wants to use, say, DNS to
resolve the address of a destination.  In the case of NAT, which address
should the destination site put into DNS?  The NAT'd address, or the
LISP-NR EID?  With a PTR in place, the site just has to place the EID in
DNS and that's it.

Some other solutions have suggested running a separate instance of DNS
to handle this case, and that would work except it adds cost to the
site.  PTRs allow for a site to be accessed without NAT or configuration
burden if they choose to do so.

So we basically have two options here, in once case the LISP site can
use NAT and manage the transition all on their own.  In the other, we
can add a new network element called a PTR that can relieve that burden
on the site, with the downside of potentially adding stretch to incoming
connections.  You can consider PTRs optional, but NAT is a core
requirement for any sensible interworking between LISP and non LISP-NR
sites.


> 
> >>> is added to it. With PTRs, the encapsulation is happening without 
> >>> the knowledge of the legacy endsite. This means that 
> either we must 
> >>> require the legacy endsites (and paths to them) to be 
> able to deal 
> >>> with PMTU discovery or the PTR - LISP site tunneling 
> mechanisms need 
> >>> to be able to carry 1500 byte payload packets. Some discussion of 
> >>> this might be useful in the document.
> >>
> >> See draft-farinacci-lisp-06.txt for resolving MTU issues.
> >
> > I did read it earlier, and I liked the MTU handling. However, you 
> > still need to deal with path MTU on the legacy-to-LISP path 
> with PTRs, 
> > and as
> 
> Could you explain this better please. References don't do me 
> any good.  
> I want to know exactly what you are talking about before I 
> speculate a reply.
> 
> > I explained above, you have to assume one of the following 
> for this to 
> > work:
> >
> > 1) support for the new ICMP-less path MTU RFC in the legacy site.
> > 2) that ICMP is not blocked in the legacy site or on the path to it
> > 3) that path between PTR and LISP site has MTU > 1500 bytes.
> 
> Well, can't you tell from the spec we believe in 3)?


I would just like to add that I don't think that the a PTR will have any
more MTU issues than an ITR might (or might not) have.


> >> Well, it doesn't happen so LISP can't help create more switching 
> >> capacity. You build out many of them. And deployment 
> experience will 
> >> tell us if the "interworking tunnels" should have large diameter 
> >> (PTRs deployed closer to non-LISP sites) or smaller diameter (PTRs 
> >> deployed closer to LISP-sites).
> >
> > This sounds reasonable, but I'm not sure I fully understand 
> how this 
> > works -- maybe we need to resolve the aggregation question first 
> > before we can talk about this. If you can aggregate EID 
> space in the 
> > PTRs, I think this will work.
> 
> Here's the scenario:
> 
> 1) Start out deploying 100 PTRs for IPv6.
> 2) They each advertise an IANA-assigned global IPv6 EID block 
> of 0240::/16.
> 3) As more LISP sites come on, you add more PTRs.


I think that this is a key point - PTRs are more attractive to me the
more you can aggregate EID space. 


> 
> > points. Still, in the routing system the same EID space is 
> advertised 
> > from multiple locations. I suspect the properties of this 
> are similar 
> > to anycast.
> 
> People confuse this a lot. Anycast is how you assign 
> addresses to boxes. Advertising the same prefix from multiple 
> spots is multi-path routing.


We've tried to make this clear in the text, I guess it needs to be
clearer. :-/

-Darrel

--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg