Re: [RAM] New LISP draft available ...

Scott,

On 2007-07-25 14:24, Scott Brim wrote:
> I didn't see a reply from Dino so ...
> 
> On 07/22/2007 17:40 PM, Brian E Carpenter allegedly wrote:
>> General points that aren't mentioned and perhaps should be:
>>
>> MTU size reduction
>> Fragmentation (in IPv4)
>> Referrals (host A passes an address for host B to host C)
> 
> This kind of thing is a reason for maintaining current "address"
> behavior.  What host A passes will be what host B believes its address
> is, and what the LISP system considers to be B's EID.

Sure, but it should be said.

> 
>>> 4.1.  Packet Flow Sequence
>> ...
>>>    1.  host1.abc.com wants to open a TCP connection to host2.xyz.com.
>>>        It does a DNS lookup on host2.xyz.com.  An A record is returned.
>>>        This address is used as the destination EID and the locally-
>>>        assigned address of host1.abc.com is used as the source EID.  An
>>>        IP packet is built using the EIDs in the IP header and sent to
>>>        the default router.
>> 'default router' seems wrong (it would typically be understood to
>> mean the default router on the host's LAN). Doesn't this mean
>> 'a site egress router' (which is ingress to the LISP domain)?
> 
> This is from the point of view of the originating endpoint, so it's
> not the site egress router.  Whatever it uses to get its packets
> forwarded to the destination -- probably a "default" router, but
> technically "next hop router" is probably better.

Yes, but the next line says:
     2.  The default router is configured as an ITR.
Are you saying that all next hop routers are ITRs? I would
have thought that only site egresses would be ITRs.

> 
>> In 6.1.1 and elswhere you give RFC2434 as a reference for
>> AFIs. There's nothing about AFIs in that RFC; in fact AFI documentation
>> is a bit of a mystery.
> 
> Got a better reference?  All I know is BGP docs.

OK, look at the first page of http://www.iana.org/numbers.html
There is now a registry (I think I looked once before and
couldn't find it).

     Brian

_______________________________________________
RAM mailing list
RAM@iab.org
https://www1.ietf.org/mailman/listinfo/ram