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

From: "Hancock, Robert" <[email-masked]>
Date: Fri, 13 Jun 2003 09:16:27 +0100

hi 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, 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.

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?

cheers,

robert h.

> -----Original Message-----
> From: Allison Mankin [mailto:[email-masked]]
> Sent: 13 June 2003 05:33
> To: Hancock, Robert
> Cc: [email-masked]; [email-masked]
> Subject: Re: [NSIS] AD Review comments on draft-ietf-nsis-req-07.txt 
> 
> 
> Robert,
> 
> Thanks for the explanations and comments.  They were helpful.
> 
> I have one amplification to make:
> 
> > 5.9.6 MAY interwork with non-traditional routing 
> >     
> >    NSIS assumes L3 routing, but networks, which do non-traditional 
> >    routing, should not break it. 
> 
> You explain this as follows:
> 
> > b) The second requirement is about wanting NSIS protocols 
> that aren't broken
> >
> > by the presence of policy-based forwarding in NSIS-unaware 
> regions of the 
> > network. Again, 'interwork' is probably the wrong word.
> 
> So my guess that what the group meant by non-traditional 
> (non-L3) routing
> was L4 switches/NATs was incorrect.  The text is not fixed by 
> changing the
> word 'interwork', it needs to have a clearer statement of the 
> environment
> in which you expect NSIS to be robust.  Policy-based 
> forwarding would seem
> to me to be a form of L3 routing, so I'm still not sure.  
> Could you clarify?
> 
> This part of what you say:
> 
>   NSIS must be function in circumstances where parts of the 
> network are
>   NSIS-aware
> 
> does not have to be coupled to the network having unusual 
> routing, so this
> is not coming through clearly.
> 
> Allison
> _______________________________________________
> nsis mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nsis
> 
_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: Allison Mankin <[email-masked]>
Date: Sat, 14 Jun 2003 23:32:46 -0700

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

> 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 

There is no one name for the different types of routing, so yes, that is
the better way to go.
> a terminology/clarity issue?
As I said above, yes and yes.
_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis