Subject: [RAM] Re: thoughts on draft-farinacci-lisp-00

From: Dino Farinacci <[email-masked]>
Date: Wed, 31 Jan 2007 16:40:43 -0800

I took the liberty to cc my coauthors. And I apologize in advance for  
the long reply.

> I read the draft and was quite happy with
> it in terms of something that is intended to
> be a base for experiments. A couple of

Thanks for your comments Jari. See my responses inline. Sorry this  
took some time to respond to.

> observations and questions, however:
>
>> LISP
> As an old Lisp hacker, I like the name of your
> proposal :-) Now, if you can also name the
> addresses as CARs and identifiers as CDRs
> (or maybe that's CIRs)...

We tried but it just wouldn't work. But taking the CDR of the  
encapsulated packet in the ETR does decapsulate the packet and taking  
the CAR of the pre-encapsulated packet in the ITR sends just the  
header.  ;-)

>>    The operator community has requested that the IETF take a  
>> practical
>>    approach to solving the scaling problems associated with global
>>    routing state growth.  This document offers a simple solution  
>> which
>>    is intended for use in a pilot program to gain experience in  
>> working
>>    on this problem.
>>
>>    The authors hope that publishing this specification will allow the
>>    rapid implementation of multiple vendor prototypes and  
>> deployment on
>>    a small scale.  Doing this will help the community:
>>
>>    o  ...
>>
> I very much agree with the approach of testing practical
> solutions and getting experience on what the hard
> issues really are. Thank you for writing up your
> prototyping/experimenting plans; we should have
> more drafts that take this approach.

You are most welcome. We gotta have a little fun, shouldn't we?  ;-)

>> load-splitting across its members.
> Is load-splitting a requirement from a traffic
> engineering perspective? What is the impact
> from the point of view of the same TCP
> session ending up going over multiple
> paths? Note that most of the end-host
> multihoming work has punted this
> question by stating that load-balancing
> is out of scope.

This can be optional. It gives better failover, like ECMP does in  
routing today. We wanted the frequency of EID-to-RLOC changes to be  
extremely low and not take into account reachability. We wanted to  
track reachability outside of the mapping function.

> Or is there something that you can
> do to avoid the problem with TCP, such as
> requiring that traffic from the same EID
> source/destination pair can never be split
> across paths?

Yes, we can. We can latch each EID/32 (or EID/128 in IPv6) to a  
specific RLOC.
Just like we hash today in routers forwarding on ECMP paths.

>>  3.  In LISP 1, the packet is routed through the Internet as it is
>>      today.  In LISP 1.5, the packet is routed on a different  
>> topology
>>      which may have EID prefixes distributed and advertised in an
>>      aggregatable fashion.  In either case, the packet arrives at the
>>      ETR.
> I like this, because it means that applications
> that are unaware that they are dealing with
> EIDs can leak them to other hosts, and those
> hosts will still be use the EIDs, because they
> are routable.
>
> However, presumably this means that for
> LISP 1, there is no change in the size
> of the routing table needed in the global
> Internet. Every site has to be able to be
> reachable with EIDs.

We have plans to forward packets with EIDs on another topology. One  
that is possibly slower performance that can have a strict hierarchy  
of EID-prefix aggregation. That does not suffer the multi-homing  
attachment point problem or need more-specific route injection for TE  
purposes.

This could be:

o Server based (like send data packets to 7 root servers for instance)
o A separate tunnel topology
o A separate VRF that runs on very small subset of the existing BGP  
peering
   topology
o A separate SAFI or maybe even a separate AFI?
o DHTs
o Others?

> (Conversely, in LISP 3 & 4, you would
> have the application referral problem.)

Yes, you are right. But we need to consider it for the PI-advocates.

>> RLOC unreachability is
>> detected by the receipt of ICMP Host Unreachable messages.  When an
>> RLOC has been determined unreachable, it is not used for active
>> traffic; this is the same as if it is listed in a Mapping Reply with
>> priority 255.
> I'm a bit uncomfortable with relying solely on
> ICMP for this function. What happens if something
> filters it away, will you be able to recover?

