Design Options of NSIS Diagnostics NSLP draftfunsisdiagnosticsnslp00 txt

Design Options of NSIS Diagnostics NSLP <draft-fu-nsis-diagnostics-nslp-00. txt> Xiaoming Fu Ingo Juchem Christian Dickmann Hannes Tschofenig 1 IETF 64 th meeting, Vancouver, Canada

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

Overview • Problem • Design options • Next steps 3 IETF 64 th 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 Qo. S reservation information? • Firewall/NAT existence? • RFC 2475: per session PATH/RESV state diagnostics 4 IETF 64 th meeting, Vancouver, Canada

Problem (Cont. ) • Currently, GIST does not support any multi-hop diagnostics functions • Stack proposal negotiation only takes place between peers • Qo. S 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 5 IETF 64 th 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? • 6 Proposal: sysadmin and limit to his domain only IETF 64 th 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? • 7 Proposal: Only sysadm to query Option 1 IETF 64 th meeting, Vancouver, Canada

Design Options (2 b) • 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) 8 • Pro: flexible • Con: requires policy definition/proper authorization model IETF 64 th 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-byhop fashion • Pro: gather everything potentially needed, eg, timestamps in GIMPS “ping” • Con: more complex, require larger size • Proposal: Option 1 9 IETF 64 th 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 Do. S attacks • Proposal: No any state should be introduced (if no reverse direction info is required) 10 IETF 64 th 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: 11 • Use MRM object for query msg routing: • D-mode as default, when MA exists, reuse it. IETF 64 th 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 12 IETF 64 th 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] 13 IETF 64 th meeting, Vancouver, Canada

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