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

["Henderson, Thomas R" <thomas.r.henderson@boeing.com>]

Erik, just a few more nits:

page 5:  "identifier - an IP layer identifier" seems like a circular definition, especially since "identifier" does not seem to be often used in the text without a qualifying "IP" preceding it.  Perhaps, in parallel to the address definition it could say: "IP identifier - an IP layer name for an endpoint (stack name in [NSRG])..." 

page 5:  "NOTE:  This proposal does not contain any IP layer identifiers"  But it does discuss a number of options.  Suggest "NOTE:  This proposal does not define any IP layer identifiers, but discusses some options in Section 9."

page 7:  RFC 3484 is cited but not referenced later

page 12: s/multi6 one some packets/multi6 some packets/

page 12: s/packet to big/packet too big/

page 15: s/advise/advice/

page 19: Previously (Sec 2.1) you define X as a malicious host, but then you seem to use host X in a non-malicious context here.  Actually, I don't recall where X is malicious within this document, so maybe revise 2.1?

Tom

> -----Original Message-----
> From: Erik Nordmark [mailto:erik.nordmark@sun.com]
> Sent: Wednesday, January 26, 2005 2:01 PM
> To: marcelo bagnulo braun
> Cc: shim6@psg.com
> Subject: Re: about draft-ietf-multi6-l3shim-00.txt
> 
> 
> 
> 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
> 
> 
>