From nsis-bounces@ietf.org Thu Nov 01 19:26:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InjPv-0005Lg-Ln; Thu, 01 Nov 2007 19:25:39 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1InjPv-0005LM-BK for nsis-confirm+ok@megatron.ietf.org; Thu, 01 Nov 2007 19:25:39 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InjPu-0005Hp-V3 for nsis@ietf.org; Thu, 01 Nov 2007 19:25:39 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1InjPj-0002kA-8X for nsis@ietf.org; Thu, 01 Nov 2007 19:25:28 -0400 Received: (qmail invoked by alias); 01 Nov 2007 23:25:23 -0000 Received: from ip-90-187-154-134.web.vodafone.de (EHLO [90.187.154.134]) [90.187.154.134] by mail.gmx.net (mp058) with SMTP; 02 Nov 2007 00:25:23 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18af7tf3gEap4AaYreeMdxXJTk3RyR/wvZzh9zBpD /C4mNcKu5/gAsA Message-ID: <472A6062.5080803@gmx.net> Date: Fri, 02 Nov 2007 00:25:22 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "nsis@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3a331e4a192f4d33f18e6f8376287cf6 Subject: [NSIS] RMD Comments X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Georgios, Hi all, I am working my way through the RMD QOSM specification. I have a few comments: Major comment: -------------- * From the IANA registry I understand that the PHR Container is a QSPEC parameter. Correct? If it is then there is a problem since the "Container ID" is supposed to be a single value registered for the name of the object. You cannot assign different IDs to it, such as PHR_Resource_Request, PHR_Release_Request, PHR_Refresh_Update To resolve the problem I would put the "Container ID" into a separate field. Not a big change. ------------------- * The IANA consideration section is a mess. 6. IANA Considerations RMD-QOSM requires a new IANA registry for the RMD QoS Model Identifier. It is a 8-bit value, carried in the field of the QSpec object [QSP-T]. [hannes] I think you want to say that " A new QOSM ID ("RMD QOSM") needs to be assigned by IANA. The value has to be placed into the QSPEC Type registry that was created with [ref-to-QSPEC]. " RMD-QOSM defines 2 new objects for the QSpec Template: PHR container and PDR container, see 4.1.2 and 4.1.3. For these new containers, new IDs in the QSpec Template Object Type registry should be assigned. [hannes] You should write: " The following new parameters are registered in the Parameter ID registry that was created with [ref-to-QSPEC]: Value Parameter ID --------------------------------+------------------------ To-be-assigned-by-IANA | PHR Container To-be-assigned-by-IANA | Bandwidth To-be-assigned-by-IANA | PDR Container --------------------------- Minor comments: --------------- * Figure 4 and Figure 5 I don't know what format is described with this figure. Is Figure 4 a snippet of Parameter defined in the QSPEC? -------------------- * Delete the following sentence: Note that the Parameter ID is equal to Bandwidth_ID. After IANA assigns the proper ID value to the parameter then the Bandwdith_ID term has to be replaced accordingly. Just replace the "Parameter ID" in the figure with "Bandwidth ID". ---------------------- * The figure with parameter format has no figure #. * : 1 bit. When set to "1" it indicates that the resources/bandwidth carried by a tearing RESERVE MUST not be released. --> MUST NOT be ... ---------------- More comments --------------------------------------------------------- * I am curious what the per flow intra-domain QoS-NSLP states actually mean. I thought that RMD is particularly targeting non-per flow intra-domain states. ----------- * The protocol has a number of options. A couple of very fundamental deployment choices are listed at beginning of Section 3.2.3. Is there are single mandatory-to-implement variant? ----------------- * I don't understand this sentence: " The RMD QoS model functionality is notified by reading the parameter of the "PDR Container" that the reservation has been successful. " ----------------- * I am not sure what you mean by "QoS-NSLP" functionality in the following sentence: " Furthermore, the INFO_SPEC object SHOULD be read by the QoS-NSLP functionality. " * Why do you say that the values of the INFO_SPEC object "SHOULD" be: " In case of successful reservation the INFO_SPEC object SHOULD have the following values: * Error Severity Class: Success * Error Code value: Reservation successful " rather than MUST. --------------------------- * "the SCOPING flag MUST not be set, meaning that a default scoping of the message is used. " ... flag MUST NOT ... ----------------------------------- * Section 4.6.1.1.2: * " Note that the DSCP value MUST be obtained from the MRI values obtained from GIST. The value of the DSCP value SHOULD be obtained via the MRI parameters that the QoS-NSLP receives from GIST. Duplicate sentence. Why not to say "MUST" instead of SHOULD? Where else would you get the prarameters from. * " * If the bandwidth allocated for the PHB_high_priority traffic is fully utilized, and a high priority request arrives, other policies can be used, which are beyond the scope of this document." ... other policies can be used for what? For granting the request ? * Furthermore, the "B" (BREAK) QoS-NSLP flag in the end to end RESERVE message MUST not be set and it MUST be unset if it was set, see QoS-NSLP-RMF API described in QoS-NSLP. ... MUST NOT ... Why do you want to clear the B flag? * " * the value of the field of the PDR container MUST be equal to the value of the parameter of the PHR container that was carried by its associated intra-domain RESERVE(RMD-QSpec) message." Why is this necessary? * the value of the Parameter/Container ID field of the PDR container MUST be set "PDR_7" (i.e., PDR_Reservation_Report); Why is this specific value used? * * Furthermore, an initial QSpec object MUST be included in the RESPONSE message. The parameters included in the QSPEC object are copied from the original values. About what RESPONSE message are we talking about? In all other cases so far you distinguished between the e2e and the intra-domain RESPONSE. -------------------------------------------------- * Section 4.6.1.4: If a QNE edge or QNE Interior node is not able to reserve the number of requested resources, the "PHR_Resource_Request" that is associated with the parameter MUST be marked. How is it marked? ------------------------- * Section 4.6.1.5 "If a refresh RESERVE message does not arrive at a QNE Interior node within the refresh time-out period then the resources associated with this message are removed." How do you remove resources based on a non-received message? "However, in the situation that an end-to-end (tear) RESERVE is retransmitted, see Section 5.2.4 in [QoS-NSLP], then this message MUST not initiate an intra-domain (tear) RESERVE message. This is because the RMF values related to the end-to-end (tear) RESERVE message have been already released during the process of the original (initial) end-to-end (tear) RESERVE message." In short you want to say that when resources have been released already then you do not release them again. ... use MUST NOT .... if you want to keep the above listed text. * In Section 4.6.1.5 you do a lot of calculation on the T_Lag. Unfortunately, you do not expain why you do all the calculation. -------------------------------------------------- * 4.6.1.2.3 " The QSpec that was carried by the end to end RESERVE belonging to the same session as this end-to-end RESPONSE is included in this message." When you say "this message" then to what message do you refer? * To which context does this statement refer " The "E" flag associated with the QSpec object and the "E" flag associated with the parameter are set. " This paragraph is totally confusing. -------------------------------------------------------- * 4.6.1.3.1 * Up to this section I have not understood what the "single-" vs. "multiple-" domain stuff is about . " In a single-domain case the PDR container field is not needed in the message. " * "the PDR has to be processed and removed by the RMD-QOSM functionality in the QNE Ingress node. The RMD-QOSM functionality is notified by the parameter of the PDR container that the refresh procedure has been successful or unsuccessful." Does the first ingress node remove the PDR container? What does the last sentence mean? More comments --------------------------------- * Section 4.6.1.4. * "If a QNE edge or QNE Interior node is not able to reserve the number of requested resources, the "PHR_Resource_Request" that is associated with the parameter MUST be marked." How is it marked? ------------------------------------------ * PDR container and a PHR Container. Section 4.1.2. and 4.1.3 just say "This is the container." but do not really explain why they need to exist. I think that it would be really important to say something about it. ----------------------- * Why do you need the value? For statistical purposes? More comments: ------------------- With an aggregate reservation the timeout for a reservation refers to the entire aggregate. Hence, if there is a timeout then the entire aggregate is removed. Correct? ------------------------ Is the object mandatory in an intra-domain RESERVE? Reading Section 4.6.1.1. I didn't get the impression. Reading Section 4.6.1.3.2 I got the impression it is mandatory: " Any QNE edge or QNE Interior node that receives a "PHR_Refresh_Update" field MUST identify the traffic class state (PHB) (using the parameter). " ----------------------- In Section 4.6.1.3.1 you write: " Most of the non-default values of the objects contained in this message MUST be used and set by the QNE Ingress in the same way as described in Section 4.6.1.1. The following objects are used and/or set differently: " Still, you list the following statement although it is written in the same way in Section 4.6.1.1: * The flag REPLACE MUST be set to FALSE = 0; ---------------------------------- * "When the RMD-RMF of a QNE edge or QNE Interior node processes a "PHR_Release_Request" PHR container it MUST identify the parameter and estimate the time period that elapsed after the previous refresh, see also Section 3 of [CsTa05]. The sentence should say "QNE egress and interior nodes ..." The ingress is not included since it sends the PHR_Release_Request. ------------------------- * There is something wrong with the description of the Partial Release Procedure since the description assumes that the PHR container contains the parameter. The PHR container only contains the parameter. Example: " * the value of the parameter of the PDR container included in the received PDR container (with =1 and parameter of the "PHR Container". " The following text only works if the RESERVE message contains a PDR container, which is currently not mandated. " Furthermore, the QNE MUST perform the following procedures. If the values of the and parameters included in the "PHR_Resource_Release" PHR container are ( and =0) then the value MUST be compared with the calculated value." --------------------------- * Furthermore, somewhere in Section 4.6.1.5.2 you write: "Note that the above described procedure applies to the situation that the QNE edges maintain a per flow QoS-NSLP reservation state." It would be good to know which parts exactly relate to the per-flow vs. the aggregate reservation state since there is obviously a lot of text "above". I am not sure why you think that the partial release procedure would only be applicable to the per-flow reservation state. Ciao Hannes _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Nov 02 03:13:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Inqgy-0001Sm-Gc; Fri, 02 Nov 2007 03:11:44 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1Inqgx-0001SV-Gh for nsis-confirm+ok@megatron.ietf.org; Fri, 02 Nov 2007 03:11:43 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Inqgx-0001Rj-2i for nsis@ietf.org; Fri, 02 Nov 2007 03:11:43 -0400 Received: from rotterdam.ewi.utwente.nl ([130.89.10.5]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Inqgv-0005R2-Cb for nsis@ietf.org; Fri, 02 Nov 2007 03:11:42 -0400 Received: from webmail.cs.utwente.nl (janus.ewi.utwente.nl [130.89.10.26]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with SMTP id lA27BRcU020283; Fri, 2 Nov 2007 08:11:27 +0100 (MET) Received: from 84.82.109.231 (auth. user karagian@imap1.ewi.utwente.nl) by webmail.cs.utwente.nl with HTTP; Fri, 02 Nov 2007 07:11:27 +0000 To: "Hannes Tschofenig" , "nsis@ietf.org" Subject: Re: [NSIS] RMD Comments Date: Fri, 02 Nov 2007 07:11:25 +0000 X-Mailer: IlohaMail/0.8.13 (On: webmail.cs.utwente.nl) Message-ID: In-Reply-To: <472A6062.5080803@gmx.net> From: "Georgios Karagiannis" Bounce-To: "Georgios Karagiannis" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Fri, 02 Nov 2007 08:11:37 +0100 (MET) X-Spam-Score: 1.8 (+) X-Scan-Signature: 8bebc843ecf489bb7d907f63ccb001af Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Hannes Thank you very much! Please see some answers in line! Best regards, Georgios On 11/1/2007, "Hannes Tschofenig" wrote: >Hi Georgios, >Hi all, > >I am working my way through the RMD QOSM specification. I have a few comment= s: > > Major comment: > -------------- > > * From the IANA registry I understand that the PHR Container is a > QSPEC parameter. Correct? > > If it is then there is a problem since the "Container ID" is supposed > to be a single value registered for the name of the object. You cannot > assign different IDs to it, such as PHR_Resource_Request, > PHR_Release_Request, PHR_Refresh_Update Georgios: Not really! The Container ID is similar to Parameter ID. You can have as many as many values as the containers you want to have! > > To resolve the problem I would put the "Container ID" into a separate > field. Not a big change. Georgios: I am not sure that this is a problem, since, similar to Parameter ID, you can use more values for the Container ID. > >------------------- > > * The IANA consideration section is a mess. > > 6. IANA Considerations > > RMD-QOSM requires a new IANA registry for the RMD QoS Model > Identifier. It is a 8-bit value, carried in the Type> field of > the QSpec object [QSP-T]. > > [hannes] I think you want to say that > > " > A new QOSM ID ("RMD QOSM") needs to be assigned by IANA. The value has > to be placed into the QSPEC Type registry that was created with > [ref-to-QSPEC]. > " Georgios: Agree! thank you very much! > RMD-QOSM defines 2 new objects for the QSpec Template: PHR container > and PDR container, see 4.1.2 and 4.1.3. For these new containers, new > IDs in the QSpec Template Object Type registry should be assigned. > > > [hannes] You should write: > > " > The following new parameters are registered in the Parameter > ID registry that was created with [ref-to-QSPEC]: > > Value Parameter ID > --------------------------------+------------------------ > To-be-assigned-by-IANA | PHR Container > To-be-assigned-by-IANA | Bandwidth > To-be-assigned-by-IANA | PDR Container > >--------------------------- Georgios: Agree! thank you very much! > > > > Minor comments: > --------------- > > * Figure 4 and Figure 5 > > I don't know what format is described with this figure. Is > Figure 4 a snippet of Parameter defined in the QSPEC? Georgios: Yes! We can mention this in the text! > > >-------------------- >* Delete the following sentence: > > Note that the Parameter ID is equal to > Bandwidth_ID. After IANA assigns the proper ID value to the > parameter then the Bandwdith_ID term has > to be replaced accordingly. > > Just replace the "Parameter ID" in the figure with "Bandwidth ID". Georgios: Okay > >---------------------- > > * The figure with parameter format has no figure #. > > * : 1 bit. When set to "1" it indicates that the > resources/bandwidth > carried by a tearing RESERVE MUST not be released. > > --> MUST NOT be ... Georgios: Okay! > >---------------- > >More comments > >--------------------------------------------------------- > > * I am curious what the per flow intra-domain QoS-NSLP states actually > mean. I thought that RMD is particularly targeting non-per flow > intra-domain states. Georgios: It is related to the per flow states that are maintained at the edges! The per-flow intra-domain QoS-NSLP means that there are per flow states at the edges that are used to store information associated with RMD-QOSM. >----------- > > * The protocol has a number of options. > A couple of very fundamental deployment choices are listed at > beginning of Section 3.2.3. Is there are single mandatory-to-implement > variant? Georgios: We have not defined a single mandatory-to-implement variant! We, however identified which deployment choices can be combined together in Section 3.2.3. > >----------------- > > > * I don't understand this sentence: > > " The RMD QoS model functionality is notified by reading the > parameter of the "PDR Container" that the reservation has been > successful. " Georgios: We can chnge it as: "The reservation has been successful if the bit carried by the "PDR Container" is not set and equal to "0"." > >----------------- > >* I am not sure what you mean by "QoS-NSLP" functionality in the > following sentence: > > " > Furthermore, the INFO_SPEC object SHOULD be read by the QoS-NSLP > functionality. > " Georgios: What about: "The "INFO_SPEC" is processed as defined in the QoS-NSLP specification." > * Why do you say that the values of the INFO_SPEC object "SHOULD" be: > > " > In case of successful reservation the INFO_SPEC object > > SHOULD have the following values: > > * Error Severity Class: Success > * Error Code value: Reservation successful " > > rather than MUST. Georgios: Okay! >--------------------------- > > * "the SCOPING flag MUST not be set, meaning that a default > scoping of the message is used. > " > > ... flag MUST NOT ... Georgios; Okay! > >----------------------------------- > > > >* Section 4.6.1.1.2: > > * " Note that the DSCP value MUST be obtained from the > MRI values obtained from GIST. The value of the DSCP value > SHOULD > be obtained via the MRI parameters that the QoS-NSLP receives > from GIST. > >Duplicate sentence. Why not to say "MUST" instead of SHOULD? > Where else would you get the prarameters from. Georgios: Okay! > * " * If the bandwidth allocated for the PHB_high_priority > traffic is fully utilized, and a high priority request arrives, other > policies can be used, which are beyond the scope of this document." > > ... other policies can be used for what? For granting the request ? Georgios: we have to clarify that the policies are related to how the allocated bandwidth is allocated, rather than policies that e.g., grant the request > > > * Furthermore, the "B" (BREAK) QoS-NSLP flag in the end to end > RESERVE message MUST not be set and it MUST be unset if it was set, > see QoS-NSLP-RMF API described in QoS-NSLP. > > > ... MUST NOT ... Georgios: Okay! > Why do you want to clear the B flag? Georgios: You are right! The text "and it MUST be unset if it was set" should be removed. > > > * " * the value of the field of the PDR container MUST > be equal to > the value of the parameter of the PHR container that was > carried by its associated intra-domain RESERVE(RMD-QSpec) > message." > > Why is this necessary? Georgios: because the PDR container will be sent to the ingress and the M value should be the same as the M value contained in the intra-domain RESERVE message. We will clarify this! > > >* the value of the Parameter/Container ID field of the > PDR container MUST be set "PDR_7" (i.e., PDR_Reservation_Report); > > Why is this specific value used? Georgios: This is a temporary value, that should be used until IANA assigns the values required by RMD-QOSM. In Section 4.1 we explain this point. > > > * * Furthermore, an initial QSpec object MUST be included in the > RESPONSE message. The parameters included in the QSPEC Reserved> object are copied from the original values. > > About what RESPONSE message are we talking about? In all other cases > so far you distinguished between the e2e and the intra-domain > RESPONSE. Georgios: The bullet is associated with the end-to-end RESPONSE. We can emphasize this even more! > >-------------------------------------------------- > >* Section 4.6.1.4: > >If a QNE edge or QNE Interior node is not able to >reserve the number of requested resources, the >"PHR_Resource_Request" that is associated with >the parameter MUST be marked. > > How is it marked? Georgios: You are right! It should say "MUST be marked (i.e., bit MUST be set) > >------------------------- > >* Section 4.6.1.5 > >"If a refresh RESERVE message does not arrive at a >QNE Interior node within the refresh time-out period then the >resources associated with this message are removed." > > How do you remove resources based on a non-received message? Georgios: It should say "then the resources associated with this message are not updated. This will mean that the reserved bandwdith associated with the reduced state is decreased in the next refresh period by the corresponding bandwidth that was not refreshed, see Section 4.3.3." We will clarify this, thanks. > > > "However, in the situation >that an end-to-end (tear) RESERVE is retransmitted, see Section 5.2.4 >in [QoS-NSLP], then this message MUST not initiate an intra-domain >(tear) RESERVE message. This is because the RMF values related to >the end-to-end (tear) RESERVE message have been already released >during the process of the original (initial) end-to-end (tear) RESERVE >message." > > In short you want to say that when resources have been released > already then you do not release them again. > > ... use MUST NOT .... if you want to keep the above listed text. Georgios: Agree! > > > * In Section 4.6.1.5 you do a lot of calculation on the T_Lag. >Unfortunately, you do not expain why you do all the calculation. Georgios: You are right! We will do that! > >-------------------------------------------------- > >* 4.6.1.2.3 > >" The QSpec that was carried by the end to end RESERVE belonging to >the same session as this end-to-end RESPONSE is included in this >message." > >When you say "this message" then to what message do you refer? Georgios: We refer to the end-to-end RESPONSE message. We will include end-to-end RESPONSE message. > >* To which context does this statement refer " >The "E" flag associated with >the QSpec object and the "E" flag associated with the > parameter are set. " Georgios: The above paragraph refers to the generation of the end-to-end RESPONSE message. Note that values are carried by the end-to-end RESERVE and the values of the are carried by the end-to-end RESPONSE. We will clarify this. > >This paragraph is totally confusing. Georgios: We will try to clarify it! > >-------------------------------------------------------- > > > * 4.6.1.3.1 > > * Up to this section I have not understood what the "single-" vs. > "multiple-" domain stuff is about . > >" In a single-domain case the PDR container field > is not needed in the message. " Georgios: I see what you mean! We will clarify this! > > * "the PDR has to be processed and removed by the RMD-QOSM > functionality in the QNE Ingress node. The RMD-QOSM > functionality is notified by the parameter of the PDR >container > that the refresh procedure has been successful or unsuccessful." > > Does the first ingress node remove the PDR container? > What does the last sentence mean? Georgios: Yes, there is only one ingress node. The second sentence should actually be used as first sentence. > > >More comments --------------------------------- > >* Section 4.6.1.4. > > * "If a QNE edge or QNE Interior node is not able to > reserve the number of requested resources, the > "PHR_Resource_Request" that is associated with > the parameter MUST be marked." > > How is it marked? Georgios: Agree, we will fix this! It should say that it is marked (i.e., bit is set). > > >------------------------------------------ > > * PDR container and a PHR Container. > > Section 4.1.2. and 4.1.3 just say "This is the container." > but do not really explain why they need to exist. > > I think that it would be really important to say something about it. Georgios: Agree, we will fix this! > >----------------------- > > > * Why do you need the value? For statistical purposes? Georgios: No, this is used during the partial release procedure! I thought that we gave examples for the use of each parameter in the containers! > > > > >More comments: ------------------- > >With an aggregate reservation the timeout for a reservation refers to > the entire aggregate. > Hence, if there is a timeout then the entire aggregate is removed. > > Correct? Georgios: yes it is correct! We will include a procedure that solves this issue. >------------------------ > > Is the object mandatory in an intra-domain RESERVE? > > Reading Section 4.6.1.1. I didn't get the impression. > > Reading Section 4.6.1.3.2 I got the impression it is mandatory: > > " Any QNE edge or QNE Interior > node that receives a "PHR_Refresh_Update" field > MUST identify the traffic class state (PHB) (using the > parameter). " Georgios: Thanks, we will fix this! > >----------------------- > > In Section 4.6.1.3.1 you write: > > " > Most of the non-default values of the objects contained in this > message MUST be used and set by the QNE Ingress in the same > way as described in Section 4.6.1.1. The following objects are > used and/or set differently: > " > Still, you list the following statement although it is written in the > same way in Section 4.6.1.1: > > * The flag REPLACE MUST be set to FALSE =3D 0; Georgios: You are right! We will have to remove the sentence above! > >---------------------------------- > >* "When the RMD-RMF of a QNE edge or QNE Interior node processes a >"PHR_Release_Request" PHR container it MUST identify the > parameter and estimate the time period that elapsed >after the previous refresh, see also Section 3 of [CsTa05]. > > > The sentence should say "QNE egress and interior nodes ..." > The ingress is not included since it sends the PHR_Release_Request. Georgios: Yes, you are right! > >------------------------- > >* There is something wrong with the description of the Partial Release >Procedure since the description assumes that the PHR container >contains the parameter. > >The PHR container only contains the parameter. Georgios: You are right! We assumed that this will be carried by the PDR container. However, there is a mismatch in the text. We will fix this by including the parameter into the PHR container and fixing the text where needed. Thus the PHR container will include, in addition to the common header, 2 words, instead of one. > > Example: >" > * the value of the parameter of the PDR container >included in the received PDR container (with =3D1 and > in the parameter of the "PHR Container". > " > > The following text only works if the RESERVE message contains a PDR > container, which is currently not mandated. > " Georgios: Yes! But it is better to include the parameter into the PHR container. > Furthermore, the QNE MUST perform the following procedures. > If the values of the and parameters included in the > "PHR_Resource_Release" PHR container are ( and =3D0) then the > value MUST be compared with the calculated > value." Georgios: Yes, you are right! we will modify it! >--------------------------- > >* Furthermore, somewhere in Section 4.6.1.5.2 you write: > > "Note that the above described procedure applies to the situation that >the QNE edges maintain a per flow QoS-NSLP reservation state." > >It would be good to know which parts exactly relate to the per-flow vs. >the aggregate reservation state since there is obviously a lot of text > "above". Georgios: Agree, we will make it more clear! > I am not sure why you think that the partial release procedure would > only be applicable to the per-flow reservation state. Georgios: This is because the aggregated reservation procedure depends on more than one micro-flows and the way of adding or releasing aggregated resources is different than the method used for the per-flow reservation states. > >Ciao >Hannes > > > > >_______________________________________________ >nsis mailing list >nsis@ietf.org >https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Sat Nov 03 03:15:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IoDAw-0008G9-H4; Sat, 03 Nov 2007 03:12:10 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1IoDAu-0008Cf-Ip for nsis-confirm+ok@megatron.ietf.org; Sat, 03 Nov 2007 03:12:08 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IoDAp-000872-Qs for nsis@ietf.org; Sat, 03 Nov 2007 03:12:03 -0400 Received: from perseverance-96.encs.concordia.ca ([132.205.96.94] helo=perseverance.services.encs.concordia.ca) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IoDAk-0005vV-Ch for nsis@ietf.org; Sat, 03 Nov 2007 03:11:58 -0400 Received: from localhost (nul-web@tact-96.encs.concordia.ca [132.205.96.48]) by perseverance.services.encs.concordia.ca (envelope-from gao_b@cs.concordia.ca) (8.13.7/8.13.7) with ESMTP id lA37Btr6019492 for ; Sat, 3 Nov 2007 03:11:55 -0400 X-Received-HTTP: from dsl-207-112-45-54.tor.primus.ca (dsl-207-112-45-54.tor.primus.ca [207.112.45.54]) by mail.encs.concordia.ca (Horde MIME library) with HTTP; Sat, 03 Nov 2007 03:11:54 -0400 Message-ID: <20071103031154.iga0wu8ilo1wkck4@mail.encs.concordia.ca> Date: Sat, 03 Nov 2007 03:11:54 -0400 From: Bo Gao To: nsis@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.1.5) X-Scanned-By: MIMEDefang 2.58 on perseverance.encs.concordia.ca at 2007/11/03 03:11:55 EDT X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Subject: [NSIS] a comment about the Messaging Association State Machine of draft-ietf-nsis-ntlp-14 X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hello, In the section 6.4 Messaging Association Processing, it is said " =20 Timers may also be necessary to detect connection failure (e.g. no =20 incoming connection within a certain period), but these are not =20 modelled explicitly". It would be better to add a timer explicitly to =20 detect the connection failure. If TCP is used for the Messaging =20 Association, we have to use a non-block connect() call. I found that =20 most time, the connect() wouldn't finish the TCP connection right =20 away. If we can add a timer to the state machine, we can retry to do =20 the connect() call whenever the timer expires. If the connect() =20 returns "EISCONN", that means the socket is connected. Then the state =20 machine can transfer to Connected state. Otherwise we can just restart =20 the timer. It would be a better solution than just to use select() to wait for =20 some time after non-blocking connect() call. In the rule 8 of the Responder Node Processing of section 6.3, "start =20 Expire_RNode timer" is better to changed to "(re)start Expire_RNode =20 timer". Also Can anyone tell me when the Messaging Association state machine =20 is created by the Responding Node? Sincerely Bo Gao E-mail:gao_b@cs.concordia.ca _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Nov 05 08:02:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ip1bU-0006xG-JX; Mon, 05 Nov 2007 08:02:56 -0500 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1Ip1ar-00065N-Mo for nsis-confirm+ok@megatron.ietf.org; Mon, 05 Nov 2007 08:02:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ip1ar-00064z-Cz for nsis@ietf.org; Mon, 05 Nov 2007 08:02:17 -0500 Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ip1ap-0005za-Uw for nsis@ietf.org; Mon, 05 Nov 2007 08:02:17 -0500 Received: from sbz-32.cs.helsinki.fi (sbz-32.cs.helsinki.fi [128.214.9.100]) (AUTH: PLAIN cs-relay, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Mon, 05 Nov 2007 15:02:11 +0200 id 000704DA.472F1453.00006354 Received: by sbz-32.cs.helsinki.fi (Postfix, from userid 50703) id DB29B155BA; Mon, 5 Nov 2007 15:02:10 +0200 (EET) Received: from localhost (localhost [127.0.0.1]) by sbz-32.cs.helsinki.fi (Postfix) with ESMTP id D5C92140A8 for ; Mon, 5 Nov 2007 15:02:10 +0200 (EET) Date: Mon, 5 Nov 2007 15:02:10 +0200 (EET) From: Lauri J T Liuhto To: nsis@ietf.org Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Subject: [NSIS] GIST peering concern X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org While implementing our own NSLPs and the API between GIST and NSLPs, we came across something in the current NTLP i-d we think might be a problem. In section 4.3.2 "Local Processing and Validation" it is stated that: "The first option (peering) MUST be chosen if the node is the final destination of the Query message, or if the GIST hop count has reached zero." We think this is problematic for at least two reasons. 1) This removes flexibility from the NSLP application and forces certain behaviour. Thus it complicates NSLP application logic, since the NSLP must be aware of this exception to its peering "wishes". 2) It could be possible to overload resources, such as memory and UDP send rate, of a GIST node. Sending Queries with an (intentionally) low GIST hop-count would lead to nodes being forced to peer, though it is stated in the same section (4.3.2), that a node can decline peering for "overload protection reasons". We suggest that an error message be defined for the case when a flow endpoint does not wish to peer, or that the definition of the "Endpoint Found" message be extended to include this case. Currently section 4.3.4 seems to state, that "Endpoint Found" can only be sent when the NSLP is not present on the GIST node. Regards, Nuutti, Teemu and Lauri -- Lauri Liuhto _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Nov 05 09:12:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ip2gZ-0002tK-Gs; Mon, 05 Nov 2007 09:12:15 -0500 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1Ip2gY-0002r5-3s for nsis-confirm+ok@megatron.ietf.org; Mon, 05 Nov 2007 09:12:14 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ip2gX-0002qa-Ps for nsis@ietf.org; Mon, 05 Nov 2007 09:12:13 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ip2gX-0007J5-IQ for nsis@ietf.org; Mon, 05 Nov 2007 09:12:13 -0500 Received: from ietf.org (stiedprweb1.va.neustar.com [10.91.34.42]) by ns3.neustar.com (Postfix) with ESMTP id 2ED61175CD; Mon, 5 Nov 2007 14:11:43 +0000 (GMT) Received: from mirror by ietf.org with local (Exim 4.43) id 1Ip2g2-0006BO-NG; Mon, 05 Nov 2007 09:11:42 -0500 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 To: acmorton@att.com From: IETF I-D Submission Tool Message-Id: Date: Mon, 05 Nov 2007 09:11:42 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: gash@att.com, cdvorak@att.com, yacine.el_mghazli@alcatel.fr, nsis@ietf.org Subject: [NSIS] New Version Notification for draft-ietf-nsis-y1541-qosm-05 X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org A new version of I-D, draft-ietf-nsis-y1541-qosm-05.txt has been successfuly submitted by Al Morton and posted to the IETF repository. Filename: draft-ietf-nsis-y1541-qosm Revision: 05 Title: Y.1541-QOSM -- Y.1541 QoS Model for Networks Using Y.1541 QoS Classes Creation_date: 2007-11-05 WG ID: nsis Number_of_pages: 15 Abstract: This draft describes a QoS-NSLP QoS model (QOSM) based on ITU-T Recommendation Y.1541 Network QoS Classes and related signaling requirements. Y.1541 specifies 8 classes of Network Performance objectives, and the Y.1541-QOSM extensions include additional QSPEC parameters and QOSM processing guidelines. The IETF Secretariat. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Nov 05 09:20:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ip2o9-0003pG-CO; Mon, 05 Nov 2007 09:20:05 -0500 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1Ip2o7-0003nn-N8 for nsis-confirm+ok@megatron.ietf.org; Mon, 05 Nov 2007 09:20:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ip2o7-0003m5-Bj; Mon, 05 Nov 2007 09:20:03 -0500 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ip2o6-0007u3-7t; Mon, 05 Nov 2007 09:20:03 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 31C03328D1; Mon, 5 Nov 2007 14:20:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Ip2o6-0003ek-3W; Mon, 05 Nov 2007 09:20:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 05 Nov 2007 09:20:02 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: nsis@ietf.org Subject: [NSIS] I-D Action:draft-ietf-nsis-y1541-qosm-05.txt X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Next Steps in Signaling Working Group of the IETF. Title : Y.1541-QOSM -- Y.1541 QoS Model for Networks Using Y.1541 QoS Classes Author(s) : G. Ash, et al. Filename : draft-ietf-nsis-y1541-qosm-05.txt Pages : 15 Date : 2007-11-05 This draft describes a QoS-NSLP QoS model (QOSM) based on ITU-T Recommendation Y.1541 Network QoS Classes and related signaling requirements. Y.1541 specifies 8 classes of Network Performance objectives, and the Y.1541-QOSM extensions include additional QSPEC parameters and QOSM processing guidelines. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nsis-y1541-qosm-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-nsis-y1541-qosm-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-nsis-y1541-qosm-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-11-05091140.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nsis-y1541-qosm-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nsis-y1541-qosm-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-11-05091140.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --NextPart-- From nsis-bounces@ietf.org Mon Nov 12 04:36:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrViS-0008FJ-N4; Mon, 12 Nov 2007 04:36:24 -0500 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1IrViR-0008BM-VE for nsis-confirm+ok@megatron.ietf.org; Mon, 12 Nov 2007 04:36:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrViR-0008AY-LV for nsis@ietf.org; Mon, 12 Nov 2007 04:36:23 -0500 Received: from smtp1.mei.co.jp ([133.183.129.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IrViO-0002aY-2c for nsis@ietf.org; Mon, 12 Nov 2007 04:36:23 -0500 Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp1.mei.co.jp (8.12.11.20060614/3.7W/bulls) with ESMTP id lAC9aCww012715 for ; Mon, 12 Nov 2007 18:36:12 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx2) with ESMTP id lAC9aEY22148 for ; Mon, 12 Nov 2007 18:36:14 +0900 (JST) Received: from epochmail.jp.panasonic.com (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/phillies) with ESMTP id lAC9aDf09926 for ; Mon, 12 Nov 2007 18:36:13 +0900 (JST) Received: by epochmail.jp.panasonic.com (8.12.11.20060308/3.7W/soml28) id lAC9aDDE023106 for nsis@ietf.org; Mon, 12 Nov 2007 18:36:13 +0900 (JST) Received: from [10.238.172.40] by soml28.jp.panasonic.com (8.12.11.20060308/3.7W) with ESMTP id lAC9a7Dw022929; Mon, 12 Nov 2007 18:36:09 +0900 (JST) Date: Mon, 12 Nov 2007 18:36:15 +0900 From: Takako Sanda To: nsis@ietf.org Message-Id: <20071112182126.1E52.SANDA.TAKAKO@jp.panasonic.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.20 [ja] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: sanda.takako@jp.panasonic.com Subject: [NSIS] Request your comments for NSIS Applicability Mobility draft X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi all, Here is a new version of NSIS Applicability Mobility draft. http://geocities.com/panasonic_ietf/draft-ietf-nsis-applicability-mobility-signaling-08.txt Please review this, and send your comments if you have any no later than 16 Feb. In this version, Section 4 (Basic Operations for Mobility Support) especially localized mobility part was mainly updated so that the draft can be harmonized with QoS-NSLP draft. The following parts, described in Open Issues (Section 8), were still kept unchanged. o Cleaning up MIP interaction o Cleaning up Security Consideration o NAT traversal The authors especially need your comments for these open issues:- - whether the cleaning up for MIP interaction part is really necessary - whether the cleaning up for security consideration is really necessary - whether the NAT traversal issue should be discussed in Mobility draft (in addition to in NAT/FW NSLP draft) BR, Takako _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Nov 12 04:55:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrW0q-0000Rx-QY; Mon, 12 Nov 2007 04:55:24 -0500 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1IrW0p-0000Qi-RZ for nsis-confirm+ok@megatron.ietf.org; Mon, 12 Nov 2007 04:55:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrW0p-0000P1-FD for nsis@ietf.org; Mon, 12 Nov 2007 04:55:23 -0500 Received: from smtp1.mei.co.jp ([133.183.129.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IrW0l-0003IO-7X for nsis@ietf.org; Mon, 12 Nov 2007 04:55:23 -0500 Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp1.mei.co.jp (8.12.11.20060614/3.7W/kings) with ESMTP id lAC9tIdX019533 for ; Mon, 12 Nov 2007 18:55:18 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx2) with ESMTP id lAC9tIY00674 for ; Mon, 12 Nov 2007 18:55:18 +0900 (JST) Received: from epochmail.jp.panasonic.com (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/redsox) with ESMTP id lAC9tJk09230 for ; Mon, 12 Nov 2007 18:55:19 +0900 (JST) Received: by epochmail.jp.panasonic.com (8.12.11.20060308/3.7W/soml21) id lAC9tH1L010472 for nsis@ietf.org; Mon, 12 Nov 2007 18:55:17 +0900 (JST) Received: from [10.238.172.40] by soml21.jp.panasonic.com (8.12.11.20060308/3.7W) with ESMTP id lAC9t891010132; Mon, 12 Nov 2007 18:55:11 +0900 (JST) Date: Mon, 12 Nov 2007 18:55:16 +0900 From: Takako Sanda To: nsis@ietf.org Subject: Re: [NSIS] Request your comments for NSIS Applicability Mobility draft In-Reply-To: <20071112182126.1E52.SANDA.TAKAKO@jp.panasonic.com> References: <20071112182126.1E52.SANDA.TAKAKO@jp.panasonic.com> Message-Id: <20071112185336.ADC1.SANDA.TAKAKO@jp.panasonic.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.20 [ja] X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: sanda.takako@jp.panasonic.com X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi all, > Please review this, and send your comments if you have any no later than > 16 Feb. Mistaken. No later than 16 Fri., please :-) cheers, Takako On Mon, 12 Nov 2007 18:36:15 +0900 Takako Sanda wrote: > Hi all, > > Here is a new version of NSIS Applicability Mobility draft. > http://geocities.com/panasonic_ietf/draft-ietf-nsis-applicability-mobility-signaling-08.txt > > Please review this, and send your comments if you have any no later than > 16 Feb. > > In this version, Section 4 (Basic Operations for Mobility Support) > especially localized mobility part was mainly updated so that the draft > can be harmonized with QoS-NSLP draft. > > The following parts, described in Open Issues (Section 8), were still > kept unchanged. > o Cleaning up MIP interaction > o Cleaning up Security Consideration > o NAT traversal > The authors especially need your comments for these open issues:- > - whether the cleaning up for MIP interaction part is really necessary > - whether the cleaning up for security consideration is really > necessary > - whether the NAT traversal issue should be discussed in Mobility draft > (in addition to in NAT/FW NSLP draft) > > BR, > Takako > > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Nov 14 04:35:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsEeP-0005Hs-T6; Wed, 14 Nov 2007 04:35:13 -0500 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1IsEeO-0005Gl-Ma for nsis-confirm+ok@megatron.ietf.org; Wed, 14 Nov 2007 04:35:12 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsEeJ-0005Co-HC for nsis@ietf.org; Wed, 14 Nov 2007 04:35:07 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IsEeI-0001wy-Uw for nsis@ietf.org; Wed, 14 Nov 2007 04:35:07 -0500 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 42C8C2017E; Wed, 14 Nov 2007 10:35:06 +0100 (CET) X-AuditID: c1b4fb3e-b2038bb0000007e1-48-473ac14ae534 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 2CAD020054; Wed, 14 Nov 2007 10:35:06 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Nov 2007 10:35:06 +0100 Received: from [153.88.13.143] ([153.88.13.143]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Nov 2007 10:35:05 +0100 Message-ID: <473AC148.5010002@ericsson.com> Date: Wed, 14 Nov 2007 10:35:04 +0100 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Lauri J T Liuhto Subject: Re: [NSIS] GIST peering concern References: In-Reply-To: X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Nov 2007 09:35:06.0014 (UTC) FILETIME=[A3D2A3E0:01C826A1] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi, I haven't seen any reply to this comment. Please do as I will not accept outstanding issues when going forward with the doc. Cheers Magnus Lauri J T Liuhto skrev: > While implementing our own NSLPs and the API between GIST and NSLPs, we > came across something in the current NTLP i-d we think might be a > problem. > > In section 4.3.2 "Local Processing and Validation" it is stated that: > "The first option (peering) MUST be chosen if the node is the final > destination of the Query message, or if the GIST hop count has reached > zero." We think this is problematic for at least two reasons. > > 1) This removes flexibility from the NSLP application and forces certain > behaviour. Thus it complicates NSLP application logic, since the NSLP > must be aware of this exception to its peering "wishes". > > 2) It could be possible to overload resources, such as memory and UDP > send rate, of a GIST node. Sending Queries with an (intentionally) > low GIST hop-count would lead to nodes being forced to peer, though > it is stated in the same section (4.3.2), that a node can decline > peering for "overload protection reasons". > > We suggest that an error message be defined for the case when a flow > endpoint does not wish to peer, or that the definition of the "Endpoint > Found" message be extended to include this case. Currently section 4.3.4 > seems to state, that "Endpoint Found" can only be sent when the NSLP is > not present on the GIST node. > > Regards, > Nuutti, Teemu and Lauri > -- Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM/M ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Nov 14 16:15:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsPZk-0006Y7-C3; Wed, 14 Nov 2007 16:15:08 -0500 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1IsPZf-0006UE-EL for nsis-confirm+ok@megatron.ietf.org; Wed, 14 Nov 2007 16:15:03 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsPZf-0006Tr-1Y; Wed, 14 Nov 2007 16:15:03 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IsPZe-0002hI-L8; Wed, 14 Nov 2007 16:15:02 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 4DD17175DF; Wed, 14 Nov 2007 21:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IsPZd-0008Gx-Re; Wed, 14 Nov 2007 16:15:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 14 Nov 2007 16:15:01 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: nsis@ietf.org Subject: [NSIS] I-D ACTION:draft-ietf-nsis-rmd-12.txt X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Next Steps in Signaling Working Group of the IETF. Title : RMD-QOSM - The Resource Management in Diffserv QOS Model Author(s) : A. Bader, et al. Filename : draft-ietf-nsis-rmd-12.txt Pages : 97 Date : 2007-11-14 This document describes an NSIS QoS Model for networks that use the Resource Management in Diffserv (RMD) concept. RMD is a technique for adding admission control and pre-emption function to Differentiated Services (Diffserv) networks. The RMD QoS Model allows devices external to the RMD network to signal reservation requests to edge nodes in the RMD network. The RMD Ingress edge nodes classify the incoming flows into traffic classes and signals resource requests for the corresponding traffic class along the data path to the Egress edge nodes for each flow. Egress nodes reconstitute the original requests and continue forwarding them along the data path towards the final destination. In addition, RMD defines notification functions to indicate overload situations within the domain to the edge nodes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nsis-rmd-12.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-nsis-rmd-12.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-nsis-rmd-12.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-11-14150914.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nsis-rmd-12.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nsis-rmd-12.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-11-14150914.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --NextPart-- From nsis-bounces@ietf.org Wed Nov 14 16:38:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsPwB-00037u-IF; Wed, 14 Nov 2007 16:38:19 -0500 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1IsPwA-000370-3W for nsis-confirm+ok@megatron.ietf.org; Wed, 14 Nov 2007 16:38:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsPw9-00036r-Pv for nsis@ietf.org; Wed, 14 Nov 2007 16:38:17 -0500 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsPw5-0001Nv-2v for nsis@ietf.org; Wed, 14 Nov 2007 16:38:17 -0500 Received: from irams2.ira.uni-karlsruhe.de ([141.3.10.82]) by iramx2.ira.uni-karlsruhe.de with esmtps id 1IsPw2-0003Th-FE; Wed, 14 Nov 2007 22:38:12 +0100 Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by irams2.ira.uni-karlsruhe.de with esmtps id 1IsPw1-0004y4-25; Wed, 14 Nov 2007 22:38:10 +0100 Received: from i72ms.tm.uni-karlsruhe.de ([141.3.70.5] helo=smtp.ipv6.tm.uni-karlsruhe.de) by irams1.ira.uni-karlsruhe.de with esmtps id 1IsPw0-0003tL-SP; Wed, 14 Nov 2007 22:38:08 +0100 Received: from vorta.ipv6.tm.uni-karlsruhe.de (vorta.ipv6.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:207:e9ff:fe0c:5e44]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id 68FF22FC00E; Wed, 14 Nov 2007 22:38:08 +0100 (CET) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1IsPw0-0008I0-4P; Wed, 14 Nov 2007 22:38:08 +0100 Message-ID: <473B6ABF.4050509@tm.uka.de> Date: Wed, 14 Nov 2007 22:38:07 +0100 From: Roland Bless Organization: Institute of Telematics, University of Karlsruhe User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060111 Thunderbird/1.5 Mnenhy/0.7.3.0 MIME-Version: 1.0 To: Lauri J T Liuhto Subject: Re: [NSIS] GIST peering concern References: In-Reply-To: X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Status: No X-Spam-Score: -1.3 (-) X-Spam-Report: -1.4 ALL_TRUSTED Passed through trusted hosts only via SMTP 0.1 AWL AWL: From: address is in the auto white-list X-Spam-Host: irams2.ira.uni-karlsruhe.de X-ATIS-Checksum: v3zoCAcc32ckk X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Lauri, Lauri J T Liuhto wrote: > While implementing our own NSLPs and the API between GIST and NSLPs, we > came across something in the current NTLP i-d we think might be a > problem. > > In section 4.3.2 "Local Processing and Validation" it is stated that: > "The first option (peering) MUST be chosen if the node is the final > destination of the Query message, or if the GIST hop count has reached > zero." We think this is problematic for at least two reasons. > > 1) This removes flexibility from the NSLP application and forces certain > behaviour. Thus it complicates NSLP application logic, since the NSLP > must be aware of this exception to its peering "wishes". > > 2) It could be possible to overload resources, such as memory and UDP > send rate, of a GIST node. Sending Queries with an (intentionally) > low GIST hop-count would lead to nodes being forced to peer, though > it is stated in the same section (4.3.2), that a node can decline > peering for "overload protection reasons". I would agree here. However, I'm not sure what the rationale was for the current text. Probably Robert has an answer. > We suggest that an error message be defined for the case when a flow > endpoint does not wish to peer, or that the definition of the "Endpoint > Found" message be extended to include this case. Currently section 4.3.4 > seems to state, that "Endpoint Found" can only be sent when the NSLP is > not present on the GIST node. One must be careful to not open new attack possibilities by causing error message backscatter. For diagnostic purposes I would also recommend to send back an error. Regards, Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Nov 15 08:45:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Isf1l-0000ez-NJ; Thu, 15 Nov 2007 08:45:05 -0500 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1Isf1k-0000eJ-8m for nsis-confirm+ok@megatron.ietf.org; Thu, 15 Nov 2007 08:45:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Isf1j-0000e9-TP for nsis@ietf.org; Thu, 15 Nov 2007 08:45:03 -0500 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Isf1e-0003tP-SX for nsis@ietf.org; Thu, 15 Nov 2007 08:45:03 -0500 Received: from irams2.ira.uni-karlsruhe.de ([141.3.10.82]) by iramx2.ira.uni-karlsruhe.de with esmtps id 1Isf1W-0007hc-E7; Thu, 15 Nov 2007 14:44:54 +0100 Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by irams2.ira.uni-karlsruhe.de with esmtps id 1Isf1V-0002wO-7l; Thu, 15 Nov 2007 14:44:50 +0100 Received: from i72ms.tm.uni-karlsruhe.de ([141.3.70.5] helo=smtp.ipv6.tm.uni-karlsruhe.de) by irams1.ira.uni-karlsruhe.de with esmtps id 1Isf1U-00044J-2t; Thu, 15 Nov 2007 14:44:48 +0100 Received: from vorta.ipv6.tm.uni-karlsruhe.de (vorta.ipv6.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:207:e9ff:fe0c:5e44]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id 00A252FC00E; Thu, 15 Nov 2007 14:44:44 +0100 (CET) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1Isf1O-0000W8-V7; Thu, 15 Nov 2007 14:44:43 +0100 Message-ID: <473C4D46.7020002@tm.uka.de> Date: Thu, 15 Nov 2007 14:44:38 +0100 From: Roland Bless Organization: Institute of Telematics, University of Karlsruhe User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060111 Thunderbird/1.5 Mnenhy/0.7.3.0 MIME-Version: 1.0 To: Jukka MJ Manner References: <20071105200346.2BAF.SANDA.TAKAKO@jp.panasonic.com> <47343862.5040206@tm.uka.de> In-Reply-To: X-Enigmail-Version: 0.94.4.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Status: No X-Spam-Score: -1.3 (-) X-Spam-Report: -1.4 ALL_TRUSTED Passed through trusted hosts only via SMTP 0.1 AWL AWL: From: address is in the auto white-list X-Spam-Host: irams2.ira.uni-karlsruhe.de X-ATIS-Checksum: v3zoCAcc32ckk X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Cc: "nsis@ietf.org" , Takako Sanda Subject: [NSIS] Re: [NSIS Mobility draft] Updating from -07 to -08 X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Jukka, [I'm taking this to the list now...] Jukka MJ Manner wrote: > I think we are talking about the same thing. The main point is that if IP > addresses change, the MRI is invalidated, and the QNI must then, in one > way or another be notified. There must be (otherwise nothing works) some > mobility signaling where the QNI gets to know the new IP of the MN, and > can then reissue a RESERVE with a new MRI. Ok, however, I believe that your proposed solution doesn't work: you proposed to send a NOTIFY towards the CN. This will require usage of the new flow's MRI and the resulting GIST Query must be sent in _upstream_ direction, i.e., PC-MRI(CN->MN-newCoA, D-Flag=1) - upstream. Now there is the problem of choosing the correct encapsulation for the Query: only _upstream_ Q-mode encapsulation would be an option, but this is not appropriate to use in this case due to its limited applicability to certain environments. Even if the MN could send the NOTIFY to its new access router (QNE4 below), there is no routing state installed yet in upstream direction in QNE4, i.e., it doesn't know any next peer in upstream direction, so only upstream Q-mode could be used, but that is not really applicable in this case. So only the last paragraph of section 4.3.3 applies: o If no routing state exists, GIST can attempt to use Q-mode as in the Query case: either sending a Data message with the Q-mode encapsulation, or using the event as a trigger for routing state setup (see Section 4.4). If this is not possible, e.g. because the encapsulation for the MRM is only defined for one message direction, then this is an error condition which is reported back to the local signalling application. So an error will be reported back to the application. As a conclusion: sending a NOTIFY in upstream direction does not work along paths that have no routing state yet. > The asymmetric paths is a real problem, especially if the MN switches e.g. > interface technologies, goes from WLAN to WiMAX, and changes operators at > the same time. In that case the QUERY will hit some node, the QNI at the > latest, which can then send the RESERVE towards the new location of the > MN. We will come back later with more detailed comments about the mobility scenarios. Regards, Roland & Martin (Roehricht) > > Jukka > > On Fri, 9 Nov 2007, Roland Bless wrote: > >> Hi Jukka, >> >> see comments below. >> >> Jukka MJ Manner wrote: >>>> >>>>> [MN] [QNE1] --- [QNE2] ---\ >>>>> | \ >>>>> | [QNE3] --- [QNE6] --- [QNE7] --- >>>>> | / >>>>> V / >>>>> [MN] [QNE4] --- [QNE5]---/ >>>>> >>>> >>>>> - MN moves, gets a hint from GIST that routing has changed >>>>> - MN sends a NOTIFY towards QNI saying "Route Change" 0x02 >>>>> - QNE4 will receive it, and forward it, same with QNE5 >>>>> - The NOTIFY will hit QNE3, which notes that the message for a known >>>>> session comes from a new SII-Handle. >>>>> - QNE3 should then send a full RESERVE with a new RSN and an RII to >>>>> QNE5 >>>>> - QNE4 will receive the RESERVE, make the reservation, and forward it >>>>> to the MN >>>>> - The MN gets the RESERVE and replies with a RESPONSE >>>> - In order to send NSIS message hop by hop for upstream direction (MN-> >>>> QNE4->...->QNE7... in the figure below), GIST state need to be >>>> established in advance, and this GIST state is established for >>>> downstream direction (e.g., QNE3 aware of route change and perform route >>>> change process towards MN in the new location). But if this is possible, >>>> I guess "make it faster" operation (operation above) does not make sense, >>>> because QNE3 (CRN) will able to do new reservation and teardown without >>>> receiving NOTIFY from MN. >>>> - How MRI update can be done in this case? >>> >>> In order for the MN to send the NOTIFY, each GIST hop will need to set up >>> state upstream. This state establishment will result in a QUERY hitting >>> QNE3, which will decide to peer. The SID is known, thus, the QNE3 will >>> consider this a re-routing event, and perform the signaling as above. This >>> should work? QNE3 will not know about the re-routing until QNE1 figures >>> out the MN has disappeared, and QNE1 starts tearing down the reservation. >> Sorry, but I don't get the point here and I doubt that its working >> correctly. what is the exact scenario? >> >> - MN is QNR and data receiver? >> - Reservation is sender-initiated? >> - MN uses Mobile IP? >> >> I see the different cases now: >> a) MN gets a new IP address and default route >> b) MN performs mobility management signaling (Bindung Update) >> >> Is it that GIST will already detect a route change by a) >> or will the route be changed by b)? >> >> With the current proposal I have the following issues: >> * In case of a) it may be the case that QNE3 is not even hit by a Query >> sent upstream due to asymmetric paths. >> * The MRI must get updated along the whole path, especially for >> profile update in the first hop router at the QNI. >> * QNE3 tries to automatically reserve resources as they were before the >> handover. This is especially inappropriate in case of vertical >> handovers when the QSPEC should be changed. Therefore it would be good >> that the QNI is involved in re-issuing a RESERVE. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Nov 15 21:51:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsrJ6-0006Dq-VV; Thu, 15 Nov 2007 21:51:48 -0500 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1IsrJ5-0006AC-67 for nsis-confirm+ok@megatron.ietf.org; Thu, 15 Nov 2007 21:51:47 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsrJ4-000667-QR for nsis@ietf.org; Thu, 15 Nov 2007 21:51:46 -0500 Received: from smtp.mei.co.jp ([133.183.100.20]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IsrJ2-0002CR-1E for nsis@ietf.org; Thu, 15 Nov 2007 21:51:45 -0500 Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kc-maile11) with ESMTP id lAG2pW90020979; Fri, 16 Nov 2007 11:51:32 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx2) with ESMTP id lAG2pXP00161; Fri, 16 Nov 2007 11:51:33 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/indians) with SMTP id lAG2pWp01747; Fri, 16 Nov 2007 11:51:32 +0900 (JST) Received: from [127.0.0.1] ([10.81.113.75]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Nov 2007 10:51:28 +0800 Message-ID: <473D05AF.9050507@sg.panasonic.com> Date: Fri, 16 Nov 2007 10:51:27 +0800 From: Hong Cheng User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Roland Bless Subject: Re: [NSIS] Re: [NSIS Mobility draft] Updating from -07 to -08 References: <20071105200346.2BAF.SANDA.TAKAKO@jp.panasonic.com> <47343862.5040206@tm.uka.de> <473C4D46.7020002@tm.uka.de> In-Reply-To: <473C4D46.7020002@tm.uka.de> X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Nov 2007 02:51:28.0571 (UTC) FILETIME=[95ED98B0:01C827FB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9af087f15dbdd4c64ae6bbcdbc5b1d44 Cc: Takako Sanda , Jukka MJ Manner , "nsis@ietf.org" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Roland and Jukka, This seems like some interesting discussion that should be used to update the MIP operation part in the draft. Based on the description, I don't think a NOTIFY from MN is necessary when the other end (CN or HA) is a QNE. When MN is the Data Sender, it should work this way: - MN changes its IP addr, e.g. obtain a new-CoA; - MN sends a QUERY(RESERVE-INIT)towards the CN/HA with the new MRI (if it's QNR); or - MN sends a RESERVE towards the CN with the new MRI (if it's QNI) When MN is the Data Receiver, and the CN/HA is a QNE, it should work this way: - MN changes its IP addr, e.g. obtain a new-CoA; - MN does Mobility Management signaling to inform CN/HA of new-CoA (otherwise data path would not change, remember CN/HA is the data sender); - CN/HA is triggered by GIST to send QUERY towards MN using new MRI; - MN sends RESPONSE (if it's QNR) or RESERVE (if it's QNI); and - CN/HA sends RESERVE if it is QNI. In the above step 3, CN/HA sends QUERY instead of RESERVE directly(if CN/HA is QNI) because the path condition may change as MN changes location (as indicated in your earlier email, WiFi and WiMAX may provides different throughput). However, if time is a concern, CN/HA can always use back the old QSPEC for a direct RESERVE first. The situation will become a bit more interesting when the CN/HA is not QNE. In this case, how the MN does the update worth some discussion. If MN is the Data Sender, same operation as above should be able to work. If MN is the Data Receiver, there are problems in signaling as indicated in Roland's email, especially when we assume the routing is asymmetric. There are two possible ways: - If MN knows the QNI/QNR addr, it can send a NOTIFY/QUERY directly to it. However, in the current QoS NSLP spec, there is no way for the MN to know that info. Should we fix this, e.g. as a special mobility/proxy INFO-Element? - Get some help from the CN/HA (the data sender). Possibly to encapsulate the NOTIFY to CN/HA, and get them to send it via Data Path. This is like sending a special PING to the CN/HA. What do you think? cheers Cheng Hong Roland Bless wrote: > Hi Jukka, > > [I'm taking this to the list now...] > > Jukka MJ Manner wrote: >> I think we are talking about the same thing. The main point is that if IP >> addresses change, the MRI is invalidated, and the QNI must then, in one >> way or another be notified. There must be (otherwise nothing works) some >> mobility signaling where the QNI gets to know the new IP of the MN, and >> can then reissue a RESERVE with a new MRI. > > Ok, however, I believe that your proposed solution doesn't work: > you proposed to send a NOTIFY towards the CN. This will require usage > of the new flow's MRI and the resulting GIST Query must be sent in > _upstream_ direction, i.e., PC-MRI(CN->MN-newCoA, D-Flag=1) - upstream. > Now there is the problem of choosing the correct encapsulation for the > Query: only _upstream_ Q-mode encapsulation would be an option, but this > is not appropriate to use in this case due to its limited applicability > to certain environments. Even if the MN could send the NOTIFY to its > new access router (QNE4 below), there is no routing state installed yet > in upstream direction in QNE4, i.e., it doesn't know any next peer > in upstream direction, so only upstream Q-mode could be used, but that > is not really applicable in this case. So only the last paragraph of > section 4.3.3 applies: > o If no routing state exists, GIST can attempt to use Q-mode as in > the Query case: either sending a Data message with the Q-mode > encapsulation, or using the event as a trigger for routing state > setup (see Section 4.4). If this is not possible, e.g. because > the encapsulation for the MRM is only defined for one message > direction, then this is an error condition which is reported back > to the local signalling application. > > So an error will be reported back to the application. > As a conclusion: sending a NOTIFY in upstream direction does not > work along paths that have no routing state yet. > >> The asymmetric paths is a real problem, especially if the MN switches e.g. >> interface technologies, goes from WLAN to WiMAX, and changes operators at >> the same time. In that case the QUERY will hit some node, the QNI at the >> latest, which can then send the RESERVE towards the new location of the >> MN. > > We will come back later with more detailed comments about the mobility > scenarios. > > Regards, > Roland & Martin (Roehricht) > >> Jukka >> >> On Fri, 9 Nov 2007, Roland Bless wrote: >> >>> Hi Jukka, >>> >>> see comments below. >>> >>> Jukka MJ Manner wrote: >>>>> >>>>>> [MN] [QNE1] --- [QNE2] ---\ >>>>>> | \ >>>>>> | [QNE3] --- [QNE6] --- [QNE7] --- >>>>>> | / >>>>>> V / >>>>>> [MN] [QNE4] --- [QNE5]---/ >>>>>> >>>>> >>>>>> - MN moves, gets a hint from GIST that routing has changed >>>>>> - MN sends a NOTIFY towards QNI saying "Route Change" 0x02 >>>>>> - QNE4 will receive it, and forward it, same with QNE5 >>>>>> - The NOTIFY will hit QNE3, which notes that the message for a known >>>>>> session comes from a new SII-Handle. >>>>>> - QNE3 should then send a full RESERVE with a new RSN and an RII to >>>>>> QNE5 >>>>>> - QNE4 will receive the RESERVE, make the reservation, and forward it >>>>>> to the MN >>>>>> - The MN gets the RESERVE and replies with a RESPONSE >>>>> - In order to send NSIS message hop by hop for upstream direction (MN-> >>>>> QNE4->...->QNE7... in the figure below), GIST state need to be >>>>> established in advance, and this GIST state is established for >>>>> downstream direction (e.g., QNE3 aware of route change and perform route >>>>> change process towards MN in the new location). But if this is possible, >>>>> I guess "make it faster" operation (operation above) does not make sense, >>>>> because QNE3 (CRN) will able to do new reservation and teardown without >>>>> receiving NOTIFY from MN. >>>>> - How MRI update can be done in this case? >>>> In order for the MN to send the NOTIFY, each GIST hop will need to set up >>>> state upstream. This state establishment will result in a QUERY hitting >>>> QNE3, which will decide to peer. The SID is known, thus, the QNE3 will >>>> consider this a re-routing event, and perform the signaling as above. This >>>> should work? QNE3 will not know about the re-routing until QNE1 figures >>>> out the MN has disappeared, and QNE1 starts tearing down the reservation. >>> Sorry, but I don't get the point here and I doubt that its working >>> correctly. what is the exact scenario? >>> >>> - MN is QNR and data receiver? >>> - Reservation is sender-initiated? >>> - MN uses Mobile IP? >>> >>> I see the different cases now: >>> a) MN gets a new IP address and default route >>> b) MN performs mobility management signaling (Bindung Update) >>> >>> Is it that GIST will already detect a route change by a) >>> or will the route be changed by b)? >>> >>> With the current proposal I have the following issues: >>> * In case of a) it may be the case that QNE3 is not even hit by a Query >>> sent upstream due to asymmetric paths. >>> * The MRI must get updated along the whole path, especially for >>> profile update in the first hop router at the QNI. >>> * QNE3 tries to automatically reserve resources as they were before the >>> handover. This is especially inappropriate in case of vertical >>> handovers when the QSPEC should be changed. Therefore it would be good >>> that the QNI is involved in re-issuing a RESERVE. > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Nov 16 03:15:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IswM3-0000MO-Pe; Fri, 16 Nov 2007 03:15:11 -0500 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1IswM2-0000H2-Kq for nsis-confirm+ok@megatron.ietf.org; Fri, 16 Nov 2007 03:15:10 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IswM1-0000Bp-Um for nsis@ietf.org; Fri, 16 Nov 2007 03:15:10 -0500 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IswM1-0005RA-Hy for nsis@ietf.org; Fri, 16 Nov 2007 03:15:09 -0500 Received: from i72ms.tm.uni-karlsruhe.de ([141.3.70.5] helo=smtp.ipv6.tm.uni-karlsruhe.de) by iramx2.ira.uni-karlsruhe.de with esmtps id 1IswLy-0004pU-Nl for ; Fri, 16 Nov 2007 09:15:08 +0100 Received: from vorta.ipv6.tm.uni-karlsruhe.de (vorta.ipv6.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:207:e9ff:fe0c:5e44]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id 840432FC00C for ; Fri, 16 Nov 2007 09:15:06 +0100 (CET) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1IswLy-0004Gm-1a for nsis@ietf.org; Fri, 16 Nov 2007 09:15:06 +0100 Message-ID: <473D5189.3020909@tm.uka.de> Date: Fri, 16 Nov 2007 09:15:05 +0100 From: Roland Bless Organization: Institute of Telematics, University of Karlsruhe User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060111 Thunderbird/1.5 Mnenhy/0.7.3.0 MIME-Version: 1.0 To: "nsis@ietf.org" X-Enigmail-Version: 0.94.4.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Spam-Status: No X-Spam-Score: -1.3 (-) X-Spam-Report: -1.4 ALL_TRUSTED Passed through trusted hosts only via SMTP 0.1 AWL AWL: From: address is in the auto white-list X-Spam-Host: iramx2.ira.uni-karlsruhe.de X-ATIS-Checksum: v3zoCAcc32ckk X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Subject: [NSIS] Request comments on draft-bless-nsis-est-mrm-00 X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi, unfortunately I missed the deadline for initial draft documents but I will submit the document on December, 3rd when the queue opens again. Until then you can get it unofficially from here: http://doc.tm.uka.de/2007/draft-bless-nsis-est-mrm-00.txt We came across this MRM due to need for optimized mobility scenarios, but we think it might be joined with other existing proposals with other backgrounds in the future, e.g. Hypath. However, since the proposal is simple and the document is short you should have a look at it. Furthermore, I implemented it and it was quite easy and works well, even if used together with the standard PC-MRM. I guess that it nicely demonstrates the flexibility and extensibility of GIST. Abstract: The standard operation of the General Internet Signaling Transport (GIST) Protocol uses a path-coupled message routing method (PC-MRM) to find nodes interested in signaling message exchanges. This specification proposes an Explicit Signaling Target Message Routing Method (EST-MRM) in order to allow sending of signaling messages to explicit targets. Regards, Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Nov 16 05:55:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsyrR-0000DY-MO; Fri, 16 Nov 2007 05:55:45 -0500 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1IsyrQ-00008i-3Q for nsis-confirm+ok@megatron.ietf.org; Fri, 16 Nov 2007 05:55:44 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsyrP-00005b-KA for nsis@ietf.org; Fri, 16 Nov 2007 05:55:43 -0500 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IsyrO-0006yL-2D for nsis@ietf.org; Fri, 16 Nov 2007 05:55:43 -0500 Received: from i72ms.tm.uni-karlsruhe.de ([141.3.70.5] helo=smtp.ipv6.tm.uni-karlsruhe.de) by iramx2.ira.uni-karlsruhe.de with esmtps id 1IsyrH-0004Dj-6m; Fri, 16 Nov 2007 11:55:37 +0100 Received: from vorta.ipv6.tm.uni-karlsruhe.de (vorta.ipv6.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:207:e9ff:fe0c:5e44]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id 0004E2FC00E; Fri, 16 Nov 2007 11:55:34 +0100 (CET) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1IsyrG-0004Op-NH; Fri, 16 Nov 2007 11:55:34 +0100 Message-ID: <473D7726.1070504@tm.uka.de> Date: Fri, 16 Nov 2007 11:55:34 +0100 From: Roland Bless Organization: Institute of Telematics, University of Karlsruhe User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060111 Thunderbird/1.5 Mnenhy/0.7.3.0 MIME-Version: 1.0 To: Hong Cheng , Takako Sanda Subject: Re: [NSIS] Re: [NSIS Mobility draft] Updating from -07 to -08 References: <20071105200346.2BAF.SANDA.TAKAKO@jp.panasonic.com> <47343862.5040206@tm.uka.de> <473C4D46.7020002@tm.uka.de> <473D05AF.9050507@sg.panasonic.com> In-Reply-To: <473D05AF.9050507@sg.panasonic.com> X-Enigmail-Version: 0.94.4.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Status: No X-Spam-Score: -1.3 (-) X-Spam-Report: -1.4 ALL_TRUSTED Passed through trusted hosts only via SMTP 0.1 AWL AWL: From: address is in the auto white-list X-Spam-Host: iramx2.ira.uni-karlsruhe.de X-ATIS-Checksum: v3zoCAcc32ckk X-Spam-Score: 0.0 (/) X-Scan-Signature: f8ee348dcc4be4a59bc395f7cd6343ad Cc: Jukka MJ Manner , "nsis@ietf.org" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Hong, Takako and all, we were writing up another e-mail, but I guess your analysis is mostly correct. I'll try to summarize our (Martin and I) comments as follows: We (Martin an I) have some major comments about the draft and are willing to contribute to it. First, we find that we basically should distinguish four cases: 1.) MN is sender, sender-initiated reservation 2.) MN is sender, receiver-initiated reservation 3.) MN is receiver, sender-initiated reservation 4.) MN is receiver, receiver-initiated reservation It seems that only case 1.) is currently discussed in section 4 and we think it would be good to systematically discuss the other cases, too. In case that MobileIPv6 is used it boils down to the following cases as Hong described already. We assume that the MN changes its address and the we distinguish two flows: cases 1.)+2.) (MN-Sender) f_o: old-CoA -> CN, f_n: new-CoA -> CN cases 3.)+4.) (MN-Receiver) f_o: CN -> old-CoA, f_n: CN -> new-CoA Case 1.) - MN changes its IP address, obtains new-CoA - QoS NSLP must become aware of the handover, so that the - MN simply initiates a new RESERVE for the new flow f_n 2.) - MN changes its IP address, obtains new-CoA - QoS NSLP must become aware of the handover, so that the - MN initiates a new QUERY(RESERVE-INIT) for the new flow f_n 3.) - MN changes its IP address, obtains new-CoA - MN performs mobility management signaling, i.e. binding update to the CN. - CN becomes aware of the handover (this is the important part) so that the NSLP can initiate a new RESERVE. 4.) - MN changes its IP address, obtains new-CoA - MN performs mobility management signaling, i.e. binding update to the CN. - CN gets aware of the handover, NSLP sends a new QUERY The important part for all four cases is that the QoS NSLP becomes aware of the handover. There are several possibilities for the trigger, but I think we should use a new GIST API primitive for the notification (but probably as mobility extension of GIST not within the current proposed draft). You wrote that GIST will trigger the NSLP, but I don't think that there is currently such a possibility: new binding update actually changes an existing flow f_o into the new f_n. So the only existing primitive would be to indicate NetworkNotification(QoS-NSLP, MRI(f_o), Routing-Status-Change=Bad) for the old flow. But we need to get the new MRI in order to send the NSLP message. One problem is that GIST doesn't have any state for the new flow f_n. So I would propose to have a new NetworkNotificationType, like MRI change: NetworkNotification(QoS-NSLP, MRI(f_o), MRI(f_n)) The problem is, however, that an updated IP address (due to mobility management) may affect several GIST flows. An alternative would be a trigger caused by the application itself, e.g., due to application level signaling. It would be similar to the fact that we need such a trigger anyway for receiver-initiated reservations in order to let the sender issue an initial Query. I guess we need to support both possibilities for cross layer info. Concerning your mentioned option of directly sending a NOTIFY to the other end: that's also an alternative that I discussed with Martin. Our proposed EST-MRM would probably enable a node to do so, i.e., a NOTIFY indicating a handover event could be sent directly to the other end. Now for some further comments to the draft: Further comments on section 4.2: I propose to change the name of "State Update" at least to "Localized State Update", because my intuitive understanding of State Update is that is denotes the process to update the flow's state along the whole path. With respect to section 4.2.1 we want to remark that usually the main difference between mobility/handover scenarios and re-routing as describe in appendix A is: in the basic mobility scenario the MRI changes: the MN gets a new care-of-address and thus we have a new flow (we denote this as f_n). In contrast to this, a re-routing by route changes will usually not lead to a change of the MRI. So normally only the CRN can determine at NSLP level that a handover happened by detecting two different MRIs (f_o=old flow and f_n=new flow) belonging to the same SID. GIST does not really care about the SID, so this relation must be handled at the NSLP level. Furthermore, I would propose to rephrase the last paragraph of section 4.2.3 as QoS NSLP does not allow to sent RESERVEs towards the QNI. Thus, there is no option to do it differently. Best regards, Roland and Martin Hong Cheng wrote: > Hi Roland and Jukka, > > This seems like some interesting discussion that should be used to > update the MIP operation part in the draft. > > Based on the description, I don't think a NOTIFY from MN is necessary > when the other end (CN or HA) is a QNE. > > When MN is the Data Sender, it should work this way: > - MN changes its IP addr, e.g. obtain a new-CoA; > - MN sends a QUERY(RESERVE-INIT)towards the CN/HA with the new MRI (if > it's QNR); or > - MN sends a RESERVE towards the CN with the new MRI (if it's QNI) > > When MN is the Data Receiver, and the CN/HA is a QNE, it should work > this way: > - MN changes its IP addr, e.g. obtain a new-CoA; > - MN does Mobility Management signaling to inform CN/HA of new-CoA > (otherwise data path would not change, remember CN/HA is the data sender); > - CN/HA is triggered by GIST to send QUERY towards MN using new MRI; > - MN sends RESPONSE (if it's QNR) or RESERVE (if it's QNI); and > - CN/HA sends RESERVE if it is QNI. > In the above step 3, CN/HA sends QUERY instead of RESERVE directly(if > CN/HA is QNI) because the path condition may change as MN changes > location (as indicated in your earlier email, WiFi and WiMAX may > provides different throughput). However, if time is a concern, CN/HA can > always use back the old QSPEC for a direct RESERVE first. > > The situation will become a bit more interesting when the CN/HA is not > QNE. In this case, how the MN does the update worth some discussion. > > If MN is the Data Sender, same operation as above should be able to work. > > If MN is the Data Receiver, there are problems in signaling as indicated > in Roland's email, especially when we assume the routing is asymmetric. > There are two possible ways: > - If MN knows the QNI/QNR addr, it can send a NOTIFY/QUERY directly to > it. However, in the current QoS NSLP spec, there is no way for the MN to > know that info. Should we fix this, e.g. as a special mobility/proxy > INFO-Element? > - Get some help from the CN/HA (the data sender). Possibly to > encapsulate the NOTIFY to CN/HA, and get them to send it via Data Path. > This is like sending a special PING to the CN/HA. > > What do you think? > > > Roland Bless wrote: >> Hi Jukka, >> >> [I'm taking this to the list now...] >> >> Jukka MJ Manner wrote: >>> I think we are talking about the same thing. The main point is that if IP >>> addresses change, the MRI is invalidated, and the QNI must then, in one >>> way or another be notified. There must be (otherwise nothing works) some >>> mobility signaling where the QNI gets to know the new IP of the MN, and >>> can then reissue a RESERVE with a new MRI. >> Ok, however, I believe that your proposed solution doesn't work: >> you proposed to send a NOTIFY towards the CN. This will require usage >> of the new flow's MRI and the resulting GIST Query must be sent in >> _upstream_ direction, i.e., PC-MRI(CN->MN-newCoA, D-Flag=1) - upstream. >> Now there is the problem of choosing the correct encapsulation for the >> Query: only _upstream_ Q-mode encapsulation would be an option, but this >> is not appropriate to use in this case due to its limited applicability >> to certain environments. Even if the MN could send the NOTIFY to its >> new access router (QNE4 below), there is no routing state installed yet >> in upstream direction in QNE4, i.e., it doesn't know any next peer >> in upstream direction, so only upstream Q-mode could be used, but that >> is not really applicable in this case. So only the last paragraph of >> section 4.3.3 applies: >> o If no routing state exists, GIST can attempt to use Q-mode as in >> the Query case: either sending a Data message with the Q-mode >> encapsulation, or using the event as a trigger for routing state >> setup (see Section 4.4). If this is not possible, e.g. because >> the encapsulation for the MRM is only defined for one message >> direction, then this is an error condition which is reported back >> to the local signalling application. >> >> So an error will be reported back to the application. >> As a conclusion: sending a NOTIFY in upstream direction does not >> work along paths that have no routing state yet. >> >>> The asymmetric paths is a real problem, especially if the MN switches e.g. >>> interface technologies, goes from WLAN to WiMAX, and changes operators at >>> the same time. In that case the QUERY will hit some node, the QNI at the >>> latest, which can then send the RESERVE towards the new location of the >>> MN. >> We will come back later with more detailed comments about the mobility >> scenarios. >> >> Regards, >> Roland & Martin (Roehricht) >> >>> Jukka >>> >>> On Fri, 9 Nov 2007, Roland Bless wrote: >>> >>>> Hi Jukka, >>>> >>>> see comments below. >>>> >>>> Jukka MJ Manner wrote: >>>>>> >>>>>>> [MN] [QNE1] --- [QNE2] ---\ >>>>>>> | \ >>>>>>> | [QNE3] --- [QNE6] --- [QNE7] --- >>>>>>> | / >>>>>>> V / >>>>>>> [MN] [QNE4] --- [QNE5]---/ >>>>>>> >>>>>> >>>>>>> - MN moves, gets a hint from GIST that routing has changed >>>>>>> - MN sends a NOTIFY towards QNI saying "Route Change" 0x02 >>>>>>> - QNE4 will receive it, and forward it, same with QNE5 >>>>>>> - The NOTIFY will hit QNE3, which notes that the message for a known >>>>>>> session comes from a new SII-Handle. >>>>>>> - QNE3 should then send a full RESERVE with a new RSN and an RII to >>>>>>> QNE5 >>>>>>> - QNE4 will receive the RESERVE, make the reservation, and forward it >>>>>>> to the MN >>>>>>> - The MN gets the RESERVE and replies with a RESPONSE >>>>>> - In order to send NSIS message hop by hop for upstream direction (MN-> >>>>>> QNE4->...->QNE7... in the figure below), GIST state need to be >>>>>> established in advance, and this GIST state is established for >>>>>> downstream direction (e.g., QNE3 aware of route change and perform route >>>>>> change process towards MN in the new location). But if this is possible, >>>>>> I guess "make it faster" operation (operation above) does not make sense, >>>>>> because QNE3 (CRN) will able to do new reservation and teardown without >>>>>> receiving NOTIFY from MN. >>>>>> - How MRI update can be done in this case? >>>>> In order for the MN to send the NOTIFY, each GIST hop will need to set up >>>>> state upstream. This state establishment will result in a QUERY hitting >>>>> QNE3, which will decide to peer. The SID is known, thus, the QNE3 will >>>>> consider this a re-routing event, and perform the signaling as above. This >>>>> should work? QNE3 will not know about the re-routing until QNE1 figures >>>>> out the MN has disappeared, and QNE1 starts tearing down the reservation. >>>> Sorry, but I don't get the point here and I doubt that its working >>>> correctly. what is the exact scenario? >>>> >>>> - MN is QNR and data receiver? >>>> - Reservation is sender-initiated? >>>> - MN uses Mobile IP? >>>> >>>> I see the different cases now: >>>> a) MN gets a new IP address and default route >>>> b) MN performs mobility management signaling (Bindung Update) >>>> >>>> Is it that GIST will already detect a route change by a) >>>> or will the route be changed by b)? >>>> >>>> With the current proposal I have the following issues: >>>> * In case of a) it may be the case that QNE3 is not even hit by a Query >>>> sent upstream due to asymmetric paths. >>>> * The MRI must get updated along the whole path, especially for >>>> profile update in the first hop router at the QNI. >>>> * QNE3 tries to automatically reserve resources as they were before the >>>> handover. This is especially inappropriate in case of vertical >>>> handovers when the QSPEC should be changed. Therefore it would be good >>>> that the QNI is involved in re-issuing a RESERVE. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Nov 16 05:58:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Isyu9-00042n-9m; Fri, 16 Nov 2007 05:58:33 -0500 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1Isyu6-00041c-JX for nsis-confirm+ok@megatron.ietf.org; Fri, 16 Nov 2007 05:58:31 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Isyu6-00041R-82 for nsis@ietf.org; Fri, 16 Nov 2007 05:58:30 -0500 Received: from rsys001x.roke.co.uk ([193.118.201.108]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Isyu5-00077N-Dn for nsis@ietf.org; Fri, 16 Nov 2007 05:58:30 -0500 Received: from rsys005a.comm.ad.roke.co.uk ([193.118.193.85]) by rsys001x.roke.co.uk (8.13.1/8.13.1) with ESMTP id lAGAwNPt021169; Fri, 16 Nov 2007 10:58:23 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] GIST peering concern Date: Fri, 16 Nov 2007 10:58:23 -0000 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] GIST peering concern Thread-Index: AcgnBrdy6GvZkN+fRK+75+ZXmAHhbgBNVk7A References: <473B6ABF.4050509@tm.uka.de> From: "Hancock, Robert" To: "Roland Bless" , "Lauri J T Liuhto" X-MailScanner-roke-co-uk: Found to be clean X-MailScanner-roke-co-uk-SpamCheck: X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org hi, sorry for the delayed response. there are some subtleties in this sort of question. i think there are two scenarios: a) a non-endpoint being forced to peer because the GHC is zero, even though it would rather not for policy or load issues. b) an endpoint being forced to peer, even though it would rather not for policy or load issues. for (a), i think the right answer would be to allow the receiver to generate the 'hop limit exceeded' error message (which it would have done anyway if it did not host the NSLP at all, rather than hosting an NSLP which happens not to want to peer). The implication would be just to remove the clause "... , or if the GIST hop count has reached zero". (That clause went in as a side effect of review discussions, but I think this is an equally valid way to address the review in question.) for (b), i think the question is how the endpoint should be allowed to control its own load, and what feedback should be given to the sender about that. Note that it's always possible (in any protocol over an unreliable transport, as GIST is in this scenario) to silently drop a message and rely on the sender to back off and retransmit. As far as I understand it, this is what TCP and IKE would do.=20 Another possibility is to send a 'hard error' message ("I'm busy") to which the sender would have to respond in some specific way. The danger of that is a threefold security issue: - you force the receiver to reveal information about its load - you modify the sender behaviour with an unauthenticated message (not necessarily fatal, but needs a tradeoff analysis) - you provide a method for off-path attackers to create backscatter (probably not a big issue here) I don't believe any (widespread) protocols operate in this way, although I'd be interested in counter-examples. A third possibility is to be like the first possibility, but with the option at the receiver to send an informative diagnostic saying "I'm busy". The sender would behave as though a packet had been dropped (back off and retry) but would know more about what is going on. The current spec does the first. I think the second is not appropriate (prepared to hear arguments). A diagnostic of the third type could be added quite easily, since it does not actually change protocol operation (happy to receive text suggestions ;-).) cheers, robert h. > -----Original Message----- > From: Roland Bless [mailto:bless@tm.uka.de]=20 > Sent: 14 November 2007 21:38 > To: Lauri J T Liuhto > Cc: nsis@ietf.org > Subject: Re: [NSIS] GIST peering concern >=20 > Hi Lauri, >=20 > Lauri J T Liuhto wrote: > > While implementing our own NSLPs and the API between GIST=20 > and NSLPs,=20 > > we came across something in the current NTLP i-d we think=20 > might be a=20 > > problem. > >=20 > > In section 4.3.2 "Local Processing and Validation" it is=20 > stated that:=20 > > "The first option (peering) MUST be chosen if the node is the final=20 > > destination of the Query message, or if the GIST hop count=20 > has reached=20 > > zero." We think this is problematic for at least two reasons. > >=20 > > 1) This removes flexibility from the NSLP application and=20 > forces certain=20 > > behaviour. Thus it complicates NSLP application logic,=20 > since the NSLP=20 > > must be aware of this exception to its peering "wishes". > >=20 > > 2) It could be possible to overload resources, such as=20 > memory and UDP=20 > > send rate, of a GIST node. Sending Queries with an=20 > (intentionally) =20 > > low GIST hop-count would lead to nodes being forced to=20 > peer, though=20 > > it is stated in the same section (4.3.2), that a node=20 > can decline=20 > > peering for "overload protection reasons". >=20 > I would agree here. However, I'm not sure what the rationale=20 > was for the current text. Probably Robert has an answer. >=20 > > We suggest that an error message be defined for the case=20 > when a flow=20 > > endpoint does not wish to peer, or that the definition of the=20 > > "Endpoint Found" message be extended to include this case.=20 > Currently=20 > > section 4.3.4 seems to state, that "Endpoint Found" can=20 > only be sent=20 > > when the NSLP is not present on the GIST node. >=20 > One must be careful to not open new attack possibilities by=20 > causing error message backscatter. For diagnostic purposes I=20 > would also recommend to send back an error. >=20 > Regards, > Roland >=20 >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Sun Nov 18 16:20:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItrZC-0002rQ-IU; Sun, 18 Nov 2007 16:20:34 -0500 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1ItrZA-0002rE-Vt for nsis-confirm+ok@megatron.ietf.org; Sun, 18 Nov 2007 16:20:32 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItrZA-0002r4-7d; Sun, 18 Nov 2007 16:20:32 -0500 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ItrZ9-0004mJ-RO; Sun, 18 Nov 2007 16:20:32 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id B430C2AC5E; Sun, 18 Nov 2007 21:20:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1ItrYf-0006Qt-GH; Sun, 18 Nov 2007 16:20:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Sun, 18 Nov 2007 16:20:01 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: nsis@ietf.org Subject: [NSIS] I-D Action:draft-ietf-nsis-ntlp-sctp-02.txt X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Next Steps in Signaling Working Group of the IETF. Title : General Internet Signaling Transport (GIST) over SCTP Author(s) : X. Fu, et al. Filename : draft-ietf-nsis-ntlp-sctp-02.txt Pages : 11 Date : 2007-11-18 The General Internet Signaling Transport (GIST) protocol currently uses TCP or TLS over TCP for connection mode operation. This document describes the usage of GIST over the Stream Control Transmission Protocol (SCTP). The use of SCTP can take advantage of features provided by SCTP, namely streaming-based transport, support of multiple streams to avoid head of line blocking, and the support of multi-homing to provide network level fault tolerance. Additionally, the support for the Partial Reliability Extension of SCTP is discussed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nsis-ntlp-sctp-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-nsis-ntlp-sctp-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-nsis-ntlp-sctp-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-11-18161610.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nsis-ntlp-sctp-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nsis-ntlp-sctp-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-11-18161610.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --NextPart-- From nsis-bounces@ietf.org Sun Nov 18 21:22:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItwGq-0007la-Eb; Sun, 18 Nov 2007 21:21:56 -0500 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1ItwGp-0007iv-I7 for nsis-confirm+ok@megatron.ietf.org; Sun, 18 Nov 2007 21:21:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItwGp-0007hC-5s for nsis@ietf.org; Sun, 18 Nov 2007 21:21:55 -0500 Received: from smtp.mei.co.jp ([133.183.100.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ItwGj-0000tT-51 for nsis@ietf.org; Sun, 18 Nov 2007 21:21:55 -0500 Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kc-maile11) with ESMTP id lAJ2LZ30004061; Mon, 19 Nov 2007 11:21:35 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx2) with ESMTP id lAJ2LaP09104; Mon, 19 Nov 2007 11:21:36 +0900 (JST) Received: from epochmail.jp.panasonic.com ([127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/redsox) with ESMTP id lAJ2Lat06073; Mon, 19 Nov 2007 11:21:36 +0900 (JST) Received: by epochmail.jp.panasonic.com (8.12.11.20060308/3.7W/soml28) id lAJ2LZhh024420; Mon, 19 Nov 2007 11:21:35 +0900 (JST) Received: from [10.68.136.102] by soml28.jp.panasonic.com (8.12.11.20060308/3.7W) with ESMTP id lAJ2LUA1024288; Mon, 19 Nov 2007 11:21:30 +0900 (JST) Date: Mon, 19 Nov 2007 11:23:39 +0900 From: Takako Sanda To: Roland Bless Subject: Re: [NSIS] Re: [NSIS Mobility draft] Updating from -07 to -08 In-Reply-To: <473D7726.1070504@tm.uka.de> References: <473D05AF.9050507@sg.panasonic.com> <473D7726.1070504@tm.uka.de> Message-Id: <20071119111153.A9A6.SANDA.TAKAKO@jp.panasonic.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.24.02 [ja] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9cc83ac38bbbabacbf00f656311dd8d8 Cc: Hong Cheng , "nsis@ietf.org" , Jukka MJ Manner X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Roland, Thank you for the useful comments. As you say, it will be good to describe all of four cases in the draft: 1.) MN is sender, sender-initiated reservation 2.) MN is sender, receiver-initiated reservation 3.) MN is receiver, sender-initiated reservation 4.) MN is receiver, receiver-initiated reservation But as submission deadline is today, I do not think we can write these scenarios in -08. Therefore, I will only adopt all of your other comments for -08, and add other scenarios for -09 soon after coming IETF meeting. Is this fine? cheers, Takako On Fri, 16 Nov 2007 11:55:34 +0100 Roland Bless wrote: > Hi Hong, Takako and all, > > we were writing up another e-mail, but I guess your analysis is > mostly correct. I'll try to summarize our (Martin and I) comments > as follows: > > We (Martin an I) have some major comments about the draft and are > willing to contribute to it. > First, we find that we basically should distinguish four cases: > 1.) MN is sender, sender-initiated reservation > 2.) MN is sender, receiver-initiated reservation > 3.) MN is receiver, sender-initiated reservation > 4.) MN is receiver, receiver-initiated reservation > > It seems that only case 1.) is currently discussed in section 4 > and we think it would be good to systematically discuss > the other cases, too. > > In case that MobileIPv6 is used it boils down to > the following cases as Hong described already. We assume > that the MN changes its address and the we distinguish > two flows: > cases 1.)+2.) (MN-Sender) f_o: old-CoA -> CN, f_n: new-CoA -> CN > cases 3.)+4.) (MN-Receiver) f_o: CN -> old-CoA, f_n: CN -> new-CoA > > Case > 1.) > - MN changes its IP address, obtains new-CoA > - QoS NSLP must become aware of the handover, so that the > - MN simply initiates a new RESERVE for the new flow f_n > > 2.) > - MN changes its IP address, obtains new-CoA > - QoS NSLP must become aware of the handover, so that the > - MN initiates a new QUERY(RESERVE-INIT) for the new flow f_n > > 3.) > - MN changes its IP address, obtains new-CoA > - MN performs mobility management signaling, i.e. binding update > to the CN. > - CN becomes aware of the handover (this is the important part) > so that the NSLP can initiate a new RESERVE. > 4.) > - MN changes its IP address, obtains new-CoA > - MN performs mobility management signaling, i.e. binding update > to the CN. > - CN gets aware of the handover, NSLP sends a new > QUERY > > The important part for all four cases is that > the QoS NSLP becomes aware of the handover. There > are several possibilities for the trigger, but I > think we should use a new GIST API primitive for > the notification (but probably as mobility extension > of GIST not within the current proposed draft). > You wrote that GIST will trigger the NSLP, > but I don't think that there is currently such > a possibility: > new binding update actually changes an existing flow > f_o into the new f_n. So the only existing primitive > would be to indicate > NetworkNotification(QoS-NSLP, MRI(f_o), Routing-Status-Change=Bad) > for the old flow. But we need to get the new MRI > in order to send the NSLP message. One problem is that > GIST doesn't have any state for the new flow f_n. > So I would propose to have a new NetworkNotificationType, > like MRI change: > NetworkNotification(QoS-NSLP, MRI(f_o), MRI(f_n)) > The problem is, however, that an updated IP address > (due to mobility management) may affect several GIST > flows. > > An alternative would be a trigger caused by the > application itself, e.g., due to application level > signaling. It would be similar to the fact that > we need such a trigger anyway for receiver-initiated > reservations in order to let the sender issue an initial > Query. I guess we need to support both possibilities > for cross layer info. > > Concerning your mentioned option of directly sending > a NOTIFY to the other end: that's also an alternative > that I discussed with Martin. Our proposed EST-MRM > would probably enable a node to do so, i.e., a NOTIFY > indicating a handover event could be sent directly > to the other end. > > Now for some further comments to the draft: > > Further comments on section 4.2: > I propose to change the name of "State Update" > at least to "Localized State Update", because > my intuitive understanding of State Update is > that is denotes the process to update the flow's state > along the whole path. > > With respect to section 4.2.1 we want to remark that > usually the main difference between mobility/handover > scenarios and re-routing as describe in appendix A is: > in the basic mobility scenario the MRI changes: the > MN gets a new care-of-address and thus we have a new flow > (we denote this as f_n). In contrast to this, a re-routing > by route changes will usually not lead to a change of > the MRI. So normally only the CRN can determine at > NSLP level that a handover happened by detecting two > different MRIs (f_o=old flow and f_n=new flow) belonging > to the same SID. GIST does not really care about the SID, > so this relation must be handled at the NSLP > level. > > Furthermore, I would propose to rephrase the last > paragraph of section 4.2.3 as QoS NSLP does not allow > to sent RESERVEs towards the QNI. Thus, there is no > option to do it differently. > > Best regards, > Roland and Martin > > Hong Cheng wrote: > > Hi Roland and Jukka, > > > > This seems like some interesting discussion that should be used to > > update the MIP operation part in the draft. > > > > Based on the description, I don't think a NOTIFY from MN is necessary > > when the other end (CN or HA) is a QNE. > > > > When MN is the Data Sender, it should work this way: > > - MN changes its IP addr, e.g. obtain a new-CoA; > > - MN sends a QUERY(RESERVE-INIT)towards the CN/HA with the new MRI (if > > it's QNR); or > > - MN sends a RESERVE towards the CN with the new MRI (if it's QNI) > > > > When MN is the Data Receiver, and the CN/HA is a QNE, it should work > > this way: > > - MN changes its IP addr, e.g. obtain a new-CoA; > > - MN does Mobility Management signaling to inform CN/HA of new-CoA > > (otherwise data path would not change, remember CN/HA is the data sender); > > - CN/HA is triggered by GIST to send QUERY towards MN using new MRI; > > - MN sends RESPONSE (if it's QNR) or RESERVE (if it's QNI); and > > - CN/HA sends RESERVE if it is QNI. > > In the above step 3, CN/HA sends QUERY instead of RESERVE directly(if > > CN/HA is QNI) because the path condition may change as MN changes > > location (as indicated in your earlier email, WiFi and WiMAX may > > provides different throughput). However, if time is a concern, CN/HA can > > always use back the old QSPEC for a direct RESERVE first. > > > > The situation will become a bit more interesting when the CN/HA is not > > QNE. In this case, how the MN does the update worth some discussion. > > > > If MN is the Data Sender, same operation as above should be able to work. > > > > If MN is the Data Receiver, there are problems in signaling as indicated > > in Roland's email, especially when we assume the routing is asymmetric. > > There are two possible ways: > > - If MN knows the QNI/QNR addr, it can send a NOTIFY/QUERY directly to > > it. However, in the current QoS NSLP spec, there is no way for the MN to > > know that info. Should we fix this, e.g. as a special mobility/proxy > > INFO-Element? > > - Get some help from the CN/HA (the data sender). Possibly to > > encapsulate the NOTIFY to CN/HA, and get them to send it via Data Path. > > This is like sending a special PING to the CN/HA. > > > > What do you think? > > > > > > Roland Bless wrote: > >> Hi Jukka, > >> > >> [I'm taking this to the list now...] > >> > >> Jukka MJ Manner wrote: > >>> I think we are talking about the same thing. The main point is that if IP > >>> addresses change, the MRI is invalidated, and the QNI must then, in one > >>> way or another be notified. There must be (otherwise nothing works) some > >>> mobility signaling where the QNI gets to know the new IP of the MN, and > >>> can then reissue a RESERVE with a new MRI. > >> Ok, however, I believe that your proposed solution doesn't work: > >> you proposed to send a NOTIFY towards the CN. This will require usage > >> of the new flow's MRI and the resulting GIST Query must be sent in > >> _upstream_ direction, i.e., PC-MRI(CN->MN-newCoA, D-Flag=1) - upstream. > >> Now there is the problem of choosing the correct encapsulation for the > >> Query: only _upstream_ Q-mode encapsulation would be an option, but this > >> is not appropriate to use in this case due to its limited applicability > >> to certain environments. Even if the MN could send the NOTIFY to its > >> new access router (QNE4 below), there is no routing state installed yet > >> in upstream direction in QNE4, i.e., it doesn't know any next peer > >> in upstream direction, so only upstream Q-mode could be used, but that > >> is not really applicable in this case. So only the last paragraph of > >> section 4.3.3 applies: > >> o If no routing state exists, GIST can attempt to use Q-mode as in > >> the Query case: either sending a Data message with the Q-mode > >> encapsulation, or using the event as a trigger for routing state > >> setup (see Section 4.4). If this is not possible, e.g. because > >> the encapsulation for the MRM is only defined for one message > >> direction, then this is an error condition which is reported back > >> to the local signalling application. > >> > >> So an error will be reported back to the application. > >> As a conclusion: sending a NOTIFY in upstream direction does not > >> work along paths that have no routing state yet. > >> > >>> The asymmetric paths is a real problem, especially if the MN switches e.g. > >>> interface technologies, goes from WLAN to WiMAX, and changes operators at > >>> the same time. In that case the QUERY will hit some node, the QNI at the > >>> latest, which can then send the RESERVE towards the new location of the > >>> MN. > >> We will come back later with more detailed comments about the mobility > >> scenarios. > >> > >> Regards, > >> Roland & Martin (Roehricht) > >> > >>> Jukka > >>> > >>> On Fri, 9 Nov 2007, Roland Bless wrote: > >>> > >>>> Hi Jukka, > >>>> > >>>> see comments below. > >>>> > >>>> Jukka MJ Manner wrote: > >>>>>> > >>>>>>> [MN] [QNE1] --- [QNE2] ---\ > >>>>>>> | \ > >>>>>>> | [QNE3] --- [QNE6] --- [QNE7] --- > >>>>>>> | / > >>>>>>> V / > >>>>>>> [MN] [QNE4] --- [QNE5]---/ > >>>>>>> > >>>>>> > >>>>>>> - MN moves, gets a hint from GIST that routing has changed > >>>>>>> - MN sends a NOTIFY towards QNI saying "Route Change" 0x02 > >>>>>>> - QNE4 will receive it, and forward it, same with QNE5 > >>>>>>> - The NOTIFY will hit QNE3, which notes that the message for a known > >>>>>>> session comes from a new SII-Handle. > >>>>>>> - QNE3 should then send a full RESERVE with a new RSN and an RII to > >>>>>>> QNE5 > >>>>>>> - QNE4 will receive the RESERVE, make the reservation, and forward it > >>>>>>> to the MN > >>>>>>> - The MN gets the RESERVE and replies with a RESPONSE > >>>>>> - In order to send NSIS message hop by hop for upstream direction (MN-> > >>>>>> QNE4->...->QNE7... in the figure below), GIST state need to be > >>>>>> established in advance, and this GIST state is established for > >>>>>> downstream direction (e.g., QNE3 aware of route change and perform route > >>>>>> change process towards MN in the new location). But if this is possible, > >>>>>> I guess "make it faster" operation (operation above) does not make sense, > >>>>>> because QNE3 (CRN) will able to do new reservation and teardown without > >>>>>> receiving NOTIFY from MN. > >>>>>> - How MRI update can be done in this case? > >>>>> In order for the MN to send the NOTIFY, each GIST hop will need to set up > >>>>> state upstream. This state establishment will result in a QUERY hitting > >>>>> QNE3, which will decide to peer. The SID is known, thus, the QNE3 will > >>>>> consider this a re-routing event, and perform the signaling as above. This > >>>>> should work? QNE3 will not know about the re-routing until QNE1 figures > >>>>> out the MN has disappeared, and QNE1 starts tearing down the reservation. > >>>> Sorry, but I don't get the point here and I doubt that its working > >>>> correctly. what is the exact scenario? > >>>> > >>>> - MN is QNR and data receiver? > >>>> - Reservation is sender-initiated? > >>>> - MN uses Mobile IP? > >>>> > >>>> I see the different cases now: > >>>> a) MN gets a new IP address and default route > >>>> b) MN performs mobility management signaling (Bindung Update) > >>>> > >>>> Is it that GIST will already detect a route change by a) > >>>> or will the route be changed by b)? > >>>> > >>>> With the current proposal I have the following issues: > >>>> * In case of a) it may be the case that QNE3 is not even hit by a Query > >>>> sent upstream due to asymmetric paths. > >>>> * The MRI must get updated along the whole path, especially for > >>>> profile update in the first hop router at the QNI. > >>>> * QNE3 tries to automatically reserve resources as they were before the > >>>> handover. This is especially inappropriate in case of vertical > >>>> handovers when the QSPEC should be changed. Therefore it would be good > >>>> that the QNI is involved in re-issuing a RESERVE. > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Nov 19 01:10:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Itzpp-0005PB-CC; Mon, 19 Nov 2007 01:10:17 -0500 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1Itzpj-0005Ba-LH for nsis-confirm+ok@megatron.ietf.org; Mon, 19 Nov 2007 01:10:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Itzpi-00059k-3Y for nsis@ietf.org; Mon, 19 Nov 2007 01:10:10 -0500 Received: from smtp.mei.co.jp ([133.183.100.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ItzpZ-0008P2-RU for nsis@ietf.org; Mon, 19 Nov 2007 01:10:09 -0500 Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kc-maile11) with ESMTP id lAJ69ppp003853; Mon, 19 Nov 2007 15:09:51 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx3) with ESMTP id lAJ69pS06380; Mon, 19 Nov 2007 15:09:51 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/mariners) with SMTP id lAJ69qA15523; Mon, 19 Nov 2007 15:09:52 +0900 (JST) Received: from [127.0.0.1] ([10.81.113.75]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Nov 2007 14:09:42 +0800 Message-ID: <474128A4.2060905@sg.panasonic.com> Date: Mon, 19 Nov 2007 14:09:40 +0800 From: Hong Cheng User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Roland Bless Subject: Re: [NSIS] Re: [NSIS Mobility draft] Updating from -07 to -08 References: <20071105200346.2BAF.SANDA.TAKAKO@jp.panasonic.com> <47343862.5040206@tm.uka.de> <473C4D46.7020002@tm.uka.de> <473D05AF.9050507@sg.panasonic.com> <473D7726.1070504@tm.uka.de> In-Reply-To: <473D7726.1070504@tm.uka.de> X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Nov 2007 06:09:42.0244 (UTC) FILETIME=[C6595240:01C82A72] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2b3349545af520ba354ccdc9e1a03fc1 Cc: "nsis@ietf.org" , Jukka MJ Manner , Takako Sanda X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Roland, Thanks for the more comprehensive analysis. I agree with your points. However, I think the described procedure somehow assumes that the CN is a QNE. In case the CN is not the QNI/QNR, there might need to have further improvement (as mentioned in my early mail). I think this should also be mentioned in the draft, as NSIS allows this case. Please find some other comments inline below: cheers Cheng Hong Roland Bless wrote: > Hi Hong, Takako and all, > > we were writing up another e-mail, but I guess your analysis is > mostly correct. I'll try to summarize our (Martin and I) comments > as follows: > > We (Martin an I) have some major comments about the draft and are > willing to contribute to it. > First, we find that we basically should distinguish four cases: > 1.) MN is sender, sender-initiated reservation > 2.) MN is sender, receiver-initiated reservation > 3.) MN is receiver, sender-initiated reservation > 4.) MN is receiver, receiver-initiated reservation > > It seems that only case 1.) is currently discussed in section 4 > and we think it would be good to systematically discuss > the other cases, too. [HCheng] Agree. I think the current draft needs to be cleaned up. Your suggestion sounds quite reasonable. > In case that MobileIPv6 is used it boils down to > the following cases as Hong described already. We assume > that the MN changes its address and the we distinguish > two flows: > cases 1.)+2.) (MN-Sender) f_o: old-CoA -> CN, f_n: new-CoA -> CN > cases 3.)+4.) (MN-Receiver) f_o: CN -> old-CoA, f_n: CN -> new-CoA > > Case > 1.) > - MN changes its IP address, obtains new-CoA > - QoS NSLP must become aware of the handover, so that the > - MN simply initiates a new RESERVE for the new flow f_n > > 2.) > - MN changes its IP address, obtains new-CoA > - QoS NSLP must become aware of the handover, so that the > - MN initiates a new QUERY(RESERVE-INIT) for the new flow f_n > > 3.) > - MN changes its IP address, obtains new-CoA > - MN performs mobility management signaling, i.e. binding update > to the CN. > - CN becomes aware of the handover (this is the important part) > so that the NSLP can initiate a new RESERVE. > 4.) > - MN changes its IP address, obtains new-CoA > - MN performs mobility management signaling, i.e. binding update > to the CN. > - CN gets aware of the handover, NSLP sends a new > QUERY > > The important part for all four cases is that > the QoS NSLP becomes aware of the handover. There > are several possibilities for the trigger, but I > think we should use a new GIST API primitive for > the notification (but probably as mobility extension > of GIST not within the current proposed draft). > You wrote that GIST will trigger the NSLP, > but I don't think that there is currently such > a possibility: > new binding update actually changes an existing flow > f_o into the new f_n. So the only existing primitive > would be to indicate > NetworkNotification(QoS-NSLP, MRI(f_o), Routing-Status-Change=Bad) > for the old flow. But we need to get the new MRI > in order to send the NSLP message. One problem is that > GIST doesn't have any state for the new flow f_n. > So I would propose to have a new NetworkNotificationType, > like MRI change: > NetworkNotification(QoS-NSLP, MRI(f_o), MRI(f_n)) [HCheng] This sounds reasonable. I agree that we should make this an mobility extension of the GIST, as it only needs to be supported by some specific nodes, e.g. MN or CN. > The problem is, however, that an updated IP address > (due to mobility management) may affect several GIST > flows. [HCheng] Does this mean this specific API should support a wildcarded NSLP ID? On a MN, the change of MRI should affect all the NSLP. On the CN, only the NSLP having a session with MN should be affected. Should GIST differentiate this? > > An alternative would be a trigger caused by the > application itself, e.g., due to application level > signaling. It would be similar to the fact that > we need such a trigger anyway for receiver-initiated > reservations in order to let the sender issue an initial > Query. I guess we need to support both possibilities > for cross layer info. [HCheng] I guess the application layer trigger is a separate issue instead of an alternative, as not all application supports IP address changes. This may also relates to some earlier discussion of Appl-NSLP interface. > Concerning your mentioned option of directly sending > a NOTIFY to the other end: that's also an alternative > that I discussed with Martin. Our proposed EST-MRM > would probably enable a node to do so, i.e., a NOTIFY > indicating a handover event could be sent directly > to the other end. [HCheng] The EST-MRM seems quite useful in this case. Another way is to simply define a flag such that the message could be routed directly. However, I guess the main issue of concern is how to find/locate where the message should be sent, assuming asymmetric routing. > Now for some further comments to the draft: > > Further comments on section 4.2: > I propose to change the name of "State Update" > at least to "Localized State Update", because > my intuitive understanding of State Update is > that is denotes the process to update the flow's state > along the whole path. > > With respect to section 4.2.1 we want to remark that > usually the main difference between mobility/handover > scenarios and re-routing as describe in appendix A is: > in the basic mobility scenario the MRI changes: the > MN gets a new care-of-address and thus we have a new flow > (we denote this as f_n). In contrast to this, a re-routing > by route changes will usually not lead to a change of > the MRI. So normally only the CRN can determine at > NSLP level that a handover happened by detecting two > different MRIs (f_o=old flow and f_n=new flow) belonging > to the same SID. GIST does not really care about the SID, > so this relation must be handled at the NSLP > level. [HCheng] Agree. Although GIST should have adequate information to handle it, I don't think it cares (or should care about this). > Furthermore, I would propose to rephrase the last > paragraph of section 4.2.3 as QoS NSLP does not allow > to sent RESERVEs towards the QNI. Thus, there is no > option to do it differently. > > Best regards, > Roland and Martin > > Hong Cheng wrote: >> Hi Roland and Jukka, >> >> This seems like some interesting discussion that should be used to >> update the MIP operation part in the draft. >> >> Based on the description, I don't think a NOTIFY from MN is necessary >> when the other end (CN or HA) is a QNE. >> >> When MN is the Data Sender, it should work this way: >> - MN changes its IP addr, e.g. obtain a new-CoA; >> - MN sends a QUERY(RESERVE-INIT)towards the CN/HA with the new MRI (if >> it's QNR); or >> - MN sends a RESERVE towards the CN with the new MRI (if it's QNI) >> >> When MN is the Data Receiver, and the CN/HA is a QNE, it should work >> this way: >> - MN changes its IP addr, e.g. obtain a new-CoA; >> - MN does Mobility Management signaling to inform CN/HA of new-CoA >> (otherwise data path would not change, remember CN/HA is the data sender); >> - CN/HA is triggered by GIST to send QUERY towards MN using new MRI; >> - MN sends RESPONSE (if it's QNR) or RESERVE (if it's QNI); and >> - CN/HA sends RESERVE if it is QNI. >> In the above step 3, CN/HA sends QUERY instead of RESERVE directly(if >> CN/HA is QNI) because the path condition may change as MN changes >> location (as indicated in your earlier email, WiFi and WiMAX may >> provides different throughput). However, if time is a concern, CN/HA can >> always use back the old QSPEC for a direct RESERVE first. >> >> The situation will become a bit more interesting when the CN/HA is not >> QNE. In this case, how the MN does the update worth some discussion. >> >> If MN is the Data Sender, same operation as above should be able to work. >> >> If MN is the Data Receiver, there are problems in signaling as indicated >> in Roland's email, especially when we assume the routing is asymmetric. >> There are two possible ways: >> - If MN knows the QNI/QNR addr, it can send a NOTIFY/QUERY directly to >> it. However, in the current QoS NSLP spec, there is no way for the MN to >> know that info. Should we fix this, e.g. as a special mobility/proxy >> INFO-Element? >> - Get some help from the CN/HA (the data sender). Possibly to >> encapsulate the NOTIFY to CN/HA, and get them to send it via Data Path. >> This is like sending a special PING to the CN/HA. >> >> What do you think? >> >> >> Roland Bless wrote: >>> Hi Jukka, >>> >>> [I'm taking this to the list now...] >>> >>> Jukka MJ Manner wrote: >>>> I think we are talking about the same thing. The main point is that if IP >>>> addresses change, the MRI is invalidated, and the QNI must then, in one >>>> way or another be notified. There must be (otherwise nothing works) some >>>> mobility signaling where the QNI gets to know the new IP of the MN, and >>>> can then reissue a RESERVE with a new MRI. >>> Ok, however, I believe that your proposed solution doesn't work: >>> you proposed to send a NOTIFY towards the CN. This will require usage >>> of the new flow's MRI and the resulting GIST Query must be sent in >>> _upstream_ direction, i.e., PC-MRI(CN->MN-newCoA, D-Flag=1) - upstream. >>> Now there is the problem of choosing the correct encapsulation for the >>> Query: only _upstream_ Q-mode encapsulation would be an option, but this >>> is not appropriate to use in this case due to its limited applicability >>> to certain environments. Even if the MN could send the NOTIFY to its >>> new access router (QNE4 below), there is no routing state installed yet >>> in upstream direction in QNE4, i.e., it doesn't know any next peer >>> in upstream direction, so only upstream Q-mode could be used, but that >>> is not really applicable in this case. So only the last paragraph of >>> section 4.3.3 applies: >>> o If no routing state exists, GIST can attempt to use Q-mode as in >>> the Query case: either sending a Data message with the Q-mode >>> encapsulation, or using the event as a trigger for routing state >>> setup (see Section 4.4). If this is not possible, e.g. because >>> the encapsulation for the MRM is only defined for one message >>> direction, then this is an error condition which is reported back >>> to the local signalling application. >>> >>> So an error will be reported back to the application. >>> As a conclusion: sending a NOTIFY in upstream direction does not >>> work along paths that have no routing state yet. >>> >>>> The asymmetric paths is a real problem, especially if the MN switches e.g. >>>> interface technologies, goes from WLAN to WiMAX, and changes operators at >>>> the same time. In that case the QUERY will hit some node, the QNI at the >>>> latest, which can then send the RESERVE towards the new location of the >>>> MN. >>> We will come back later with more detailed comments about the mobility >>> scenarios. >>> >>> Regards, >>> Roland & Martin (Roehricht) >>> >>>> Jukka >>>> >>>> On Fri, 9 Nov 2007, Roland Bless wrote: >>>> >>>>> Hi Jukka, >>>>> >>>>> see comments below. >>>>> >>>>> Jukka MJ Manner wrote: >>>>>>> >>>>>>>> [MN] [QNE1] --- [QNE2] ---\ >>>>>>>> | \ >>>>>>>> | [QNE3] --- [QNE6] --- [QNE7] --- >>>>>>>> | / >>>>>>>> V / >>>>>>>> [MN] [QNE4] --- [QNE5]---/ >>>>>>>> >>>>>>> >>>>>>>> - MN moves, gets a hint from GIST that routing has changed >>>>>>>> - MN sends a NOTIFY towards QNI saying "Route Change" 0x02 >>>>>>>> - QNE4 will receive it, and forward it, same with QNE5 >>>>>>>> - The NOTIFY will hit QNE3, which notes that the message for a known >>>>>>>> session comes from a new SII-Handle. >>>>>>>> - QNE3 should then send a full RESERVE with a new RSN and an RII to >>>>>>>> QNE5 >>>>>>>> - QNE4 will receive the RESERVE, make the reservation, and forward it >>>>>>>> to the MN >>>>>>>> - The MN gets the RESERVE and replies with a RESPONSE >>>>>>> - In order to send NSIS message hop by hop for upstream direction (MN-> >>>>>>> QNE4->...->QNE7... in the figure below), GIST state need to be >>>>>>> established in advance, and this GIST state is established for >>>>>>> downstream direction (e.g., QNE3 aware of route change and perform route >>>>>>> change process towards MN in the new location). But if this is possible, >>>>>>> I guess "make it faster" operation (operation above) does not make sense, >>>>>>> because QNE3 (CRN) will able to do new reservation and teardown without >>>>>>> receiving NOTIFY from MN. >>>>>>> - How MRI update can be done in this case? >>>>>> In order for the MN to send the NOTIFY, each GIST hop will need to set up >>>>>> state upstream. This state establishment will result in a QUERY hitting >>>>>> QNE3, which will decide to peer. The SID is known, thus, the QNE3 will >>>>>> consider this a re-routing event, and perform the signaling as above. This >>>>>> should work? QNE3 will not know about the re-routing until QNE1 figures >>>>>> out the MN has disappeared, and QNE1 starts tearing down the reservation. >>>>> Sorry, but I don't get the point here and I doubt that its working >>>>> correctly. what is the exact scenario? >>>>> >>>>> - MN is QNR and data receiver? >>>>> - Reservation is sender-initiated? >>>>> - MN uses Mobile IP? >>>>> >>>>> I see the different cases now: >>>>> a) MN gets a new IP address and default route >>>>> b) MN performs mobility management signaling (Bindung Update) >>>>> >>>>> Is it that GIST will already detect a route change by a) >>>>> or will the route be changed by b)? >>>>> >>>>> With the current proposal I have the following issues: >>>>> * In case of a) it may be the case that QNE3 is not even hit by a Query >>>>> sent upstream due to asymmetric paths. >>>>> * The MRI must get updated along the whole path, especially for >>>>> profile update in the first hop router at the QNI. >>>>> * QNE3 tries to automatically reserve resources as they were before the >>>>> handover. This is especially inappropriate in case of vertical >>>>> handovers when the QSPEC should be changed. Therefore it would be good >>>>> that the QNI is involved in re-issuing a RESERVE. > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Nov 19 03:24:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu1w4-0007l4-5p; Mon, 19 Nov 2007 03:24:52 -0500 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1Iu1w2-0007NF-6S for nsis-confirm+ok@megatron.ietf.org; Mon, 19 Nov 2007 03:24:50 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu1w1-0007FW-GM for nsis@ietf.org; Mon, 19 Nov 2007 03:24:49 -0500 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iu1w1-0004Zn-4K for nsis@ietf.org; Mon, 19 Nov 2007 03:24:49 -0500 Received: from irams2.ira.uni-karlsruhe.de ([141.3.10.82]) by iramx2.ira.uni-karlsruhe.de with esmtps id 1Iu1vv-0000tB-Vt; Mon, 19 Nov 2007 09:24:45 +0100 Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by irams2.ira.uni-karlsruhe.de with esmtps id 1Iu1vu-0003cK-QG; Mon, 19 Nov 2007 09:24:43 +0100 Received: from i72ms.tm.uni-karlsruhe.de ([141.3.70.5] helo=smtp.ipv6.tm.uni-karlsruhe.de) by irams1.ira.uni-karlsruhe.de with esmtps id 1Iu1vu-0007mr-BQ; Mon, 19 Nov 2007 09:24:42 +0100 Received: from vorta.ipv6.tm.uni-karlsruhe.de (vorta.ipv6.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:207:e9ff:fe0c:5e44]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id BBCAC2FC00E; Mon, 19 Nov 2007 09:24:39 +0100 (CET) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1Iu1vr-0006pF-Ay; Mon, 19 Nov 2007 09:24:39 +0100 Message-ID: <47414844.5030409@tm.uka.de> Date: Mon, 19 Nov 2007 09:24:36 +0100 From: Roland Bless Organization: Institute of Telematics, University of Karlsruhe User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060111 Thunderbird/1.5 Mnenhy/0.7.3.0 MIME-Version: 1.0 To: Takako Sanda Subject: Re: [NSIS] Re: [NSIS Mobility draft] Updating from -07 to -08 References: <473D05AF.9050507@sg.panasonic.com> <473D7726.1070504@tm.uka.de> <20071119111153.A9A6.SANDA.TAKAKO@jp.panasonic.com> In-Reply-To: <20071119111153.A9A6.SANDA.TAKAKO@jp.panasonic.com> X-Enigmail-Version: 0.94.4.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Status: No X-Spam-Score: -1.3 (-) X-Spam-Report: -1.4 ALL_TRUSTED Passed through trusted hosts only via SMTP 0.1 AWL AWL: From: address is in the auto white-list X-Spam-Host: irams2.ira.uni-karlsruhe.de X-ATIS-Checksum: v3zoCAcc32ckk X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: Hong Cheng , "nsis@ietf.org" , Jukka MJ Manner X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Takako, Takako Sanda wrote: > Thank you for the useful comments. > > As you say, it will be good to describe all of four cases in the draft: > 1.) MN is sender, sender-initiated reservation > 2.) MN is sender, receiver-initiated reservation > 3.) MN is receiver, sender-initiated reservation > 4.) MN is receiver, receiver-initiated reservation > > But as submission deadline is today, I do not think we can write these > scenarios in -08. Therefore, I will only adopt all of your other > comments for -08, and add other scenarios for -09 soon after coming IETF > meeting. > > Is this fine? Sure, this is fine for me. Unfortunately, we cannot discuss further things personally in Vancouver, since I cannot attend the IETF meeting this time. Regards, Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Nov 19 04:01:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu2Vn-00040q-V5; Mon, 19 Nov 2007 04:01:47 -0500 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1Iu2Vn-00040b-Ag for nsis-confirm+ok@megatron.ietf.org; Mon, 19 Nov 2007 04:01:47 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu2Vm-00040M-Uo for nsis@ietf.org; Mon, 19 Nov 2007 04:01:47 -0500 Received: from smtp.mei.co.jp ([133.183.100.20]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iu2Vm-00080P-3c for nsis@ietf.org; Mon, 19 Nov 2007 04:01:46 -0500 Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kc-maile13) with ESMTP id lAJ91gDC018415 for ; Mon, 19 Nov 2007 18:01:42 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx2) with ESMTP id lAJ91gP26642 for ; Mon, 19 Nov 2007 18:01:42 +0900 (JST) Received: from epochmail.jp.panasonic.com (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/indians) with ESMTP id lAJ91h828879 for ; Mon, 19 Nov 2007 18:01:43 +0900 (JST) Received: by epochmail.jp.panasonic.com (8.12.11.20060308/3.7W/soml27) id lAJ91fXn016719 for nsis@ietf.org; Mon, 19 Nov 2007 18:01:41 +0900 (JST) Received: from [10.68.136.102] by soml27.jp.panasonic.com (8.12.11.20060308/3.7W) with ESMTP id lAJ91eGo016681 for ; Mon, 19 Nov 2007 18:01:40 +0900 (JST) Date: Mon, 19 Nov 2007 18:03:50 +0900 From: Takako Sanda To: nsis@ietf.org Subject: Re: [NSIS] Request your comments for NSIS Applicability Mobility draft In-Reply-To: <20071112185336.ADC1.SANDA.TAKAKO@jp.panasonic.com> References: <20071112182126.1E52.SANDA.TAKAKO@jp.panasonic.com> <20071112185336.ADC1.SANDA.TAKAKO@jp.panasonic.com> Message-Id: <20071119174540.A9C5.SANDA.TAKAKO@jp.panasonic.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.24.02 [ja] X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi all, I made minor update based on Roland's comments. http://geocities.com/panasonic_ietf/draft-ietf-nsis-applicability-mobility-signaling-08.txt - In section 4.2.1 (CRN discovery), CRN discovery at NTLP layer is deleted to avoid confusion. Description for CRN discovery at NSLP layer is also updated - Title of section 4.2.2 is changed to "Localized State Update" - Section 4.2.3 (State teardown consideration) is deleted because:- o first paragraph was only repetition of other sections o discussion in second paragraph was already clarified As I mentioned other email, I will submit this as -08. Other necessary changes will be made in -09. cheers, Takako On Mon, 12 Nov 2007 18:55:16 +0900 Takako Sanda wrote: > Hi all, > > > Please review this, and send your comments if you have any no later than > > 16 Feb. > > Mistaken. No later than 16 Fri., please :-) > > cheers, > Takako > > On Mon, 12 Nov 2007 18:36:15 +0900 > Takako Sanda wrote: > > > Hi all, > > > > Here is a new version of NSIS Applicability Mobility draft. > > http://geocities.com/panasonic_ietf/draft-ietf-nsis-applicability-mobility-signaling-08.txt > > > > Please review this, and send your comments if you have any no later than > > 16 Feb. > > > > In this version, Section 4 (Basic Operations for Mobility Support) > > especially localized mobility part was mainly updated so that the draft > > can be harmonized with QoS-NSLP draft. > > > > The following parts, described in Open Issues (Section 8), were still > > kept unchanged. > > o Cleaning up MIP interaction > > o Cleaning up Security Consideration > > o NAT traversal > > The authors especially need your comments for these open issues:- > > - whether the cleaning up for MIP interaction part is really necessary > > - whether the cleaning up for security consideration is really > > necessary > > - whether the NAT traversal issue should be discussed in Mobility draft > > (in addition to in NAT/FW NSLP draft) > > > > BR, > > Takako > > > > > > > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis ----- Takako SANDA Next-Generation Mobile Communications Development Center, Matsushita Electric Industrial Co., Ltd. (Panasonic) Phone: +81 50 3687 6563 Fax: +81 46 840 5122 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Nov 19 07:50:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu65I-0004n2-9X; Mon, 19 Nov 2007 07:50:40 -0500 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1Iu65D-0004hJ-Qo for nsis-confirm+ok@megatron.ietf.org; Mon, 19 Nov 2007 07:50:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu65C-0004eh-QJ; Mon, 19 Nov 2007 07:50:34 -0500 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iu65A-0006Td-Dl; Mon, 19 Nov 2007 07:50:34 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 6298332897; Mon, 19 Nov 2007 12:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Iu64g-0001oq-A1; Mon, 19 Nov 2007 07:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 19 Nov 2007 07:50:02 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: nsis@ietf.org Subject: [NSIS] I-D Action:draft-ietf-nsis-nslp-natfw-16.txt X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Next Steps in Signaling Working Group of the IETF. Title : NAT/Firewall NSIS Signaling Layer Protocol (NSLP) Author(s) : M. Stiemerling, et al. Filename : draft-ietf-nsis-nslp-natfw-16.txt Pages : 88 Date : 2007-11-19 This memo defines the NSIS Signaling Layer Protocol (NSLP) for Network Address Translators (NATs) and firewalls. This NSLP allows hosts to signal on the data path for NATs and firewalls to be configured according to the needs of the application data flows. It enables hosts behind NATs to obtain a public reachable address and hosts behind firewalls to receive data traffic. The overall architecture is given by the framework and requirements defined by the Next Steps in Signaling (NSIS) working group. The network scenarios, the protocol itself, and examples for path-coupled signaling are given in this memo. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nsis-nslp-natfw-16.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-nsis-nslp-natfw-16.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-nsis-nslp-natfw-16.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-11-19074537.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nsis-nslp-natfw-16.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nsis-nslp-natfw-16.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-11-19074537.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --NextPart-- From nsis-bounces@ietf.org Mon Nov 19 08:25:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu6cw-0004Xd-V1; Mon, 19 Nov 2007 08:25:26 -0500 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1Iu6cv-0004WU-Jh for nsis-confirm+ok@megatron.ietf.org; Mon, 19 Nov 2007 08:25:25 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu6cv-0004Vb-7x for nsis@ietf.org; Mon, 19 Nov 2007 08:25:25 -0500 Received: from smtp0.netlab.nec.de ([195.37.70.40]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iu6cu-00072I-Kb for nsis@ietf.org; Mon, 19 Nov 2007 08:25:25 -0500 Received: from localhost (atlas1.office [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 1662428000392 for ; Mon, 19 Nov 2007 14:25:24 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office) Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OVc9FZVvMxyn for ; Mon, 19 Nov 2007 14:25:23 +0100 (CET) Received: from mx1.office (mx1.office [10.1.1.23]) by smtp0.netlab.nec.de (Postfix) with ESMTP id EC0592800034D for ; Mon, 19 Nov 2007 14:25:18 +0100 (CET) Received: from [10.1.1.109] ([10.1.1.13]) by mx1.office over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 Nov 2007 14:25:18 +0100 Mime-Version: 1.0 (Apple Message framework v752.3) To: nsis Message-Id: From: Martin Stiemerling Date: Mon, 19 Nov 2007 14:25:17 +0100 X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 19 Nov 2007 13:25:18.0848 (UTC) FILETIME=[A0FA9800:01C82AAF] X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Subject: [NSIS] Call for agenda items for IETF-70 X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2002501019==" Errors-To: nsis-bounces@ietf.org --===============2002501019== Content-Type: multipart/alternative; boundary=Apple-Mail-14-275669147 --Apple-Mail-14-275669147 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi all, If you are interested in having a slot in the NSIS meeting at the IETF, please send the following information to nsis- chairs@tools.ietf.org until **Wednesday November 22nd, 5PM PST** The request must contain this information: Draft name, Presenter's name, Time slot needed. Working group drafts have, as usually, priority over individual submissions. Thanks, Martin stiemerling@netlab.nec.de NEC Laboratories Europe - Network Research Division NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 --Apple-Mail-14-275669147 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
Hi all,

If you are interested in having = a slot in the NSIS meeting at the IETF, please send the following = information to nsis-chairs@tools.ietf.org = until=A0

=A0=A0**Wednesd= ay November 22nd, 5PM PST**

The request = must contain this information:

Draft name,
Presenter's name,
Time = slot needed.

Working group drafts have, as = usually, priority over individual submissions.=A0


=A0 Martin

stiemerling@netlab.nec.de
NEC Laboratories Europe - Network Research = Division

NEC Europe = Limited |=A0Registered Office: NEC House, 1 Victoria Road, London W3 6BL = |=A0Registered in England 2832014

=

= --Apple-Mail-14-275669147-- --===============2002501019== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --===============2002501019==-- From nsis-bounces@ietf.org Tue Nov 20 02:57:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuNyg-00012F-1T; Tue, 20 Nov 2007 02:57:02 -0500 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1IuNye-00011n-5l for nsis-confirm+ok@megatron.ietf.org; Tue, 20 Nov 2007 02:57:00 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuNyX-0000ZN-4O; Tue, 20 Nov 2007 02:56:53 -0500 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuNyW-0001dM-Az; Tue, 20 Nov 2007 02:56:53 -0500 Received: from irams2.ira.uni-karlsruhe.de ([141.3.10.82]) by iramx2.ira.uni-karlsruhe.de with esmtps id 1IuNyT-0000x4-9d; Tue, 20 Nov 2007 08:56:51 +0100 Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by irams2.ira.uni-karlsruhe.de with esmtps id 1IuNyR-0004R8-W5; Tue, 20 Nov 2007 08:56:49 +0100 Received: from i72ms.tm.uni-karlsruhe.de ([141.3.70.5] helo=smtp.ipv6.tm.uni-karlsruhe.de) by irams1.ira.uni-karlsruhe.de with esmtps id 1IuNyR-0007A6-Fq; Tue, 20 Nov 2007 08:56:47 +0100 Received: from vorta.ipv6.tm.uni-karlsruhe.de (vorta.ipv6.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:207:e9ff:fe0c:5e44]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id 7D00C2FC00E; Tue, 20 Nov 2007 08:56:46 +0100 (CET) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1IuNyO-0007vJ-8K; Tue, 20 Nov 2007 08:56:44 +0100 Message-ID: <4742933B.5060501@tm.uka.de> Date: Tue, 20 Nov 2007 08:56:43 +0100 From: Roland Bless Organization: Institute of Telematics, University of Karlsruhe User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060111 Thunderbird/1.5 Mnenhy/0.7.3.0 MIME-Version: 1.0 Subject: Re: [NSIS] WGLC for draft-ietf-dime-qos-parameters-01 References: <470202BF.4000701@gmx.net> <47146250.1000504@tm.uka.de> <47146E15.9090200@gmx.net> In-Reply-To: <47146E15.9090200@gmx.net> X-Enigmail-Version: 0.94.4.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Status: No X-Spam-Score: -1.2 (-) X-Spam-Report: -1.4 ALL_TRUSTED Passed through trusted hosts only via SMTP 0.2 MISSING_HEADERS Missing To: header 0.0 AWL AWL: From: address is in the auto white-list X-Spam-Host: irams2.ira.uni-karlsruhe.de X-ATIS-Checksum: v3zoCAcc32ckk X-Spam-Score: 1.6 (+) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: dime@ietf.org, 'radext mailing list' , "nsis@ietf.org" , tsvwg IETF list X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Hannes, [sorry for the long delay of my reply] Hannes Tschofenig wrote: > There are a couple of reasons why we did not want to re-use the QSPEC > draft as is. > > The first reason is that the Diameter QoS attribute document and the > Diameter QoS application document, see > http://www.ietf.org/internet-drafts/draft-ietf-dime-diameter-qos-01.txt > http://www.ietf.org/internet-drafts/draft-ietf-dime-qos-attributes-02.txt > are independent of NSIS. There is no dependency between NSIS and these > documents although the Diameter interworking may also be used for NSIS. Ok. > The second reason is that the QSPEC draft has a different focus in the > sense that the description that is used for the front-end protocol (in > this case NSIS) is somewhat different to the interaction that takes > place at the backend. If you go through the QSPEC draft then you will > notice that many aspects in the draft are so specific to the NSIS > interactions. Unfortunately, the QSPEC is not just a collection of > parameters. We did not want to let the reader figure out which parts of > the document are relevant for them even if they use the Diameter QoS > work for a different purpose (such as in the interaction with RSVP). In > fact, in previous draft versions we just made references to the QSPEC > and when this was brought to other SDOs then this was a real show > stopper since people got totally confused. Ok. > The third reason is that we are changing the format of the QSPEC > headers. We tried to keep the changes at a minimum but still they are > different. Some time back we even considered to use a Diameter specific > format. There are still comments floating around suggesting it but at > the moment the plain QoS parameters are still in the format of the > QSPEC. We also make use of the registry created for the QoS parameters; > some of my recent mails referred to the mismatch between the QSPEC > registry and the registry created by a document in the TSVWG. > > The final reason is that we are changing the semantic of the > extensibility mechanism. The concept of QoS models (QoSM) as defined in > the QSPEC and the requirements for defining a QoSM does not work with > the Diameter usage. Hence, we had to change it. See Section 5 and 6 of > http://www.ietf.org/internet-drafts/draft-ietf-dime-qos-parameters-01.txt > > I believe these reasons justify a new document. > >> 2) The draft doesn't provide a meaningful definition of which parameters >> should be present together etc. It is only an unstructured list of >> parameter objects and there is no hint given about which combinations >> are allowed or meaningful etc. >> > That's true and I don't think draft-ietf-dime-qos-parameters-01 needs to > say anything about it. draft-ietf-dime-diameter-qos-01.txt and > draft-ietf-dime-qos-attributes-02.txt provide some minimum semantic. For > example, when someone wants to use the IntServ Controlled-Load Service QoSM > http://tools.ietf.org/wg/nsis/draft-kappler-nsis-qosmodel-controlledload-05.txt > and if an interaction with the Diameter backend infrastructure is > desired then they would take the respective parameters from the received > NSIS message and copy them into a Diameter message. The QoS profile > would be set to a value as defined in the IntServ Controlled-Load > Service QoSM (note that it has not been done yet). If there are specific > issues that need to be said about the backend infrastructure interaction > then they may be discussed in the respective QoSM but so far I have not > heard about anything. > > For some other QoSMs, such as RMD, I have never heard that a AAA > interaction would be desired. There, the usage model is different. > > Does this make sense to you? Yes. Thanks. Regards, Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Nov 20 09:14:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuTrY-0000IY-0Y; Tue, 20 Nov 2007 09:14:04 -0500 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1IuTrX-0000IG-Hr for nsis-confirm+ok@megatron.ietf.org; Tue, 20 Nov 2007 09:14:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuTrX-0000I8-85 for nsis@ietf.org; Tue, 20 Nov 2007 09:14:03 -0500 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuTrT-0003F6-ES for nsis@ietf.org; Tue, 20 Nov 2007 09:14:03 -0500 Received: from irams2.ira.uni-karlsruhe.de ([141.3.10.82]) by iramx2.ira.uni-karlsruhe.de with esmtps id 1IuTrM-0000yh-Ty; Tue, 20 Nov 2007 15:13:54 +0100 Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by irams2.ira.uni-karlsruhe.de with esmtps id 1IuTrJ-0000I8-Kz; Tue, 20 Nov 2007 15:13:52 +0100 Received: from i72ms.tm.uni-karlsruhe.de ([141.3.70.5] helo=smtp.ipv6.tm.uni-karlsruhe.de) by irams1.ira.uni-karlsruhe.de with esmtps id 1IuTrJ-0003ry-27; Tue, 20 Nov 2007 15:13:49 +0100 Received: from vorta.ipv6.tm.uni-karlsruhe.de (vorta.ipv6.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:207:e9ff:fe0c:5e44]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id 727692FC00E; Tue, 20 Nov 2007 15:13:45 +0100 (CET) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1IuTrE-0008BR-IF; Tue, 20 Nov 2007 15:13:45 +0100 Message-ID: <4742EB97.7090401@tm.uka.de> Date: Tue, 20 Nov 2007 15:13:43 +0100 From: Roland Bless Organization: Institute of Telematics, University of Karlsruhe User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060111 Thunderbird/1.5 Mnenhy/0.7.3.0 MIME-Version: 1.0 To: Hong Cheng Subject: Re: [NSIS] Re: [NSIS Mobility draft] Updating from -07 to -08 References: <20071105200346.2BAF.SANDA.TAKAKO@jp.panasonic.com> <47343862.5040206@tm.uka.de> <473C4D46.7020002@tm.uka.de> <473D05AF.9050507@sg.panasonic.com> <473D7726.1070504@tm.uka.de> <474128A4.2060905@sg.panasonic.com> In-Reply-To: <474128A4.2060905@sg.panasonic.com> X-Enigmail-Version: 0.94.4.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Status: No X-Spam-Score: -1.3 (-) X-Spam-Report: -1.4 ALL_TRUSTED Passed through trusted hosts only via SMTP 0.1 AWL AWL: From: address is in the auto white-list X-Spam-Host: irams2.ira.uni-karlsruhe.de X-ATIS-Checksum: v3zoCAcc32ckk X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: "nsis@ietf.org" , Jukka MJ Manner , Takako Sanda X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Hong, Hong Cheng wrote: > Thanks for the more comprehensive analysis. I agree with your points. > However, I think the described procedure somehow assumes that the CN is > a QNE. In case the CN is not the QNI/QNR, there might need to have > further improvement (as mentioned in my early mail). I think this should > also be mentioned in the draft, as NSIS allows this case. Yes, that was what you described, I guess that you are referring to the Proxy Mode of QoS NSLP. > [HCheng] Does this mean this specific API should support a wildcarded > NSLP ID? On a MN, the change of MRI should affect all the NSLP. On the > CN, only the NSLP having a session with MN should be affected. Should > GIST differentiate this? I guess that will affect all flows whose MRI is touched and that are managed by GIST. If an address change is signalled to GIST internally (e.g., triggered by MobileIP implementation), GIST must iterate through its message routing state tabled look for the changed address. If found, it will issue an API indication for the change, no matter what NSLP is affected. >> An alternative would be a trigger caused by the >> application itself, e.g., due to application level >> signaling. It would be similar to the fact that >> we need such a trigger anyway for receiver-initiated >> reservations in order to let the sender issue an initial >> Query. I guess we need to support both possibilities >> for cross layer info. > > [HCheng] I guess the application layer trigger is a separate issue > instead of an alternative, as not all application supports IP address > changes. This may also relates to some earlier discussion of Appl-NSLP > interface. Sure, not every application will be able or willing to deal with that. >> Concerning your mentioned option of directly sending >> a NOTIFY to the other end: that's also an alternative >> that I discussed with Martin. Our proposed EST-MRM >> would probably enable a node to do so, i.e., a NOTIFY >> indicating a handover event could be sent directly >> to the other end. > > [HCheng] The EST-MRM seems quite useful in this case. Another way is to > simply define a flag such that the message could be routed directly. > > However, I guess the main issue of concern is how to find/locate where > the message should be sent, assuming asymmetric routing. If the message must only hit the other end, actually you don't care about the fact how the message came there. Specifically, you want to avoid setting up GIST state along the "wrong path" that is going to time out anyway... >> (Handover should be managed at NSLP level) > [HCheng] Agree. Although GIST should have adequate information to handle > it, I don't think it cares (or should care about this). I guess that -- following along the end-to-end argument -- the NSLP has more accurate information on what to do or may apply its on logic. It would be hard to get it right at the GIST level for any application... Regards, Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Nov 20 15:15:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuZV9-0001Zs-Td; Tue, 20 Nov 2007 15:15:19 -0500 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1IuZUt-0000yI-B5 for nsis-confirm+ok@megatron.ietf.org; Tue, 20 Nov 2007 15:15:03 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuZUs-0000xv-Oh; Tue, 20 Nov 2007 15:15:02 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuZUs-0000q4-9N; Tue, 20 Nov 2007 15:15:02 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id E6717175AC; Tue, 20 Nov 2007 20:15:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IuZUr-0006Cn-Eu; Tue, 20 Nov 2007 15:15:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 20 Nov 2007 15:15:01 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: nsis@ietf.org Subject: [NSIS] I-D ACTION:draft-ietf-nsis-applicability-mobility-signaling-08.txt X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Next Steps in Signaling Working Group of the IETF. Title : Applicability Statement of NSIS Protocols in Mobile Environments Author(s) : S. Lee, et al. Filename : draft-ietf-nsis-applicability-mobility-signaling-08.txt Pages : 59 Date : 2007-11-20 Mobility of an IP-based node affects routing paths, and as a result, can have a significant effect on the protocol operation and state management. This draft discusses the effects mobility can cause to the NSIS protocol suite, and how the protocols operate in different scenarios, with mobility management protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nsis-applicability-mobility-signaling-08.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-nsis-applicability-mobility-signaling-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-nsis-applicability-mobility-signaling-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-11-20140224.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nsis-applicability-mobility-signaling-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nsis-applicability-mobility-signaling-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-11-20140224.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --NextPart-- From nsis-bounces@ietf.org Tue Nov 20 15:26:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuZfd-0004QT-RA; Tue, 20 Nov 2007 15:26:09 -0500 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1IuZfc-0004Q8-L1 for nsis-confirm+ok@megatron.ietf.org; Tue, 20 Nov 2007 15:26:08 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuZfc-0004Pv-3m for nsis@ietf.org; Tue, 20 Nov 2007 15:26:08 -0500 Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuZfb-0002Sw-I8 for nsis@ietf.org; Tue, 20 Nov 2007 15:26:08 -0500 Received: from sbz-31.cs.helsinki.fi (sbz-31.cs.helsinki.fi [128.214.9.99]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Tue, 20 Nov 2007 22:26:06 +0200 id 00070405.474342DE.00006F5B Date: Tue, 20 Nov 2007 22:26:06 +0200 (EET) From: Jukka MJ Manner To: Roland Bless Subject: Re: [NSIS] Re: [NSIS Mobility draft] Updating from -07 to -08 In-Reply-To: <4742EB97.7090401@tm.uka.de> Message-ID: References: <20071105200346.2BAF.SANDA.TAKAKO@jp.panasonic.com> <47343862.5040206@tm.uka.de> <473C4D46.7020002@tm.uka.de> <473D05AF.9050507@sg.panasonic.com> <473D7726.1070504@tm.uka.de> <474128A4.2060905@sg.panasonic.com> <4742EB97.7090401@tm.uka.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: "nsis@ietf.org" , Hong Cheng , Takako Sanda X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Just as a quick note, I need more time (and a lot of paper, and good pens) to figure out all your discussions, and the implications. I'll get back to you on that later. Jukka On Tue, 20 Nov 2007, Roland Bless wrote: > Hi Hong, > > Hong Cheng wrote: > > Thanks for the more comprehensive analysis. I agree with your points. > > However, I think the described procedure somehow assumes that the CN is > > a QNE. In case the CN is not the QNI/QNR, there might need to have > > further improvement (as mentioned in my early mail). I think this should > > also be mentioned in the draft, as NSIS allows this case. > > Yes, that was what you described, I guess that you are referring to the > Proxy Mode of QoS NSLP. > > > [HCheng] Does this mean this specific API should support a wildcarded > > NSLP ID? On a MN, the change of MRI should affect all the NSLP. On the > > CN, only the NSLP having a session with MN should be affected. Should > > GIST differentiate this? > > I guess that will affect all flows whose MRI is touched and > that are managed by GIST. If an address change is signalled to > GIST internally (e.g., triggered by MobileIP implementation), > GIST must iterate through its message routing state tabled look > for the changed address. If found, it will issue an API indication > for the change, no matter what NSLP is affected. > > >> An alternative would be a trigger caused by the > >> application itself, e.g., due to application level > >> signaling. It would be similar to the fact that > >> we need such a trigger anyway for receiver-initiated > >> reservations in order to let the sender issue an initial > >> Query. I guess we need to support both possibilities > >> for cross layer info. > > > > [HCheng] I guess the application layer trigger is a separate issue > > instead of an alternative, as not all application supports IP address > > changes. This may also relates to some earlier discussion of Appl-NSLP > > interface. > > Sure, not every application will be able or willing > to deal with that. > > >> Concerning your mentioned option of directly sending > >> a NOTIFY to the other end: that's also an alternative > >> that I discussed with Martin. Our proposed EST-MRM > >> would probably enable a node to do so, i.e., a NOTIFY > >> indicating a handover event could be sent directly > >> to the other end. > > > > [HCheng] The EST-MRM seems quite useful in this case. Another way is to > > simply define a flag such that the message could be routed directly. > > > > However, I guess the main issue of concern is how to find/locate where > > the message should be sent, assuming asymmetric routing. > > If the message must only hit the other end, actually > you don't care about the fact how the message came there. > Specifically, you want to avoid setting up GIST state along > the "wrong path" that is going to time out anyway... > > >> (Handover should be managed at NSLP level) > > [HCheng] Agree. Although GIST should have adequate information to handle > > it, I don't think it cares (or should care about this). > > I guess that -- following along the end-to-end argument -- the > NSLP has more accurate information on what to do or may apply > its on logic. It would be hard to get it right at the GIST level > for any application... > > Regards, > Roland > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Nov 20 15:41:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuZtx-0001hz-SA; Tue, 20 Nov 2007 15:40:57 -0500 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1IuZtw-0001fI-GQ for nsis-confirm+ok@megatron.ietf.org; Tue, 20 Nov 2007 15:40:56 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuZb2-0001Mt-6N for nsis@ietf.org; Tue, 20 Nov 2007 15:21:24 -0500 Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuZb1-00024U-3W for nsis@ietf.org; Tue, 20 Nov 2007 15:21:23 -0500 Received: from sbz-31.cs.helsinki.fi (sbz-31.cs.helsinki.fi [128.214.9.99]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Tue, 20 Nov 2007 22:21:21 +0200 id 00070405.474341C1.000009A1 Date: Tue, 20 Nov 2007 22:21:21 +0200 (EET) From: Jukka MJ Manner To: NSIS Working Group Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Subject: [NSIS] NSIS User's guide X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi all, Roland and I started to write a "NSIS user's guide", a document describing in short what NSIS is, how would you make use of it, and how can you extended it. Unfortunately, I missed the 00-draft deadline by a few minutes last week. :( The draft will be submitted once the I-D admin accepts new documents again in early December. The draft can be found below. We would naturally like to see some discussion about whether people feel such a document would be useful (marketing) material for our work, and if so, is our draft a good or bad start. http://www.cs.helsinki.fi/u/jmanner/draft-manner-nsis-user-guide-00.txt BR, Jukka _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Nov 21 05:08:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IumV8-0004AP-LN; Wed, 21 Nov 2007 05:08:10 -0500 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1IumV7-0004A6-Br for nsis-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 05:08:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IumV1-00048V-Ob for nsis@ietf.org; Wed, 21 Nov 2007 05:08:03 -0500 Received: from moutng.kundenserver.de ([212.227.126.183]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IumUx-0007GV-Kq for nsis@ietf.org; Wed, 21 Nov 2007 05:08:03 -0500 Received: from amd64.laiers.local (dslb-088-066-051-232.pools.arcor-ip.net [88.66.51.232]) by mrelayeu.kundenserver.de (node=mrelayeu1) with ESMTP (Nemesis) id 0MKwpI-1IumUv17uA-0008MN; Wed, 21 Nov 2007 11:07:58 +0100 From: Max Laier Organization: =?utf-8?q?Universit=C3=A4t_Karlsruhe?= (TH) To: nsis@ietf.org Subject: Re: [NSIS] NSIS User's guide Date: Wed, 21 Nov 2007 11:07:44 +0100 User-Agent: KMail/1.9.7 References: In-Reply-To: MIME-Version: 1.0 Message-Id: <200711211107.52072.max.laier@tm.uka.de> X-Provags-ID: V01U2FsdGVkX1+ig6ZaeOYZiYpIrrxsIKbVusO9AAA2Xc/Tjer 3ZmDnKIw6i2jstkpPm+fJhUwKUjNk3M/c4TkfuP+i+eIXG3FeX ieuj9xc0AFYLMp3wnoj4CYIuFWwO/uveq/O5bHbTkQ= X-Spam-Score: -0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: Jukka MJ Manner X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1693620210==" Errors-To: nsis-bounces@ietf.org --===============1693620210== Content-Type: multipart/signed; boundary="nextPart4539695.Q2oR0HtPl3"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit --nextPart4539695.Q2oR0HtPl3 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Tuesday 20 November 2007, Jukka MJ Manner wrote: > The draft will be submitted once the I-D admin accepts new documents > again in early December. The draft can be found below. We would > naturally like to see some discussion about whether people feel such a > document would be useful (marketing) material for our work, and if so, > is our draft a good or bad start. > > http://www.cs.helsinki.fi/u/jmanner/draft-manner-nsis-user-guide-00.txt A good read and useful first introduction. Some things that caught my=20 eye: Section 8.4. "New NSLP protocols" could benefit from a reference to=20 I-D.ietf-nsis-ntlp Appendix B. "API between GIST and Signalling=20 Applications". Maybe Fig. 1 as follows: +-----+ +--------+ +-------+ | | | | | | | QoS | | NAT/FW | | ... | NSLP | | | | | | +-----+ +--------+ +-------+ ---------------------------------------------------------------------- +--------------------------+ | | | GIST | NTLP | | +--------------------------+ ---------------------------------------------------------------------- +--------------------------+ | TLS | +--------------------------+ +--------------------------+ | TCP | UDP | SCTP | DCCP | +--------------------------+ +--------------------------+ | IPsec | +--------------------------+ +--------------------------+ | IPv4(+RAO) | IPv6(+RAO) | +--------------------------+ The document doesn't mention IPv6 at all. Eventhough it should be=20 considered common place by now, I still think it's worth mentioning. And three nits: birds of a feather session on Wednesday 21st March *2001* at the 50th ... only a router that runs GIST and the corresponding NSLP will take the packet out of the fast path, and *start* processing it within GIST. ... If fragmentation is required it automatically establishes an MA and sends the signaling traffic over *a reliable protocol*. =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart4539695.Q2oR0HtPl3 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQBHRAN4XyyEoT62BG0RAkDuAJ47cigmyurJAqEUQ/xwEsLupo2sFgCcCwHf 2kVgk/pM6Y2oaxsNBjZ6cbg= =xrU/ -----END PGP SIGNATURE----- --nextPart4539695.Q2oR0HtPl3-- --===============1693620210== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --===============1693620210==-- From nsis-bounces@ietf.org Thu Nov 22 06:22:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvA8t-0000aS-IQ; Thu, 22 Nov 2007 06:22:47 -0500 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1IvA8s-0000aF-Qs for nsis-confirm+ok@megatron.ietf.org; Thu, 22 Nov 2007 06:22:46 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvA8s-0000Zy-CV for nsis@ietf.org; Thu, 22 Nov 2007 06:22:46 -0500 Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IvA8r-0002Al-Pg for nsis@ietf.org; Thu, 22 Nov 2007 06:22:46 -0500 Received: from sbz-31.cs.helsinki.fi (sbz-31.cs.helsinki.fi [128.214.9.99]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Thu, 22 Nov 2007 13:22:44 +0200 id 000805A7.47456684.00003031 Date: Thu, 22 Nov 2007 13:22:44 +0200 (EET) From: Jukka MJ Manner To: Max Laier Subject: Re: [NSIS] NSIS User's guide In-Reply-To: <200711211107.52072.max.laier@tm.uka.de> Message-ID: References: <200711211107.52072.max.laier@tm.uka.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Max, Thank you for the feedback. You are right, the issue of IPv4/IPv6 must be spelled out better in a revision (and the language fixed ;). Jukka On Wed, 21 Nov 2007, Max Laier wrote: > On Tuesday 20 November 2007, Jukka MJ Manner wrote: > > The draft will be submitted once the I-D admin accepts new documents > > again in early December. The draft can be found below. We would > > naturally like to see some discussion about whether people feel such a > > document would be useful (marketing) material for our work, and if so, > > is our draft a good or bad start. > > > > http://www.cs.helsinki.fi/u/jmanner/draft-manner-nsis-user-guide-00.txt > > A good read and useful first introduction. Some things that caught my > eye: > > Section 8.4. "New NSLP protocols" could benefit from a reference to > I-D.ietf-nsis-ntlp Appendix B. "API between GIST and Signalling > Applications". > > Maybe Fig. 1 as follows: > +-----+ +--------+ +-------+ > | | | | | | > | QoS | | NAT/FW | | ... | NSLP > | | | | | | > +-----+ +--------+ +-------+ > ---------------------------------------------------------------------- > +--------------------------+ > | | > | GIST | NTLP > | | > +--------------------------+ > ---------------------------------------------------------------------- > +--------------------------+ > | TLS | > +--------------------------+ > +--------------------------+ > | TCP | UDP | SCTP | DCCP | > +--------------------------+ > +--------------------------+ > | IPsec | > +--------------------------+ > +--------------------------+ > | IPv4(+RAO) | IPv6(+RAO) | > +--------------------------+ > > The document doesn't mention IPv6 at all. Eventhough it should be > considered common place by now, I still think it's worth mentioning. > > And three nits: > > birds of a feather session on Wednesday 21st March *2001* at the 50th > > ... only a router > that runs GIST and the corresponding NSLP will take the packet out of > the fast path, and *start* processing it within GIST. ... > > If fragmentation is > required it automatically establishes an MA and sends the > signaling traffic over *a reliable protocol*. > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Nov 22 11:45:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvFAo-00065X-A8; Thu, 22 Nov 2007 11:45:06 -0500 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1IvFAm-0005wP-Km for nsis-confirm+ok@megatron.ietf.org; Thu, 22 Nov 2007 11:45:04 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvFAm-0005tl-5H for nsis@ietf.org; Thu, 22 Nov 2007 11:45:04 -0500 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IvFAk-0004tU-11 for nsis@ietf.org; Thu, 22 Nov 2007 11:45:04 -0500 Received: (qmail invoked by alias); 22 Nov 2007 16:44:58 -0000 Received: from p54987B3E.dip.t-dialin.net (EHLO [192.168.1.5]) [84.152.123.62] by mail.gmx.net (mp007) with SMTP; 22 Nov 2007 17:44:58 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/sgIsq8WDsKNuyvM6biT89sWUXSMlLW7c1daVLNa +5A9CrVywtJ6sE Message-ID: <4745B206.4060805@gmx.net> Date: Thu, 22 Nov 2007 17:44:54 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Georgios Karagiannis Subject: Re: [NSIS] RMD Comments References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 6217cd54077d488d29096a65a152105e Cc: "nsis@ietf.org" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Georgios, Georgios Karagiannis wrote: > Hi Hannes > > Thank you very much! > Please see some answers in line! > > Best regards, > Georgios > > On 11/1/2007, "Hannes Tschofenig" wrote: > > >> Hi Georgios, >> Hi all, >> >> I am working my way through the RMD QOSM specification. I have a few comments: >> >> Major comment: >> -------------- >> >> * From the IANA registry I understand that the PHR Container is a >> QSPEC parameter. Correct? >> >> If it is then there is a problem since the "Container ID" is supposed >> to be a single value registered for the name of the object. You cannot >> assign different IDs to it, such as PHR_Resource_Request, >> PHR_Release_Request, PHR_Refresh_Update >> > > Georgios: Not really! > The Container ID is similar to Parameter ID. You can have as many as > many values as the containers you want to have! > > Section 4.1.2. of http://www.ietf.org/internet-drafts/draft-ietf-nsis-rmd-12.txt defines the PHR Container. Here is the relevant text: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |M|E|N|r| Container ID |r|r|r|r| 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |S|M| Admitted Hops|B|U| Time Lag | Overload % |K| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max Adm Hops | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: PHR container Parameter/Container ID: 8 bit field, indicating the PHR type: PHR_Resource_Request, PHR_Release_Request, PHR_Refresh_Update. While it appears that it is a single QSPEC parameter it really isn't. It is, in fact, a request to IANA to allocate 3 QSPEC parameters, as shown above. I don't know whether anyone in the group considers this to be a problem. So far, nobody raised some concerns. >> To resolve the problem I would put the "Container ID" into a separate >> field. Not a big change. >> > > Georgios: I am not sure that this is a problem, since, similar to > Parameter ID, you can use more values for the Container ID. > > >> ------------------- >> >> * The IANA consideration section is a mess. >> >> 6. IANA Considerations >> >> RMD-QOSM requires a new IANA registry for the RMD QoS Model >> Identifier. It is a 8-bit value, carried in the > Type> field of >> the QSpec object [QSP-T]. >> >> [hannes] I think you want to say that >> >> " >> A new QOSM ID ("RMD QOSM") needs to be assigned by IANA. The value has >> to be placed into the QSPEC Type registry that was created with >> [ref-to-QSPEC]. >> " >> > > Georgios: Agree! thank you very much! > > >> RMD-QOSM defines 2 new objects for the QSpec Template: PHR container >> and PDR container, see 4.1.2 and 4.1.3. For these new containers, new >> IDs in the QSpec Template Object Type registry should be assigned. >> >> >> [hannes] You should write: >> >> " >> The following new parameters are registered in the Parameter >> ID registry that was created with [ref-to-QSPEC]: >> >> Value Parameter ID >> --------------------------------+------------------------ >> To-be-assigned-by-IANA | PHR Container >> To-be-assigned-by-IANA | Bandwidth >> To-be-assigned-by-IANA | PDR Container >> >> --------------------------- >> > > Georgios: Agree! thank you very much! > > >> >> Minor comments: >> --------------- >> >> * Figure 4 and Figure 5 >> >> I don't know what format is described with this figure. Is >> Figure 4 a snippet of Parameter defined in the QSPEC? >> > > Georgios: Yes! We can mention this in the text! > > >> -------------------- >> * Delete the following sentence: >> >> Note that the Parameter ID is equal to >> Bandwidth_ID. After IANA assigns the proper ID value to the >> parameter then the Bandwdith_ID term has >> to be replaced accordingly. >> >> Just replace the "Parameter ID" in the figure with "Bandwidth ID". >> > > Georgios: Okay > > >> ---------------------- >> >> * The figure with parameter format has no figure #. >> >> * : 1 bit. When set to "1" it indicates that the >> resources/bandwidth >> carried by a tearing RESERVE MUST not be released. >> >> --> MUST NOT be ... >> > > Georgios: Okay! > > >> ---------------- >> >> More comments >> >> --------------------------------------------------------- >> >> * I am curious what the per flow intra-domain QoS-NSLP states actually >> mean. I thought that RMD is particularly targeting non-per flow >> intra-domain states. >> > > Georgios: It is related to the per flow states that are maintained at the > edges! > The per-flow intra-domain QoS-NSLP means that there are per flow states > at the edges that are used to store information associated with RMD-QOSM. > > That might be good to mention somewhere. For example, in the terminology section. > >> ----------- >> >> * The protocol has a number of options. >> A couple of very fundamental deployment choices are listed at >> beginning of Section 3.2.3. Is there are single mandatory-to-implement >> variant? >> > > Georgios: We have not defined a single mandatory-to-implement variant! > We, however identified which deployment choices can be combined together > in Section 3.2.3. > > I see. >> ----------------- >> >> >> * I don't understand this sentence: >> >> " The RMD QoS model functionality is notified by reading the >> parameter of the "PDR Container" that the reservation has been >> successful. " >> > > Georgios: We can chnge it as: > "The reservation has been successful if the bit carried by the > "PDR Container" is not set and equal to "0"." > > Sounds good. >> ----------------- >> >> * I am not sure what you mean by "QoS-NSLP" functionality in the >> following sentence: >> >> " >> Furthermore, the INFO_SPEC object SHOULD be read by the QoS-NSLP >> functionality. >> " >> > > Georgios: What about: > "The "INFO_SPEC" is processed as defined in the QoS-NSLP > specification." > > Sounds good. >> * Why do you say that the values of the INFO_SPEC object "SHOULD" be: >> >> " >> In case of successful reservation the INFO_SPEC object >> >> SHOULD have the following values: >> >> * Error Severity Class: Success >> * Error Code value: Reservation successful " >> >> rather than MUST. >> > > Georgios: Okay! > > >> --------------------------- >> >> * "the SCOPING flag MUST not be set, meaning that a default >> scoping of the message is used. >> " >> >> ... flag MUST NOT ... >> > > Georgios; Okay! > > >> ----------------------------------- >> >> >> >> * Section 4.6.1.1.2: >> >> * " Note that the DSCP value MUST be obtained from the >> MRI values obtained from GIST. The value of the DSCP value >> SHOULD >> be obtained via the MRI parameters that the QoS-NSLP receives >> from GIST. >> >> Duplicate sentence. Why not to say "MUST" instead of SHOULD? >> Where else would you get the prarameters from. >> > > Georgios: Okay! > > >> * " * If the bandwidth allocated for the PHB_high_priority >> traffic is fully utilized, and a high priority request arrives, other >> policies can be used, which are beyond the scope of this document." >> >> ... other policies can be used for what? For granting the request ? >> > > Georgios: we have to clarify that the policies are related to > how the allocated bandwidth is allocated, rather than policies that > e.g., grant the request > > OK. >> * Furthermore, the "B" (BREAK) QoS-NSLP flag in the end to end >> RESERVE message MUST not be set and it MUST be unset if it was set, >> see QoS-NSLP-RMF API described in QoS-NSLP. >> >> >> ... MUST NOT ... >> > > Georgios: Okay! > > >> Why do you want to clear the B flag? >> > > Georgios: You are right! The text "and it MUST be unset if it was set" > should be removed. > > >> * " * the value of the field of the PDR container MUST >> be equal to >> the value of the parameter of the PHR container that was >> carried by its associated intra-domain RESERVE(RMD-QSpec) >> message." >> >> Why is this necessary? >> > > Georgios: because the PDR container will be sent to the ingress and > the M value should be the same as the M value contained in the > intra-domain RESERVE message. We will clarify this! > > > Thanks. >> * the value of the Parameter/Container ID field of the >> PDR container MUST be set "PDR_7" (i.e., PDR_Reservation_Report); >> >> Why is this specific value used? >> > > Georgios: This is a temporary value, that should be used until > IANA assigns the values required by RMD-QOSM. In Section 4.1 we > explain this point. > > Got it. >> * * Furthermore, an initial QSpec object MUST be included in the >> RESPONSE message. The parameters included in the QSPEC > Reserved> object are copied from the original values. >> >> About what RESPONSE message are we talking about? In all other cases >> so far you distinguished between the e2e and the intra-domain >> RESPONSE. >> > > Georgios: The bullet is associated with the end-to-end RESPONSE. > We can emphasize this even more! > > Ok. >> -------------------------------------------------- >> >> * Section 4.6.1.4: >> >> If a QNE edge or QNE Interior node is not able to >> reserve the number of requested resources, the >> "PHR_Resource_Request" that is associated with >> the parameter MUST be marked. >> >> How is it marked? >> > > Georgios: You are right! It should say "MUST be marked (i.e., > bit MUST be set) > > >> ------------------------- >> >> * Section 4.6.1.5 >> >> "If a refresh RESERVE message does not arrive at a >> QNE Interior node within the refresh time-out period then the >> resources associated with this message are removed." >> >> How do you remove resources based on a non-received message? >> > > Georgios: It should say "then the resources associated with this message > are not updated. This will mean that the reserved bandwdith associated > with the reduced state is decreased in the next refresh period by the > corresponding bandwidth that was not refreshed, see Section 4.3.3." > We will clarify this, thanks. > > Ok. >> "However, in the situation >> that an end-to-end (tear) RESERVE is retransmitted, see Section 5.2.4 >> in [QoS-NSLP], then this message MUST not initiate an intra-domain >> (tear) RESERVE message. This is because the RMF values related to >> the end-to-end (tear) RESERVE message have been already released >> during the process of the original (initial) end-to-end (tear) RESERVE >> message." >> >> In short you want to say that when resources have been released >> already then you do not release them again. >> >> ... use MUST NOT .... if you want to keep the above listed text. >> > > Georgios: Agree! > > >> * In Section 4.6.1.5 you do a lot of calculation on the T_Lag. >> Unfortunately, you do not expain why you do all the calculation. >> > > Georgios: You are right! We will do that! > > >> -------------------------------------------------- >> >> * 4.6.1.2.3 >> >> " The QSpec that was carried by the end to end RESERVE belonging to >> the same session as this end-to-end RESPONSE is included in this >> message." >> >> When you say "this message" then to what message do you refer? >> > > Georgios: We refer to the end-to-end RESPONSE message. We will include > end-to-end RESPONSE message. > > >> * To which context does this statement refer " >> The "E" flag associated with >> the QSpec object and the "E" flag associated with the >> parameter are set. " >> > > Georgios: The above paragraph refers to the generation of the end-to-end > RESPONSE message. > Note that values are carried by the end-to-end RESERVE and > the values of the are carried by the end-to-end RESPONSE. > We will clarify this. > > >> This paragraph is totally confusing. >> > > Georgios: We will try to clarify it! > > >> -------------------------------------------------------- >> >> >> * 4.6.1.3.1 >> >> * Up to this section I have not understood what the "single-" vs. >> "multiple-" domain stuff is about . >> >> " In a single-domain case the PDR container field >> is not needed in the message. " >> > > Georgios: I see what you mean! We will clarify this! > > >> * "the PDR has to be processed and removed by the RMD-QOSM >> functionality in the QNE Ingress node. The RMD-QOSM >> functionality is notified by the parameter of the PDR >> container >> that the refresh procedure has been successful or unsuccessful." >> >> Does the first ingress node remove the PDR container? >> What does the last sentence mean? >> > > Georgios: Yes, there is only one ingress node. > The second sentence should actually be used as first sentence. > > >> More comments --------------------------------- >> >> * Section 4.6.1.4. >> >> * "If a QNE edge or QNE Interior node is not able to >> reserve the number of requested resources, the >> "PHR_Resource_Request" that is associated with >> the parameter MUST be marked." >> >> How is it marked? >> > > Georgios: Agree, we will fix this! It should say that it is marked > (i.e., bit is set). > > >> ------------------------------------------ >> >> * PDR container and a PHR Container. >> >> Section 4.1.2. and 4.1.3 just say "This is the container." >> but do not really explain why they need to exist. >> >> I think that it would be really important to say something about it. >> > > Georgios: Agree, we will fix this! > > >> ----------------------- >> >> >> * Why do you need the value? For statistical purposes? >> > > Georgios: No, this is used during the partial release procedure! > I thought that we gave examples for the use of each parameter in the > containers! > > I have to re-read that part. >> >> >> More comments: ------------------- >> >> With an aggregate reservation the timeout for a reservation refers to >> the entire aggregate. >> Hence, if there is a timeout then the entire aggregate is removed. >> >> Correct? >> > > Georgios: yes it is correct! > We will include a procedure that solves this issue. > > >> ------------------------ >> >> Is the object mandatory in an intra-domain RESERVE? >> >> Reading Section 4.6.1.1. I didn't get the impression. >> >> Reading Section 4.6.1.3.2 I got the impression it is mandatory: >> >> " Any QNE edge or QNE Interior >> node that receives a "PHR_Refresh_Update" field >> MUST identify the traffic class state (PHB) (using the >> parameter). " >> > > Georgios: Thanks, we will fix this! > > >> ----------------------- >> >> In Section 4.6.1.3.1 you write: >> >> " >> Most of the non-default values of the objects contained in this >> message MUST be used and set by the QNE Ingress in the same >> way as described in Section 4.6.1.1. The following objects are >> used and/or set differently: >> " >> Still, you list the following statement although it is written in the >> same way in Section 4.6.1.1: >> >> * The flag REPLACE MUST be set to FALSE = 0; >> > > Georgios: You are right! We will have to remove the sentence above! > > >> ---------------------------------- >> >> * "When the RMD-RMF of a QNE edge or QNE Interior node processes a >> "PHR_Release_Request" PHR container it MUST identify the >> parameter and estimate the time period that elapsed >> after the previous refresh, see also Section 3 of [CsTa05]. >> >> >> The sentence should say "QNE egress and interior nodes ..." >> The ingress is not included since it sends the PHR_Release_Request. >> > > Georgios: Yes, you are right! > > >> ------------------------- >> >> * There is something wrong with the description of the Partial Release >> Procedure since the description assumes that the PHR container >> contains the parameter. >> >> The PHR container only contains the parameter. >> > > Georgios: You are right! We assumed that this will be carried by the PDR > container. However, there is a mismatch in the text. We will fix this by > including the parameter into the PHR container and > fixing the text where needed. > Thus the PHR container will include, in addition to the > common header, 2 words, instead of one. > > >> Example: >> " >> * the value of the parameter of the PDR container >> included in the received PDR container (with =1 and >> > in the parameter of the "PHR Container". >> " >> >> The following text only works if the RESERVE message contains a PDR >> container, which is currently not mandated. >> " >> > > Georgios: Yes! But it is better to include the > parameter into the PHR container. > > >> Furthermore, the QNE MUST perform the following procedures. >> If the values of the and parameters included in the >> "PHR_Resource_Release" PHR container are ( and =0) then the >> value MUST be compared with the calculated >> value." >> > > Georgios: Yes, you are right! we will modify it! > > >> --------------------------- >> >> * Furthermore, somewhere in Section 4.6.1.5.2 you write: >> >> "Note that the above described procedure applies to the situation that >> the QNE edges maintain a per flow QoS-NSLP reservation state." >> >> It would be good to know which parts exactly relate to the per-flow vs. >> the aggregate reservation state since there is obviously a lot of text >> "above". >> > > Georgios: Agree, we will make it more clear! > > >> I am not sure why you think that the partial release procedure would >> only be applicable to the per-flow reservation state. >> > > Georgios: This is because the aggregated reservation procedure depends on > more than one micro-flows and the way of adding or releasing aggregated > resources is different than the method used for the per-flow reservation > states. > > Have to re-read that part again. Ciao Hannes >> Ciao >> Hannes >> >> >> >> >> _______________________________________________ >> nsis mailing list >> nsis@ietf.org >> https://www1.ietf.org/mailman/listinfo/nsis >> _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Nov 22 11:58:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvFNL-0001M4-Uu; Thu, 22 Nov 2007 11:58:03 -0500 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1IvFNK-0001HL-Fv for nsis-confirm+ok@megatron.ietf.org; Thu, 22 Nov 2007 11:58:02 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvFNJ-0001Gv-Jq for nsis@ietf.org; Thu, 22 Nov 2007 11:58:01 -0500 Received: from rotterdam.ewi.utwente.nl ([130.89.10.5]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IvFNH-0005SK-CU for nsis@ietf.org; Thu, 22 Nov 2007 11:58:01 -0500 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id lAMGvdlk020860; Thu, 22 Nov 2007 17:57:56 +0100 (MET) From: "Georgios Karagiannis" To: "'Hannes Tschofenig'" References: <4745B206.4060805@gmx.net> Subject: RE: [NSIS] RMD Comments Date: Thu, 22 Nov 2007 17:57:33 +0100 Message-ID: <001b01c82d28$ca4413a0$4c0d5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcgtJw1K/O2+n1VwTi2XN1R5VJ4wywAAWobw In-Reply-To: <4745B206.4060805@gmx.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Spam-Score: 0.088 () AWL X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Thu, 22 Nov 2007 17:57:58 +0100 (MET) X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d231d878f8d68d85cf12b60d23450ce Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Hannes Regarding the below comment: > While it appears that it is a single QSPEC parameter it really isn't. > It is, in fact, a request to IANA to allocate 3 QSPEC > parameters, as shown above. Yes you are right, there are 3 containers! Best regards, Georgios > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: donderdag 22 november 2007 17:45 > To: Georgios Karagiannis > Cc: nsis@ietf.org > Subject: Re: [NSIS] RMD Comments > > Hi Georgios, > > Georgios Karagiannis wrote: > > Hi Hannes > > > > Thank you very much! > > Please see some answers in line! > > > > Best regards, > > Georgios > > > > On 11/1/2007, "Hannes Tschofenig" wrote: > > > > > >> Hi Georgios, > >> Hi all, > >> > >> I am working my way through the RMD QOSM specification. I > have a few comments: > >> > >> Major comment: > >> -------------- > >> > >> * From the IANA registry I understand that the PHR Container is a > >> QSPEC parameter. Correct? > >> > >> If it is then there is a problem since the "Container ID" > is supposed > >> to be a single value registered for the name of the object. You > >> cannot assign different IDs to it, such as PHR_Resource_Request, > >> PHR_Release_Request, PHR_Refresh_Update > >> > > > > Georgios: Not really! > > The Container ID is similar to Parameter ID. You can have > as many as > > many values as the containers you want to have! > > > > > > Section 4.1.2. of > http://www.ietf.org/internet-drafts/draft-ietf-nsis-rmd-12.txt > defines the PHR Container. > Here is the relevant text: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |M|E|N|r| Container ID |r|r|r|r| 2 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |S|M| Admitted Hops|B|U| Time Lag | Overload % |K| | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Max Adm Hops | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure 6: PHR container > > Parameter/Container ID: > 8 bit field, indicating the PHR type: PHR_Resource_Request, > PHR_Release_Request, PHR_Refresh_Update. > > > While it appears that it is a single QSPEC parameter it really isn't. > It is, in fact, a request to IANA to allocate 3 QSPEC > parameters, as shown above. > > I don't know whether anyone in the group considers this to be > a problem. > So far, nobody raised some concerns. > > > >> To resolve the problem I would put the "Container ID" into > a separate > >> field. Not a big change. > >> > > > > Georgios: I am not sure that this is a problem, since, similar to > > Parameter ID, you can use more values for the Container ID. > > > > > >> ------------------- > >> > >> * The IANA consideration section is a mess. > >> > >> 6. IANA Considerations > >> > >> RMD-QOSM requires a new IANA registry for the RMD QoS Model > >> Identifier. It is a 8-bit value, carried in the >> Type> field of > >> the QSpec object [QSP-T]. > >> > >> [hannes] I think you want to say that > >> > >> " > >> A new QOSM ID ("RMD QOSM") needs to be assigned by IANA. The value > >> has to be placed into the QSPEC Type registry that was > created with > >> [ref-to-QSPEC]. > >> " > >> > > > > Georgios: Agree! thank you very much! > > > > > >> RMD-QOSM defines 2 new objects for the QSpec Template: PHR > container > >> and PDR container, see 4.1.2 and 4.1.3. For these new > containers, new > >> IDs in the QSpec Template Object Type registry should be assigned. > >> > >> > >> [hannes] You should write: > >> > >> " > >> The following new parameters are registered in the Parameter ID > >> registry that was created with [ref-to-QSPEC]: > >> > >> Value Parameter ID > >> --------------------------------+------------------------ > >> To-be-assigned-by-IANA | PHR Container To-be-assigned-by-IANA | > >> Bandwidth To-be-assigned-by-IANA | PDR Container > >> > >> --------------------------- > >> > > > > Georgios: Agree! thank you very much! > > > > > >> > >> Minor comments: > >> --------------- > >> > >> * Figure 4 and Figure 5 > >> > >> I don't know what format is described with this figure. Is > Figure 4 a > >> snippet of Parameter defined in the QSPEC? > >> > > > > Georgios: Yes! We can mention this in the text! > > > > > >> -------------------- > >> * Delete the following sentence: > >> > >> Note that the Parameter ID is equal to Bandwidth_ID. After IANA > >> assigns the proper ID value to the parameter then the > >> Bandwdith_ID term has to be replaced accordingly. > >> > >> Just replace the "Parameter ID" in the figure with "Bandwidth ID". > >> > > > > Georgios: Okay > > > > > >> ---------------------- > >> > >> * The figure with parameter format has no figure #. > >> > >> * : 1 bit. When set to "1" it indicates that the > >> resources/bandwidth carried by a tearing RESERVE MUST not be > >> released. > >> > >> --> MUST NOT be ... > >> > > > > Georgios: Okay! > > > > > >> ---------------- > >> > >> More comments > >> > >> --------------------------------------------------------- > >> > >> * I am curious what the per flow intra-domain QoS-NSLP states > >> actually mean. I thought that RMD is particularly > targeting non-per > >> flow intra-domain states. > >> > > > > Georgios: It is related to the per flow states that are > maintained at > > the edges! > > The per-flow intra-domain QoS-NSLP means that there are per flow > > states at the edges that are used to store information > associated with RMD-QOSM. > > > > > > That might be good to mention somewhere. For example, in the > terminology section. > > > > >> ----------- > >> > >> * The protocol has a number of options. > >> A couple of very fundamental deployment choices are listed at > >> beginning of Section 3.2.3. Is there are single > >> mandatory-to-implement variant? > >> > > > > Georgios: We have not defined a single > mandatory-to-implement variant! > > We, however identified which deployment choices can be combined > > together in Section 3.2.3. > > > > > I see. > > >> ----------------- > >> > >> > >> * I don't understand this sentence: > >> > >> " The RMD QoS model functionality is notified by reading the > >> parameter of the "PDR Container" that the reservation has been > >> successful. " > >> > > > > Georgios: We can chnge it as: > > "The reservation has been successful if the bit carried by the > > "PDR Container" is not set and equal to "0"." > > > > > Sounds good. > > >> ----------------- > >> > >> * I am not sure what you mean by "QoS-NSLP" functionality in the > >> following sentence: > >> > >> " > >> Furthermore, the INFO_SPEC object SHOULD be read by the QoS-NSLP > >> functionality. > >> " > >> > > > > Georgios: What about: > > "The "INFO_SPEC" is processed as defined in the QoS-NSLP > > specification." > > > > > Sounds good. > > >> * Why do you say that the values of the INFO_SPEC object > "SHOULD" be: > >> > >> " > >> In case of successful reservation the INFO_SPEC object > >> > >> SHOULD have the following values: > >> > >> * Error Severity Class: Success > >> * Error Code value: Reservation successful " > >> > >> rather than MUST. > >> > > > > Georgios: Okay! > > > > > >> --------------------------- > >> > >> * "the SCOPING flag MUST not be set, meaning that a default > >> scoping of the message is used. > >> " > >> > >> ... flag MUST NOT ... > >> > > > > Georgios; Okay! > > > > > >> ----------------------------------- > >> > >> > >> > >> * Section 4.6.1.1.2: > >> > >> * " Note that the DSCP value MUST be obtained from the > >> MRI values obtained from GIST. The value of the DSCP value > >> SHOULD > >> be obtained via the MRI parameters that the QoS-NSLP > receives > >> from GIST. > >> > >> Duplicate sentence. Why not to say "MUST" instead of SHOULD? > >> Where else would you get the prarameters from. > >> > > > > Georgios: Okay! > > > > > >> * " * If the bandwidth allocated for the PHB_high_priority > >> traffic is fully utilized, and a high priority request > arrives, other > >> policies can be used, which are beyond the scope of this document." > >> > >> ... other policies can be used for what? For granting the request ? > >> > > > > Georgios: we have to clarify that the policies are related > to how the > > allocated bandwidth is allocated, rather than policies that e.g., > > grant the request > > > > > OK. > > >> * Furthermore, the "B" (BREAK) QoS-NSLP flag in the end to end > >> RESERVE message MUST not be set and it MUST be unset if > it was set, > >> see QoS-NSLP-RMF API described in QoS-NSLP. > >> > >> > >> ... MUST NOT ... > >> > > > > Georgios: Okay! > > > > > >> Why do you want to clear the B flag? > >> > > > > Georgios: You are right! The text "and it MUST be unset if > it was set" > > should be removed. > > > > > >> * " * the value of the field of the PDR container MUST > >> be equal to > >> the value of the parameter of the PHR container that was > >> carried by its associated intra-domain RESERVE(RMD-QSpec) > >> message." > >> > >> Why is this necessary? > >> > > > > Georgios: because the PDR container will be sent to the ingress and > > the M value should be the same as the M value contained in the > > intra-domain RESERVE message. We will clarify this! > > > > > > > Thanks. > > >> * the value of the Parameter/Container ID field of the > PDR container > >> MUST be set "PDR_7" (i.e., PDR_Reservation_Report); > >> > >> Why is this specific value used? > >> > > > > Georgios: This is a temporary value, that should be used until IANA > > assigns the values required by RMD-QOSM. In Section 4.1 we explain > > this point. > > > > > Got it. > > >> * * Furthermore, an initial QSpec object MUST be included in the > >> RESPONSE message. The parameters included in the QSPEC >> Reserved> object are copied from the original Desired> values. > >> > >> About what RESPONSE message are we talking about? In all > other cases > >> so far you distinguished between the e2e and the intra-domain > >> RESPONSE. > >> > > > > Georgios: The bullet is associated with the end-to-end RESPONSE. > > We can emphasize this even more! > > > > > Ok. > > >> -------------------------------------------------- > >> > >> * Section 4.6.1.4: > >> > >> If a QNE edge or QNE Interior node is not able to reserve > the number > >> of requested resources, the "PHR_Resource_Request" that is > associated > >> with the parameter MUST be marked. > >> > >> How is it marked? > >> > > > > Georgios: You are right! It should say "MUST be marked > (i.e., > > bit MUST be set) > > > > > >> ------------------------- > >> > >> * Section 4.6.1.5 > >> > >> "If a refresh RESERVE message does not arrive at a QNE > Interior node > >> within the refresh time-out period then the resources > associated with > >> this message are removed." > >> > >> How do you remove resources based on a non-received message? > >> > > > > Georgios: It should say "then the resources associated with this > > message are not updated. This will mean that the reserved bandwdith > > associated with the reduced state is decreased in the next refresh > > period by the corresponding bandwidth that was not > refreshed, see Section 4.3.3." > > We will clarify this, thanks. > > > > > Ok. > > >> "However, in the situation > >> that an end-to-end (tear) RESERVE is retransmitted, see > Section 5.2.4 > >> in [QoS-NSLP], then this message MUST not initiate an intra-domain > >> (tear) RESERVE message. This is because the RMF values > related to the > >> end-to-end (tear) RESERVE message have been already > released during > >> the process of the original (initial) end-to-end (tear) RESERVE > >> message." > >> > >> In short you want to say that when resources have been released > >> already then you do not release them again. > >> > >> ... use MUST NOT .... if you want to keep the above listed text. > >> > > > > Georgios: Agree! > > > > > >> * In Section 4.6.1.5 you do a lot of calculation on the T_Lag. > >> Unfortunately, you do not expain why you do all the calculation. > >> > > > > Georgios: You are right! We will do that! > > > > > >> -------------------------------------------------- > >> > >> * 4.6.1.2.3 > >> > >> " The QSpec that was carried by the end to end RESERVE > belonging to > >> the same session as this end-to-end RESPONSE is included in this > >> message." > >> > >> When you say "this message" then to what message do you refer? > >> > > > > Georgios: We refer to the end-to-end RESPONSE message. We > will include > > end-to-end RESPONSE message. > > > > > >> * To which context does this statement refer " > >> The "E" flag associated with > >> the QSpec object and the "E" flag > associated with the > >> parameter are set. " > >> > > > > Georgios: The above paragraph refers to the generation of the > > end-to-end RESPONSE message. > > Note that values are carried by the > end-to-end RESERVE > > and the values of the are carried by the > end-to-end RESPONSE. > > We will clarify this. > > > > > >> This paragraph is totally confusing. > >> > > > > Georgios: We will try to clarify it! > > > > > >> -------------------------------------------------------- > >> > >> > >> * 4.6.1.3.1 > >> > >> * Up to this section I have not understood what the "single-" vs. > >> "multiple-" domain stuff is about . > >> > >> " In a single-domain case the PDR container field > >> is not needed in the message. " > >> > > > > Georgios: I see what you mean! We will clarify this! > > > > > >> * "the PDR has to be processed and removed by the RMD-QOSM > >> functionality in the QNE Ingress node. The RMD-QOSM > >> functionality is notified by the parameter > of the PDR > >> container > >> that the refresh procedure has been successful or > unsuccessful." > >> > >> Does the first ingress node remove the PDR container? > >> What does the last sentence mean? > >> > > > > Georgios: Yes, there is only one ingress node. > > The second sentence should actually be used as first sentence. > > > > > >> More comments --------------------------------- > >> > >> * Section 4.6.1.4. > >> > >> * "If a QNE edge or QNE Interior node is not able to > >> reserve the number of requested resources, the > >> "PHR_Resource_Request" that is associated with > >> the parameter MUST be marked." > >> > >> How is it marked? > >> > > > > Georgios: Agree, we will fix this! It should say that it is > marked > > (i.e., bit is set). > > > > > >> ------------------------------------------ > >> > >> * PDR container and a PHR Container. > >> > >> Section 4.1.2. and 4.1.3 just say "This is the container." > >> but do not really explain why they need to exist. > >> > >> I think that it would be really important to say something > about it. > >> > > > > Georgios: Agree, we will fix this! > > > > > >> ----------------------- > >> > >> > >> * Why do you need the value? For > statistical purposes? > >> > > > > Georgios: No, this is used during the partial release procedure! > > I thought that we gave examples for the use of each > parameter in the > > containers! > > > > > I have to re-read that part. > > >> > >> > >> More comments: ------------------- > >> > >> With an aggregate reservation the timeout for a > reservation refers to > >> the entire aggregate. > >> Hence, if there is a timeout then the entire aggregate is removed. > >> > >> Correct? > >> > > > > Georgios: yes it is correct! > > We will include a procedure that solves this issue. > > > > > >> ------------------------ > >> > >> Is the object mandatory in an intra-domain RESERVE? > >> > >> Reading Section 4.6.1.1. I didn't get the impression. > >> > >> Reading Section 4.6.1.3.2 I got the impression it is mandatory: > >> > >> " Any QNE edge or QNE Interior > >> node that receives a "PHR_Refresh_Update" field > >> MUST identify the traffic class state (PHB) (using the > >> parameter). " > >> > > > > Georgios: Thanks, we will fix this! > > > > > >> ----------------------- > >> > >> In Section 4.6.1.3.1 you write: > >> > >> " > >> Most of the non-default values of the objects contained in this > >> message MUST be used and set by the QNE Ingress in the same > >> way as described in Section 4.6.1.1. The following objects are > >> used and/or set differently: > >> " > >> Still, you list the following statement although it is > written in the > >> same way in Section 4.6.1.1: > >> > >> * The flag REPLACE MUST be set to FALSE = 0; > >> > > > > Georgios: You are right! We will have to remove the sentence above! > > > > > >> ---------------------------------- > >> > >> * "When the RMD-RMF of a QNE edge or QNE Interior node processes a > >> "PHR_Release_Request" PHR container it MUST identify the > > >> parameter and estimate the time period that elapsed after the > >> previous refresh, see also Section 3 of [CsTa05]. > >> > >> > >> The sentence should say "QNE egress and interior nodes ..." > >> The ingress is not included since it sends the PHR_Release_Request. > >> > > > > Georgios: Yes, you are right! > > > > > >> ------------------------- > >> > >> * There is something wrong with the description of the Partial > >> Release Procedure since the description assumes that the PHR > >> container contains the parameter. > >> > >> The PHR container only contains the parameter. > >> > > > > Georgios: You are right! We assumed that this will be > carried by the > > PDR container. However, there is a mismatch in the text. We > will fix > > this by including the parameter into the PHR > > container and fixing the text where needed. > > Thus the PHR container will include, in addition to the > common header, > > 2 words, instead of one. > > > > > >> Example: > >> " > >> * the value of the parameter of the PDR > >> container included in the received PDR container (with =1 and > >> >> included in the parameter of the "PHR > Container". > >> " > >> > >> The following text only works if the RESERVE message > contains a PDR > >> container, which is currently not mandated. > >> " > >> > > > > Georgios: Yes! But it is better to include the > > parameter into the PHR container. > > > > > >> Furthermore, the QNE MUST perform the following procedures. > >> If the values of the and parameters included in the > >> "PHR_Resource_Release" PHR container are ( and =0) > then the > >> value MUST be compared with the calculated > >> value." > >> > > > > Georgios: Yes, you are right! we will modify it! > > > > > >> --------------------------- > >> > >> * Furthermore, somewhere in Section 4.6.1.5.2 you write: > >> > >> "Note that the above described procedure applies to the situation > >> that the QNE edges maintain a per flow QoS-NSLP reservation state." > >> > >> It would be good to know which parts exactly relate to the > per-flow vs. > >> the aggregate reservation state since there is obviously a lot of > >> text "above". > >> > > > > Georgios: Agree, we will make it more clear! > > > > > >> I am not sure why you think that the partial release > procedure would > >> only be applicable to the per-flow reservation state. > >> > > > > Georgios: This is because the aggregated reservation > procedure depends > > on more than one micro-flows and the way of adding or releasing > > aggregated resources is different than the method used for the > > per-flow reservation states. > > > > > Have to re-read that part again. > > > Ciao > Hannes > > >> Ciao > >> Hannes > >> > >> > >> > >> > >> _______________________________________________ > >> nsis mailing list > >> nsis@ietf.org > >> https://www1.ietf.org/mailman/listinfo/nsis > >> > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Nov 22 12:04:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvFTA-000852-GM; Thu, 22 Nov 2007 12:04:04 -0500 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1IvFT9-00084R-FS for nsis-confirm+ok@megatron.ietf.org; Thu, 22 Nov 2007 12:04:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvFT9-00084H-5p; Thu, 22 Nov 2007 12:04:03 -0500 Received: from rotterdam.ewi.utwente.nl ([130.89.10.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IvFT3-0007Nh-7j; Thu, 22 Nov 2007 12:04:03 -0500 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id lAMH3q2P021660; Thu, 22 Nov 2007 18:03:56 +0100 (MET) From: "Georgios Karagiannis" To: , , "'tsvwg'" Date: Thu, 22 Nov 2007 18:03:47 +0100 Message-ID: <002101c82d29$a8779f20$4c0d5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcgtKaUM6aO1LskDT3KzpbkhSeWGXQ== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Spam-Score: 0.238 () AWL,FVGT_s_OBFU_Q0 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Thu, 22 Nov 2007 18:03:56 +0100 (MET) X-Spam-Score: 0.3 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Cc: Subject: [NSIS] CFP - IWQoS 2008 X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org ------------------------------------------------------------ 16th INTERNATIONAL WORKSHOP ON QUALITY OF SERVICE (IWQoS 2008) June 2-4, 2008 University of Twente, Enschede, The Netherlands http://iwqos08.ewi.utwente.nl/ ------------------------------------------------------------ *** Abstract deadline: January 21, 2008 *** *** Paper submission deadline: January 28, 2008 *** CALL FOR PAPERS Since 1994, IWQoS has served as the prime annual workshop on Quality of Service, providing an international forum for the presentation and discussion of cutting edge research in the field. Building on the success of previous workshops, the objective of the workshop is to bring together researchers, developers, and practitioners working in this area to discuss recent and innovative results, and to identify future directions and challenges in developing practical computer/communication systems where predictable, controlled, and robust performance is a central requirement. IWQoS has a long standing tradition of being highly interactive, while maintaining highest standards of competitiveness and excellence. The scope of the workshop covers the main and currently important aspects of QoS research, including related issues such as availability, reliability, security, pricing, resource management, and performance guarantees. The program will include the following highlights: - Key-note by industrial speaker - A session with short position papers - Key-note and invited paper The session with short position papers will be highly interactive and leave much room for the audience to get involved. The short papers will go through the general reviewing process. TECHNICAL PROGRAM As in previous years, the workshop covers a broad spectrum of QoS issues in communications networking. IWQoS 2008 will particularly emphasize the increasing importance of application level QoS and perceived QoS, i.e., the quality of applications as experienced by the end users, which is usually expressed in terms of a 'mean opinion score' (MOS). Relevant topics for the workshop include the following: - End-to-end QoS provisioning in heterogeneous network environments - Application protocols and QoS - QoS in overlay and peer-to-peer networks - QoS adaptation, adaptive applications - Perceived QoS for VoIP and multimedia applications - Mapping network performance to perceived QoS - Service-level agreements (SLAs) and QoS - QoS modelling for gaming applications - Measurement based QoS estimation and verification - QoS in wireless, mobile, ad hoc and sensor networks - QoS in context aware systems (also related to mobility) - End-to-end QoS signalling and support - QoS in home networks, intranets and Metro Ethernets - Operating systems support and end-system design for QoS COMMITTEE General chair: Boudewijn Haverkort, University of Twente TPC co-chairs: Hans van den Berg, TNO Information and Communication Technology Gunnar Karlsson, KTH, Royal Institute of Technology Local chair: Georgios Karagiannis, University of Twente BEST STUDENT PAPER AWARD Award will be given at the conference to the best student paper, whose first author is/was a student at the time of the paper submission. PROCEEDINGS IWQoS invites submission of manuscripts that present original research results and that neither have been published nor are currently under review for another conference or journal. Any previous or simultaneous publication of related material should be explicitly noted in the submission. The proceedings will be published by IEEE ComSoc. We also solicit submissions for the short position papers session. The short papers will be included in the conference proceedings. IMPORTANT DATES - Abstract deadline: January 21, 2008, 11:59pm CET - Paper submission deadline: January 28, 2008, 11:59pm CET - Notification of acceptance: March 18, 2008 - Camera-ready papers due: April 8, 2008 - Early registration deadline and hotel reservation cut-off date: April 15th, 2008 - Workshop dates: June 2-4, 2008 - Workshop reception and welcome party: June 1, 2008 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Nov 23 18:16:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ivhkc-0005VS-IE; Fri, 23 Nov 2007 18:15:58 -0500 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1Ivhkb-0005VI-OM for nsis-confirm+ok@megatron.ietf.org; Fri, 23 Nov 2007 18:15:57 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ivhkb-0005VA-3B for nsis@ietf.org; Fri, 23 Nov 2007 18:15:57 -0500 Received: from smtp0.netlab.nec.de ([195.37.70.40]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ivhka-0005G3-Go for nsis@ietf.org; Fri, 23 Nov 2007 18:15:57 -0500 Received: from localhost (atlas1.office [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 7FA8A28000350 for ; Sat, 24 Nov 2007 00:15:55 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office) Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IxqP1DOk2Vtw for ; Sat, 24 Nov 2007 00:15:55 +0100 (CET) Received: from mx1.office (mx1.office [10.1.1.23]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 6173F28000303 for ; Sat, 24 Nov 2007 00:15:50 +0100 (CET) Received: from [10.7.0.4] ([10.7.0.4]) by mx1.office over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Sat, 24 Nov 2007 00:15:46 +0100 Mime-Version: 1.0 (Apple Message framework v752.3) To: nsis Message-Id: <57BCC14C-53FD-4B9C-8EEE-C2D5D78B0B1F@netlab.nec.de> From: Martin Stiemerling Date: Fri, 23 Nov 2007 13:44:20 +0100 X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 23 Nov 2007 23:15:46.0806 (UTC) FILETIME=[C756F960:01C82E26] X-Spam-Score: 1.9 (+) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Subject: [NSIS] WGLC: draft-ietf-nsis-nslp-natfw-16.txt X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1268705724==" Errors-To: nsis-bounces@ietf.org --===============1268705724== Content-Type: multipart/alternative; boundary=Apple-Mail-9-618811727 --Apple-Mail-9-618811727 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed [writing as WG chair] Dear all, The authors believe that the NATFW NSLP (draft-ietf-nsis-nslp-natfw-16.txt) is ready for WGLC. The WGLC starts today and will run until December 14th. Please review the draft, and comment if you feel that this draft is ready to be sent to the IESG. A simple mail saying that the draft is ready for publication would be great. Of course, if you read the draft and find open issues, then please send a summary of your issue with the current draft. Thanks, John and Martin stiemerling@netlab.nec.de NEC Laboratories Europe - Network Research Division NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 --Apple-Mail-9-618811727 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
[writing as WG chair]

