Subject: [RAM] Request to advance RFC4214 to Proposed Standard

From: "Templin, Fred L" <[email-masked]>
Date: Sat, 24 Mar 2007 21:36:20 -0700

RFC Editor,

This is a request to advance RFC4214 to Proposed Standard, since
multiple and widely-deployed implementations exist. See:

  http://isatap.com

Fred L. Templin
[email-masked]

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

---

From: "Templin, Fred L" <[email-masked]>
Date: Sat, 24 Mar 2007 22:06:26 -0700

Purusant to my previous message, I would like to specifically
ask that Mark Townsley tender this request as AD sponsor per
RFC3932 (BCP92). Also, please note that there are multiple
interoperable and widely-deployed implementations.

Fred L. Templin

> -----Original Message-----
> From: Templin, Fred L 
> Sent: Saturday, March 24, 2007 9:36 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [RAM] Request to advance RFC4214 to Proposed Standard
> 
> RFC Editor,
>

---

From: Jari Arkko <[email-masked]>
Date: Sun, 25 Mar 2007 09:32:30 +0300

Fred,

Just FYI -- requests to put something on the standards track
go to the ADs, not the RFC Editor. For more information, see
http://www.ietf.org/IESG/content/ions/ion-ad-sponsoring.html

In any case, since you are copying the RAM list I presume that
you think this would work as a solution to routing scalability?
We do indeed have a number of solutions in the lets-cross-the-
internet-by-tunneling space :-) and I too often wonder if a new
tool is going to be very different from the old ones. I would
appreciate some additional thoughts however on why you
believe this works for routing scalability, what its properties
would be, how you would deploy it, etc.

Jari

---

From: "Templin, Fred L" <[email-masked]>
Date: Sun, 25 Mar 2007 01:37:58 -0700

Jari,

Yes, I would appreciate the opportunity to talk openly which has
really not been the case for the many years I have been saddled
with this heavy burden. I have really no doubt that this mechanism
is the "missing link" that would allow for a set of integrated
tools to span the Internet end-to-end and allow for virutally
limitless scaling while reducing core routing table churn and
growth to sub-linear levels. Given the proper mapping function
and tunnel endpoint mobility tools, it would also give global
mobility management and multihoming as natural consequences of
the architecture.

Now, think about how cool all of this sounds - but, then stop and
think about the social ramifications. How would it be, for example,
if anyone on the Internet could connect to anyone else over
encrypted tunnels end-to-end with no opportunity for the network
to block harmful communications. The network could of course throw
up road blocks, but the endpoints could simply pop up somewhere else
and continue their covert and possibly ill-intended communications.
In short, the endpoints could simply route around any network
problem spots and keep on talking unimpeded and undetected - even
if what they were talking about was planning the next major
terrorist attack.

This would be Internet transparency taken to the ultimate level,
but one really does have to stop and ask whether the world is
ready for this? Would it be utopia or anarchy - I'm really hoping
that someone out there could answer that for me. Until that time,
I am suspending my request for standards-track consideration.

Folks have been pretty shy about talking to me for the many years
I have been saddled with this. Is there anything anyone out there
would like to say now?

Thanks - Fred

> From: Jari Arkko [mailto:[email-masked]] 
> Sent: Saturday, March 24, 2007 11:33 PM
> To: Templin, Fred L
> Cc: [email-masked]; [email-masked]; W. Mark Townsley
> Subject: Re: [RAM] Request to advance RFC4214 to Proposed Standard
> 
> Fred,
>

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 25 Mar 2007 11:43:42 +0200

Jari,

Speaking as a long time participant in ngtrans/v6ops,
I believe this request should only be addressed via v6ops,
which, if I recall correctly, has as its established
consensus to progress no more IPv6 coexistence techniques.

I'm not saying that consensus can't be changed, but until
it is, I'd be against AD sponsoring of this request
(without any comment on the merits of this or other
proposed additional coexistence techniques).

     Brian

---

From: Jari Arkko <[email-masked]>
Date: Sun, 25 Mar 2007 12:55:52 +0300

Sure -- the plans and opinions of an existing WG in this
space is an input to a sponsoring decision. But for now I
really just wanted to know why Fred thinks its relevant
for the RAM discussion.

Jari

---

From: Peter Sherbin <[email-masked]>
Date: Sun, 25 Mar 2007 14:28:32 -0700 (PDT)

I believe this very good draft is still a subject to comments and here it goes:

General
1. Both EID and RLOC remain (IP) addresses of dual nature: locator & identifier.
Hence actually there is no Locator/ID separation. 

End User
1. Depends on ISP for RLOCs, the entire notion of PI is negated
2. Extra overhead

ISP and End User
1. Have to introduce 2 more sets of routers: ITP / ETP, which is an extra cost

We may want to continue looking for a clear split between locator and ID, where
locator describes topo location only, while ID uniquely names the object with no
reference to its location. 128-bit IPv6 has enough(?) room to combine both in one
source/destination descriptor.

Thanks,

Peter

____________________________________________________________________________________
Never miss an email again!
Yahoo! Toolbar alerts you the instant new Mail arrives.
http://tools.search.yahoo.com/toolbar/features/mail/

