1 IETF 64th meeting, Vancouver, Canada Design Options of NSIS Diagnostics NSLP Xiaoming Fu Ingo Juchem Christian Dickmann Hannes Tschofenig

2 IETF 64th meeting, Vancouver, Canada Acknowledgment Thank following colleagues for discussions of various issues in the list and/or individually: Bob Braden Scott Bradner Elwyn Davies Allison Mankin Jukka Manner David Oran Martin Stiemerling Sebastian Willert (and some other members in NSIS WG)

3 IETF 64th meeting, Vancouver, Canada Overview Problem Design options Next steps

4 IETF 64th meeting, Vancouver, Canada Problem Operators/sysadms may want to have a means to diagnose the NSIS nodes for detecting NSIS support in these nodes for detecting NSIS states in these nodes At least for their own domains An NSIS end user may want to diagnose the network NSIS information, too (?) User’s QoS reservation information? Firewall/NAT existence? RFC2475: per session PATH/RESV state diagnostics

5 IETF 64th meeting, Vancouver, Canada Problem (Cont.) Currently, GIST does not support any multi-hop diagnostics functions Stack proposal negotiation only takes place between peers QoS NSLP Query messages are used for determine the available resource information QOSM ID support information is not clear at the moment NAT/FW NSLP Latest version defines a “Trace” to identify NATFW nodes  A generic diagnostics NSLP might be needed

6 IETF 64th meeting, Vancouver, Canada Design Options (1) Issue: which GIST information should be diagnosed Option 1: MAs in each GIST node Pro: helpful to diagnose the current available MAs Cons: implementation-specific? Possible presence: every MA table in the GIST node Option 2: all MRSs in each GIST node Pro: get info on every active NSIS sessions in each node Cons: too fine granularity? Large message size? Authorization issues? Possible presence: the number of MRSs along the path or detailed MRSs but limit to a domain Open issue: who can query GIST info? NI/NR or any NE? Proposal: sysadmin and limit to his domain only

7 IETF 64th meeting, Vancouver, Canada Design Options (2) Issue: Which NSLP information should be diagnosed? Option 1: supported NSLP-IDs in each GIST node Pro: simple Cons: not useful enough? Recall GIST only talks to the next node supporting the requested NSLP Possible presence: take it, but add a bit more info Whether is a FW or NAT, QOSM-ID info etc. Option 2: aggregated NSLP state information in each GIST node Pro: may be useful Cons: how? Authorization issue? Option 3: all detailed individual NSLP state information Pros: Authorization issue; message too large? Open issue: authorization issue: who can issue the query? Proposal: Only sysadm to query Option 1

8 IETF 64th meeting, Vancouver, Canada Design Options (2b) Issue: Granularity of NSLP state? Option 1: a sysadm to query all NSLP session state? Pro: all info for diagnosing NSLP status Con: too fine-grained? MTU issue? Proposal: a summary of NSLP session state(?) (How exactly?) Option 2: a NI/NR to query its NSLP session state? Pro: authorization issue seems to be easier Con: what about triggered by other entities? Option 3: a 3-part to query an established NSLP session state (RSVP fashion) Pro: flexible Con: requires policy definition/proper authorization model

9 IETF 64th meeting, Vancouver, Canada Design Options (3) Issue: Which message sequences of the diagnostics func Option 1: query being delivered to each GIST node along the path, response directly back to the querying node Pro: simple Con: anything required to be added in the reverse direction? Option 2: both query and response being processed hop-by- hop fashion Pro: gather everything potentially needed, eg, timestamps in GIMPS “ping” Con: more complex, require larger size Proposal: Option 1

10 IETF 64th meeting, Vancouver, Canada Design Options (4) Issue: Does diagnostics create any NSIS state? Option 1: No (i.e., just use GIST stateless delivery) Option 2: GIST state only Pro: can be used to collect reverse direction info if required Con: maybe prone to DoS attacks Proposal: No any state should be introduced (if no reverse direction info is required)

11 IETF 64th meeting, Vancouver, Canada Design Options (5) Issue: Encapsulation of the message Option 1: D-mode (UDP). Pro: does not need to introduce any state Con: MTU limitation Option 2: C-mode (e.g. TCP) Pro: reuse existing MAs does not hurt, No MTU issue Con: when no MA between two peers, needs to introduce MAs Does one want to remove it? If so reverse routing is needed Proposal: Use MRM object for query msg routing: D-mode as default, when MA exists, reuse it.

12 IETF 64th meeting, Vancouver, Canada Design Options (6) Issue: Message formatting Option 1: All TLV Objects for each info Pro: generic presentation Con: more bits required Option 2: compacted into a message segment for info gathered in each node Pro: smaller size Con: any changes difficult later Proposal: Option 1

13 IETF 64th meeting, Vancouver, Canada Strawman Design: Towards a Diagnostics NSLP DIAGNOSTIC-message = Common header, [Query object], [Hop object]* Common header: Diag_NSLPID, type (query or response), total length Query header: which info needs to be queried Hop-object = Hop header [IP address object] [General GIST information object] [SID-bound Response object] [NSLP state information object] [Available NSLPs object] [Additional information object]

14 IETF 64th meeting, Vancouver, Canada Next Steps Is this work useful? Next steps with diagnostics functions? Inputs, comments and suggestions appreciated!