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

2nd part Re: revision of architecture draft is now published

The first mail was unintentionally sent, so i include the remaining comments here.

- about section 4.5

I am not sure about the following comment:

  "Packet header rewriting by remote network elements has a large number
   of associated considerations, and documentation relating to the
   considerations of the use of Network Address Translators [4] contains
   much of this material."

I mean, if the multi6 layer within the host replaces the received locator by the ULP identifier, then it doesn't really matter the locator than was actually carried in the packet, right? I mean, in any case, the locator is transparent to the ULP which only deals with the identifier.

Moreover, perhaps replacing locators by identifiers introduce some of the nat problems, but in any case, i don't see how this related to the fact that the locator is replaced by the host or by the edge router. So perhaps some comment like this one is required but imho is not restricted to this section but to all mechanisms that replace locators by identifiers.
Perhaps you were considering other issues here?

- about section 5.1

i fail to understand the case you are describing with:


   It is also possible to allow the endpoint identity and locator space
   to overlap, and distinguish between the two identity realms by the
   context of usage rather than by a prefix comparison.  However, this
   reuse of the locator token space as identity tokens has the potential
   to create the anomalous situation where a particular locator value is
   used as an identity value by a different endpoint.  It is not clear
   that the identity and locator contexts can be clearly disambiguated
   in every case, which is a major drawback to this particular approach.

In particular which is the difference between this case and the "home" locator case?

Later in this section (the last paragraph, actually) it is stated that:

   Instead of structured tokens that double as lookup keys to obtain
   mappings from endpoint identities to locator sets, the alternative is
   to use an unstructured token space, where individual token values are
   drawn opportunistically for use within a multi-homed session context.
   Here the semantics of the endpoint identity are subtly changed.  The
   endpoint identity is not a persistent alias or reference to the
   identity of the endpoint, but a means to allow the identity protocol
   element to confirm that two locators are part of the same mapped
   locator set for a remote endpoint.  In this context the unstructured
   opportunistic endpoint identifier values are used in determining
   locator equivalence rather than in some form of lookup function.

i think that it is also possible to use an unstructured identifier name space in a non opportunistic mode, like HIP, that supports both modes. I mean, the identifier in this case is persistent, but as the address space is not structured, lookups are at least difficult if not impossible in the short term.
So perhaps it would be interesting to split this paragraph in two, one about unstructured namespaces, and another one about using them in a opportunistic manner?

- in section 5.3.2

where it states that:

   One of the potential drawbacks of placing this functionality within
   the transport protocol layer is that it is possible that each
   transport protocol will require a distinct implementation of identity
   functionality.

i would add that another drawback is that some transport layers (such as UDP) don't have the notion of session neither, so in this case i guess only the app knows about sessions

- in section 5.3.3

when considering opportunistic identifiers to initiate the communication.
note that non of the proposals AFAIK, use opportunistic identifiers for the server side. imho this is very difficult, because, the client side needs to know the identifier in order to initiate the communication. It would be possible that the client side would select the servers identity beforehand, but this may imply collisions if the server is already using it. imho opportunistic ids are only suitable for clients (if any), but not for servers.

- section 6.1

when it states that

      Does the transport need to translate the upper level interface
      token into an identity token that identifies the session?

i guess that is not the transport who does the translation but it can also be the wedge layer

then when it states that

      How does the session initiator establish that the remote end of
      the session can support the multi-homing version of the transport
      protocol?

what do you mean by "the multihoming version of the transport protocol"? i mean in the wedge layer approach, for instance, the trasnport protocol is not multihoming capable, but the wedge layer is. I think that perhaps this section should reffer more to a multi6 capable endpoint rather than a multi6 capable transport protocol

Additionally, i guess that i would also include in this section something about how does the endpoints discover the locator set available for the other endpoint and how do they select the source and destiantion locator. In other words, i think that a couple of functions within the fucntional decomposition should be:
* locator discovery
* locator selection (both source and destination) for initial contact

Regards, marcelo

PS: sorry for the fragmentation of the comments :-(


El 30/06/2004, a las 4:22, Geoff Huston escribió:

draft-huston-multi6-architectures-01.txt has been published by the drafts editor. This version integrates comments made by working group members on the -00 version and also includes material proposed in the interim multi6 working group meeting earlier this month.

I would like to propose to the chairs that the working group consider:

- that this document be adopted as a working group document, and

- that the appendix of this document be split off from the main text of the document and separately developed as a working group document.


thanks.