Re: about draft-ietf-multi6-l3shim-00.txt

[Erik Nordmark <erik.nordmark@sun.com>]

marcelo bagnulo braun wrote:
> Hi Erik,
>
> I think the document is very clear. I have some comments below...

Thanks for the careful review.

> I would say that the assumption being made is even stronger than this.
> In addition to what is stated, there is another assumption being made
> w.r.t. to the site exit router selection. Precisely, i think that the
> solution assumes that a modification in the source and destination
> addresses would result in a change of the site exit path used to route
> both incoming and outgoing packets. This assumption holds true trivially
> for incoming packets since we are assuming provider aggregatable
> addressing, but for the case of outgoing traffic, this is not trivial
> and some mechanisms are needed for this (in particular some of the
> ingress filtering mechanisms also provide such functionality, but note
> that there are some solution for the ingress filtering compatibility
> problem (like address rewriting or simply relaxing ingress filters) that
> solve the ingress filtering problem but don't provide this functionality)

That might very well be one way we end up addressing the ingress 
filtering and source address relationship, but I don't think the shim6 
approach necessarily assumes that the source address must affect the 
chose exit. If there is a need to be able to explore all exits (which is 
actually a question) i.e. packets transmitted by A to B should take all 
possible exits from A's site, then the source,destination pair of 
locators need to be able to cause the different exits.
But depending on the complexity of such solutions we might decide that 
they are not worth-while.

In any case, I think it is premature to state this as an assumption of 
the form "the source address must affect the exit".

>
>> 2.  Terminology
>
>
> [...]
>
>>       identifier  - an IP layer identifier for an IP layer endpoint
>>                     (stack name in [NSRG]).  The transport endpoint is a
>
> 
^name?
>
> maybe i am not understanding this, but isn't a "name" missing above?

Yes, that is the easiest edit. It could say "The transport endpoint is a 
function of the transport level, and the transport endpoint *name* would 
typically ..." but that doesn't add much.

>>                     function of the transport protocol and would
>>                     typically include the IP identifier plus a port
>>                     number.  NOTE: This proposal does not contain any IP
>>                     layer identifiers.
>>
>>       upper-layer identifier (ULID)
>>                   - an IP locator which has been selected for
>
>
> Wouldn't be better to substitute locator for address in this definition?

Well, it is a locator, so I guess it could be either.
FWIW The document tries to use the term "address" very sparingly (and 
I'll fix it to be even more careful). The document uses the term 
"address field" liberally, but that is not the same as the "address" term.

>> 4.2.  Renumbering Implications
>>
>>    As stated above, this approach does not target to not make
>
>
> remove one of the "not" above

Oops


>>    This potential source for confusion can be avoided if we require that
>>    any communication using a ULID must be terminated when the ULID
>>    becomes invalid (due to the underlying prefix becoming invalid).
>>
>
> I think this is an overkill.
> Which is the probability of this event? i mean, the event is that the
> prefix is renumbered and assigned to another site within the lifetime of
> an established communication, and then that the same address is assigned
> to a host (only this is 2^(-64)) and then that this host establishes a
> communication with the same host that the initial one is communicating...
> I wouldn't worry about this case.

I'll edit your text above and add it to the document.


> But, presumably, the MTU change would occur, as you mention, after a
> locator failure. This means that a new path will be used after this, and
> this, by itself, may imply a change in the available MTU. So, my point
> is that the change on the MTU is inherent of the fact that we are
> changing the path used for an established communication and not only due
> to the addition of an additional extension header.

I'll also add the above to the document.



>> 7.1.  DNS and Centrally Assigned Unique-local Addresses
>>
>>    Earlier we've mentioned that the protocol might provide the basic
>>    mechanism to use Unique-local addresses as ULIDs.
>>
>>    In the cases where hosts have been assigned centrally assigned ULAs
>>    [ULA-CENTRAL], one can potentially take advantage of this to provide
>>    better support for applications.  With centrally assigned ULAs it is
>>    possible to register them in the reverse DNS tree.  As a result, one
>>    could use the DNS not only for applications which care about reverse
>>    and forward tree being consistent, but also to find the full set of
>>    locators from the ULID.
>>
>>
>
>
> But this is the case not only for Centrally assigned ULAs, but for also
> for all routable addresses, right?
> So i would suggest to move this (very valuable) comment to the previous
> section, that makes general observations about the DNS.

Yes, text needs to be yet more clear on what is ULA specific.
The key point the doc should make is that in some cases consistent 
reverse and forward trees for a locator set are hard (such as two 
"consumer" ISPs each providing DNS, but no way for the site to control 
what goes in the DNS for the reverse tree). Using centrally assigned 
ULAs means that the site can interact with the entity assigning the ULA 
to get consistent reverse DNS.



>>         When the policy is triggered, which could be on either A or B,
>>         an initial context establishment takes place.  This exchange
>>         might fail should the peer not support the multi6 protocol.  If
>
>
> I don't understand the usage of the "should" of the last sentence (but
> this is probably me)

English isn't my mother tongue either. I'll reword to use "if" instead:
"This exchange will fail if the peer does not support the multi6 protocol."

>>         it succeeds it results in both ends receiving the locator sets
>>         from their respective peer, and the security mechanism provides
>>         some way to verify these sets.
>>
>>         At this point in time it is possible for the hosts to change to
>>         a different locator in the set.  But until they have exchanged
>>         the locator sets, and probably until they rehome the context to
>
>
> i would remove the "probably" in the previous sentence ( i mean, only
> after a rehoming they will start using a new locator, right?)

Well, they might send test packets after they have a locator set for the 
peer, so there would be some difference in the packets they send.

>>    Note that we do not yet understand how beneficial it would be to be
>>    able to accept packets from unknown source locators (the rules for
>>    packet injection can probably be more relaxed than for where packets
>
>
> i don't understand this sentence... wouldn't it be "reception" rather
> than "injection"?

Yes


>>    The alternative would be to layer multi6 above IPsec, but that
>>    doesn't seem to provide any benefits and it would add the need to
>>    create different IPsec SAs when the locators change due to rehoming.
>>
>
> wouldn't be good to refer to the mobike work at this point?

Would should the document say other than just "[MOBIKE]"
?

   Erik