[NSIS] Dave Oran's comments

[john.loughney at nokia.com]

These are Dave Oran's comments.

thanks,
John

This covers my overall impressions and my comments on GIMPS. Comments on 
QoS and NATFW to follow.

General:
- I'm still not comfortable with the delicate tradeoffs of responsiveness 
to routing changes and message overhead. This is fundamental to the whole 
C-mode/D-mode operation and hence we may just have to live with the 
tradeoffs
- Don't feel comfortable that the ordering properties among the signaling 
applications carried by GIMPS are captured in the design. For example, QoS 
signaling depends on prior establishment of NAT and FW state. What enforces 
this ordering, and if so, does it require extra RTTs to set up the 
dependent state?

NTLP Comments:

- Definition of data flow excludes multicast. OK, but should this be part 
of  the definition?
- Definition of data flow enforces "unique path". Does this mean path 
splitting is not ok even for flows where delivery order doesn't matter?
- How does path coupling work if proxies are not on the path?
- What led to the decision to use a hop count rather than a VIA-style path 
recording?
- The D-mode gimps message needs to truly mimic the actual data flow in 
order to guarantee congruent routing. This is particularly important where 
routers may be doing their own flow routing based on things like DSCP.
- If NATs have to be GIMPS-aware then aren't we punting a big part of the 
application scope for NSIS?
- NIT on tunneling - it's the outer header of the tunneled packets which 
doesn't have RAO, not the tunneled packet itself.
- section 8.3 says raw IP ruled out by section 8.2 but I see nothing in 8.2 
which argues for ruling out raw ip encapsulation. Just confused here...
- small point on aggregation - its the exit interface which defines the 
aggregation level, not the router. A router could have interfaces at 
different aggregation levels.

Comments on NSLP

- in general this doc is not as well written as NTLP and needs some 
editorial work. Parts are pretty hard to understand.
- Policy control may involve "envelope resource utilitzation" policy in 
addition to simple AAA. This means that hard synchronization with the AAA 
policy state and the NSLP element may be necessary.
- Is there a need for explicit teardown invoked by the AAA element?
- How is receiver selection based on ADSPEC done if resources are reserved 
in the forward direction with RESERVE?
- some talk about 2-phase operation for RSVP. Any thought of the same for 
NSLP?
- Didn't see any way to do resource sharing across flows.
- Ditto for fate-sharing across flows (if you tear one down you tear the 
fate-shared ones down)
- Reservation priority is declared out of scope but is critically 
important. We can't just punt this. One thought is to have it be part of a 
set of "common facilities" that go across all the GIMPS applications. I bet 
there are a number of such common things which are not part of the 
transport but aren't specific to a particular signaling appication.
- Is there any capability for make-before-break so that reservations can be 
installed on multiple paths at the same time to deal with graceful 
mobility? It seems that the notion of flow/session separation captures part 
of this, but I don't see how it solves the double-booking problems on the 
common links.
- how does bi-dir reservation enforce symmetric routing?



_______________________________________________
nsis mailing list
nsis@ietf.org
https://www1.ietf.org/mailman/listinfo/nsis