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

Dino,

On 2007-07-25 18:20, Dino Farinacci wrote:
>> 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?

Not really, except that the extra header (unknown to the sender)
will reduce the MTU and we'd like to avoid that causing fragmentation.

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

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

Fine, so this is a phrasing issue.

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

RFC 3697 doesn't give any guidance for unencrypted tunnels.
The only firm requirement is that the (inner) flow label
is delivered unchanged. I can imagine scenarios where you'd want
to keep the same label and others where you'd want to treat the
tunnel as a flow in itself. So I would vote for MAY copy until
we understand more.

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

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

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

Maybe I'm disagreeing with that rule then. Is there a *technical* argument
for why the server side must determine the weights?
> 
>> Nit: the citations of RFC3056 and RFC2784 are inverted in the text.
> 
> Will fix. Thanks again.

You're very welcome.

    Brian

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