Well we received a lot of input on this. And I polled about 20 people  
from differing backgrounds. We are split. People say, we will just  
punch holes and don't worry about it. I offered encapsulating in ESP  
which has a hole punch in almost every firewall I have heard of and  
use a null cipher when you don't want to use authentication. And when  
you do, figure out a way to find keys.

So we are inclined to not change it at this point. During prototyping  
the truth will be told (no matter what the experts say ;-)).

> Also, the failure/reachability part probably needs more
> work in general. When do you switch back from a situation
> where the RLOC has been determined as unreachable?

When you get a reply from the ETR's unreachable RLOC, you can probe  
with an ICMP EID-to-RLOC request to see if it is replied to. Of  
course, you must rate limit and send requests for *EID-prefixes*. The  
request must cover a course-grain EID.

>>    LISP is designed to be very hardware-based forwarding  
>> friendly.  By
>>    doing tunnel header prepending [RFC1955] and stripping instead  
>> of re-
>>    writing addresses, existing hardware can support the forwarding  
>> model
>>    with little or no modification.  Where modifications are required,
>>    they should be limited to re-programming existing hardware rather
>>    than requiring expensive design changes to hard-coded  
>> algorithms in
>>    silicon.
>>
>
> Sounds good.

Well, if we want to solve the problem quickly, we have to think of  
these things.

>> EID-prefix-to-Locator mappings need to be explicitly configured.
> Can you expand on what this means? So, for instance, in
> the first hop router case, what would we have to
> configure? The EID prefix advertised in the local network --
> but wouldn't we have to configure a prefix anyway?
> Or the mapping between the router's RLOC and this
> prefix? But even that might be obvious, assuming
> that the Lisp feature is turned on and that you have
> one prefix in the local network and one RLOC from
> higher up...

In the ITR, you configure this:

o The EID-prefix is a course route that goes into the RIB/FIB. This  
route
   escapes traditional packet forwarding so LISP header prepending  
can happen.
   For local destinations, there are more specific routes in the IGP  
that
   cause packet forwarding to occur with no header prepend.

o The RLOCs for the ITR must be specified. In a cisco implementation  
I am
   thinking it can point to a loopback interface, so those addresses  
are the
   source RLOCs for sending LISP encapsulated packets.

In the ETR, you configure this:

o The EID-prefixes you must respond to with an ICMP EID-to-RLOC  
Reply. This
   again is an escape from the FIB for the case when the outer IP  
destination
   address is the same as the inner IP destination address. In the  
case the
   RLOC is the outer address, the packet is naturally decapsulated  
because the
   outer IP destination address is one of the ETR's assigned local  
addresses.

o The RLOCs for the ETR must be specified so you know what to return  
in bullet
   one, and for ICMP EID-to-RLOC Request messages. Again, loopback  
interface
   addresses. In the case where the site might want more than one ETR  
(you
   might want one CE connected to ISP-A to be a ETR and another CE  
connected
   to ISP-B to be the other ETR), then each ETR configures the RLOCs  
for all
   ETR boxes. This way you don't have to deal with a append-versus- 
replace
   semantic. That is, the latest ICMP Reply received always replaces  
previously
   stored information.

So I think in the normal case, we might get away with 1 EID-prefix  
per AS with
exactly 2 RLOCs associated with that EID-prefix (data from Geoff  
Huston indicates 80% of multi-homed stubs are dual-homed). This way  
we can keep the
request overhead down by just probing for the first host that talks  
to the
first destination in a specific site. All other activity between  
these two
sites already have the mapping. A good scaling benefit.

>>    o  Experiment with provider-independent assignment of EIDs
> Any thoughts on what this would be? Either for the
> experiment or for a full-blown solution later? That
> is, what space would be allocating the EIDs from?
> Would they be syntactically distinguishable from
> regular addresses?

