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

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

Understand the issue and there is no reliable solution to it. All  
tunneling protocols have this problem. But I believe in practice it's  
not a real issue. Hosts send no larger, typically than 1500 byte  
packets and routers are now more and more on 9K MTU links.

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

Correct.

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

Okay, good suggestion.

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

There is a requirement for site-based ETRs to allow to control the  
data flow to each of the site's locators. This is precisely  
controlling ingress traffic flow.

Dino

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