Subject: RE: [NSIS] WG Last Call on draft-ietf-nsis-req-06.txt

From: "Louis-Nicolas Hamer" <[email-masked]>
Date: Wed, 22 Jan 2003 15:27:15 -0500

All,

Issue Name: ?
Submitter name: Louis-Nicolas Hamer
Submitter email address: [email-masked]
Date first submitted: 22/01/2003
Reference: none
Document: draft-ietf-nsis-req-06.txt
Comment type: T 
Priority:  2  
Section: 10.3

I have a few comments on section 10.3 UMTS access.
Sorry for sending the late comments.

Section 10.3 provides a good description of the UMTS access overall 
architecture for 3GPP release 5. But, it then speculates on how NSIS
could fit into the 3GPP release 6, which is still not yet defined by the
way. 
Although, I agree NSIS could indeed have a place in 3GPP release 6, 
I can't agree with the way it is depicted in the draft currently.

First, I am not convinced the PCF is the right place to locate the NSIS
Initiator. Why not consider the GGSN? Or the UE?
Secondly, if it would be located in the PCF (or the GGSN for that matter),
what
would be the value-added? I personally think the important section of the
network
where nsis signaling would be needed is at the access level, not in the
backbone network.
So why originate NSIS after the access network? Value is limited IMHO.

I think having this example, as it is currently is not acceptable. I propose
we clean it up:
	-maybe we can agree on a more acceptable example usage of nsis in
UMTS access?
	-maybe we could instead list all of the possible usages (instead of
listing only one)
	-or strip out the example all together (I would prefer not too).

I am not sure who contributed this section, so I guess in order to achieve
closure, it would be best
if the contributors contacted me directly or through the mailing list.
Unless the chair (or someone else) has a better way forward.

Cheers,

L-N

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: Wednesday, January 22, 2003 3:23 AM
> To: [email-masked]; [email-masked]
> Subject: RE: [NSIS] WG Last Call on draft-ietf-nsis-req-06.txt
> 
> 
> John, 
> 
> here are some of my issues to the document. Sorry for posting 
> them late.
> 
> Issue Name: 
> Submitter name: Anders Bergsten
> Submitter email address: [email-masked]
> Date first submitted: 03-01-20
> Reference: -
> Document: draft-ietf-nsis-req-06.txt
> Comment type: T
> Priority:  2
> Document Section: 2, pg 3, last paragraph
> Rationale/Explanation of issue: Definition of 
> Receiver-initiated signaling protocol seems flawed. The 
> definition states that the NSIS responder _initiates_ the 
> reservation on behalf of the receiver. According to the 
> definition of NSIS Responder, the NSIS Responder _responds_ 
> to NSIS messages. The NSIS Responder does not initiate a 
> message, hence, the definition is flawed. The definition of 
> Receiver-initiated signaling protocol should be defined by 
> where the NSIS Initiator is situated, not where the NSIS 
> Responder is situated. Therefore I propose a change to 
> something similar to the below. 
> 
> Requested change: 
> "Receiver-initiated signaling protocol: A receiver-initiated 
> signaling protocol is a protocol where the resources that the 
> signaling protocol should reserve is situated topologically 
> closer to the source than the NSIS Initiator is. This means 
> is that the resource management functions need to be 
> processed from the NSIS Initiator back towards the sender."
> 
> 
> Issue Name: 
> Submitter name: Anders Bergsten
> Submitter email address: [email-masked]
> Date first submitted: 03-01-20
> Reference: -
> Document: draft-ietf-nsis-req-06.txt
> Comment type: T 
> Priority:  2 (?)
> Document Section: 5.2.2
> Rationale/Explanation of issue: The section contain two 
> different and possibly opposing requirement. The title says 
> "No constraint MUST be posed on the signaling..." and page 
> 12, paragraph 5 says "... NSIS signaling used between those 
> virtual routers MUST follow the same path as the data". These 
> are two different requirements where the second actually pose 
> a contraint on the signaling path. 
> 
> Requested change: I personally prefer the second requirement 
> and propose to use only that. This requirement states that it 
> is some contraint on the path followed, which I think is 
> good. I think it also sufficiently covers both the "bandwidth 
> broker" and on-path alternatives to signaling. If people 
> still prefer the first, I would like the requirement to state 
> the following: "The only constraint on the signaling and NSIS 
> forwarders is that they follow the correct AS-path" (or some 
> equivilant term for AS-path).
> 
> 
> Issue Name: 
> Submitter name: Anders Bergsten
> Submitter email address: [email-masked]
> Date first submitted: 03-01-13
> Reference: -
> Document: draft-ietf-nsis-req-06.txt
> Comment type: T 
> Priority:  2
> Document Section: 5.3.4
> Rationale/Explanation of issue: "A request for service MUST 
> be answered at least with a yes or no". This does not state 
> by whom the reply should be sent, neither is it clear enough 
> on how to be interpreted. The only thing this adds to me is 
> uncertainty - there is a risk that someone interpretes this 
> as "if I have sent a request I can expect a reply", ie "The 
> network MUST answer a request for service". This is 
> impossible to promise, since packets can be lost. 
> 
> Requested change: I prefer to keep the requirement in the 
> title and let that be the requirement. This requirement is 
> slightly different than what is written within the text, and 
> it talks about "success" of a service. If the requirement in 
> the text should be interpreted as "A NSIS responder MUST 
> answer a request for service", I want that stated. Thus, I 
> request one of two resolutions to this issue: 
> 	1) Use only the requirement in the title (only a 
> success needs to be reported) and remove the "clarifying" 
> requirement in the text.
> 	2) Add information on WHO must answer to the request 
> (Something along, "The NSIS responder MUST reply with at 
> least a yes/no").
> 
> 
> Issue Name: 
> Submitter name: Anders Bergsten
> Submitter email address: [email-masked]
> Date first submitted: 03-01-20
> Reference: -
> Document: draft-ietf-nsis-req-06.txt
> Comment type: T 
> Priority:  2
> Document Section: 5.4.5
> Rationale/Explanation of issue: The requirement ("the network 
> MUST NOT know that a relationship between the group flows 
> exists", etc) in last paragraph of the section is a very hard 
> requirement to meet up with, I think. The interaction between 
> routing and state maintainance causes some problems here. I 
> start with a pure on-data-path signaling scenario. If a 
> router is to maintain state and get a group of state 
> requests, it must assume that they actually belong to him, 
> otherwise it does not make sense. This requires either that 
> the previous node does group flows together that have a 
> relation with next-hop node or that the node can force 
> relationship onto a group of flows (this method is used by 
> MPLS), where we control the path. If we do not allow for "the 
> network" to know relationships between flows, a node cannot 
> assume that the resource belongs to him and need to have a 
> method to find the right owner of the flow - which may be 
> harder to solve than allowing a node to know a r! elationship 
> between flows. 
> Requested change: Not sure how to resolve the issue, 
> unfortunately. The best thing would be to remove the 
> paragraph and leave only the requirement on that NSIS MAY 
> group flows. 
> 
> 
> Then I have a general comment about the use of MUST/SHOULD... 
> I feel there are too many requirements that are MUSTs, and I 
> am not sure that it is understood how these requirements is 
> met up by a protocol (ie what is the cost for having to 
> implement this). For example, what is the implications of 
> this requirement "State MUST be addressed independent of flow 
> identification"? I would request that the MUSTs/SHOULDs etc 
> is not to be interpreted as in RFC2119 as I believe that 
> would be hard to find a protocol that match all the MUSTs. I 
> would request to use must/should/may instead so that 
> subsequent work do not interprete them as "hard" 
> requirements, but rather as indications of requirement. 
> 
> Anders
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]
> > Sent: den 8 januari 2003 02:04
> > To: [email-masked]
> > Cc: [email-masked]
> > Subject: [NSIS] WG Last Call on draft-ietf-nsis-req-06.txt
> > 
> > 
> > Dear all,
> > 
> > Marcus Brunner has submitted an updated version of the
> > requirements document.  He feels that he has addressed all of 
> > the remaining open issues, and we feel that it is ready for 
> > WG last call.  There are a number of editorial nits, but 
> > otherwise the document is in good shape.
> > 
> > Therefore, I am asking the working group to review the
> > document and submit any issues found.
> > 
> > The working group last call will last until Wednesday January
> > 22nd, 4 PM Pacific Coast Time.
> > 
> > I will send a subsequent mail outlining the procedure for
> > submitting issues.
> > 
> > thanks,
> > John
> > _______________________________________________
> > nsis mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/nsis
> > 
> _______________________________________________
> nsis mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nsis
>

---

From: Kuntal Chowdhury <[email-masked]>
Date: Wed, 22 Jan 2003 16:39:39 -0600

Hi all,
There is a need to capture the scope of signaling (NSIS) in all 3G 
wireless networks besides UMTS (e.g. need to cover cdma2000). Otherwise, 
it gives a false impression that, the NSIS requirements are UMTS 
centric. I read the sections 10.2 and 10.3. There is a good similarity 
between 3GPP and 3GPP2 IP networks. The following is my attempt to 
generalize the Figure:

                            +--------+
                 +----------| P-CSCF |-------> SIP signaling
                /           +--------+
               / SIP            :
              :             +--------+         +----------------+
              :             | Policy |         | NSIS Forwarder |
              :             +--------+         +----------------+
              :                 :                 |
              :                 : COPS            |
              :                 : 	         |
            +----+          +--------+            |
            | UE |----------| Access |------------+	   +----+	
            +----+          | Gateway|----------------------| ER |
                            +--------+      		   +----+	

I also agree with Louis that UE and/or the Access Gateway are the most 
natural candidates for NSIS initiator. Therefore I changed the above 
figure to reflect that. There is also similarity between UMTS/GPRS and 
cdma2000 radio link QoS setup e.g. UMTS creates different radio bearers 
with different QoS needs and in cdma2000 the same is done with multiple 
service instances. If my suggestion is agreeable, then I will be happy 
to provide updated text for section 10.2 and 10.3.

Regards,
Kuntal

Hamer, Louis-Nicolas [CAR:DR13:EXCH] wrote:
> Secondly, if it would be located in the PCF (or the GGSN for that 
> matter), what
> would be the value-added? I personally think the important section of 
> the network
>         -maybe we can agree on a more acceptable example usage of nsis 
> in UMTS access?
>         -maybe we could instead list all of the possible usages (instead 
> of listing only one)
> I am not sure who contributed this section, so I guess in order to 
> achieve closure, it would be best