I think they should be syntactically distinguishable from locator  
addresses (err, the same addresses we use today) for debugging  
purposes. A sniffer trace
really needs to reveal what's going on for debugging purposes. That  
is why we didn't want to go with an address rewrite solution but a  
new-header/tunneling
solution.

I would say to start, to get IANA to give out to an EID registry a  
couple class
As. Is 32 million EIDs too small? This would be a non-problem if the  
inner
header was IPv6.

Having said that IPv4 has way plenty of addresses if they were only  
used for
locators. So maybe we only need the hosts to convert to IPv6 to get  
the bountiful EID space and keep the router network IPv4.  ;-)

But I do believe to get LISP to scale better, you have to allocate  
blocks in power-of-2 chunks so we can aggregate EID-prefixes. Not so  
much to scale table size but to reduce control message flow and EID- 
to-RLOC cache misses.

>>    ICMP EID-to-RLOC Reply messages are authoritative to the same  
>> extent
>>    DNS Replies are.  LISP is no less secure than DNS and at this  
>> time we
>>    do not intend to add any additional security mechanisms to the
>>    proposal.
>>
> I am not sure the comparison to DNS is correct.

Well many have said this. We are planning on having some sort of  
security mechanism for the -01 draft release. But don't expect much  
because we don't want lots of infrastructure change. I have been  
advised by various operators to go lightweight here. That is, no  
third-party participation to manage keys.

> A different comparison would be to look at what
> attackers in different locations (on path, off
> path, peers) can do and whether there is something
> that changes in this proposal.
>
> If Request - Reply is defined so that only the Reply
> has an effect and that suitable Reply contents
> cannot be guessed by off-path attackers, then I

I think spoof-detection isn't that hard to solve, that is if we  
really ought to solve it. But validating that ETR-x is the one that  
has RLOC A and B for EID-prefix foo is what some say needs to be  
solved and is where the slippery slope begins.

> think we have roughly what we already have
> for Internet security: on-path attackers will be
> able to cause problems, but there is some
> weak protection against off-path attackers.
> This is mostly good enough, I think.

Noted.

> But I suspect there are details that the draft
> did not go into. For instance, wouldn't there
> be a need for a router to tell its peer that
> the router's own addresses have changed? How
> would that be implemented with only Request and
> Reply?

There will be no unsolicited replies. There can't be because you have  
to track
all active ITRs that have spoken to you. That clearly doesn't scale  
and for the most part, what we have proposed is a fairly stateless  
ETR and only a mapping cache based ITR.

Big content providers have told me for client packets coming into  
their server hosts, they do not want to 1) do a EID-to-RLOC mapping  
for returning packets to
clients and 2) don't want to hold a mapping cache entry for a long  
period of time. So they will swap RLOCs when they can (which means  
the client site will
control the return path to some extent).

>>    2.  The default router is configured as an ITR.  It prepends a  
>> LISP
>>        header to the packet, with one of it's RLOCs as the source IP
>>        address and uses the destination EID from the original packet
>>        header as the destination IP address.
> How does the ITR know that it can use LISP
> towards this destination? Is it syntactically
> obvious from the destination EID, is it configured,
> or is it dynamically learned?

Definitely not configured or else k number of EID-prefixes would have  
to be configured, where k, in best case is the number of destination  
ASes.

For starters, you can use either 1) a FIB miss or a 2) default route  
hit as signifying the destination is outside of your AS. Of course,  
you can have ACLs as exception lists and for policy but let's not do  
this later for prototyping.

>>    o  Experiment with mobility to determine if both acceptable
>>       convergence and session survivability properties can be  
>> scalably
>>       implemented to support both individual device roaming and site
>>       service provider changes.
>>
> The draft does not have a lot of other text on mobility.
> I suspect there are details to be worked out... for instance,
> would this be able to provide a rendezvous function
> for simultaneously moving hosts? And it seems to
> preclude talking to legacy hosts while moving.