---

From: Dino Farinacci <[email-masked]>
Date: Sun, 25 Mar 2007 15:44:37 -0700

> I believe this very good draft is still a subject to comments and  

Thanks for our comments. And they are certainly not coming too late.

> Hence actually there is no Locator/ID separation.

There is a separation but at the network level and not the stack  
level. Lixia, over last week used the term "multi-level addresses"  
which I think is the case for LISP based EID and Locator terms.

That is, the 'address' has scope depending where the ITR and ETR are  
located in the source and destination site, respectively.

So, if your ITR/ETR are on the first/last-hop routers, then the inner  
"ID addresses" are used simply used as link-local (and as connection  
IDs for the transport layer).

If your ITR/ETR are at the CE edges of site, then the scope of the  
"ID address" is used throughout the site.

But we can say after a packet is tunneled, that the only addresses in  
the outer header are certainly "Locator addresses". And are the ones  
we want to aggregate-optimize in the PE and P routers in the core.

We will make it more clear in the next draft that this separation is  
network-based and has scope.

> 1. Depends on ISP for RLOCs, the entire notion of PI is negated

Yes, well we all depend on ISP address block allocation or else we  
can't send packet globally. If you are a site, not attached to the  
Internet, you can use RFC 1918 addresses, as you do today, to be used  
as both EIDs and Locators within your site scope. If you need  
mobility, you can deploy a LISP ITR and ETR inside of your site, and  
have Locator reachability inside your "site core". But I believe most  
sites won't need to do this. And that is goodness, because you can  
run your network the way you do today, even in the new world of  
separation (or in a "jack-up world").

> 2. Extra overhead

Well yes, the cost of tunneling to get redirection is paid in terms  
of additional header bytes. TANSTAFL.

> 1. Have to introduce 2 more sets of routers: ITP / ETP, which is an  

They are not new routers, they are existing routers with new  
functionality. And as a vendor, I am trying to not require hardware  
changes to deploy the functionality. You will need a new software  
upgrade for the ITR/ETR. Let's see, in practice, if this turns out to  
be true.

> source/destination descriptor.

Well, what we want to do is get site's to have ingress packet traffic  
engineering, get better aggregation in both PE and P routers in the  
core, and to allow ISPs to reroute traffic through other ISPs (ISP- 
based TE). We can do this with this proposal.

These are the requirements and goals we would like to focus on. If,  
at the same time, we get session survivability at any granularity, it  
is a bonus.

Thanks again,
Dino

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 26 Mar 2007 11:53:09 +0200

> upgrade for the ITR/ETR. Let's see, in practice, if this turns out to 

I think there is much more than that.
If you want to perform the TE functionalities that have been described 
in the LISP draft, you need to make the information about the multiple 
locators available for an identifier to the ISP. Such information is 
not available in the packet. So in order to allow the intermediate ISP 
to acutally be able to reroute packet to altenrative locators 
associated to the identifier contained in the inner header of the 
packet, you must let the intermediate ISP discover the alternative 
locator information. I am not sure how you are planning to do this, but 
afict it will need much more infrastrucutre that what currently is 
described in the draft.

am i missing something?

regards, marcelo

> core, and to allow ISPs to reroute traffic through other ISPs 
> (ISP-based TE). We can do this with this proposal.
>
> These are the requirements and goals we would like to focus on. If, at 
> the same time, we get session survivability at any granularity, it is 
> a bonus.
>
> Thanks again,
> Dino
>

---

From: JFC Morfin <[email-masked]>
Date: Mon, 26 Mar 2007 16:20:32 +0200

Marcelo,
I strongly oppose to that. For three major reasons:

1) the internal packet may not be a TCP/IP packet (or a crypted 
TCP/IP packet). This is why LISP is adequate to support 
multitechnology systems.
2) LISP permits the user to build and force his own routing strategy. 
And to go through secure nodes (along his own criteria).
3) depending on the final destination or on the content the ISP could 
apply its own multi-tier strategy.

This is why I tink the re-EIN concept should be reviewed together 
with multi-level addressing and revived NIMROD topology report - 
including information for LISP (and may be an addition to the DNS to 
indicate the real nature of a given IP).
jfc

At 11:53 26/03/2007, marcelo bagnulo braun wrote:

>>upgrade for the ITR/ETR. Let's see, in practice, if this turns out to be true.
>
>If you want to perform the TE functionalities that have been 
>described in the LISP draft, you need to make the information about 
>the multiple locators available for an identifier to the ISP. Such 
>information is not available in the packet. So in order to allow the 
>intermediate ISP to acutally be able to reroute packet to 
>altenrative locators associated to the identifier contained in the 
>inner header of the packet, you must let the intermediate ISP 
>discover the alternative locator information. I am not sure how you 
>are planning to do this, but afict it will need much more 
>infrastrucutre that what currently is described in the draft.
>
>am i missing something?
>
>
>regards, marcelo
>
>
>>Well, what we want to do is get site's to have ingress packet 
>>traffic engineering, get better aggregation in both PE and P 
>>routers in the core, and to allow ISPs to reroute traffic through 
>>other ISPs (ISP-based TE). We can do this with this proposal.
>>
>>at the same time, we get session survivability at any granularity, 
>>it is a bonus.
>>
>>Thanks again,
>>Dino
>>

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 26 Mar 2007 16:54:12 +0200

