Subject: [NSIS] Issue list for MRI, packet_classifier, flow specficiation, etc..

From: "Cheng Hong" <[email-masked]>
Date: Tue, 25 Oct 2005 12:52:31 +0800

Hi all,

We have presented a internet draft regarding the Flow ID issues in last
IETF meeting, and was given a action point to provide an issue list on
that topic for further discussion. Due to all sorts of reasons, it has
been delayed. It seems that the group is now talking about the relevant
issues in several different threads. So, in a related note, below is the
relevant issues we have identified (it is also covered in the updated
draft
http://www.psl.com.sg/internet-drafts/draft-cheng-nsis-flowid-issues-02.
txt).

cheers

Cheng Hong

==========================

- synchronization issue of the MRI and flow specification
  The MRI, as its name suggests, it is mainly designed for the message
routing. However, in the current NSIS framework, it is also used for
deriving the packet classification (flow specification) information. In
certain cases, it is desired to have a more flexible relationship
between the two. 

These cases includes:
 = Multiple addresses flow specification support. The MRI is not able to
properly signal multiple address combination for the packet
classification, even with the assistance of the wildcarding and
PACKET_CLASSIFIER. 

 = Predictive signaling support. In this case, the specific flow
specification (packet classification) information may not be able when
the signaling is needed. Due to the dependency on the MRI, to
change/update the packet classification info will result in a different
MRI/Flow ID, which is not desirable since it means re-establishment of
the signaling state.

 = Address manipulation support without change the signaling state. This
is required in some scenario, e.g. some application progressively adds
in flows, and the tunneling support. Current packet classifier
definition requires change of the MRI/Flow ID when the (packet
classification) address information changes.

(More details are available in
http://www.psl.com.sg/internet-drafts/draft-cheng-nsis-flowid-issues-02.
txt)

 = Some NSLP application requirements. Certain NSLP application desires
to have a flexibility to signaling some flow specification that is not
covered in MRI. (e.g. as per discussion of the metering QoS NSLP in
 metering NSLP relevant issues discussed in
http://www.ietf.org/mail-archive/web/nsis/current/msg05591.html) 

In conclusion, we see some requirement for a greater flexibility for
signaling the flow specification than the current practice (using MRI
only).

==========================
However, to introduce that flexibility, we also see some problem/issues.

- NAT traversal. Current MRI based flow specification signaling only
requires update of the MRI when goes through the NAT. However, if other
objects are introduced, the NAT will need to update both objects, and
need to guarantee that the same rules are applied on them.
	
- Place to carry the packet classifier. This has been discussed
extensively in the tread
http://www1.ietf.org/mail-archive/web/nsis/current/msg05583.html There
are different options: place in QoS-NSLP, or in QSPEC. For placing it in
QoS-NSLP, a stackable packet_classifier is needed to support stackable
QSPEC. But, to place it in QSPEC, some NAT traversal problem is
envisaged.

- There are also some issues that has been mentioned in Ali's post
regarding the flexibility 
http://www.ietf.org/mail-archive/web/nsis/current/msg05605.html

- Implementation(debugging) considerations
  Some concerns has been raised about the difficulties in the
implementation and debugging once more flexibility is introduced. This
has to be a tradeoff between the function needs (or signaling
efficiency) and the implementation complexity. 

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

---

From: Thomas Herzog <[email-masked]>
Date: Tue, 25 Oct 2005 10:58:36 +0200

Hi, all,

I am currently implementing a GIST instance, which can be configured to use 
Late State installation as described in Section 4.4.1.

Section 4.4.1 states, "the GIST-confirm must contain sufficient information to 
allow it to be processed identically to the original Query".

However, a GIST-Confirm does NOT contain a stack configuration data object (it 
is furthermore said, that even the stack proposal object it carries is a 
mirror of the one it received in the confirm).

When the Querier Node wants to set up a C-Mode Message Association, it will 
send the Confirm via the newly created C-Mode connection.

The Responder now must install the MA_HOLD_TIME of the Querier, so its MA 
State Machine can set the SendHello timer accordingly (GIST Hellos are sent 
from either direction to hold the MA open).

Unfortunately, in the late state installation case, it has no access to the 
Querier's MA_HOLD_TIME, as this would be carried in the stack configuration 
object, which is not included. (and even if it would be included, it should 
be the mirrored one from the Response, fitting to the stack proposal 
object...)

So in my eyes, with the current draft, there is no possibility to set up a 
Message Association in Late State Installation case!

Can someone elaborate on this and tell me if I am totally mistaken?

Cheers,
Thomas