Well we have to understand the convergence expectations for mobility.  
Of course
when a host is moving and the ETR is swapping locators, the ETR  
doesn't care. For the ITR, it is the same case as the initialization  
sequence since the new ITR may not have an EID-to-RLOC mapping. But  
for now, that is all we want to say.

> And here are also some editorial comments while
> I'm at it:
>>    When a data packet triggers a Reply to be sent, the RLOC  
>> associated
>>    with the EID-prefix matched by the EID in the original packet
>>    destination IP address field will be returned.
> Did you mean "the RLOCs associated ...."? Presumably there
> must be multiple RLOCs per EID or EID prefix.

Yes, thanks, I will fix.

>>    [RFC4423]  Moskowitz, R. and P. Nikander, "Host Identity Protocol
>>               (HIP) Architecture", RFC 4423, May 2006.
>>
> Why was this listed as a normative reference? Were you
> using something from this RFC?

No, just wanted to include references to other solutions.

> Jari

Thanks again,
Dino

_______________________________________________
RAM mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ram

---

From: "Bound, Jim" <[email-masked]>
Date: Thu, 8 Feb 2007 08:04:10 -0500

Dino,

I like very much this technology approach using LISP to resolve RAM
issues.  Great job by you, Dave, and Vince and contribution to the IETF.
Suggest you target stable draft for July Chicago meeting Prague is far
to soon.  Then shift right other time frames.

I hope we can move in this direction and it left doors open for ongoing
and future work esp. for end-to-end.  

A suggestion is make the draft IP version agnostic and yes this will
work with IPv6 on first two general reads.  I am willing to help you do
this if you want the help.

I also believe it is transparent to Mobile IP work and for me that
problem is solved and LISP does not preclude using what we have today,
but will make it more efficient (hand waving here for now yes).

This architecture assumes PI space for all sites is globally in the DNS.
Do you agree with that assumption?

A question will there be any IPR claims on the LISP architecture?

>LISP 1.5:  where EIDs are routable for bootstrapping EID-to-RLOC
>      mappings; such routing is via a separate topology.

Then from EID definition:

>LISP uses PI blocks for EIDs; such EIDs MUST
>      NOT be used as a LISP RLOCs. 

Does the above mean EIDs cannot use PA's?

I believe there are cases within LISP where optimizations are necessary
to reduce the LISP processing at the edge and tunnel processing where
the source packet is capable of simply passing through the LISP site
topology.  I am sure you know the mission critical use cases here so I
will not note them for now. 

Specifically:

>o  End-systems (hosts) only know about EIDs.

I am fine with this but then there may be cases where end-system becomes
intermediate node or something to that effect to address the use cases
for optimizations I reference above. 

This could produce a new set of new type of edge boxes/software in the
market too should we consider those consequences, as discussed under ITR
terminology.

>Some of the design goals of this proposal include:

I think we need to add multi-homing to this set of goals too.

And from PA defintion below:

>Traditionally, IP multihoming has been implemented by each multi-homed
site acquiring 
>its own, globally-visible prefix.  LISP uses only
topologically-assigned and 
>aggregatable address blocks for RLOCs, eliminating this demonstrably
non-scalable 
>practice.

I think the above will assist with the multi-homing problem and suggest
we need section in the draft why that is true.

>Egress Tunnel Router (ETR):   a router that accepts an IP packet
>     where destination address in the "outer" IP header is one of its
>     own RLOCs.  The router strips the "outer" header and forwards the
>     packet based on the next IP header found.  In general, an ETR
>    receives LISP-encapsulated IP packets from the Internet on one
>   side and sends decapsulated IP packets to site end-systems on the
> other side.

Assuming here below the ETR is the last router within a site to forward
a packet to the destination over an Intranet or Internet?

Does not the above assume or state the ETR is sending the End Systems IP
packet which implies the End System IP header prior to ITR knew the
RLOC?   Seems confusing?

Section 4.1 Packet Flow Sequence #3 did not help me?