El 26/03/2007, a las 16:20, JFC Morfin escribió:

> Marcelo,
> I strongly oppose to that.

i am not following you... exactly you strongly oppose to what?

regards, marcelo

>  For three major reasons:
>
> 1) the internal packet may not be a TCP/IP packet (or a crypted TCP/IP 
> packet). This is why LISP is adequate to support multitechnology 
> systems.
> This is why I tink the re-EIN concept should be reviewed together with 
> multi-level addressing and revived NIMROD topology report - including 
> information for LISP (and may be an addition to the DNS to indicate 
> the real nature of a given IP).
> jfc
>
>> intermediate ISP to acutally be able to reroute packet to altenrative 
>> locators associated to the identifier contained in the inner header 
>> of the packet, you must let the intermediate ISP discover the 
>> alternative locator information. I am not sure how you are planning 
>> to do this, but afict it will need much more infrastrucutre that what 
>> currently is described in the draft.
>>
>> am i missing something?
>>
>>
>> regards, marcelo
>>
>>
>>> traffic engineering, get better aggregation in both PE and P routers 
>>> in the core, and to allow ISPs to reroute traffic through other ISPs

---

From: JFC Morfin <[email-masked]>
Date: Mon, 26 Mar 2007 17:55:59 +0200

>i am not following you... exactly you strongly oppose to what?

Dear Marcelo,
I oppose to considering as a must what is for me a major security 
violation: "to allow the intermediate ISP to acutally be able to 
reroute packet to altenrative locators associated to the identifier 
contained in the inner header of the packet, you must let the 
intermediate ISP discover the alternative locator information"
Or did I miss another position you expressed?
Cheers.
jfc

>>2) LISP permits the user to build and force his own routing 
>>strategy. And to go through secure nodes (along his own criteria).
>>3) depending on the final destination or on the content the ISP 
>>could apply its own multi-tier strategy.
>>
>>including information for LISP (and may be an addition to the DNS 
>>to indicate the real nature of a given IP).
>>jfc
>>
>>>>functionality. And as a vendor, I am trying to not require 
>>>>hardware changes to deploy the functionality. You will need a new 
>>>>software upgrade for the ITR/ETR. Let's see, in practice, if this 
>>>>turns out to be true.
>>>
>>>described in the LISP draft, you need to make the information 
>>>about the multiple locators available for an identifier to the 
>>>ISP. Such information is not available in the packet. So in order 
>>>to allow the intermediate ISP to acutally be able to reroute 
>>>packet to altenrative locators associated to the identifier 
>>>contained in the inner header of the packet, you must let the 
>>>intermediate ISP discover the alternative locator information. I 
>>>am not sure how you are planning to do this, but afict it will 
>>>need much more infrastrucutre that what currently is described in the draft.
>>>
>>>am i missing something?
>>>
>>>
>>>regards, marcelo
>>>
>>>
>>>>These are the requirements and goals we would like to focus on. 
>>>>If, at the same time, we get session survivability at any 
>>>>granularity, it is a bonus.
>>>>
>>>>Thanks again,
>>>>Dino
>>>>

---

From: Peter Sherbin <[email-masked]>
Date: Mon, 26 Mar 2007 11:27:10 -0700 (PDT)

You will need a new software  
> upgrade for the ITR/ETR. Let's see, in practice, if this turns out to  

Yes as per the design goals LISP is clearly non-disruptive.

Thanks,

Peter

---

From: MARCELO BAGNULO BRAUN <[email-masked]>
Date: Mon, 26 Mar 2007 21:44:41 +0200

> Or did I miss another position you expressed?

i am not taking any position w.r.t. if this is a good idea or not. My 
point is that IF you want to enable the TE tools proposed in the LISP 
draft, you need to provide the information about the alternative 
locators associated to the identifier contained in the inner header to 
the intermediate ISP, and that this would imply additional mechanisms 
to be deployed in the intermediate ISP

I am not taking any position whether this is a good idea or not, just 
trying to understand what is needed to provide the TE capabilities 
described in the LISP draft

Since these mechanisms to distribute the altenrative locator 
information associated to an identifier are not described in the LISP 
draft, i am wondering if i am missing something

regards, marcelo

-- 
----
MARCELO BAGNULO BRAUN
WebCartero
Universidad Carlos III de Madrid

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 26 Mar 2007 14:28:37 -0700

> information is not

If the ISP needs the mappings it could get it, but according to the  
draft, the TE-ITR will look at outer headers and if the site ITR had  
prepended a header, the outer DA at the TE-ITR is a locator address.

In the ISP's case, an equivalence class of prefixes will be  
associated with the TE-ITR's encapsulation. And this would be mostly  
static in nature.

> am i missing something?

The TE-ITR will not look at the inner header but the DA in the outer  
header against it's own database which is policy configured.

Dino

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 27 Mar 2007 10:16:11 +0200

