Re: OPS-Dir review of draft-ietf-nsis-applicability-mobility-signaling-18

Dear David,

Thank you for your comments during IETF last call.
I have revised the draft based on your comments. 

http://www.ietf.org/internet-drafts/draft-ietf-nsis-applicability-mobility-signaling-19.txt

Main revised points were:
   1.  Abstract and Introduction were changed to clearly say the NSIS
       protocols operations can work in mobility environments without
       particular operations, and additional operations such as CRN
       discovery are only for enhancement and informational.

   2.  Some texts were added to section 4 to say the state in old path
       can be torn by timer.

   3.  Consideration in tearing down end-to-end tunneling state was
       mentioned in section 5.

   4.  Authorization for CRN was briefly mentioned in security
       consideration.


The most important point here is this document primary discribes how
NSIS protocols work in mobile environment, and secondary informs
enhanced method such as CRN discovery.
In this version, this point is clearly described in the text. 

As CRN operation in Mobile IP tunneling is also informational for
enhanced operation, I avoided adding too much text to describe the
topics you have pointed out. But added considerations.

Thanks,
Takako

On Wed, 16 Jun 2010 20:08:40 -0400
<[email protected]> wrote:

> I have performed an Operations Directorate review of draft-ietf-nsis-applicability-mobility-signaling-18
> 
> Operations directorate reviews are solicited primarily to help the area directors improve their efficiency, particularly when preparing for IESG telechats, and allowing them to focus on documents requiring their attention and spend less time on the trouble-free ones.  Improving the documents is important, but clearly a secondary purpose.  A third purpose is to broaden the OpsDir reviewers' exposure to work going on in other parts of the IETF.
> 
> Reviews from OpsDir members do not in and of themselves cause the IESG to raise issue with a document. The reviews may, however, convince individual IESG members to raise concern over a particular document
> requiring further discussion. The reviews, particularly those conducted in last call and earlier, may also help the document editors improve their documents.
> 
> --------------
> Summary: This document is on the right track, but has open issues discussed in the review.
> 
> The only real open issue is whether the specification of CRN behavior is important enough to merit standards track for this document.  Everything else noted in this review is minor.
> 
> This draft describes the use and behavior of NSIS with IP mobility.  I'm somewhat surprised that the draft is intended for informational status - while much of the draft is descriptive information, there appear to be requirements on crossover node (CRN) behavior that are crucial to the desired traffic behavior and that appear not to be specified in any other document.
> 
> Crossover nodes (CRNs) are a crucial aspect of this draft as mobile IP routes are unlikely to shift in their entirety when a mobile node moves - a CRN is the point at which the new and old routes from the mobile node converge (for traffic from the mobile node) or diverge (for traffic to the mobile node); due to asymmetric routing, the CRNs for the two directions of traffic may not be co-located.  The draft clearly recognizes the operational importance of not reserving QoS resources twice over the common portion of the route and of optimizing teardown of the portion of the reservation abandoned due to movement of a mobile node - both depend on actions performed by CRNs.
> 
> The extensive use of tunneling with mobile IP makes the interaction of the NSIS protocols with tunnels crucial to this draft.  From an operational perspective, this results in a need for any node that may be a mobile IP tunnel endpoint to be NSIS-tunnel-aware for the mobile IP tunnels.  At a minimum, that should be stated.
> 
> I believe that the CRN discovery procedures are correctly described for the tunnel setup scenarios - the upshot is that if the topological crossover point is in the middle of the tunnel, then there are two CRNs, one for the end-to-end QoS session, whose CRN is at one end of the tunnel and one for the tunnel QoS session located at the topological crossover location.  OTOH, teardown is not described - it is vital that the NOTIFY that will cause reservation state teardown for the end-to-end QoS session be sent through the tunnel before the tunnel itself is torn down - that suggests that this tunneled NOTIFY generally needs to be sent before the NOTIFY that causes reservation state teardown for the tunnel QoS session.
> 
> OTOH, Figure 5 raises a scenario that doesn't seem to be covered.  Figure 5 describes NSIS operation through tunnels that have pre-configured QoS sessions.  These sessions have a CRN dependency analogous to that described above, but the CRN within the tunnel is with respect to whatever protocol or mechanism is used to create and teardown tunnels as needed for mobility - that protocol need not be NSIS, and hence its signaling details are out-of-scope for this draft, but it should be pointed out that the concerns about dual reservations and teardown of the abandoned portion of the reservation still apply (and doubly so if the pre-configured QoS sessions through the tunnel are not based on soft state).
> 
> Most of the management and many of the operational considerations in Appendix A of RFC 5706 apply primarily to the base NSIS protocol documents, but the following seem relevant to this document in addition to the above discussions of CRNs:
> 
> A.1.2 Installation and Initial Setup: Whether a node is authorized to function as a CRN should be configurable.  This may be a security consideration, and is definitely a management consideration, as control of CRN functionality in combination with control of the nodes that can participate in NSIS may be used by a network operator to control the structure of the logical QoS reservation overlay on the operator's actual network.
> 
> A.1.4 Requirements on other protocols and functional components: The above comment about the importance of mobile IP tunnel endpoints being NSIS-tunnel-aware falls into this category.
> 
> A.2.4 Configuration Management: NSIS actions taken by a node acting as a CRN should be loggable
> (e.g., sending of a NOTIFY that is expected to tear down QoS reservation state, and the action of not forwarding the teardown RESERVE that is returned).
> 
> Thanks,
> --David
> ----------------------------------------------------
> David L. Black, Distinguished Engineer
> EMC Corporation, 176 South St., Hopkinton, MA? 01748
> +1 (508) 293-7953???????????? FAX: +1 (508) 293-7786
> [email protected]??????? Mobile: +1 (978) 394-7754
> ----------------------------------------------------
> 
> _______________________________________________
> nsis mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/nsis