1. NSIS Terminology Issues Robert Hancock IETF #55 - Atlanta November 2002

2. Background Trying to provide unambiguous, unsurprising, useful terms Focus on requirements and framework needs for now And charter compatibility!

3. ‘Non-Traditional Routing’ Need a term for ‘where a standard router decides how to send a packet on its next IP hop not only based on the IP DA’ Is this ‘policy routing’? ‘Policy forwarding’? ‘Multi-field routing’? Not a useful concept to distinguish?

4. Signalling Types Path-coupled/decoupled Defined currently in framework doc Protests have died down? Shift to reqts? Other types of signalling… Signalling to request a particular type of path Signalling not about paths at all Currently not in scope – need terms for these?

5. QoS-Centric Terms Need a word for “the thing signalling is used to control or request or install” Currently ‘reservation’ Need a word for “the thing managing what is being signalled for” Currently ‘resource management function’ Agree these terms can be used abstractly? Or invent new abstract terms?

6. WG and Protocol Names “NSIS” = name of an IETF working group Used for “the stuff that NSIS w.g. will make” Used for “the work that the stuff that the NSIS w.g. will make will do” Iron discipline may allow us to restrict to the first case (and more words elsewhere) NTLP/NSLP – OK as names for [types of] work items, not protocols? More easily distinguished variants?

7. Peers and Neighbours Need a word for “the NSIS entity I am talking to directly” Peer – objection on grounds of taste? Neighbour – topological connotations? Different concepts at different layers? Any other suggestions?

8. XXX Discovery Seem to be 3 overlapping concepts: 1.“Deciding how to send to my N/P” 2.“How the e2e signalling path is put together” 3.“Finding all local (or even global) topology” ‘Discovery’ always interpreted as (3) (2) could be handled as a working assumption in framework (1) – ‘selection’? ‘determination’?

9. Sender/Receiver Initiation/Orientation ‘Sender/Receiver’ – w.r.t. data flow always  3 independent roles to consider: 1.Who triggers the signalling process 2.Who decides what to ask for 3.Who is authorised to make the request All could be taken by sender or receiver or network (proxy) – distinction is really ‘with’ or ‘against’ data flow? NTLP only cares about (1) (if any?)

10. ‘Reservation’ Identifiers May have two concepts One related to abstract identifiers used between communicating NSLP instances One related to NTLP support for moving state to clean up after a path change Mainly a framework issue to decide which approach – reqts could describe the problem addressed?