> prepended a header, the outer DA at the TE-ITR is a locator address.

ok, so in this case the intermediate ISP should know that two (or more) 
locators are equivalent (i.e. they are associated to the same 
identifier (or potentially set of identifiers)), right?

> In the ISP's case, an equivalence class of prefixes will be associated 
> with the TE-ITR's encapsulation. And this would be mostly static in 
> nature.
>

So, if i understand correctly an equivalence class of locators are all 
the locators associated to an identifier (or a set of identifiers). In 
particular, in the case of a multihomed site, an equivalence class is 
the set of RLOC (i.e. of PA addresses) that are associated to the site, 
right?

in this case, i agree with the mostly static nature.

But in any case, the intermediate ISP should be able to discover the 
classes of equivalence of locators, i.e. all the locator sets that have 
been associated to each multihomed site. I agree this could be done 
manually, but i am not sure whether having to manually configure all 
the sets of PA addresses associated to each multihomed site will be an 
acceptable solution for a big ISP. I mean, we are saying that there 
will be thousands of multihomed sites, right? I think some mechanisms 
for automatically distributing the equivalemnce class information to 
the intermediate ISPs will be needed if we want to make this 
practical... for instance a parallel instance of BGP distributing this 
information...

regards, marcelo

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 27 Mar 2007 09:06:28 -0400

Hi All,

I've been thinking about the incremental deployment of LISP, and I'm  
having trouble understanding what people mean by that...

LISP does define 4 LISP "variants"-- one where both EIDs and RLOCs  
are globally routable, one where ICMP is used for the mapping from  
EIDs to RLOCs, one where DNS is used for that mapping, and one where  
another mechanism (TBD) is used.  However, I don't understand how any  
of those variants can be deployed incrementally.

In each of the LISP variants, traffic sent from a LISP-enabled  
network will travel through a LISP ITR where it will be encapsulated  
in an additional IP header containing one or two RLOCs.  It is  
necessary for that traffic to travel through a LISP ETR on the  
receiving end, in order to have the outer header removed before it is  
forwarded to the final destination.

End-nodes in LISP-enabled networks will not be able to communicate  
directly with end-nodes in non-LISP-enable networks, because non-LISP- 
enabled networks will not have ETRs at their borders to remove the  
additional IP header. So, it isn't actually possible to deploy LISP  
at the border of one end-user site or ISP network at a time  (which  
is what I would consider incremental deployment); LISP can only be  
deployed in topologically closed regions of the Internet that are  
completely surrounded by LISP ETRs.  We wouldn't see any DFZ route  
scaling benefits until the DFZ was entirely contained within a LISP  
region.

The four variants would only seem to complicate deployment, IMO,  
because as various LISP regions join together, you would need to  
consider whether they are using the same LISP variant or not.

Thoughts?

Margaret

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 27 Mar 2007 13:09:33 -0700

Sorry to have left this thread hanging, but this discussion
has been moved over to the v6ops list.

Thanks - Fred

> Sent: Sunday, March 25, 2007 2:56 AM
> To: Brian E Carpenter
> Cc: Templin, Fred L; [email-masked]; [email-masked]

---

From: Russ White <[email-masked]>
Date: Wed, 28 Mar 2007 11:59:49 -0400

> apply its own multi-tier strategy.

These two are contradictory.....

I can build a tunnel that forces my traffic to go along a specific path.
Anyone along the path can, in turn, build a tunnel forcing my traffic to
go along a different path.

In general, path selection should not be a component of any security
architecture, IMHO.

Even if you turn this into a traffic engineering problem and solution,
you have to remember that anyone in your path can destroy your traffic
engineering with their traffic engineering. I actually think this is one
of the "problems" we are trying to handle here, but it's "under the
covers," in a sense, because the focus is on the table size, rather than
the TE--but, from what I'm hearing, the table size is a direct result of
the longest match routing traffic engineering that's being used today.

:-)

Russ

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 29 Mar 2007 10:36:32 -0700

