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

Re: Comments on draft-ietf-shim6-proto-00.txt

marcelo bagnulo braun wrote:


Yet another missing discussion: is there some interaction
with this protocol and the protocol defined in Marcelo's
draft that talked about communication with non-shim6
peers? It would appear that some aspects (e.g. input from
RAs) is common.



As i understand it, we have two cases:
- a host within the multihomed site that wants to initiate a new communication with an external legacy host after an outage, and - a host within the multihomed site that wants to initiate a new communication with an external shim host after an outage
In the first case the mechanisms for doing this must only reside in the multihomed host, while in the second case, the mechanism can involve both (the multihomed and the external) hosts
Clearly the mechanisms used for the first case can be used for the second case as well (obviously the mechanisms for the second and not suitable for the first case)
The question is whether it wouldn't be better to define mechanisms that are specific for the second case, taking advantage of the shim capabilities of the shim peer.
The benefit that i can think of in this case would be that retrial would be transparent for the ULP, since it would be solved by the shim. The drawback is that the shim session needs to be established before the communication is initiated, which may not always be the case. An additional drawback is the added complexity, that need to quantify, since these shim based mechanisms to deal with non working ULIDs are in addition to the mechanisms for dealing with legacy hosts. Additional difficulties for this mechanisms is the discovery of alternative locators for initiating the communication, which is likely to be based on information posted in the DNS, but that information is probably not as good as it may seem, since the addresses associated with a given FQDN may not belong to a single host, resulting in invalid ULID/locator combinations.
As a side note, these mechanisms for dealing with non reachable ULIDs are needed for supporting things like ULAs as ULIDs. 

As I see it, your draft actually had two parts: what to do and how
to find out what prefix isn't working right now. The latter part
provides information that the shim6 protocol should also use.
As you note above, the former part has some tradeoffs and needs
more discussion.




  multihoming can be provided for IPv6 with failover and load spreading
  properties


I'm a bit concerned that we have not figured out all the details
regarding load spreading. You don't want a particular session
spread around different paths, because doing so would
confuse existing congestion avoidance mechanisms. The obvious
answer appears to be making sure that that we keep the same
locator pair for the same session. But can we identify sessions
in all cases? Also, protocol description in Section 4 and beyond
does not talk about when and how loadsharing is initiated and
abandoned.



I am not sure what do you mean by load sharing...


I mean to say "load spreading" which was the term the
document used. But no matter what the term is, my
point was that we have not defined what this means in
detail. As you note below there are some different
possibilities.
If we are talking about distributing the traffic across the multiple exit paths of the multihomed site, i would say that this would be naturally provided by the selection of ULIDs by the applications. I mean, just the fact that different hosts select different prefixes for initiating communications would result in a distribution of the load across the different ISPs. I mean that there is no point to distribute the packets of a given communication among the different paths, since what really matters AFAICT is the overall load, which is the aggregation of the load of all nodes, which will be distributed because different communications will use different prefixes hence different ISPs (as opposed to a single communication distributing the load among multiple ISPs)
However, this is clearly not good enough for achieving some form of traffic engineering or policing where something more that spreading the load evenly across isps is required. 

In any case, i think it would make sense to explain this in the doc


  In addition, the non-shim6 messages, which we call payload packets,
  will not contain the ULIDs after a failure.  This introduces the
  requirement that the <peer locator, local locator, local context tag>
  MUST uniquely identify the context.  Since the peer's set of locators
  might be dynamic the simplest form of unique allocation of the local
  context tag is to pick a number that is unique on the host.  Hosts
  which serve multiple ULIDs using disjoint sets of locators can
  maintain the context tag allocation per such disjoint set.


Not sure if this always needs to be true.
It might be that the shim6 failover protocol signaling
is used to tell the peer what the new locators are. If
that's the case, then the local context tag alone does
not need to be unique, you could rely also on the
addresses.

Also, there seems to be security issue in using just
the context tag to do the demux.
as i understand it, once that the context is identified using the context tag, the addresses included in the packet are verified against the locator set available for that context. If the addresses included in the packet are not included in the locator set of the context, the packet will be ignored 

Ok. This would work. Maybe I missed that statement if it was in
the document.


It might be possible to combine these functions. But lets
do the individual design first for each, and combine later
if possible.

Also, the assistance from payload packets in the explore
phase is not discussed.



i am missing what you mean here... could you expand?


This is what we had discussed earlier, I think on Christian's
suggestion, that the reception of payload packets with
a specific src/dst could be used as assistance in the
exploration phase.

--Jari