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

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