>> If the ISP needs the mappings it could get it, but according to  
>> the draft, the TE-ITR will look at outer headers and if the site  
>> ITR had prepended a header, the outer DA at the TE-ITR is a  
>> locator address.
>>
>
> ok, so in this case the intermediate ISP should know that two (or  
> more) locators are equivalent (i.e. they are associated to the same  

I don't know what you mean. The TE-ITR only needs to route on the  
outer DA so it would only need a FIB route that the DA would match.

>> associated with the TE-ITR's encapsulation. And this would be  
>> mostly static in nature.
>>
>
> So, if i understand correctly an equivalence class of locators are  
> all the locators associated to an identifier (or a set of  
> identifiers). In particular, in the case of a multihomed site, an  
> equivalence class is the set of RLOC (i.e. of PA addresses) that  
> are associated to the site, right?

No, it is the same way an ISP routes data for a set of prefixes  
across an IGP shortcut MPLS LSP.

This is the same problem just using an IP tunnel to move large number  
of flows from going to one egress point to another.

> But in any case, the intermediate ISP should be able to discover  
> the classes of equivalence of locators, i.e. all the locator sets  
> that have been associated to each multihomed site. I agree this  
> could be done

We need to be clear here. We are talking about TE "inside a set of  
ISPs". So the TE-ITR would/could be the first-hop ISP and the TE-ETR  
could be at any transit ISP to get the packet to where the first LISP  
header says it should go.

> manually, but i am not sure whether having to manually configure  
> all the sets of PA addresses associated to each multihomed site  
> will be an acceptable solution for a big ISP. I mean, we are saying  
> that there will be

I am not suggesting that.

> thousands of multihomed sites, right? I think some mechanisms for  
> automatically distributing the equivalemnce class information to  
> practical... for instance a parallel instance of BGP distributing  
> this information...

Understand.

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 29 Mar 2007 11:06:21 -0700

> EIDs to RLOCs, one where DNS is used for that mapping, and one  
> where another mechanism (TBD) is used.  However, I don't understand  
> how any of those variants can be deployed incrementally.

LISP 1 can be deployed by adding either new boxes that do the ITR and  
ETR function or by configuring existing boxes, with a software  
upgrade, to do the ITR and ETR functions. The IDs are routable here  
so it is assumed those routes are in BGP today. What LISP 1 buys you is:

     1) Inserting a level of indirection (jack-up).
     2) Gives us experience with doing a Locator/ID split.
     3) Determine how dynamic a locator reachability algorithm will  
behave.
     4) Will on-demand caching of EID-to-RLOC and triggered mapping  
replies
        be sufficient to scale.

LISP 1.5 gives you all the benefits of LISP 1 but the routable IDs  
can happen on another topology. Thereby allowing you to remove the  
routes that the IDs needed in LISP 1 to route on, from the BGP core.  
What LISP 1.5 buys you is:

     1) Experience with allocating PI to sites but to not carry them in
        the BGP core. They would be carried in another topology.
     2) We can get experience with aggregating EID-prefixes which now  
has
        no dependence on topology. This can give us data to determine  
the
        size, scope, and scale of a LISP 3 solution.

LISP 2 allows a non-triggered approach by using a request/reply  
interface. By not adding any new infrastructure, it forces us to use  
the only scalable database we know about, that is DNS. The  
disadvantage of using DNS is:

     1) Routing depends on directory and directory depends on routing.
     2) RTT latency when doing the lookup.
     3) Packet drops while waiting for reply to come into the ITR.

LISP 2 *could* be a non-starter, but documented for completeness.

LISP 3 allows us to be innovative and build something new that can  
scale to the requirements specifically for a Locator/ID split. So DNS  
and BGP are explicitly avoided and we give into building a new  
database. If we build a new database, we could have:

     1) The mappings already stored in the ITRs so there is no packet  
drops
        and no latency.
     2) We can secure the mapping database at the same time we figure  
out
        how to do the mapping distribution. Then we don't need an  
explicit
        PKI, we could make the distribution peering infrastructure store
        keys.
     3) We keep the design simple (meaning we don't have to  
bastardize an
        existing mechanism to give us what we want, i.e. BGP), and we  
build
        in "lessons learned" from doing protocol design before.
     4) We make it integrated in the sense to support both IPv4 and  
IPv6.

> network will travel through a LISP ITR where it will be  
> encapsulated in an additional IP header containing one or two  
> RLOCs.  It is necessary for that traffic to

When you prepend a new header, exactly one locator is put in the DA  
field.

> travel through a LISP ETR on the receiving end, in order to have  
> the outer header removed before it is forwarded to the final  
> destination.

Right.

> directly with end-nodes in non-LISP-enable networks, because non- 
> LISP-enabled networks will not have ETRs at their borders to remove  
> the additional IP header.

Correct. But an ITR will know if there is an ETR in the site.  
Otherwise, it has no locator address to encapsulate to.

In LISP 1 and 1.5, when the inner DA is copied to the outer DA in the  
ITR and there is no ETR, the destination host will return an ICMP  
Protocol Unreachable message.

In LISP 2 and 3, the ITR knows there is no ETR so the packet is  
routed natively and assumed the destination site's prefix is in the  
BGP core.

> So, it isn't actually possible to deploy LISP at the border of one  
> end-user site or ISP network at a time  (which is what I would  
> consider incremental deployment); LISP can only be deployed in  
> topologically closed regions of the Internet that are completely  
> surrounded by LISP ETRs.  We wouldn't see any DFZ route scaling  
> benefits until the DFZ was entirely contained within a LISP region.

Do you still think so from my defense above?

> because as

We are not saying all 4 will be deployed. I envision this to be the  
roll-out sequence:

o Prototype and "pilot deploy" LISP 1 and 1.5. Doing one  
implementation gets
   you both variants.
o LISP 2 will probably not be used and thrown away.
o LISP 3 will be developed to use DHTs or a push mechanism.

As we deploy the LISP 3 variant, we will not be able to route IDs on  
the native core since we'll be removing prefixes from the BGP core.  
If we cannot
retrieve the mappings via the LISP 3 mechanism, we could route the ID  
on the non-congruent topology ala LISP 1.5.

If LISP 3 proves to work well, we can remove the alternate topology  
of LISP 1.5. It's hard to say this will be reality but we can all  
count on learning a lot along the way.

Make more sense?

Dino

---

From: Roland Dobbins <[email-masked]>
Date: Thu, 29 Mar 2007 11:13:10 -0700

On Mar 29, 2007, at 11:06 AM, Dino Farinacci wrote:

> The disadvantage of using DNS is:
>

4) The global DNS infrastructure wasn't designed/implemented to  
handle this kind of requirement, it's neither fast nor reliable  
enough, IMHO (works pretty well for its intended purpose, but DNS is  
a 'behind the scenes' kind of thing which is often neglected and  
certainly can't be made front-and-center as a requirement for routing).

The mechanisms used for mappings in LISP or any other proposal should  
be contained within the network infrastructure and simply cannot have  
a dependency upon any other external system, IMHO.

-----------------------------------------------------------------------
Roland Dobbins <[email-masked]> // 408.527.6376 voice

         Words that come from a machine have no soul.

                       -- Duong Van Ngo

---

From: David Meyer <[email-masked]>
Date: Thu, 29 Mar 2007 13:32:59 -0800

> certainly can't be made front-and-center as a requirement for routing).

	Ever looked at a NAPTR record? In any event, I'm not in
	favor of using DNS as an auxillary rouing database, but
	it is happing (at least at the application routing
	level). Sort of suggests that a more general database
	functionality might be needed/missing.

> a dependency upon any other external system, IMHO.

	"No circular dependencies" -- A long held Internet
	design principle dating back to Postel (or maybe
	before). 

	--dmm

---

From: Russ White <[email-masked]>
Date: Thu, 29 Mar 2007 17:36:21 -0400

> 	functionality might be needed/missing.

Which begs the question--is the root of the problem the current
structure of DNS, perhaps? Is it worth looking at something to replace
DNS, rather than something to shim between DNS and IP?

> 	design principle dating back to Postel (or maybe

This rules out any sort of locator/id split that doesn't use a push
model of locator/id mapping, I think.

:-)

Russ

---

From: Roland Dobbins <[email-masked]>
Date: Thu, 29 Mar 2007 14:42:37 -0700

> DNS, rather than something to shim between DNS and IP?

If it's DNS or X.500 or LDAP or whatever -completely self-contained  
within the network infrastructure itself, fine, no problem-.  It  
can't be siloed off to separate general-purpose computers/applicances  
adminned by groups distinct from the network operations staff, nor  
can the network operations staff be expected admin separate general- 
purpose computers or appliances.

                       -- Duong Van Ngo

---

From: David Meyer <[email-masked]>
Date: Thu, 29 Mar 2007 13:45:20 -0800

> purpose computers or appliances.

	cf. infrastructure ENUM (let's not go there).

	--dmm

---

From: Pekka Savola <[email-masked]>
Date: Fri, 30 Mar 2007 08:23:38 +0300 (EEST)

On Thu, 29 Mar 2007, Dino Farinacci wrote:
> In LISP 1 and 1.5, when the inner DA is copied to the outer DA in the ITR and 
> there is no ETR, the destination host will return an ICMP Protocol 
> Unreachable message.

What are the fallbacks if:

a) A transit router has no route to the destination for whatever
    reasons, but does have a default discard route and does not
    generate ICMP errors for packets which match that route?
    [personally I don't think this is necessarily a very serious
    problem because this happens with current routing as well]

b) the destination implementation just doesn't send out Protocol
    Unreachables for unknown protocols? (not sure how common this is)

c) the destination (host?) is currently rate-limiting ICMP error
    generation (mandated by the specification) and the ICMP error is
    not sent?  [e.g., this is why you couldn't build this ICMP error
    generation dependency between two routers either; routers are
    actually even more busy with their ICMP error generation and more
    likely to  not send the error]

d) some poor firewall or ACL filters out the ICMP message at the ICMP
    originator's domain, in transit, or at the recipient's domain?

e) the ICMP error gets lost in the network (transient routing loop,
    congestion, etc.).  ICMP delivery is after all unreliable.

While participating in Transport Area working groups (e.g., TCPM) I've 
had an.. opportunity to hear rants about ICMP, for example, that it 
should be considered completely optional and anything that requires 
ICMP to work is broken; at best, ICMP should be an optimization 
mechanism.

I'm not sure if I completely agree with these, but for sure I wouldn't 
built a system that had a very strong requirement for ICMP error 
generation and propagation.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 30 Mar 2007 11:04:55 +0200

> outer DA so it would only need a FIB route that the DA would match.

agree
the question is where does the information about the equivalent 
destinations comes from

>> equivalence class is the set of RLOC (i.e. of PA addresses) that are 
>> associated to the site, right?
>
> No, it is the same way an ISP routes data for a set of prefixes across 
> an IGP shortcut MPLS LSP.
>

> of flows from going to one egress point to another.

right, so what is the benefit added by LISP?

I mean you can do tunnels to change large amount of flows within a set 
of ISPs today, without LISP right?

I understood that the benefit provided by LISP is that you would be 
able to do this autmatically because the intermediate ISP would be able 
to learn the equivalent classes of locators automatically without 
needing to do any manual configuration, but it seems this is not the 
case...

Regards, marcelo

---

From: Dino Farinacci <[email-masked]>
Date: Sat, 31 Mar 2007 01:13:00 -0700

>> In LISP 1 and 1.5, when the inner DA is copied to the outer DA in  
>> the ITR and there is no ETR, the destination host will return an  
>> ICMP Protocol Unreachable message.
>

If ICMP messages are not returned, the ITR cannot detect  
unreachability. If you try to solve this by having the ITR poll,  
there will be too many messages and it won't scale.

>    Unreachables for unknown protocols? (not sure how common this is)

This would look just like an ETR or a transit router not returning  
any ICMP messages. There is not much you can do. You *could* monitor  
return traffic if you have path symmetry.

>    likely to  not send the error]

The Internet is best-effort, we are not trying to make datagram  
delivery more reliable. If a EID mapping has multiple locators and  
the ETR indicates the priority of each locator is the same, the ITR  
can load-split traffic among the locators.

>    originator's domain, in transit, or at the recipient's domain?

The protocol needs feedback. If you choose UDP to return the mapping  
or error message, those could get filtered as well. There is no magic  
here, you have to fix the filters.

If we let these things get in the way, nothing will be able to get  
deployed.

>    congestion, etc.).  ICMP delivery is after all unreliable.

Oh well, would you rather have a TCP connection between active ITR/ 
ETR pairs, I don't think so.

ARP requests and replies are unreliable.
DNS requests and replies are unreliable.
SNMP packets are unreliable.

We have lived with this. The Internet is best-effort and I think it  
does a good job of being "best".

> While participating in Transport Area working groups (e.g., TCPM)  
> I've had an.. opportunity to hear rants about ICMP, for example,  
> that it should be considered completely optional and anything that  
> requires ICMP to work is broken; at best, ICMP should be an  
> optimization mechanism.

What would you suggest as an alternative that won't have the same  
issues?

> I'm not sure if I completely agree with these, but for sure I  
> wouldn't built a system that had a very strong requirement for ICMP  
> error generation and propagation.

The messages were defined originally to be of value. Yes, they have  
been abused over the years, but the intent of the original designers  
was to help the network. The LISP authors plan to continue to use ICMP.

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Sat, 31 Mar 2007 01:18:56 -0700

>>> more) locators are equivalent (i.e. they are associated to the  
>>> same identifier (or potentially set of identifiers)), right?
>>

Still can't understand what you are asking.

>> This is the same problem just using an IP tunnel to move large  
>> number of flows from going to one egress point to another.
>>
>

Not all ISPs use MPLS. They want to keep OpEx down, so less protocols  
allow them to do that.

You might want to do TE between ISP A and ISP C, where ISP B is  
between them. MPLS isn't used across ASes.

> I mean you can do tunnels to change large amount of flows within a  
> set of ISPs today, without LISP right?

This is true. But they could use a mapping agent to make it more  
dynamic than what they now. Today, they *could* use GRE tunnels and  
run BGP over them as well.

> able to do this autmatically because the intermediate ISP would be  
> able to learn the equivalent classes of locators automatically  
> without needing to do any manual configuration, but it seems this  
> is not the case...

It can be dyanmic with respect to having ETRs configured with  
mappings that steer traffic to a new set of locators.

Dino

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sat, 31 Mar 2007 11:22:46 +0200

> Still can't understand what you are asking.

i see, maybe we have different assumptions...

In order to do TE based on tunnels, the router that is doing that, must 
be able to decide that all packets with destination address IPA should 
be forwarded through the tunnel with destination address IPB.

For example, if we have a multihomed site with RLOC IPA and IPB, an 
intermediate router could try to do some TE and tunnel all packets 
going to IPA into a tunnel going to IPB. This is similar to what they 
do today, by selecting one or the other route announced by BGP by the 
multihomed site

so, in order to do this tunnel, the router must know that IPA and IPB 
are two locators that can be used to reach the multihomed site, and 
then configure the tunnel

my question is how does the router in the intermediate ISP learns that 
IPA and IPB are two locators of the multihomed site?

Please note that there are other criteria to select the inner and outer 
destiantion addresses of the TE tunnel, and this is one example, but in 
any case, the intermediate ISP must somehow learn what address/prefixes 
match in order to perform the TE tunnelling

If this is done manually, my point is that you can do this today, by 
manually configuring tunnels, so i don't understand what LISP is adding 
to all this... more below...
> dynamic than what they now.

exactly

do this mapping agent is part of LISP?
how does this mapping agent learns the tunnel configurations?

> Today, they *could* use GRE tunnels and run BGP over them as well.
>
>> without needing to do any manual configuration, but it seems this is 
>> not the case...
>
> It can be dyanmic with respect to having ETRs configured with mappings 
> that steer traffic to a new set of locators.
>

exactly
but in this case, they must be able to learn dynamically which 
addresses match with which address, so they can create the tunnels 
dynamically

Regards, marcelo

PS: I will on the road for a few days, so i am not sure if i will be 
able to read email, but fwiw, i think this is one fundamental part of 
the puzzle that is lacking in all available solutions

