RE: [NSIS] Questions about draft-ietf-nsis-req-09.txt

["Hancock, Robert" <[e-mail]>]

i can make some tiny clarifications (maybe):

> I had a few questions regarding the nsis req. draft
> and would appreciate any help. 
> 
> In the following paragraph from the draft:
>     
>   "2. Something that assists in managing state further
> along the signaling path, the NSIS Forwarder.  
>     
>    The NSIS Forwarder does not interact with higher
> layers, but interacts with the NSIS Initiator, NSIS
> Responder, and possibly one or more NSIS Forwarders on
> the signaling path, edge-to-edge or end-to-end."
>    
>   I do not completely understand the necessity of
> direct interactions between NSIS Forwarder with NSIS
> Initiator and NSIS Responder. For example, in the
> following diagram:
>   
>   A-B-C-D-E-F
>     |_____|
>        |
>      Domain  
>      
>  Assuming that A and F are NSIS Initiators and
> Responders respectively and that B-C-D-E belong to the
> same domain and are NSIS Forwarders for a particular
> session. Why would C or D need to communicate with
> either of A or F. I may be missing something important
> here and would really appreciate if someone made it
> clear for me.

[reh] in these cases, the interactions may be with neighbour
NEs only (C talks to B which talks to A). 

> 
> In the following paragraph from the draft:
>     
>   "6. NSIS assumes layer 3 routing and the
> determination of next data node selection is not done
> by NSIS."
>    
> Would this requirement have to change in any way if we
> decide to allow the NSIS Initiator some (partial or
> complete) control over the path through which the data
> for a particular session must flow?

[reh] the node with NI functionality could do this, but
it would not be part of NSIS functionality to specify how.
In other words, there could be node implementations which 
coordinate routing and signalling, but this doesn't alter
the signalling requirement.

> 
> From the draft:
> 
> "  5.1.2 NSIS MUST be designed modularly  
>     
>    A modular design allows for more lightweight
> implementations, if fewer features are needed.
> Mutually exclusive solutions are supported. Examples
> for modularity: 
>       
>    - Work over any kind of network (narrowband versus
> broadband, error-prone versus reliable, ...). This
> implies low bandwidth signaling, and elimination of
> redundant information MUST be supported if necessary. 
> 
>     
>    - State setup for uni- and bi-directional flows is
> possible 
>        
>    - Extensible in the future with different add-ons
> for certain environments or scenarios  
>     
>    - Protocol layering, where appropriate. This means
> NSIS MUST provide a base protocol, which can be
> adapted to different environments. "
> 
> I was particularly impressed with the above
> requirement. The requirement for Security is known to
> be different in different segments of the network and
> IMO is a good candidate as an optional composable
> module. If soft-state approach is chosen, refresh
> reduction may also be a good candidate since it
> depends on the number of sessions for which the NSIS
> entity has to preserve state. Moreover any NSIS entity
> should be able to dynamically compose its stack of
> modules to serve the NSIS protocol. This becomes
> apparent in wireless networks where the requirements
> for any NSIS entity change dramatically depending on
> its position (in the access or core) in the network.
> This does not affect the draft's suggestions about
> handling handovers since NSIS sessions may have to be
> resignalled in such a case anyway.
> 
> One question I had was: Would the role of the NSIS
> entity (NI,NF,NR) have any affect on what modules
> compose its set of features for the NSIS protocol. How
> would we handle situation where a single NSIS entity
> has multiple roles for multiple sessions that it is a
> part of? Running multiple processes might be an
> overkill and defeat the whole purpose.

[reh] I think the answer to the first question in this last
paragraph is 'yes, obviously' and to the second is 'it
is up to the implementor'.

> 
> From the draft:
> 
> "  5.4.5 Grouping of signaling for several micro-flows
> MAY be provided 
>     
>    NSIS MAY group signaling information for several
> micro-flow into one signaling message. The goal of
> this is the optimization in terms of setup delay,
> which can happen in parallel. This helps applications 
>   requesting several flows at once. Also potential
> refreshes (in case of a soft state solution) might
> profit from grouping.  
>        
>    However, the network needs not know that a
> relationship between the grouped flows exists. There
> MUST NOT be any transactional semantic associated with
> the grouping. It is only meant for optimization
> purposes."
> 
> Let us assume that three NSIS sessions exist 1) A (NI)
> and G(NR),
> 2) B(NI) and H (NR) and 3) C(NI) and I(NR)
>    
> A---+               +---G
>     |               |  
> B---+---D---E---F---+---H
>     |               | 
> C---+               +---I
> 
> Does the grouping of signaling for micro-flows apply
> to this situation. In other words, would D attempt to
> group signaling information for the three NSIS
> signaling messages it receives from A, B and C?

[reh] see the framework discussion on bundling. the interpretation in
this example would be 'D could put the messages in the same
packet if it found it convenient to do so' (but whether any
implementation would attempt to do so is another matter). this
is really a protocol design question.

>     
> Lastly, there was no mention of prioritization of NSIS
> resource requests - for e.g. a NSIS request with
> higher priority may terminate an existing NSIS
> reservation and make the resources available. Has it
> been left out on purpose or covered implicitly
> somewhere in the draft?

[reh] this is being discussed as something which can be
achieved within the QoS signalling application protocol. 
the need for the functionality is understood, but currently
it's not clear that there needs to be a direct requirement
on the protocol itself.

> 
> Thanks for patiently going through the email. I would
> appreciate any comments and/or answers to these
> questions.
> 
> Regards,
> Vishal

hope this helps,

r.

> 
> __________________________________
> Do you Yahoo!?
> Yahoo! SiteBuilder - Free, easy-to-use web site design software
> http://sitebuilder.yahoo.com
> 
> _______________________________________________
> nsis mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/nsis
> 

_______________________________________________
nsis mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/nsis