LISP does not alter the orginal end-systems IP header is my read of the
spec?

>o  EIDs are not expected to be usable for end-to-end communication in
>      the absence of an EID-to-RLOC mapping operation.

But, the end-system should be able to encrypt all but the IP header
(with IPv6 the options are in the clear too) and pass through the ITR
and ETR.  In addtion this gets to the required optimizations above in
certain cases.

>o  EIDs may also be structured (subnetted) in a manner suitable for
>      local routing within an autonomous system.

Suggest change to "EID can also be ...." remove the connotation of "MAY"
above.

I need to spend more time with sections 6,7,8,9,10.  Probably will send
mail if required for each of them individually.

Thanks
/jim

---

From: "Bound, Jim" <[email-masked]>
Date: Sat, 10 Feb 2007 17:57:39 -0500

Hi Dino,

All set but provide clarifications and some stuff I was just missing the
point and thanks for clearing me up.  I think this is pretty awesome
idea and implementation suggestion too.  Will review other sections I
noted to see if I can provide worthwhile input. Some responses in line. 

> Well my personal plan was to have a prototype available for 
> people to play with. So we could say we'll have a stable 
> draft with a matching implementation. By then, I suspect the 
> security design for LISP will be ready as well.

ack that is pretty aggressive thanks.

> 
> > I hope we can move in this direction and it left doors open for 
> > ongoing and future work esp. for end-to-end.
> 
> What do you mean? Is this a general comment or one 
> specifically related to LISP?

General comment.  Bottom line my test for end-to-end is if you and I
want to talk over IM on the net and we want defense in depth we both can
encrypt as peers all but our IP headers and only way we can be attacked
at the IP layer is if a criminal has the money to crack the level of
encryption we use.  Intermeidate nodes between us simply get the packets
to us in the best way they can with the IP header and protect that
packet via DPI, IDP, etc. witihout peeking at TCP or UDP.  Thats all.

> > work with IPv6 on first two general reads.  I am willing to 
> help you 
> > do this if you want the help.
> 
> Sure, I will do this in the second draft. In fact, I am 
> contemplating having "mixed mode mappings" where one could 
> have a v4-EID to v6-RLOC mapping or maybe more useful a 
> v6-EID to v4-RLOC mapping.

Thanks.

> Right. Do you have an opinion if it could be used instead of 
> the mobile-IP work? Just wondering, not really advocating it.

Right now can't type all I want to because of the day job :--).  But I
do believe LISP can extend via the RLOC the scope or diameter of the
networks I roam before I need a new care of address.  I still think we
need the care of address and all that goes with it for global seamless
IP mobility ergo yes we still need Mobile IP but LISP can make it more
efficient.  Glad to on about this in another mail if useful.

> PI or PA. It doesn't assume much from the structure of the 
> address hosts insert in IP headers. But depending on where 
> you put the ITRs and ETRs, there is "internal routing" based 
> on these addresses.

Ack.

> No there will not be. I stated to the IAB that we (or at 
> least I) will attempt to work with the IETF process and keep 
> this work open.

Thank You Very Much it is important we all work like this IMHO it breeds
open systems view from the IETF with honor.

> Right, when we say "routable" we don't necessarily mean on 
> the capital-I Internet. We want to have a data triggered 
> event to avoid packet loss. Remember, the routers don't have 
> the advantage of connection setup, unless we hack TCP-syn 
> snooping in the ITR.

Ack.

> 
> PI blocks are routable today. I realize we want to reduce the 
> amount of PI prefixes in the core and if possible eliminate 
> them altogether.  
> So that is why we indicated we could route these packets (for 
> rare bootstraping cases) on another/smaller/cost-reduced/performance-
> reduced infrastructure.
> 
> They can.

Ack.

> 
> > I believe there are cases within LISP where optimizations are 
> > necessary to reduce the LISP processing at the edge and tunnel 
> > processing where the source packet is capable of simply passing 
> > through the LISP site topology.  I am sure you know the mission 
> > critical use cases here so I will not note them for now.
> 
> Sure, I think you can tag FIB entries. The ones that are 
> tagged are the ones that would get LISP headers appended.

Got it.  Thanks for that education.

> > I am fine with this but then there may be cases where end-system 
> > becomes intermediate node or something to that effect to 
> address the 
> > use cases for optimizations I reference above.
> 
> I saw your reference but please elaborate more on it.

You answered by the tagging above.  If packet is not tagged can I assume
it is not tunneled to the ETR?

> > market too should we consider those consequences, as 
> discussed under 
> > ITR terminology.
> 
> You mean like a NAT?  ;-)

No I don't see LISP causing NAT but could help IPv6 NAP for sure for
transition. Bandwidth Brokers, Deep Packet Inspection Optimizations via
Hardware, new Session Control nodes to support IMS, Streaming, or even
NSIS. 

> Well, it certainly is an indirect goal where if you satisfy 
> the stated goals, you get multi-homing as well. But in the 
> next rev, we will make that more clear.

Ack.

> > I think the above will assist with the multi-homing problem and 
> > suggest we need section in the draft why that is true.
> 
> Okay, will add.

Great maybe if you and authors are comfortable adding that to the
results from LISP would be a valid entry then.

> > Assuming here below the ETR is the last router within a site to 
> > forward a packet to the destination over an Intranet or Internet?
> 
> I can't parse your sentence to know what you really mean. But 
> I can say the ETR is the router that removes the outer LISP 
> header and will then route the packet based on the inner 
> header. If the ETR is directly connected to the destination 
> host, then the destination address is used to do a ARP lookup 
> (after it determines the destination resides on an attached 
> subnet). In other cases, the ETR routes the packet that the 
> IGP can deliver to the destination host.  
> Therefore, the inner address is still routable "inside of the domain".

I was on bad tangent.  I was viewing ITR and ETR in same source node
(EID) network.
Thanks and sorry.

> 
> > Does not the above assume or state the ETR is sending the 
> End Systems 
> > IP packet which implies the End System IP header prior to 
> ITR knew the
> > RLOC?   Seems confusing?
> 
> RLOCs are used for global routing, that is outside of a 
> domain. We formalize it to mean the addresses in "the outer 
> header". The original packet is routed like it is today. So I 
> guess you can say it is a locator within a ETR's scope.

Got it as I said bad tangent on my part, bad coffee :--).

> > LISP does not alter the orginal end-systems IP header is my read of 
> > the spec?
> 
> Correct. But in LISP 1, we use the inner addresses to probe 
> for an EID-to-RLOC mapping.

Ack. I did see that one.

> Yes, definitely.

Ack.

> What do you suggest then? Changing it from "may" to "are"?

"are" would work.

> 
> > I need to spend more time with sections 6,7,8,9,10.  Probably will 
> > send mail if required for each of them individually.
> 
> Cool. Thanks for your comments Jim.

Thanks for your response too.

/jim

---

From: Dino Farinacci <[email-masked]>
Date: Sat, 10 Feb 2007 14:27:55 -0800

> issues.  Great job by you, Dave, and Vince and contribution to the  

Thanks Jim.

> to soon.  Then shift right other time frames.

Well my personal plan was to have a prototype available for people to  
play with. So we could say we'll have a stable draft with a matching  
implementation. By then, I suspect the security design for LISP will  
be ready as well.

> and future work esp. for end-to-end.

What do you mean? Is this a general comment or one specifically  
related to LISP?

> work with IPv6 on first two general reads.  Ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HG0hL-0007lv-Sv
	for [email-masked]; Sat, 10 Feb 2007 17:27:59 -0500
From: Dino Farinacci <[email-masked]>
Subject: Re: [RAM] Re: thoughts on draft-farinacci-lisp-00
Date: Sat, 10 Feb 2007 14:27:55 -0800
To: "Bound, Jim" <[email-masked]>
Cc: [email-masked]