Dear all,

The authors believe that = the NATFW NSLP
(draft-ietf-nsis-nslp-natfw-16.txt) is ready = for WGLC.=A0

The WGLC starts today and = will run until December 14th.=A0

Please = review the draft, and comment if you feel that this draft
is ready to be sent to the IESG.=A0 A simple mail = saying that the
draft is ready for publication = would be great.

Of course, if you read the draft and find open = issues, then please
send a summary of your = issue with the current draft.

Thanks,=A0

=A0=A0John and = Martin

stiemerling@netlab.nec.de
NEC Laboratories Europe - Network Research = Division

NEC Europe = Limited |=A0Registered Office: NEC House, 1 Victoria Road, London W3 6BL = |=A0Registered in England 2832014

=

= --Apple-Mail-9-618811727-- --===============1268705724== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --===============1268705724==-- From nsis-bounces@ietf.org Sat Nov 24 06:50:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvtWJ-0007Lf-Be; Sat, 24 Nov 2007 06:49:59 -0500 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1IvtWI-0007LS-FK for nsis-confirm+ok@megatron.ietf.org; Sat, 24 Nov 2007 06:49:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvtWI-0007LJ-5c; Sat, 24 Nov 2007 06:49:58 -0500 Received: from [202.99.23.227] (helo=people.com.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IvtWC-0007Qm-W7; Sat, 24 Nov 2007 06:49:58 -0500 Received: from people.com.cn([127.0.0.1]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm1547481c78; Sat, 24 Nov 2007 20:02:50 +0800 Received: from megatron.ietf.org([156.154.16.145]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm15e47419d28; Mon, 19 Nov 2007 21:05:24 +0800 Received: from megatron.ietf.org([156.154.16.145]) by people.com.cn(AIMC 2.9.5.8) with SMTP id AISP action; Mon, 19 Nov 2007 21:05:24 +0800 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu65L-0004oT-Jc; Mon, 19 Nov 2007 07:50:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu65C-0004eh-QJ; Mon, 19 Nov 2007 07:50:34 -0500 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iu65A-0006Td-Dl; Mon, 19 Nov 2007 07:50:34 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 6298332897; Mon, 19 Nov 2007 12:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Iu64g-0001oq-A1; Mon, 19 Nov 2007 07:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 19 Nov 2007 07:50:02 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Archive: X-AIMC-AUTH: (null) X-AIMC-MAILFROM: i-d-announce-bounces@ietf.org X-AIMC-AUTH: (null) X-AIMC-MAILFROM: Internet-Drafts@ietf.org X-Auto-Forward: jaglee@people.com.cn jag@kw.com.cn X-Spam-Score: 2.8 (++) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: nsis@ietf.org Subject: [NSIS] I-D Action:draft-ietf-nsis-nslp-natfw-16.txt X-BeenThere: nsis@ietf.org Reply-To: internet-drafts@ietf.org List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Next Steps in Signaling Working Group of the IETF. Title : NAT/Firewall NSIS Signaling Layer Protocol (NSLP) Author(s) : M. Stiemerling, et al. Filename : draft-ietf-nsis-nslp-natfw-16.txt Pages : 88 Date : 2007-11-19 This memo defines the NSIS Signaling Layer Protocol (NSLP) for Network Address Translators (NATs) and firewalls. This NSLP allows hosts to signal on the data path for NATs and firewalls to be configured according to the needs of the application data flows. It enables hosts behind NATs to obtain a public reachable address and hosts behind firewalls to receive data traffic. The overall architecture is given by the framework and requirements defined by the Next Steps in Signaling (NSIS) working group. The network scenarios, the protocol itself, and examples for path-coupled signaling are given in this memo. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nsis-nslp-natfw-16.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-nsis-nslp-natfw-16.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-nsis-nslp-natfw-16.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-11-19074537.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nsis-nslp-natfw-16.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nsis-nslp-natfw-16.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-11-19074537.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --NextPart-- From nsis-bounces@ietf.org Mon Nov 26 05:44:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwbSL-0007Yo-IG; Mon, 26 Nov 2007 05:44:49 -0500 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1IwbSJ-0007XS-N8 for nsis-confirm+ok@megatron.ietf.org; Mon, 26 Nov 2007 05:44:47 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwbSJ-0007XK-Bk for nsis@ietf.org; Mon, 26 Nov 2007 05:44:47 -0500 Received: from smtp0.netlab.nec.de ([195.37.70.40]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IwbSI-00055t-N0 for nsis@ietf.org; Mon, 26 Nov 2007 05:44:47 -0500 Received: from localhost (atlas1.office [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 27C0328000350 for ; Mon, 26 Nov 2007 11:44:46 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office) Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5e0MPlpTaR4Z for ; Mon, 26 Nov 2007 11:44:46 +0100 (CET) Received: from mx1.office (mx1.office [10.1.1.23]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 094F528000303 for ; Mon, 26 Nov 2007 11:44:41 +0100 (CET) Received: from [10.1.1.109] ([10.1.1.109]) by mx1.office over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Nov 2007 11:44:40 +0100 Mime-Version: 1.0 (Apple Message framework v752.3) To: nsis Message-Id: <6E3AA974-A63B-4FEF-8E99-F94DA5AD8F62@netlab.nec.de> From: Martin Stiemerling Date: Mon, 26 Nov 2007 11:44:41 +0100 X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 26 Nov 2007 10:44:40.0935 (UTC) FILETIME=[593A0770:01C83019] X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Subject: [NSIS] Draft Agenda for IETF#70 X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1778026722==" Errors-To: nsis-bounces@ietf.org --===============1778026722== Content-Type: multipart/alternative; boundary=Apple-Mail-12-870832664 --Apple-Mail-12-870832664 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi all, The draft agenda for the NSIS session at the 70th IETF is uploaded: http://www3.ietf.org/proceedings/07dec/agenda/nsis.txt IETF-70, Vancouver, BC, CA **Draft Agenda for NSIS WG** WG Chair(s): John Loughney Martin Stiemerling Important: Send any change request to nsis-chairs@tools.ietf.org * Agenda Bashing (20 minutes) NOTE WELL Document Status and Accomplishments - GIST update Milestones Review * NAT/FW NSLP - Hannes Tschofenig (15 minutes) * Mobility Applicability Statement - Takako Sanda (10 minutes) * GIST over SCTP - Xiaoming Fu (10 minutes) * RMD-QOSM - Martin Stiemerling (5 minutes) Martin stiemerling@netlab.nec.de NEC Laboratories Europe - Network Research Division NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 --Apple-Mail-12-870832664 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Hi all,

The draft = agenda for the NSIS session at the 70th IETF is uploaded:


IETF-70, Vancouver, = BC, CA

**Draft Agenda for NSIS WG**
=

WG Chair(s):
John Loughney <john.loughney@nokia.com>
Martin Stiemerling <stiemerling@netlab.nec.de>= ;

Important: Send any change request = to=A0
nsis-chairs@tools.ietf.org<= /div>


* Agenda Bashing =A0 (20 = minutes)
=A0 NOTE WELL
=A0 Document Status and = Accomplishments
=A0 - GIST update
=A0 Milestones = Review

* NAT/FW NSLP - Hannes Tschofenig (15 = minutes)

* Mobility Applicability Statement - = Takako Sanda (10 minutes)

* GIST over SCTP - = Xiaoming Fu (10 minutes)

* RMD-QOSM - Martin = Stiemerling (5 minutes)

=A0=A0Martin

=
stiemerling@netlab.nec.de
NEC Laboratories Europe - Network Research = Division

NEC Europe = Limited |=A0Registered Office: NEC House, 1 Victoria Road, London W3 6BL = |=A0Registered in England 2832014

=

= --Apple-Mail-12-870832664-- --===============1778026722== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --===============1778026722==-- From nsis-bounces@ietf.org Mon Nov 26 11:09:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwgWr-0003tD-Q0; Mon, 26 Nov 2007 11:09:49 -0500 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1IwgWq-0003su-OT for nsis-confirm+ok@megatron.ietf.org; Mon, 26 Nov 2007 11:09:48 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwgWq-0003sm-BG for nsis@ietf.org; Mon, 26 Nov 2007 11:09:48 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IwgWp-0004N6-F0 for nsis@ietf.org; Mon, 26 Nov 2007 11:09:48 -0500 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 8DE972054F; Mon, 26 Nov 2007 17:09:46 +0100 (CET) X-AuditID: c1b4fb3e-ae69ebb00000459d-ce-474aefca278c Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 71840203AB; Mon, 26 Nov 2007 17:09:46 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Nov 2007 17:09:46 +0100 Received: from [147.214.30.247] ([147.214.30.247]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Nov 2007 17:09:46 +0100 Message-ID: <474AEFC9.8090204@ericsson.com> Date: Mon, 26 Nov 2007 17:09:45 +0100 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: draft-ietf-nsis-ntlp@tools.ietf.org, NSIS X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Nov 2007 16:09:46.0024 (UTC) FILETIME=[C32A6A80:01C83046] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -1.0 (-) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Cc: Subject: [NSIS] AD comments on draft-ietf-nsis-ntlp-14 X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi, I am sorry for the long time this AD review has taken. I really liked to read the document from first to last word before progressing it. I have now done this and thinks the document is in pretty good shape. I would appreciate an updated version as soon as we have resolved the questions. 1. Page 29: " 2. The signalling application does not wish to set up state with the Querying node and become its peer. This includes the case where a node wishes to avoid taking part in the signalling for overload protection reasons. GIST MUST propagate the Query, similar to the case described in Section 4.3.4. No message is sent back to the Querying node. The application MAY provide an updated NSLP payload for the same NSLPID, which will be used in the Query forwarded by GIST. Note that if the node which finally processes the Query returns an Error message, this will be sent directly back to the originating node, bypassing any forwarders. For these diagnostics to be meaningful, any GIST node forwarding a Query MUST NOT modify it except in the NSLP payload and GIST hop count; in particular, it MUST NOT modify any other GIST payloads or their order. An implementation MAY choose to achieve this by retaining the original message, rather than reconstructing it from some parsed internal representation." I can't quite understand "For these diagnostics to be meaningful, any GIST node forwarding a Query MUST NOT modify it except in the NSLP payload and GIST hop count; in particular, it MUST NOT modify any other GIST payloads or their order." Why does a forwarding node may modify the NSLP payload? Can you please explain this? GIST hop is clearly 2. Section 5.3.2.2: " The upper layer protocol MUST be UDP without intervening encapsulation layers. Following the hop-by-hop option header, the IP header MUST NOT include any extension headers other than routing options or destination options, and for the last extension header MUST have a next-header field of UDP." Here I must actually ask if this specification really can require that other IP extensions not are used. This seem to have potential clashes with other basic building blocks. So I would like to understand why the WG thinks it is necessary to make these restrictions. 3. Section 5.3.3, page 59: "A suitable approach is to restrict the token bucket parameters so that the mean output rate is a small fraction, such as 5%, of the node's lowest-speed interface." I think it should be made clear that the token bucket parameter for bit-rate is "no larger than 5%" rather than suggesting that 5% is a general good value. 4. Section 5.7.3.1: "For example, *.example.com in the APD would match certificates for a.example.com, foo.example.com, *.example.com, etc., but would not match example.com. Similarly, a certificate for *.example.com would be valid for APD identities of a.example.com, foo.example.com, *.example.com, etc., but not example.com." Is it intentional to have two sentences saying the same thing, or am I dense here. It looks very much like a repeat. 5. Section 9: NSLP ID I actually wonder about the selection of IESG approval for new NSLP IDs. Isn't that kind of restricting? Sure, it can potentially be easier to register than specification required. However, it does put load on the IESG. It also assumes that the IESG will have enough clue in the future to know what the correct way to handle a registration requests. Can someone provide me with the WGs reasoning behind this policy? 6. Appendix A. I think the text about "reserved" and its meaning needs to be moved from section A.2 to the front text for Appendix A. Otherwise it is wrongly scoped and does not cover A.1 or any A.3... 7. Section A.1: There is no explicit mention of what values should be listed in the version field for this spec. Earlier it says this is Version 1 of GIST, but that could be encoded both a 0 and 1 in this field based on previous protocols from IETF. 8. ID-nits warnings: == Unused Reference: '14' is defined on line 5231, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 2246 (ref. '15') (Obsoleted by RFC 4346) -- Obsolete informational reference (is this intentional?): RFC 2766 (ref. '18') (Obsoleted by RFC 4966) -- Obsolete informational reference (is this intentional?): RFC 2960 (ref. '19') (Obsoleted by RFC 4960) I definitely like to know if the new versions are fine or not. == Outdated reference: A later version (-04) exists of draft-ietf-behave-turn-03 == Outdated reference: A later version (-15) exists of draft-ietf-nsis-nslp-natfw-14 == Outdated reference: A later version (-02) exists of draft-pashalidis-nsis-gist-legacynats-01 == Outdated reference: A later version (-05) exists of draft-pashalidis-nsis-gimps-nattraversal-04 == Outdated reference: A later version (-04) exists of draft-ietf-nsis-ntlp-statemachine-03 == Outdated reference: A later version (-08) exists of draft-ietf-tcpm-tcpsecure-07 Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM/M ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Nov 26 11:35:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwgvG-0005sW-4B; Mon, 26 Nov 2007 11:35:02 -0500 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1IwgvE-0005s9-Oi for nsis-confirm+ok@megatron.ietf.org; Mon, 26 Nov 2007 11:35:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwgvE-0005s1-Ev for nsis@ietf.org; Mon, 26 Nov 2007 11:35:00 -0500 Received: from smtp.nokia.com ([192.100.122.230] helo=mgw-mx03.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iwgv7-0002ie-3K for nsis@ietf.org; Mon, 26 Nov 2007 11:35:00 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id lAQGYfU5022920; Mon, 26 Nov 2007 18:34:46 +0200 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Nov 2007 18:34:37 +0200 Received: from daebe104.NOE.Nokia.com ([10.241.36.13]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Nov 2007 10:34:29 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [NSIS] WGLC: draft-ietf-nsis-nslp-natfw-16.txt Date: Mon, 26 Nov 2007 10:34:25 -0600 Message-ID: <19EBBEC503C3B5469070E0A6674A533AC94234@daebe104.NOE.Nokia.com> In-Reply-To: <57BCC14C-53FD-4B9C-8EEE-C2D5D78B0B1F@netlab.nec.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] WGLC: draft-ietf-nsis-nslp-natfw-16.txt Thread-Index: AcguJwA9TuZcvcC2R5SsuJQCN/P2yQCIyTmw References: <57BCC14C-53FD-4B9C-8EEE-C2D5D78B0B1F@netlab.nec.de> From: To: , X-OriginalArrivalTime: 26 Nov 2007 16:34:29.0725 (UTC) FILETIME=[378538D0:01C8304A] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1792623269==" Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. --===============1792623269== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8304A.3754E63F" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8304A.3754E63F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Just as an FYI, as Martin is the primary author, I will handle the document in WGLC. =20 thanks, John ________________________________ From: ext Martin Stiemerling [mailto:stiemerling@netlab.nec.de]=20 Sent: 23 November, 2007 04:44 To: nsis Subject: [NSIS] WGLC: draft-ietf-nsis-nslp-natfw-16.txt =09 =09 [writing as WG chair] Dear all,=20 The authors believe that the NATFW NSLP (draft-ietf-nsis-nslp-natfw-16.txt) is ready for WGLC.=20 The WGLC starts today and will run until December 14th.=20 Please review the draft, and comment if you feel that this draft is ready to be sent to the IESG. A simple mail saying that the draft is ready for publication would be great. Of course, if you read the draft and find open issues, then please send a summary of your issue with the current draft. Thanks,=20 John and Martin =09 stiemerling@netlab.nec.de NEC Laboratories Europe - Network Research Division NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 ------_=_NextPart_001_01C8304A.3754E63F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Just=20 as an FYI, as Martin is the primary author, I will handle the document = in=20 WGLC.
 
thanks,
John

From: ext Martin Stiemerling=20 [mailto:stiemerling@netlab.nec.de]
Sent: 23 November, 2007=20 04:44
To: nsis
Subject: [NSIS] WGLC:=20 draft-ietf-nsis-nslp-natfw-16.txt

[writing as WG chair]

Dear all,

The authors believe that the NATFW NSLP
(draft-ietf-nsis-nslp-natfw-16.txt) is ready for = WGLC. 

The WGLC starts today and will run until December = 14th. 

Please review the draft, and comment if you = feel that=20 this draft
is ready to be sent to the IESG.  A = simple mail=20 saying that the
draft is ready for publication would be = great.

Of course, if you read the draft and find = open=20 issues, then please
send a summary of your issue with the = current=20 draft.

Thanks, 

  John and Martin

stiemerling@netlab.nec.de
NEC Laboratories Europe - Network Research=20 Division

NEC Europe Limited | Registered = Office: NEC=20 House, 1 Victoria Road, London W3 6BL | Registered in England=20 2832014

------_=_NextPart_001_01C8304A.3754E63F-- --===============1792623269== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --===============1792623269==-- From nsis-bounces@ietf.org Mon Nov 26 11:53:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwhD7-0002Ut-By; Mon, 26 Nov 2007 11:53:29 -0500 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1IwhD6-0002PW-Cn for nsis-confirm+ok@megatron.ietf.org; Mon, 26 Nov 2007 11:53:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwhD5-0002Kj-Tu for nsis@ietf.org; Mon, 26 Nov 2007 11:53:27 -0500 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwhCy-0003MQ-Gm for nsis@ietf.org; Mon, 26 Nov 2007 11:53:27 -0500 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id lAQGq65p014741; Mon, 26 Nov 2007 16:52:06 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 26 Nov 2007 16:52:32 -0000 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AD comments on draft-ietf-nsis-ntlp-14 Thread-Index: AcgwRxG3TGkPsnRWR3Wye3VDZYwzCwAAOsmA References: <474AEFC9.8090204@ericsson.com> From: "Hancock, Robert" To: "Magnus Westerlund" , , "NSIS" X-MailScanner-roke-co-uk: Found to be clean X-MailScanner-roke-co-uk-SpamCheck: X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: -1.0 (-) X-Scan-Signature: 501044f827b673024f6a4cb1d46e67d2 Cc: Subject: [NSIS] RE: AD comments on draft-ietf-nsis-ntlp-14 X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org magnus, thanks for the encouragement. i'll send a separate response for your comments (1) and (2)=20 [which need some work]. for the rest, i have proposed solutions below - discussion welcome. robert h. > -----Original Message----- > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]=20 > Sent: 26 November 2007 16:10 > To: draft-ietf-nsis-ntlp@tools.ietf.org; NSIS > Subject: AD comments on draft-ietf-nsis-ntlp-14 >=20 > Hi, >=20 > I am sorry for the long time this AD review has taken. I=20 > really liked to read the document from first to last word=20 > before progressing it. I have now done this and thinks the=20 > document is in pretty good shape. I would appreciate an=20 > updated version as soon as we have resolved the questions. [snip] >=20 > 3. Section 5.3.3, page 59: >=20 > "A suitable approach > is to restrict the token bucket parameters so that the mean output > rate is a small fraction, such as 5%, of the node's lowest-speed > interface." >=20 > I think it should be made clear that the token bucket=20 > parameter for bit-rate is "no larger than 5%" rather than=20 > suggesting that 5% is a general good value. something like: A suitable approach is to restrict the token bucket parameters so that the mean output rate is a small fraction of the node's lowest-speed interface. It is RECOMMENDED that this rate is no more than 5%. (I don't think this can really be MUST - a silly counterexample would be a terabit router which you can telnet into over GSM. but the RECOMMENDED should make it clear to the implementor that this is a serious piece of advice.) >=20 > 4. Section 5.7.3.1: >=20 > "For > example, *.example.com in the APD would match certificates for > a.example.com, foo.example.com, *.example.com, etc., but would not > match example.com. Similarly, a certificate for=20 > *.example.com would > be valid for APD identities of a.example.com, foo.example.com, > *.example.com, etc., but not example.com." >=20 > Is it intentional to have two sentences saying the same=20 > thing, or am I dense here. It looks very much like a repeat. Not quite: *) The first sentence states that if you populate your authorised peer database with an entry like *.example.com ALLOW then a node presenting a certificate with an identity like a.example.com will be authorised. *) The second sentence states this if you have an entry in your APD like a.example.com ALLOW then a node presenting a certificate presenting the identity *.example.com will be authorised. >=20 > 5. Section 9: NSLP ID >=20 > I actually wonder about the selection of IESG approval for=20 > new NSLP IDs. > Isn't that kind of restricting? Sure, it can potentially be=20 > easier to register than specification required. However, it=20 > does put load on the IESG. It also assumes that the IESG will=20 > have enough clue in the future to know what the correct way=20 > to handle a registration requests. Can someone provide me=20 > with the WGs reasoning behind this policy? Here there may be some history (John channelling your predecessor ADs). I think the rationale is as follows: - IESG review includes standards action as a sort of sub-case - we didn't want a plethora of proprietary protocols - we anticipated that one source of proposals would be SDOs (for which the evaluation needs to take into account the IETF's interaction with that SDO in handling some bigger standardisation question, and so is not simply a matter of expert review) It's obviously easy to modify the assignment rules, and to be honest I have no really strong opinions against a more relaxed set of policies here. >=20 > 6. Appendix A. I think the text about "reserved" and its=20 > meaning needs to be moved from section A.2 to the front text=20 > for Appendix A. Otherwise it is wrongly scoped and does not=20 > cover A.1 or any A.3... OK >=20 > 7. Section A.1: There is no explicit mention of what values=20 > should be listed in the version field for this spec. Earlier=20 > it says this is Version 1 of GIST, but that could be encoded=20 > both a 0 and 1 in this field based on previous protocols from IETF. I would say '1'.=20 >=20 > 8. ID-nits warnings: >=20 > =3D=3D Unused Reference: '14' is defined on line 5231, but no = explicit > reference was found in the text I would propose to add that as an additional reference (alongside the framework). >=20 > -- Obsolete informational reference (is this intentional?):=20 > RFC 2246 (ref. > '15') (Obsoleted by RFC 4346) aaaaaaaaaaaaargh - the TLS specification version game ... The place where this is referred from (section 5.7.3) was worked over in conjuction with the security ADs; note that there is a normative reference to 4346 also. but since we allow falling back to=20 v1.0, we have this reference also.=20 [this particular open sore seems to pop up for any protocol which can be layered on TLS - see the discussion on draft-ietf-atompub-protocol for example. in this particular case, i think the text and references are OK. personally I think it would be more rationale for the reference to 2246 to be normative, but then we would get into a much more complicated set of procedural questions.] >=20 > -- Obsolete informational reference (is this intentional?):=20 > RFC 2766 (ref. > '18') (Obsoleted by RFC 4966) will update >=20 > -- Obsolete informational reference (is this intentional?):=20 > RFC 2960 (ref. > '19') (Obsoleted by RFC 4960) will update >=20 > I definitely like to know if the new versions are fine or not. summary: yes for all of them, but the informational reference to TLS1.0 should remain (IMHO). >=20 >=20 > =3D=3D Outdated reference: A later version (-04) exists of > draft-ietf-behave-turn-03 >=20 > =3D=3D Outdated reference: A later version (-15) exists of > draft-ietf-nsis-nslp-natfw-14 >=20 > =3D=3D Outdated reference: A later version (-02) exists of > draft-pashalidis-nsis-gist-legacynats-01 >=20 > =3D=3D Outdated reference: A later version (-05) exists of > draft-pashalidis-nsis-gimps-nattraversal-04 >=20 > =3D=3D Outdated reference: A later version (-04) exists of > draft-ietf-nsis-ntlp-statemachine-03 >=20 > =3D=3D Outdated reference: A later version (-08) exists of > draft-ietf-tcpm-tcpsecure-07 will fix all of these. nice to see that we have ony fallen one version behind. >=20 > Cheers >=20 > Magnus Westerlund >=20 > IETF Transport Area Director & TSVWG Chair > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM/M > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 8 4048287 > Torshamsgatan 23 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Nov 26 12:15:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwhYA-0004iZ-F6; Mon, 26 Nov 2007 12:15:14 -0500 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1IwhY9-0004hx-Cr for nsis-confirm+ok@megatron.ietf.org; Mon, 26 Nov 2007 12:15:13 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwhY9-0004hD-1F for nsis@ietf.org; Mon, 26 Nov 2007 12:15:13 -0500 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IwhY8-0006sD-EX for nsis@ietf.org; Mon, 26 Nov 2007 12:15:12 -0500 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id lAQHDjmI020203; Mon, 26 Nov 2007 17:13:45 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 26 Nov 2007 17:14:10 -0000 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPv6 options (was: RE: AD comments on draft-ietf-nsis-ntlp-14) Thread-Index: AcgwRxG3TGkPsnRWR3Wye3VDZYwzCwABqNNQ References: <474AEFC9.8090204@ericsson.com> From: "Hancock, Robert" To: "Magnus Westerlund" , , "NSIS" X-MailScanner-roke-co-uk: Found to be clean X-MailScanner-roke-co-uk-SpamCheck: X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: Subject: [NSIS] IPv6 options (was: RE: AD comments on draft-ietf-nsis-ntlp-14) X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org hi magnus, on your point (2):=20 > 2. Section 5.3.2.2: >=20 > " The upper layer protocol MUST be UDP without intervening > encapsulation layers. Following the hop-by-hop option=20 > header, the IP > header MUST NOT include any extension headers other than routing > options or destination options, and for the last extension header > MUST have a next-header field of UDP." >=20 > Here I must actually ask if this specification really can=20 > require that other IP extensions not are used. This seem to=20 > have potential clashes with other basic building blocks. So I=20 > would like to understand why the WG thinks it is necessary to=20 > make these restrictions. This text came in response to review comments, mainly from the security and routing people. The reasoning behind the text is in two parts. Firstly, consider the current set of IPv6 options which aren't actually upper layer protocols. From IANA, they are: 00 =3D Hop-by-Hop Options 41 =3D ipv6 43 =3D Routing 44 =3D Fragment 51 =3D Authentication 60 =3D Destination Options 50 =3D Encapsulating Security Payload xx =3D Upper Layer Header 58 =3D Internet Control Message Protocol (ICMP) 59 - no next header So the text is ruling out ip in ip (which would make no sense=20 for Q-mode), fragmentation (which should not be necessary), esp/ah (which would prevent GIST working at all), and ICMP (which is really an upper layer protocol anyway).=20 In terms of future IPv6 options, we need to wonder what could exist other than hop-by-hop or destination options. I'm not sure what those would be, but quite likely those options would have some non-trivial impact on the way that the network layer processed packets (e.g. how they were forwarded). But the correct operation of GIST (in Q mode) depends rather closely on its correct interaction with the network layer. So, arbitrarily using other options would be a source of danger. >From another point of view, think of the process of defining a new IPv6 option. The spec is basically saying that you can't use that option and GIST Q-mode at the same time, without updating the GIST spec itself - which would be the trigger for some re-analysis to find out if the combination was safe. If (somehow) you are=20 forced to use the new option, then you cannot use GIST; if you=20 have freedom about whether to use the new option (which would=20 surely be the normal case), don't use it with GIST Q-mode. To me, these restrictions seem reasonable - is more rationale=20 required? robert h. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Nov 27 05:06:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwxKi-0003Mw-EI; Tue, 27 Nov 2007 05:06:24 -0500 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1IwxKf-0003Ck-Mg for nsis-confirm+ok@megatron.ietf.org; Tue, 27 Nov 2007 05:06:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwxKe-0003AL-Hk for nsis@ietf.org; Tue, 27 Nov 2007 05:06:21 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwxKZ-0002zb-C2 for nsis@ietf.org; Tue, 27 Nov 2007 05:06:20 -0500 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 4BFEE20B79; Tue, 27 Nov 2007 11:05:45 +0100 (CET) X-AuditID: c1b4fb3c-b1f9bbb0000030cf-00-474bebf9faef Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 2BB2B20A84; Tue, 27 Nov 2007 11:05:45 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Nov 2007 11:05:44 +0100 Received: from [147.214.30.247] ([147.214.30.247]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Nov 2007 11:05:44 +0100 Message-ID: <474BEBF8.2010607@ericsson.com> Date: Tue, 27 Nov 2007 11:05:44 +0100 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "Hancock, Robert" References: <474AEFC9.8090204@ericsson.com> In-Reply-To: X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Nov 2007 10:05:44.0732 (UTC) FILETIME=[13277DC0:01C830DD] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -1.0 (-) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: draft-ietf-nsis-ntlp@tools.ietf.org, NSIS Subject: [NSIS] Re: IPv6 options X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Thanks Robert, This makes sense. Cheers Magnus Hancock, Robert skrev: > hi magnus, > > on your point (2): > >> 2. Section 5.3.2.2: >> >> " The upper layer protocol MUST be UDP without intervening >> encapsulation layers. Following the hop-by-hop option >> header, the IP >> header MUST NOT include any extension headers other than routing >> options or destination options, and for the last extension header >> MUST have a next-header field of UDP." >> >> Here I must actually ask if this specification really can >> require that other IP extensions not are used. This seem to >> have potential clashes with other basic building blocks. So I >> would like to understand why the WG thinks it is necessary to >> make these restrictions. > > This text came in response to review comments, mainly from > the security and routing people. The reasoning behind the text is > in two parts. > > Firstly, consider the current set of IPv6 options which aren't > actually upper layer protocols. From IANA, they are: > > 00 = Hop-by-Hop Options > 41 = ipv6 > 43 = Routing > 44 = Fragment > 51 = Authentication > 60 = Destination Options > 50 = Encapsulating Security Payload > xx = Upper Layer Header > 58 = Internet Control Message Protocol (ICMP) > 59 - no next header > > So the text is ruling out ip in ip (which would make no sense > for Q-mode), fragmentation (which should not be necessary), > esp/ah (which would prevent GIST working at all), and ICMP > (which is really an upper layer protocol anyway). > > In terms of future IPv6 options, we need to wonder what could > exist other than hop-by-hop or destination options. I'm not > sure what those would be, but quite likely those options would > have some non-trivial impact on the way that the network layer > processed packets (e.g. how they were forwarded). But the correct > operation of GIST (in Q mode) depends rather closely on its > correct interaction with the network layer. So, arbitrarily using > other options would be a source of danger. > >>From another point of view, think of the process of defining a > new IPv6 option. The spec is basically saying that you can't use > that option and GIST Q-mode at the same time, without updating the > GIST spec itself - which would be the trigger for some re-analysis > to find out if the combination was safe. If (somehow) you are > forced to use the new option, then you cannot use GIST; if you > have freedom about whether to use the new option (which would > surely be the normal case), don't use it with GIST Q-mode. > > To me, these restrictions seem reasonable - is more rationale > required? > > robert h. > -- Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM/M ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Nov 28 05:56:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxKaq-0000vQ-8z; Wed, 28 Nov 2007 05:56:36 -0500 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1IxKao-0000qN-HY for nsis-confirm+ok@megatron.ietf.org; Wed, 28 Nov 2007 05:56:34 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxKan-0000q6-FX for nsis@ietf.org; Wed, 28 Nov 2007 05:56:33 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IxKak-0002ct-2R for nsis@ietf.org; Wed, 28 Nov 2007 05:56:31 -0500 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 0BE2B20B1A; Wed, 28 Nov 2007 11:56:27 +0100 (CET) X-AuditID: c1b4fb3c-af796bb0000030cf-d8-474d495a129a Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id E3344203E5; Wed, 28 Nov 2007 11:56:26 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Nov 2007 11:56:26 +0100 Received: from [147.214.30.247] ([147.214.30.247]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Nov 2007 11:56:26 +0100 Message-ID: <474D495A.2050705@ericsson.com> Date: Wed, 28 Nov 2007 11:56:26 +0100 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "Hancock, Robert" References: <474AEFC9.8090204@ericsson.com> In-Reply-To: X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Nov 2007 10:56:26.0443 (UTC) FILETIME=[529181B0:01C831AD] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: a069a8e8835d39ce36e425c148267a7b Cc: draft-ietf-nsis-ntlp@tools.ietf.org, NSIS Subject: [NSIS] Re: AD comments on draft-ietf-nsis-ntlp-14 X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org See inline Hancock, Robert skrev: > magnus, > > thanks for the encouragement. > > i'll send a separate response for your comments (1) and (2) > [which need some work]. > > for the rest, i have proposed solutions below - discussion welcome. > > robert h. > >> -----Original Message----- >> From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] >> Sent: 26 November 2007 16:10 >> To: draft-ietf-nsis-ntlp@tools.ietf.org; NSIS >> Subject: AD comments on draft-ietf-nsis-ntlp-14 >> >> Hi, >> >> I am sorry for the long time this AD review has taken. I >> really liked to read the document from first to last word >> before progressing it. I have now done this and thinks the >> document is in pretty good shape. I would appreciate an >> updated version as soon as we have resolved the questions. > > [snip] > >> 3. Section 5.3.3, page 59: >> >> "A suitable approach >> is to restrict the token bucket parameters so that the mean output >> rate is a small fraction, such as 5%, of the node's lowest-speed >> interface." >> >> I think it should be made clear that the token bucket >> parameter for bit-rate is "no larger than 5%" rather than >> suggesting that 5% is a general good value. > > something like: > A suitable approach is to restrict the token bucket parameters so that > the mean output rate is a small fraction of the node's lowest-speed > interface. It is RECOMMENDED that this rate is no more than 5%. > > (I don't think this can really be MUST - a silly counterexample would be > a terabit router which you can telnet into over GSM. but the RECOMMENDED > should make it clear to the implementor that this is a serious piece of > advice.) Yes, that seems reasonable. > >> 4. Section 5.7.3.1: >> >> "For >> example, *.example.com in the APD would match certificates for >> a.example.com, foo.example.com, *.example.com, etc., but would not >> match example.com. Similarly, a certificate for >> *.example.com would >> be valid for APD identities of a.example.com, foo.example.com, >> *.example.com, etc., but not example.com." >> >> Is it intentional to have two sentences saying the same >> thing, or am I dense here. It looks very much like a repeat. > > Not quite: > *) The first sentence states that if you populate your authorised > peer database with an entry like > *.example.com ALLOW > then a node presenting a certificate with an identity like a.example.com > will be authorised. > *) The second sentence states this if you have an entry in your APD like > a.example.com ALLOW > then a node presenting a certificate presenting the identity > *.example.com will be authorised. > Okay >> 5. Section 9: NSLP ID >> >> I actually wonder about the selection of IESG approval for >> new NSLP IDs. >> Isn't that kind of restricting? Sure, it can potentially be >> easier to register than specification required. However, it >> does put load on the IESG. It also assumes that the IESG will >> have enough clue in the future to know what the correct way >> to handle a registration requests. Can someone provide me >> with the WGs reasoning behind this policy? > > Here there may be some history (John channelling your predecessor > ADs). I think the rationale is as follows: > - IESG review includes standards action as a sort of sub-case > - we didn't want a plethora of proprietary protocols > - we anticipated that one source of proposals would be SDOs > (for which the evaluation needs to take into account the IETF's > interaction with that SDO in handling some bigger standardisation > question, and so is not simply a matter of expert review) > > It's obviously easy to modify the assignment rules, and to be honest > I have no really strong opinions against a more relaxed set of > policies here. Okay, as long as the WG knows what it is getting itself into. My main concern was that being restricted will in fact hamper deployment. But it appears that you like to avoid proprietary NSLPS. If that is the WG's conclusion I am fine. > > >> 6. Appendix A. I think the text about "reserved" and its >> meaning needs to be moved from section A.2 to the front text >> for Appendix A. Otherwise it is wrongly scoped and does not >> cover A.1 or any A.3... > > OK > >> 7. Section A.1: There is no explicit mention of what values >> should be listed in the version field for this spec. Earlier >> it says this is Version 1 of GIST, but that could be encoded >> both a 0 and 1 in this field based on previous protocols from IETF. > > I would say '1'. Sure, but can we please get some word in there saying that. > >> 8. ID-nits warnings: >> >> == Unused Reference: '14' is defined on line 5231, but no explicit >> reference was found in the text > > I would propose to add that as an additional reference (alongside the > framework). > >> -- Obsolete informational reference (is this intentional?): >> RFC 2246 (ref. >> '15') (Obsoleted by RFC 4346) > > aaaaaaaaaaaaargh - the TLS specification version game ... > > The place where this is referred from (section 5.7.3) was worked > over in conjuction with the security ADs; note that there is a > normative reference to 4346 also. but since we allow falling back to > v1.0, we have this reference also. > > [this particular open sore seems to pop up for any protocol which > can be layered on TLS - see the discussion on > draft-ietf-atompub-protocol > for example. in this particular case, i think the text and references > are OK. personally I think it would be more rationale for the > reference to 2246 to be normative, but then we would get into a much > more complicated set of procedural questions.] > Sure, I should have reacted to that being TLS. I know from the discussion that it is fine to refer to earlier version. >> -- Obsolete informational reference (is this intentional?): >> RFC 2766 (ref. >> '18') (Obsoleted by RFC 4966) > > will update > >> -- Obsolete informational reference (is this intentional?): >> RFC 2960 (ref. >> '19') (Obsoleted by RFC 4960) > > will update > >> I definitely like to know if the new versions are fine or not. > > summary: yes for all of them, but the informational reference > to TLS1.0 should remain (IMHO). Sure > >> >> == Outdated reference: A later version (-04) exists of >> draft-ietf-behave-turn-03 >> >> == Outdated reference: A later version (-15) exists of >> draft-ietf-nsis-nslp-natfw-14 >> >> == Outdated reference: A later version (-02) exists of >> draft-pashalidis-nsis-gist-legacynats-01 >> >> == Outdated reference: A later version (-05) exists of >> draft-pashalidis-nsis-gimps-nattraversal-04 >> >> == Outdated reference: A later version (-04) exists of >> draft-ietf-nsis-ntlp-statemachine-03 >> >> == Outdated reference: A later version (-08) exists of >> draft-ietf-tcpm-tcpsecure-07 > > will fix all of these. nice to see that we have ony fallen > one version behind. > No, problem. I know it is basically impossible to keep all draft references upto date. Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Nov 28 17:12:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxV96-0003x4-5M; Wed, 28 Nov 2007 17:12:40 -0500 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1IxV94-0003w4-R5 for nsis-confirm+ok@megatron.ietf.org; Wed, 28 Nov 2007 17:12:38 -0500 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1IxV94-0003vv-Hg for nsis@ietf.org; Wed, 28 Nov 2007 17:12:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxV7w-0008VX-BJ for nsis@ietf.org; Wed, 28 Nov 2007 17:11:28 -0500 Received: from rn-out-0910.google.com ([64.233.170.188] helo=rn-out-0102.google.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxV7w-0006QI-4N for nsis@ietf.org; Wed, 28 Nov 2007 17:11:28 -0500 Received: by rn-out-0102.google.com with SMTP id a46so1250429rne for ; Wed, 28 Nov 2007 14:11:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; bh=S8/zroNIBcaTehQoMCANfdzMt2Q5wemfOMz102SXWtY=; b=iXki36EJNDSVeb6rvPLNDyWnr3DUutf6canljwnaXKzRT012kM/KchvCWwCyJK9qo5xkAB9P4MmSp3yd9vesHFksAvlz0eXt9PvGoYUUkB7Tzxu+iD+ryCqREnHl5RtxuPYZP3cXUudIHTQEwG+wia4SegcCQpFahyR//fJgijw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:message-id:date:from:to:subject:mime-version:content-type; b=IJ4toBWv4e/EwUssm8FHiolUSPTwz6eBgFLB+y88XD/O36LT4Tr8ExVVaxVhRSOTzRL8x9wYTlF40fLvgJJbgvXtEJjK/zHJua8hjV5kfV1anxcgwAP36OOKMhi/W2DzF9Hcb38kbt6bCNBXq0W55wdbyvpsqUF8QhErYql+jMU= Received: by 10.142.108.14 with SMTP id g14mr1731101wfc.1196287887161; Wed, 28 Nov 2007 14:11:27 -0800 (PST) Received: by 10.143.6.4 with HTTP; Wed, 28 Nov 2007 14:11:27 -0800 (PST) Message-ID: <665d0ec00711281411x38db0244g3ead0e953e88a521@mail.gmail.com> Date: Wed, 28 Nov 2007 23:11:27 +0100 From: "Zineb HABACH" To: nsis@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 X-TMDA-Confirmed: Wed, 28 Nov 2007 17:12:38 -0500 Subject: [NSIS] I'm a new member X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0224638193==" Errors-To: nsis-bounces@ietf.org --===============0224638193== Content-Type: multipart/alternative; boundary="----=_Part_5664_26384787.1196287887146" ------=_Part_5664_26384787.1196287887146 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, I'm anew member of this mailing list. I'have a project in the nsis. Please,can you tell me what's the role to write to this mailing? thinks ------=_Part_5664_26384787.1196287887146 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hi,
I'm anew member of this mailing list. I'have a project in the nsis.
Please,can you tell me what's the role to write to this mailing?
thinks
------=_Part_5664_26384787.1196287887146-- --===============0224638193== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --===============0224638193==-- From nsis-bounces@ietf.org Thu Nov 29 01:58:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxdLn-00047p-2h; Thu, 29 Nov 2007 01:58:19 -0500 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1IxdLl-00047g-72 for nsis-confirm+ok@megatron.ietf.org; Thu, 29 Nov 2007 01:58:17 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxdLj-00047H-AV for nsis@ietf.org; Thu, 29 Nov 2007 01:58:15 -0500 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IxdLi-0006Ub-OT for nsis@ietf.org; Thu, 29 Nov 2007 01:58:15 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id lAT6w5Z6006724; Thu, 29 Nov 2007 08:58:09 +0200 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Nov 2007 08:58:05 +0200 Received: from daebe104.NOE.Nokia.com ([10.241.36.13]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Nov 2007 00:58:03 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [NSIS] I'm a new member Date: Thu, 29 Nov 2007 00:57:59 -0600 Message-ID: <19EBBEC503C3B5469070E0A6674A533ACB474C@daebe104.NOE.Nokia.com> In-Reply-To: <665d0ec00711281411x38db0244g3ead0e953e88a521@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] I'm a new member Thread-Index: AcgyC9ly907rrgAnR8eo7jMEwUpf9QASTeSQ References: <665d0ec00711281411x38db0244g3ead0e953e88a521@mail.gmail.com> From: To: , X-OriginalArrivalTime: 29 Nov 2007 06:58:03.0351 (UTC) FILETIME=[2FAC9E70:01C83255] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0305783002==" Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. --===============0305783002== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C83255.2FB28289" This is a multi-part message in MIME format. ------_=_NextPart_001_01C83255.2FB28289 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Welcome to the mailing list. Please read the various working group drafts, send questions, comments and clarifications. =20 Also, if you have specific interests in NSIS, it is always good to let the WG know what your level of interest is in the work we are doing. =20 John ________________________________ From: ext Zineb HABACH [mailto:zineb.habach@gmail.com]=20 Sent: 28 November, 2007 14:11 To: nsis@ietf.org Subject: [NSIS] I'm a new member =09 =09 Hi, I'm anew member of this mailing list. I'have a project in the nsis. Please,can you tell me what's the role to write to this mailing? thinks ------_=_NextPart_001_01C83255.2FB28289 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Welcome to the mailing list. Please read the various working = group=20 drafts, send questions, comments and clarifications.
 
Also,=20 if you have specific interests in NSIS, it is always good to let the WG = know=20 what your level of interest is in the work we are = doing.
 
John

From: ext Zineb HABACH=20 [mailto:zineb.habach@gmail.com]
Sent: 28 November, 2007=20 14:11
To: nsis@ietf.org
Subject: [NSIS] I'm a new=20 member

Hi,
I'm anew member of this mailing list. I'have a project in the = nsis.
Please,can you tell me what's the role to write to this = mailing?
thinks
------_=_NextPart_001_01C83255.2FB28289-- --===============0305783002== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --===============0305783002==-- From nsis-bounces@ietf.org Thu Nov 29 11:38:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxmPX-0000Ri-BL; Thu, 29 Nov 2007 11:38:47 -0500 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1IxmPW-0000RZ-VX for nsis-confirm+ok@megatron.ietf.org; Thu, 29 Nov 2007 11:38:46 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxmPW-0000RM-Kb for nsis@ietf.org; Thu, 29 Nov 2007 11:38:46 -0500 Received: from rsys001x.roke.co.uk ([193.118.201.108]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IxmPV-00032S-VK for nsis@ietf.org; Thu, 29 Nov 2007 11:38:46 -0500 Received: from rsys005a.comm.ad.roke.co.uk ([193.118.193.85]) by rsys001x.roke.co.uk (8.13.1/8.13.1) with ESMTP id lATGcXm5030181; Thu, 29 Nov 2007 16:38:34 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 29 Nov 2007 16:39:03 -0000 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AD comments on draft-ietf-nsis-ntlp-14 Thread-Index: AcgwRxG3TGkPsnRWR3Wye3VDZYwzCwCVo/IQ References: <474AEFC9.8090204@ericsson.com> From: "Hancock, Robert" To: "Magnus Westerlund" , , "NSIS" X-MailScanner-roke-co-uk: Found to be clean X-MailScanner-roke-co-uk-SpamCheck: X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: Subject: [NSIS] RE: AD comments on draft-ietf-nsis-ntlp-14 X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org magnus, finally following up your comment (1):=20 > -----Original Message----- > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]=20 > Sent: 26 November 2007 16:10 > To: draft-ietf-nsis-ntlp@tools.ietf.org; NSIS > Subject: AD comments on draft-ietf-nsis-ntlp-14 >=20 > Hi, >=20 > I am sorry for the long time this AD review has taken. I=20 > really liked to read the document from first to last word=20 > before progressing it. I have now done this and thinks the=20 > document is in pretty good shape. I would appreciate an=20 > updated version as soon as we have resolved the questions. >=20 >=20 > 1. Page 29: > " 2. The signalling application does not wish to set up=20 > state with the > Querying node and become its peer. This includes the=20 > case where > a node wishes to avoid taking part in the signalling=20 > for overload > protection reasons. GIST MUST propagate the Query, similar to > the case described in Section 4.3.4. No message is=20 > sent back to > the Querying node. The application MAY provide an updated NSLP > payload for the same NSLPID, which will be used in the Query > forwarded by GIST. Note that if the node which=20 > finally processes > the Query returns an Error message, this will be sent directly > back to the originating node, bypassing any forwarders. For > these diagnostics to be meaningful, any GIST node forwarding a > Query MUST NOT modify it except in the NSLP payload=20 > and GIST hop > count; in particular, it MUST NOT modify any other=20 > GIST payloads > or their order. An implementation MAY choose to=20 > achieve this by > retaining the original message, rather than reconstructing it > from some parsed internal representation." >=20 > I can't quite understand "For > these diagnostics to be meaningful, any GIST node forwarding a > Query MUST NOT modify it except in the NSLP payload=20 > and GIST hop > count; in particular, it MUST NOT modify any other=20 > GIST payloads > or their order." >=20 > Why does a forwarding node may modify the NSLP payload? Can=20 > you please explain this? GIST hop is clearly The question ends in "mid-air", but I can comment on the NSLP payload aspects. Basically, when a Query message is forwarded along a path, NSLPs are allowed to inspect and modify the payload. The end result is that there is a single GIST peering relationship, but where the=20 NSLP nodes at each end have gathered some additional data about the signalling application state at nodes between the peers. Note that GIST doesn't make any reliability or integrity promises=20 about the transmission of this payload - it's just NSLP data being=20 piggybacked on the handshake, so there are no constraints (imposed=20 by GIST) on what can be done to it. However, GIST itself doesn't=20 allow changes in the GIST payloads at these intermediate points,=20 because then error reporting wouldn't work. The canonical example is RMD operating edge-to-edge across a domain. The ingress sends a GIST query to the egress and these then peer with each other (statefully, creating a messaging association, including storing reverse path state and so on).=20 As the peering is set up (and when routing state is refreshed) the Query also gathers RMD state information from the interior nodes, which however don't store any RMD or GIST per-flow state. robert h. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis