[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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 at iab.org
https://www1.ietf.org/mailman/listinfo/ram