---

From: Tony Li <[email-masked]>
Date: Sat, 31 Mar 2007 09:23:16 -0700

On Mar 31, 2007, at 2:22 AM, marcelo bagnulo braun wrote:

> i think this is one fundamental part of the puzzle that is lacking  
> in all available solutions

I'm not yet convinced that this is really a requirement.  Consider  
what you're asking: the ability to TE on a per-site basis, given that  
traffic is already assigned to PA prefixes.  Typically in the past,  
ISPs have wanted to do TE within another providers prefix, and thus  
we have more specifics.  This is incredibly important for managing  
peering ratios and the like.  However, applying TE on multi-homed PI  
sites seems like it would be much less important requirement.

Am I confused?  Any operators in the forum, please speak up...

Tony

---

From: MARCELO BAGNULO BRAUN <[email-masked]>
Date: Sat, 31 Mar 2007 21:17:53 +0200

> sites seems like it would be much less important requirement.

but this seems to be the only difference from the operator perspective, 
between a PI-BGP based multihoming solution and a multihoming solution 
based on PA and an host based mechanism like HIP or shim.

since the ISPs claim that there is some TE functionalities missing, it 
zould be important to understand what are those so ze can actually 
provide those...

regards, marcelo

---

From: Tony Li <[email-masked]>
Date: Sat, 31 Mar 2007 16:18:22 -0700

>> I'm not yet convinced that this is really a requirement.   
>> Consider  what you're asking: the ability to TE on a per-site  
>> basis, given that  traffic is already assigned to PA prefixes.   
>> Typically in the past,  ISPs have wanted to do TE within another  
>> providers prefix, and thus  we have more specifics.  This is  
>> incredibly important for managing  peering ratios and the like.   
>> However, applying TE on multi-homed PI  sites seems like it would  
>> be much less important requirement.
>
> but this seems to be the only difference from the operator  
> perspective, between a PI-BGP based multihoming solution and a  
> multihoming solution based on PA and an host based mechanism like  
> HIP or shim.

Not necessarily.  Consider an ITR/ETR co-located with a PE router.   
That's very interesting from an operator perspective as they can then  
effectively change locators for a site without site intervention.

> since the ISPs claim that there is some TE functionalities missing,  
> it zould be important to understand what are those so ze can  
> actually provide those...

I agree.   Moreover, it's important that we confirm that the features  
that we are providing are those that are beneficial.

Tony

---

From: Ross Callon <[email-masked]>
Date: Sat, 31 Mar 2007 21:31:37 -0400

At 04:18 PM 3/31/2007 -0700, Tony Li wrote:
>...Not necessarily.  Consider an ITR/ETR co-located with a PE router.

I apologize for repeating myself, but I haven't seen an answer to this...

Several of the PE routers that I have been looking at recently (from
multiple vendors) seem to have a data plane that operates at a rate
that is a small number of hundreds of gigabits per second. They have
a link from the data plane to the central processor that is in many
cases perhaps 100Mbps (1,000 times slower). The link could of
course be a gigabit Ethernet. However it appears that the central
processor can't receive a constant stream even of 100Mbps of traffic.
Trying to figure out how fast the central processor can actually
gobble up (ie, process properly) incoming traffic is a bit more
complex, and the answer seems to be "it depends, but a few tens
of megabits seems reasonable".

Thus there seem to be several possibilities if LISP is going to be
deployed on PE routers:

  (1) You are going to make the data plane MUCH slower; or
  (2) You are going to very lightly load the data plane; or
  (3) You are going to implement the control aspects of LISP
     somewhere other than on the central processor; or
  (4) You are going to build routers whose central processor is
     several orders of magnitude faster than on current routers; or
  (5) You feel that you can implement LISP on a PE router
     with a load on the control plane which is at least 10,000
     times smaller than the load on the data plane (so that each
     time a packet goes to the control plane, on the average there
     are 10,000 or more packets that will be forwarded via the data
     plane before the next packet needs to go to the control plane)

I am guessing that the answer is either (5), or perhaps (3), or
   (6) You are going to deploy LISP closer to the edge (and NOT
     in the PE router).

However, I haven't seen a discussion of this point (my apology
if I just missed it, there is of course a LOT of traffic on RAM,
and strangely enough there is also other work to be done).

Thanks, Ross

---

From: Bruce Curtis <[email-masked]>
Date: Sat, 31 Mar 2007 21:56:25 -0500

I had been thinking similarly, the architecture of LISP (or any  
proxy or middlebox solution that has to create a cache or state based  
on all traffic) reminds me of IGMP v2.  A problem with IGMP v2 is  
that the switch must snoop at all of the packets from high bandwidth  
applications like Norton Ghost etc in order to find the few IGMP  
reports or joins in the stream.  In IGMP v3 on the other hand the  
switch can look at another stream or multicast group that is  
specifically designed for requests to create state (join or leave a  
group).

> and strangely enough there is also other work to be done).

---
Bruce Curtis                         [email-masked]
Certified NetAnalyst II                701-231-8527
North Dakota State University