> issues.  Great job by you, Dave, and Vince and contribution to the  

Thanks Jim.

> to soon.  Then shift right other time frames.

Well my personal plan was to have a prototype available for people to  
play with. So we could say we'll have a stable draft with a matching  
implementation. By then, I suspect the security design for LISP will  
be ready as well.

> and future work esp. for end-to-end.

What do you mean? Is this a general comment or one specifically  
related to LISP?

> this if you want the help.

Sure, I will do this in the second draft. In fact, I am contemplating  
having "mixed mode
mappings" where one could have a v4-EID to v6-RLOC mapping or maybe  
more useful a v6-EID to v4-RLOC mapping.

> but will make it more efficient (hand waving here for now yes).

Right. Do you have an opinion if it could be used instead of the  
mobile-IP work? Just wondering, not really advocating it.

> Do you agree with that assumption?

PI or PA. It doesn't assume much from the structure of the address  
hosts insert in IP headers. But depending on where you put the ITRs  
and ETRs, there is "internal routing" based on these addresses.

> A question will there be any IPR claims on the LISP architecture?

No there will not be. I stated to the IAB that we (or at least I)  
will attempt to work with the IETF process and keep this work open.

>>      NOT be used as a LISP RLOCs.

Right, when we say "routable" we don't necessarily mean on the  
capital-I Internet. We want to have a data triggered event to avoid  
packet loss. Remember, the routers don't have the advantage of  
connection setup, unless we hack TCP-syn snooping in the ITR.

PI blocks are routable today. I realize we want to reduce the amount  
of PI prefixes in the core and if possible eliminate them altogether.  
So that is why we indicated we could route these packets (for rare  
bootstraping cases) on another/smaller/cost-reduced/performance- 
reduced infrastructure.

They can.

> necessary

Sure, I think you can tag FIB entries. The ones that are tagged are  
the ones that would get LISP headers appended.

> becomes

You mean like a NAT?  ;-)

> I think we need to add multi-homing to this set of goals too.

Well, it certainly is an indirect goal where if you satisfy the  
stated goals, you get multi-homing as well. But in the next rev, we  
will make that more clear.

> suggest

Okay, will add.

>>   side and sends decapsulated IP packets to site end- am willing to help  
> you do

Sure, I will do this in the second draft. In fact, I am contemplating  
having "mixed mode
mappings" where one could have a v4-EID to v6-RLOC mapping or maybe  
more useful a v6-EID to v4-RLOC mapping.

> but will make it more efficient (hand waving here for now yes).

Right. Do you have an opinion if it could be used instead of the  
mobile-IP work? Just wondering, not really advocating it.

> Do you agree with that assumption?

PI or PA. It doesn't assume much from the structure of the address  
hosts insert in IP headers. But depending on where you put the ITRs  
and ETRs, there is "internal routing" based on these addresses.

> A question will there be any IPR claims on the LISP architecture?

No there will not be. I stated to the IAB that we (or at least I)  
will attempt to work with the IETF process and keep this work open.

>>      NOT be used as a LISP RLOCs.

Right, when we say "routable" we don't necessarily mean on the  
capital-I Internet. We want to have a data triggered event to avoid  
packet loss. Remember, the routers don't have the advantage of  
connection setup, unless we hack TCP-syn snooping in the ITR.

PI blocks are routable today. I realize we want to reduce the amount  
of PI prefixes in the core and if possible eliminate them altogether.  
So that is why we indicated we could route these packets (for rare  
bootstraping cases) on another/smaller/cost-reduced/performance- 
reduced infrastructure.

They can.

> necessary

Sure, I think you can tag FIB entries. The ones that are tagged are  
the ones that would get LISP headers appended.

> becomes

You mean like a NAT?  ;-)

> I think we need to add multi-homing to this set of goals too.

Well, it certainly is an indirect goal where if you satisfy the  
stated goals, you get multi-homing as well. But in the next rev, we  
will make that more clear.

