Re: [NSIS] AD Review comments on draft-ietf-nsis-req-07.txt

[Allison Mankin <[e-mail]>]

Robert,

Specifics are necessary in the text; the problem was trying to
encapsulate everything tersely in the phrase "non-traditional routing."
It is an important problem and does deserve notice in the requirements.
I recommend that the requirement be written with text such as you've
written in this message, saying that NSIS should not break even though
it passes through portions of the net in which these types of forwarding
(the types enumerated) make it difficult to ensure that the data will follow
the same path as the signaling message.

Perhaps you can give Marcus a new text for the section.

A few more comments inline.

Allison

> 
> i'll try to explain, hopefully in not too much detail.
> 
> historical background to this requirement (for those needing it):
> there was a long-ish discussion at the first NSIS interim (just
> over a year ago) about problems in the path-finding process, i.e. that
> two packets with the same destination address (e.g. a data packet
> and a PATH message) might be routed differently. obviously an 
> NSIS processing node can be mandated not to do this, 

Even an NSIS processing node can't avoid the following problem, which
would occur with any routing, even vanilla L3, and I think is not
mentioned in the requirements document: the route changes between
reservation refreshes and the data stream goes off the links that have
reservations..  I can't find the message by Bob that you cite without
having a Subject line (there are a number around that date and they
don't obviously have this topic), but I think he would speak of this.
Perhaps this needs to be added as another part of the same
requirement.


> but if the 
> data path crosses an NSIS-unaware cloud, the signalling and data paths
> may split and be very difficult to recombine. the requirement 
> is basically trying to say: we should not ignore this problem,
> although a general solution is recognised as hard. Bob provided
> an excellent summary of the situation in an email to the list
> (on or around 21/11/02, in my time zone).
> 
> so, I think there are two parts to stating the requirement.
> 
> one is, defining the circumstances where the splitting arises. this is
> a combination of 
> a) NSIS-unaware node, and
> b) makes a routing decision based on something other that L3 DA.
> We never found a good name for things that do (b); policy forwarding
> is part of it (some people call this policy routing which is not 
> the problem); another part is QoS routing (e.g. routing on ToS/DS value);
> another part is load sharing using a hash of some part of the packet
> header as a discriminator. These may or may not involve packet fields
> above L3, including L4 switching and things like interception middleboxes
> ("transparent" web caches), and may or may not involve L3 fields not 
> usually used in (unicast) routing, like L3 SA.
> 
> maybe there is *no* good name for the set of circumstances covered by
> (b), and the requirement should be phrased in terms of 'non-pure-L3-destination
> -
> address-routing' (although it's a bit of a mouthful), and accompanied by
> some more background.

There is no one name for the different types of routing, so yes, that is
the better way to go.
> 
> the other part of stating the requirement is to say what we should
> try to achieve in these circumstances. i don't think a concrete target
> can be set here, because a perfect solution is nearly provably impossible.
> i think the main approach is that as the signalling packets that have to 
> follow the path look more and more like data packets the problem gets
> less severe, but that's solution space, not a requirement.
> 
> do you think that the concerns are reasonable and that a useful 
> requirement covering them can be written? in other words, is this only
> a terminology/clarity issue?
> 
As I said above, yes and yes.
_______________________________________________
nsis mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/nsis