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...

Thanks for the comments Brian. Sorry for the delay, but I want to add  
to what Scott said. I didn't disagree with any of his comments.

> General points that aren't mentioned and perhaps should be:
>
> MTU size reduction
> Fragmentation (in IPv4)

I will add text to the -03 version. Did you have any suggestions?

> Referrals (host A passes an address for host B to host C)

As Scott said, everything is EID based. Will make that more clear in  
the document.

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

The default router is the first-hop router directly connected to the  
source. In this example, the ITR is placed in the first-hop router  
but can be placed anywhere, and maybe more ideally in the CE router  
(the one connected to the CE-PE link).

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

Absolutely.

> In any case the terminology is slightly different in v6 headers.

I will fix that.

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

I am not sure, depending on the semantic of the flow label which has  
been rather unclear. What do you think?

> 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.

I will include a reference to http://www.iana.org/numbers.html. We  
use the term "AFI" in PIM as well.

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

Because the cost of these bits are minimal and we don't want to  
change the record often. Want to keep the change frequency of mapping  
records low. Plus the loc-reach-bits in the encapsulation header  
refer to the position here and *could* override the 255 value.

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

You have to read the CONS draft.  ;-)

> >       ...  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.

Not true, you could have 3 locators all with non-255 priority, each  
with 0, 50, and 50 as weights. What is conveyed in this encoding is  
that the first locator is not used. When all weights are 0, the ITR  
can load-split to it's liking.

> > 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."

Well, we do want client spec-compliant implications. I realize there  
are malicious systems out there but you have to document what the  
intended rules are.

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

Will fix. Thanks again.

Dino

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