> suggest

Okay, will add.

> forward

I can't parse your sentence to know what you really mean. But I can  
say the ETR is the router that removes the outer LISP header and will  
then route the packet based on the inner header. If the ETR is  
directly connected to the destination host, then the destination  
address is used to do a ARP lookup (after it determines the  
destination resides on an attached subnet). In other cases, the ETR  
routes the packet that the IGP can deliver to the destination host.  
Therefore, the inner address is still routable "inside of the domain".

> packet which implies the End System IP header prior to ITR knew the

RLOCs are used for global routing, that is outside of a domain. We  
formalize it to mean the addresses in "the outer header". The  
original packet is routed like it is today. So I guess you can say it  
is a locator within a ETR's scope.

> the

Correct. But in LISP 1, we use the inner addresses to probe for an  
EID-to-RLOC mapping.

Yes, definitely.

> send

Dino

systems on the
> forward

I can't parse your sentence to know what you really mean. But I can  
say the ETR is the router that removes the outer LISP header and will  
then route the packet based on the inner header. If the ETR is  
directly connected to the destination host, then the destination  
address is used to do a ARP lookup (after it determines the  
destination resides on an attached subnet). In other cases, the ETR  
routes the packet that the IGP can deliver to the destination host.  
Therefore, the inner address is still routable "inside of the domain".

> packet which implies the End System IP header prior to ITR knew the

RLOCs are used for global routing, that is outside of a domain. We  
formalize it to mean the addresses in "the outer header". The  
original packet is routed like it is today. So I guess you can say it  
is a locator within a ETR's scope.

> the

Correct. But in LISP 1, we use the inner addresses to probe for an  
EID-to-RLOC mapping.

Yes, definitely.

> send

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Sat, 10 Feb 2007 23:29:09 -0800

> ack that is pretty aggressive thanks.

Well the idea is fairly simple and we'll prototype a software only  
implementation so I think it is doable.

> packet via DPI, IDP, etc. witihout peeking at TCP or UDP.  Thats all.

Okay.

> it is not tunneled to the ETR?

Right.

> Hardware, new Session Control nodes to support IMS, Streaming, or even

Okay, I will need a verbal explanation of this. Maybe at IETF.

Ack.

> I was on bad tangent.  I was viewing ITR and ETR in same source node

Okay.

Dino

---

From: "Bound, Jim" <[email-masked]>
Date: Sun, 11 Feb 2007 12:45:20 -0500

Dino, ack. Will be at Prague I just made the mental commitment this
weekend (almost the 3rd IETF meeting I would have missed since 1991 just
tired of travel as of late) to travel yet again on planes and will
register so if we can find some time to talk that would be cool. IETF
work is important clearly.

thx
/jim 

> -----Original Message-----
> From: Dino Farinacci [mailto:[email-masked]] 
> Sent: Sunday, February 11, 2007 2:29 AM
> To: Bound, Jim
> Cc: Jari Arkko; [email-masked]
> Well the idea is fairly simple and we'll prototype a software 
> only implementation so I think it is doable.
> 
> > want to talk over IM on the net and we want defense in 
> depth we both 
> > can encrypt as peers all but our IP headers and only way we can be 
> > attacked at the IP layer is if a criminal has the money to 
> crack the 
> > level of encryption we use.  Intermeidate nodes between us 
> simply get 
> > the packets to us in the best way they can with the IP header and 
> > protect that packet via DPI, IDP, etc. witihout peeking at 
> TCP or UDP.  
> > Thats all.
> 
> Okay.
> 
> > You answered by the tagging above.  If packet is not tagged can I 
> > assume it is not tunneled to the ETR?
> 
> Right.
> 
> >> You mean like a NAT?  ;-)
> >
> > transition. Bandwidth Brokers, Deep Packet Inspection Optimizations 
> > via Hardware, new Session Control nodes to support IMS, 
> Streaming, or 
> > even NSIS.
>