Subject: [NSIS] NSIS routing issues (was: RE: Comments on framework draft)

From: "Hancock, Robert" <[email-masked]>
Date: Sun, 10 Nov 2002 21:52:49 -0000

hi Melinda,

you raised some routing related issues in your first round of framework comments.

> 4.1 Feel quite strongly that interface selection should be
>     handled by IP routing
> 
> 4.5.1 Why do you want to identify "flows" at the NSIS
>     protocol layer?  The text doesn't make a good case for
>     it.  This belongs in the application
> 
> 5.2 Some of this would fall under the rubric "policy
>     routing," which could be mentioned
> 

I think there are a number of inter-related issues here.
If by 'policy routing' you mean 'making a packet forwarding decision based on something in addition to the IP DA' [*], I agree this is the main point at issue in the first half of 5.2. The existence of policy routing of this type presents a set of very hard (possibly insoluble) problems for NSIS-like path-coupled signalling (not all of which are captured in the framework document so far).

I'd be very interested to hear some feedback about how common this is in the real world, and what is actually used other than the IP DA in forwarding lookups.

It's the same reason behind some of the text in 4.1 which you may be referring to. Actually, I think there's no room for disagreement here (or rather, disagreement should be about the more fundamental issue of the addressing model): peer-peer addressed signalling messages will be normally routed, end2end addressed signalling messages will be routed the same way as data traffic would be (which might include policy routing for example). If you think the current text says more (or less) than this, feel free to suggest modification.

So far as 4.5.1 is concerned, the motivation is 2-fold:
1. Nodes may need to do 'standardised' message processing which is independent of any application (e.g. a NAT or SIIT box), so we shouldn't hide the corresponding packet header information inside the application.
2. Because of policy routing, the IP DA alone doesn't define the path, you need this flow identification information as well. If the NTLP is responsible for keeping the signalling on the path, it needs access to this data.
[The other use of the flow identification - to say what packets you actually want to do something to - obviously only needs to live in the application; maybe there are two levels of flow identification needed.]

(1) could possibly be handled by Bob's proposed 'generic core application', but (2) seems to me to be very much an NTLP issue. In any case, it's another layer-interface issue to add to the list.

Hope this has all been meaningful,

Cheers,

Robert H.

[*] I've also seen the term 'policy routing' used to refer to filtering routing protocol (typically BGP) messages according to some policy rules. I don't think we care about this at all in NSIS, provided the resulting forwarding tables are simply DA based.
_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis