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

On 2007-07-17 19:56, Dino Farinacci wrote:
> We have a new LISP-02 draft available. The packet formats are consistent 
> with CONS-01 as well as the implementation we are testing.
> 
> The draft has been submitted to the ID directory, but you can find a 
> draft at:
> 
>     http://www.dinof.net/~dino/ietf/draft-farinacci-lisp-02.txt

A few comments on this version...

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)

 > 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)?

 > 5.3.  Tunnel Header Field Descriptions
...
 >    o  The OH header Time to Live field MUST be copied from the IH header
 >       Time to Live field.
 >
 >    o  The OH header Type of Service field SHOULD be copied from the IH
 >       header Type of Service field.

Does this apply when encapsulating across versions (4 in 6 or 6 in 4)?
In any case the terminology is slightly different in v6 headers.

In the v6 case, does it apply to the flow label too?

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.

In 6.1.3:

 >    Priority:  each RLOC is assigned a priority.  Lower values are more
 >       preferable.  When multiple RLOCs have the same priority, they are
 >       used in a load-split fashion.  A value of 255 means the RLOC MUST
 >       NOT be used.

Then why waste bits sending that RLOC?

 >    Weight:  when priorities are the same for multiple RLOCs, the weight
 >       indicates how to balance traffic between them.  Weight is encoded
 >       as a percentage of total packets that match the mapping entry.  If
 >       a non-zero weight value is used for any RLOC, then all RLOCs must
 >       use a non-zero weight value and then the sum of all weight values
 >       MUST equal 100.  What did the 3rd grader say after Steve Jobs gave
 >       an iPhone demo to the class?

It doesn't add up?

 >       ...  If a zero value is used for any RLOC
 >       weight, then all weights MUST be zero and the receiver of the Map-
 >       Reply will decide how to load-split traffic.

That MUST condition seems pointless. If there is any zero value, the
other values don't matter.

 > 6.2.  Routing Locator Selection
...
 >    o  Server-side returns a list of RLOC where a subset of the list has
 >       the same best priority.  Client can only use the subset list
 >       according to the weighting assigned by the server-side.  In this
 >       case, the server-side controls both the subset list and load-
 >       splitting across its members.

That rule doesn't seem viable or enforcable. The client side may
simply not desire to take orders on how to load share, and that
could be a business issue (if the client has ISP preferences
for example). I think it needs to be "Client SHOULD only use the subset list
       according to the weighting assigned by the server-side."

Nit: the citations of RFC3056 and RFC2784 are inverted in the text.

        Brian

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