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

From: [email-masked]
Date: Thu, 8 Feb 2007 08:45:16 EST

And let me add another favoring aspect:
The ETR would also be a perfect fit for being a CTR (cascade tree router)  by 
which DDoS attacks could be outsmarted and become ineffective as I pointed  
out by some prevous email (to arch-d I think).
 
Heiner
 
In einer eMail vom 08.02.2007 14:05:28 Westeuropäische Normalzeit schreibt  
[email-masked]:

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

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

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

---

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

> The ETR would also be a perfect fit for being a CTR (cascade tree  
> router) by which DDoS attacks could be outsmarted and become  
> ineffective as I pointed out by some prevous email (to arch-d I  
> think).

Thanks for the kind words. Could you explain what you mean by  
outsmarting DDos attacks in the ETR?

Dino

---

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

Dino