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-24--712519856-- --===============0704640663== 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 --===============0704640663==-- From nsis-bounces@ietf.org Mon Dec 03 01:03:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iz4OV-0005Hc-Be; Mon, 03 Dec 2007 01:03:03 -0500 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1Iz4OT-0005HT-IM for nsis-confirm+ok@megatron.ietf.org; Mon, 03 Dec 2007 01:03:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iz4OT-0005HL-7h for nsis@ietf.org; Mon, 03 Dec 2007 01:03:01 -0500 Received: from rv-out-0910.google.com ([209.85.198.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iz4OS-0005Nm-I1 for nsis@ietf.org; Mon, 03 Dec 2007 01:03:01 -0500 Received: by rv-out-0910.google.com with SMTP id l15so2417027rvb for ; Sun, 02 Dec 2007 22:03:00 -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:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; bh=7cPalDSLsNZEdzCz/sz3zcjR7YcCSQfMuF1RzemJjzs=; b=Xe7dNaUMPhyCJLMnt63c70fgIcRVNtIMSC32E/4pdMJSSfRmhtKaOQpWgrUWhqH1udjIu2SFlQAsf/zwL7txrKfEmnscnWSxxef1IpDMhMmDPbbgXiymWY8tfxohTJjxuz3iBzs8MhLqM2MSWSd7ZOLnPElyz/ejBdaUoG0fTEQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=pWtSUR01SHgwqwm040JK2RZyeDJCAmLuJyqyl5xS5XQ0vzJVSp4UuB4Q12ijs5R01ZyBS9kpXLXqTMywXwmkk6vNavTVxpHPsCjwKD7Wwj6rZ+B16RPS7T4r/TuvwRKSEyvScl8Qh4qz8EA/J9COpKWEDuD+WBOqO95Z8niMJCw= Received: by 10.140.169.6 with SMTP id r6mr3642729rve.1196661780029; Sun, 02 Dec 2007 22:03:00 -0800 (PST) Received: by 10.140.177.2 with HTTP; Sun, 2 Dec 2007 22:03:00 -0800 (PST) Message-ID: Date: Mon, 3 Dec 2007 01:03:00 -0500 From: "Charles Shen" To: "Hannes Tschofenig" Subject: Re: [NSIS] draft-ietf-nsis-tunnel-02.txt Comments In-Reply-To: <46BAF7F1.30702@gmx.net> MIME-Version: 1.0 References: <46BAF7F1.30702@gmx.net> X-Google-Sender-Auth: 625c2031fbe410d2 X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 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: , Content-Type: multipart/mixed; boundary="===============1042004320==" Errors-To: nsis-bounces@ietf.org --===============1042004320== Content-Type: multipart/alternative; boundary="----=_Part_5012_5785847.1196661780047" ------=_Part_5012_5785847.1196661780047 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Hannes, Thanks for the comments and sorry for the tardy response as it has been buried deep in the list messages. Please see responses in line. On Aug 9, 2007 6:18 AM, Hannes Tschofenig wrote: > I have read through draft-ietf-nsis-tunnel-02.txt and here are a few > comments: > > * I don't know why you need the "Tunnel Signaling Capability Discovery" > This is for the Tunnel entry or exit point to learn whether the tunnel traversal mechanism defined in the document is supported, in other words, whether the box complies to this spec. > > * The document should not contain RFC 2119 language since the base > functionality is already in GIST and in the NSLPs. > I should clean those out if they are already in GIST and NSLPs, except probably for things specific to the tunnel traversal mechanism itself. > > * In many sections I got the impression that there is no real conclusion > or suggestion since there cannot be one. The right answer to many of the > issues is "It depends on the deployment and some policy decisions". > Hence, I wasn't quite sure how much value a lot of text will be for the > reader at the end. > > I agree there are many alternatives to many aspects of the problem, some of which I have moved from the main body to the appendix. There may still be more possibilities than one expected to be. But I personally think the problem calls for a solution and that having things listed out is still better than everyone just applying a propritary approach without discussion. Ideally things may be further narrowed down and converge on a smaller set of basic scenarios. I would very much appreciate specific comments on that. thanks. Charles > > Ciao > Hannes > > > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > ------=_Part_5012_5785847.1196661780047 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

Hi Hannes,

Thanks for the comments and sorry for the tardy response as it has been buried deep in the list messages. Please see responses in line.

On Aug 9, 2007 6:18 AM, Hannes Tschofenig <Hannes.Tschofenig@gmx.net> wrote:

I have read through draft-ietf-nsis-tunnel-02.txt and here are a few
comments:

* I don't know why you need the "Tunnel Signaling Capability Discovery"

This is for the Tunnel entry or exit point to learn whether the tunnel traversal mechanism defined in the document is supported, in other words, whether the box complies to this spec.

* The document should not contain RFC 2119 language since the base
functionality is already in GIST and in the NSLPs.

I should clean those out if they are already in GIST and NSLPs, except probably for things specific to the tunnel traversal mechanism itself.

* In many sections I got the impression that there is no real conclusion
or suggestion since there cannot be one. The right answer to many of the
issues is "It depends on the deployment and some policy decisions".
Hence, I wasn't quite sure how much value a lot of text will be for the
reader at the end.

I agree there are many alternatives to many aspects of the problem, some of which I have moved from the main body to the appendix. There may still be more possibilities than one expected to be. But I personally think the problem calls for a solution and that having things listed out is still better than everyone just applying a propritary approach without discussion. Ideally things may be further narrowed down and converge on a smaller set of basic scenarios. I would very much appreciate specific comments on that.

thanks.

Charles

Ciao
Hannes

_______________________________________________
nsis mailing list
nsis@ietf.org
https://www1.ietf.org/mailman/listinfo/nsis

------=_Part_5012_5785847.1196661780047-- --===============1042004320== 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 --===============1042004320==-- From nsis-bounces@ietf.org Mon Dec 03 08:44:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzBbN-0001C9-TF; Mon, 03 Dec 2007 08:44:49 -0500 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1Iz97y-0006Nj-82 for nsis-confirm+ok@megatron.ietf.org; Mon, 03 Dec 2007 06:06:18 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iz97x-0006NP-ID; Mon, 03 Dec 2007 06:06:17 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iz97w-00073I-GC; Mon, 03 Dec 2007 06:06:17 -0500 X-IronPort-AV: E=Sophos;i="4.23,243,1194217200"; d="scan'208";a="159377828" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 03 Dec 2007 12:06:12 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lB3B6CFF019369; Mon, 3 Dec 2007 12:06:12 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lB3B5t3h026772; Mon, 3 Dec 2007 11:06:04 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Dec 2007 12:05:53 +0100 Received: from [10.13.7.53] ([10.61.66.23]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Dec 2007 12:05:52 +0100 In-Reply-To: <19EBBEC503C3B5469070E0A6674A533ACF9DD9@daebe104.NOE.Nokia.com> References: <4710EDB4.7080306@gmx.net> <7AE49DF0-833D-4CA1-9C5D-A3AD5A40A2C8@g11.org.uk> <471382F3.10101@gmx.net> <820D7225-8B7D-4B89-8858-9F4687F70360@g11.org.uk> <4713D654.4080703@gmx.net> <4714C026.9050008@gmx.net> <963D6672-0903-4F7B-B56C-963B4BFA3452@cisco.com> <474ABE9D.5030800@ericsson.com> <8E54EB46-B6CE-4051-A10D-FD119F6374FF@g11.org.uk> <19EBBEC503C3B5469070E0A6674A533AC94240@daebe104.NOE.Nokia.com> <474B1CEE.20207@gmx.net> <19EBBEC503C3B5469070E0A6674A533AC944F1@daebe104.NOE.Nokia.com> <9F78CF9E-33AF-4E29-A3AE-CCC2112AA726@cisco.com> <371A5217-CECC-4F3C-BB04-2E73F42E1DCC@cisco.com> <219D02B1-D9F9-4953-97CC-C0464261684B@cisco.com> <19EBBEC503C3B5469070E0A6674A533ACF9DD9@daebe104.NOE.Nokia.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <13195AD2-7CF0-4A74-80D1-9394F51A9D50@cisco.com> Content-Transfer-Encoding: 7bit From: Francois Le Faucheur IMAP Date: Mon, 3 Dec 2007 03:05:42 -0800 To: dime@ietf.org, nsis@ietf.org, tsvwg tsvwg X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 03 Dec 2007 11:05:52.0425 (UTC) FILETIME=[77FC4190:01C8359C] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=7435; t=1196679972; x=1197543972; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=flefauch@cisco.com; z=From:=20Francois=20Le=20Faucheur=20IMAP=20 |Subject:=20Resolution=20of=20issue=20QoS=20Parameters=20encoding=20in=20 ,=20=20&=20 |Sender:=20; bh=A78RBi+qRoXiFBqYh5+VQBAM8xpWnme0FgY3w0c4ryU=; b=VxXfTlXFDBnqxmJeygakO3pA3+ynsvHPy3grPEJcvnc1NKX4UNYUnzWuTWj36KQgcviD/F5f U+k1VtSMLRHbPe5j2XuI89MkyJOfkm0HMjVZxKVyLG12FJZ8OhBv3XGd; Authentication-Results: ams-dkim-1; header.From=flefauch@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.2 (/) X-Scan-Signature: df9edf1223802dd4cf213867a3af6121 X-Mailman-Approved-At: Mon, 03 Dec 2007 08:44:48 -0500 Cc: "john.loughney@nokia.com>" , James Polk , Jukka Manner MJ , David Oran R , tsvwg chair , nsis-chairs@tools.ietf.org, ken carlberg , =?ISO-8859-1?Q? =28IJ/ETH=29_B=E1der_Attila ?= , cornelia.kappler@nsn.com, dime-chairs@tools.ietf.org, jouni.korhonen@teliasonera.com Subject: [NSIS] Resolution of issue QoS Parameters encoding in , & 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, The Issue: ======= Three different documents (dime-qos-parameters, nsis-qos-nslp, tsvwg- emergency-rsvp) need to convey an overlapping set of QoS parameters (specifically RPH-Priority and Admission Priority) and currently do that in an inconsistent manner. This has been brought up and partially discussed on the WG mailing lists. The Proposed Resolution =================== Co-authors of the three I-Ds as well as WG chairs of the corresponding WGs converged on the following proposed resolution. Please let us know if you have an issue/concern with this. o Regarding RPH-Priority: * tsvwg-emergency-rsvp will go ahead with its requests to IANA to provide numerical registry for RPH priority (via extending existing RPH registry). See IANA Considerations section of tsvwg-emergency-rsvp. * nsis-qspec (in section 6.2.10) will point to this registry instead of defining its own values * dime-qos-parameters (in section 4.11) will point to this registry instead of defining its own values * tsvwg-emergency-rsvp (in section 3.2) will keep pointing to this registry. o Regarding Admission Priority: * every protocol spec will only indicate that "higher value means higher priority". * there is no attempt to define what specific values should be used for what. this is left outside the scope of the protocol specs. * each protocol spec will add a statement clarifying that a given Admission Priority is to be encoded with the same value in each of the three protocol spec. For example, in tsvwg-emergency-rsvp, under section 3.1. we will add: " A given Admission Priority is encoded in this information element using the same value as when encoded in the Admission Priority parameter defined in section 6.2.9 of [nsis-qspec], or in the Admission Priority parameter defined in section 4.10 of [dime-qos-parameters]. In other words, a given value in any of the [emergency-rsvp] Admission Priority information element, the [nsis-qspec] Admission Priority parameter or the [dime-qos-parameters] Admission Priority parameter, refers to the same Admission Priority. " * the mirror statement will be added in nsis-qspec (section 6.2.9) and dime-qos-parameters (section 4.10) Francois >> >> For example in "tsvwg-emergency-rsvp" under section 3.1., after : >> " Adm. Priority (Admission Priority): 8 bits (unsigned) >> The admission control priority of the flow, in terms of >> access >> to network bandwidth in order to provide higher >> probability of >> call completion to selected flows. Higher values represent >> higher Priority. >> " >> we could add something like this: >> " A given Admission Priority is encoded in this >> information element >> using the same value as when encoded in the Admission Priority >> parameter defined in section 6.2.9 of [nsis-qspec], or >> in the Admission >> Priority parameter defined in section 4.10 of >> [dime-qos-parameters]. >> In other words, a given value in any of the >> [emergency-rsvp] Admission >> Priority information element, the [nsis-qspec] >> Admission Priority parameter >> or the [dime-qos-parameters] Admission Priority >> parameter, refers to >> the same Admission Priority. >> " >> >> Francois >> >> >>> That way, when these protocols are used in combination, you >> can't get >>> into priority inversion problems and can resist the >> temptation to try >>> to map using a local function. >>> >>> DaveO. >>> >>>> As a practical example of an issue I see in B, consider the recent >>>> comment from An Nguyen as part of the WGLC on dime-qos-parameters. >>>> He explained that ITU-T changed the "recommendation" where they >>>> define Admission Priority semantic and therefore dime-qos- >> parameters >>>> needs to point to that new ITU-T document instead. So what happens >>>> when ITU change their spec again in 2 years if we go for B. What >>>> happens if some other SDO decides to make use of admission >> priorities >>>> and define different value sets? >>>> Approach A completely isolates IETF from any of these >> external events >>>> (that should indeed be completely transparent to IETF). >>>> >>>> If we can close that one by email, no need to meet face to face in >>>> Vancouver. >>>> >>>> Francois >>>> >>>> >>>> >>>> From: "Nguyen, An P" >>>> Date: 16 October 2007 15:20:35 GMT+02:00 >>>> To: "Hannes Tschofenig" , >> , >>>> "radext mailing list" , , >>>> "tsvwg IETF list" >>>> Subject: [NSIS] RE: [Tsvwg] WGLC for draft-ietf-dime-qos- >>>> parameters-01 >>>> >>>> Hannes, >>>> >>>> Just a comment on a reference in Sect 4.10 - Admission Priority >>>> Parameter: >>>> >>>> Change the Y.1571 to Y.2171. The ITU SG-13 changed Y.1571 to Y. >>>> 2171 ( Admission Control Priority Levels in Next Generation >> Networks, >>>> Sept 2006) to reflect the NGN work. >>>> >>>> I think you should add Y.2171 to Sect 9.2 - Informative >> References as >>>> well. >>>> >>>> Regards, >>>> >>>> An >>>> >>>> >>>> >>>> >>>> On 26 Nov 2007, at 20:49, Francois Le Faucheur IMAP wrote: >>>> >>>>> >>>>> On 26 Nov 2007, at 20:23, wrote: >>>>> >>>>>> So, all three documents are about at the same state. I think it >>>>>> makess sense if the tsvwg draft creates the registry, and all of >>>>>> the other drafts reference it. >>>>> >>>>> very well. >>>>> >>>>> Since we seem to have agreement across TSWG/NSIS/DIME about the >>>>> first point (ie use a shared registry for RPH priorities) >> then let's >>>>> move to the second point ie. the actual format of that >>>>> registry: >>>>> draft-ietf-tsvwg-emergency-rsvp-04.txt proposes to >> instantiate that >>>>> registry by extending the existing IANA registry that was created >>>>> based on RFC4412. See "IANA Considerations" section of >>>>> draft-ietf-tsvwg-emergency-rsvp-04.txt. >>>>> Please let us know if you see issues with this proposal. >>>>> >>>>> Thanks >>>>> >>>>> Francois >>>>> >>>>>> >>>>>> John >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: ext Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>>>>>> Sent: 26 November, 2007 11:22 >>>>>>> To: Loughney John (Nokia-NRC/PaloAlto) >>>>>>> Cc: carlberg@g11.org.uk; magnus.westerlund@ericsson.com; >>>>>>> flefauch@cisco.com; jmpolk@cisco.com; cornelia.kappler@nsn.com; >>>>>>> oran@cisco.com; attila.bader@ericsson.com; >>>>>>> jouni.korhonen@teliasonera.com; jmanner@cs.Helsinki.FI; >>>>>>> tsvwg-chairs@tools.ietf.org; nsis-chairs@tools.ietf.org; >>>>>>> dime-chairs@tools.ietf.org >>>>>>> Subject: Re: QoS Parameters in dime-qos-parameters, >> nsis-qos-nlsp, >>>>>>> tsvwg-emeregncy-rsvp >>>>>>> >>>>>>> Hi John, >>>>>>> >>>>>>>> First off, what is the status of the drafts? I am >> going to do a >>>>>>>> WG Chair write-up on the NSIS QSPEC document. DiME QoS >>>>>>> parameters might >>>>>>>> take a bit longer. >>>>>>> >>>>>>> The DIME QoS parameter document has finished WGLC already. The >>>>>>> only technical issue that has been raised for this document is >>>>>>> related to the registry. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Ciao >>>>>>> Hannes >>>>>>> >>>>>>> >>>>> >>>> >> _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Dec 03 09:26:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzCFC-0001TD-2Q; Mon, 03 Dec 2007 09:25:58 -0500 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1IzCFB-0001Sr-2d for nsis-confirm+ok@megatron.ietf.org; Mon, 03 Dec 2007 09:25:57 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzCFA-0001RX-M8 for nsis@ietf.org; Mon, 03 Dec 2007 09:25:56 -0500 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IzCF9-0008J7-Vd for nsis@ietf.org; Mon, 03 Dec 2007 09:25:56 -0500 Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by iramx2.ira.uni-karlsruhe.de with esmtps id 1IzCF7-0006hu-4a for ; Mon, 03 Dec 2007 15:25:54 +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 for id 1IzCF5-0007ah-NM; Mon, 03 Dec 2007 15:25:52 +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 9D78B2FC070 for ; Mon, 3 Dec 2007 15:25:51 +0100 (CET) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1IzCF5-00064H-7K for nsis@ietf.org; Mon, 03 Dec 2007 15:25:51 +0100 Message-ID: <475411EE.3090008@tm.uka.de> Date: Mon, 03 Dec 2007 15:25:50 +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: multipart/mixed; boundary="------------030303090002000509070100" 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: irams1.ira.uni-karlsruhe.de X-ATIS-Checksum: v3zoCAcc32ckk X-Spam-Score: 0.0 (/) X-Scan-Signature: 48472a944c87678fcfe8db15ffecdfff Subject: [NSIS] [Fwd: I-D Action:draft-bless-nsis-est-mrm-00.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 This is a multi-part message in MIME format. --------------030303090002000509070100 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Hi, the above mentioned I-D is now officially posted. Regards, Roland --------------030303090002000509070100 Content-Type: message/rfc822; name="I-D Action:draft-bless-nsis-est-mrm-00.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="I-D Action:draft-bless-nsis-est-mrm-00.txt" Return-Path: Received: from murder ([unix socket]) by vorta (Cyrus v2.2.12) with LMTPA; Mon, 03 Dec 2007 11:54:53 +0100 X-Sieve: CMU Sieve 2.2 Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1Iz8wv-0005wJ-5P for bless@localhost; Mon, 03 Dec 2007 11:54:53 +0100 Received: from irams1.ira.uni-karlsruhe.de [141.3.10.5] by localhost with POP3 (fetchmail-6.2.5) for bless@localhost (single-drop); Mon, 03 Dec 2007 11:54:53 +0100 (CET) Received: from iramx1.ira.uni-karlsruhe.de ([141.3.10.80]) by irams1.ira.uni-karlsruhe.de with esmtps id 1Iz8vy-0003GX-8C; Mon, 03 Dec 2007 11:53:54 +0100 Received: from odin.ietf.org ([156.154.16.145] helo=megatron.ietf.org) by iramx1.ira.uni-karlsruhe.de with esmtps id 1Iz8vu-0006xf-Oq; Mon, 03 Dec 2007 11:53:54 +0100 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iz8sm-0002SJ-2i; Mon, 03 Dec 2007 05:50:36 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iz8sj-0002RP-Gm for i-d-announce@ietf.org; Mon, 03 Dec 2007 05:50:33 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iz8si-0006QD-Qi for i-d-announce@ietf.org; Mon, 03 Dec 2007 05:50:33 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 76C01175C5 for ; Mon, 3 Dec 2007 10:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Iz8sE-0005t4-0V for i-d-announce@ietf.org; Mon, 03 Dec 2007 05:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 03 Dec 2007 05:50:02 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Subject: I-D Action:draft-bless-nsis-est-mrm-00.txt X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: internet-drafts@ietf.org List-Id: i-d-announce.ietf.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: i-d-announce-bounces@ietf.org X-Spam-Status: No X-Spam-Score: -99.2 (---------------------------------------------------) X-Spam-Report: 0.6 NO_REAL_NAME From: does not include a real name -100 USER_IN_WHITELIST From: address is in the user's white-list 0.2 MIME_BOUND_NEXTPART Spam tool pattern in MIME boundary 0.0 AWL AWL: From: address is in the auto white-list X-Spam-Host: iramx1.ira.uni-karlsruhe.de X-ATIS-Checksum: v3zoCAcc32ckk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : An Explicit Signaling Target Message Routing Method (EST-MRM) for the General Internet Signaling Transport (GIST) Protocol Author(s) : R. Bless Filename : draft-bless-nsis-est-mrm-00.txt Pages : 11 Date : 2007-12-03 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-bless-nsis-est-mrm-00.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-bless-nsis-est-mrm-00.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-bless-nsis-est-mrm-00.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-12-03054316.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-bless-nsis-est-mrm-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-bless-nsis-est-mrm-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-12-03054316.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-- --------------030303090002000509070100 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 --------------030303090002000509070100-- From nsis-bounces@ietf.org Mon Dec 03 10:09:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzCun-0004Cg-Lb; Mon, 03 Dec 2007 10:08:57 -0500 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1IzCun-0004Ca-BJ for nsis-confirm+ok@megatron.ietf.org; Mon, 03 Dec 2007 10:08:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzCun-0004CP-1e for nsis@ietf.org; Mon, 03 Dec 2007 10:08:57 -0500 Received: from smtp0.netlab.nec.de ([195.37.70.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzCum-0002ix-K0 for nsis@ietf.org; Mon, 03 Dec 2007 10:08:57 -0500 Received: from localhost (atlas1.office [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 1B26F28000303 for ; Mon, 3 Dec 2007 16:08:56 +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 yV3T09gx0Lga for ; Mon, 3 Dec 2007 16:08:55 +0100 (CET) Received: from mx1.office (mx1.office [10.1.1.23]) by smtp0.netlab.nec.de (Postfix) with ESMTP id AD15A28000302 for ; Mon, 3 Dec 2007 16:08: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); Mon, 3 Dec 2007 16:08:50 +0100 Mime-Version: 1.0 (Apple Message framework v752.3) To: nsis Message-Id: From: Martin Stiemerling Date: Mon, 3 Dec 2007 16:08:45 +0100 X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 03 Dec 2007 15:08:50.0597 (UTC) FILETIME=[6940C550:01C835BE] X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Subject: [NSIS] minute taker and jabber scribe for session 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="===============0871556199==" Errors-To: nsis-bounces@ietf.org --===============0871556199== Content-Type: multipart/alternative; boundary=Apple-Mail-35--656006840 --Apple-Mail-35--656006840 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi all, We need at least one and at best two volunteers for today's NSIS session: Who is volunteering as minute taker? Who is volunteering as jabber scribe? Thanks in advance to those who volunteer! 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-35--656006840 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Hi all,

We need at = least one and at best two volunteers for today's NSIS = session:

Who = is volunteering as minute taker?

Who is volunteering as = jabber scribe?

Thanks in advance to those = who volunteer!

=A0=A0Martin

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-35--656006840-- --===============0871556199== 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 --===============0871556199==-- From nsis-bounces@ietf.org Mon Dec 03 11:54:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzEYw-0008UX-RU; Mon, 03 Dec 2007 11:54:30 -0500 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1IzEYw-0008UI-CE for nsis-confirm+ok@megatron.ietf.org; Mon, 03 Dec 2007 11:54:30 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzEYw-0008U4-1F for nsis@ietf.org; Mon, 03 Dec 2007 11:54:30 -0500 Received: from smtp0.netlab.nec.de ([195.37.70.40]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IzEYv-0008GC-Gu for nsis@ietf.org; Mon, 03 Dec 2007 11:54:29 -0500 Received: from localhost (atlas1.office [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 1006628000351 for ; Mon, 3 Dec 2007 17:54:29 +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 a+nYEpYoi1kA for ; Mon, 3 Dec 2007 17:54:28 +0100 (CET) Received: from mx1.office (mx1.office [10.1.1.23]) by smtp0.netlab.nec.de (Postfix) with ESMTP id F03EC28000350 for ; Mon, 3 Dec 2007 17:54:23 +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); Mon, 3 Dec 2007 17:54:22 +0100 Mime-Version: 1.0 (Apple Message framework v752.3) To: nsis Message-Id: <4BD31881-EC8C-446A-B2FA-E04BBC532F4F@netlab.nec.de> From: Martin Stiemerling Date: Mon, 3 Dec 2007 17:54:18 +0100 X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 03 Dec 2007 16:54:23.0857 (UTC) FILETIME=[282B8E10:01C835CD] X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Subject: [NSIS] Send your slides for today before the session 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="===============0844155936==" Errors-To: nsis-bounces@ietf.org --===============0844155936== Content-Type: multipart/alternative; boundary=Apple-Mail-39--649673906 --Apple-Mail-39--649673906 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi all presenters of today's NSIS session, I have received slides for NATFW NSLP, GIST over SCTP, RMD-QOSM, and Y.1541. Please send me the missing slides before the session, so that I can upload them to the meeting materials web site. Thank you! 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-39--649673906 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Hi all presenters of today's NSIS session,

I have received slides for = NATFW NSLP, GIST over SCTP, RMD-QOSM, and Y.1541.=A0

Please send me the missing = slides before the session, so that I can upload them to the meeting = materials web site.=A0

Thank you!

=A0=A0Martin

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-39--649673906-- --===============0844155936== 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 --===============0844155936==-- From nsis-bounces@ietf.org Mon Dec 03 12:27:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzF4G-0005ub-P1; Mon, 03 Dec 2007 12:26:52 -0500 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1IzF4F-0005sv-HZ for nsis-confirm+ok@megatron.ietf.org; Mon, 03 Dec 2007 12:26:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzF4F-0005sY-6M for nsis@ietf.org; Mon, 03 Dec 2007 12:26:51 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzF4C-0001iq-Oz for nsis@ietf.org; Mon, 03 Dec 2007 12:26:51 -0500 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 568A3220BE; Mon, 3 Dec 2007 18:26:48 +0100 (CET) X-AuditID: c1b4fb3e-b16a4bb00000459d-83-47543c58cc42 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 34FF421A94; Mon, 3 Dec 2007 18:26:48 +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, 3 Dec 2007 18:26:47 +0100 Received: from [153.88.14.9] ([153.88.14.9]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Dec 2007 18:26:47 +0100 Message-ID: <47543C55.7060608@ericsson.com> Date: Mon, 03 Dec 2007 09:26:45 -0800 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: 03 Dec 2007 17:26:47.0576 (UTC) FILETIME=[AEB78980:01C835D1] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -1.0 (-) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b 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 Hancock, Robert skrev: > magnus, > > finally following up your comment (1): > >> -----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. >> >> >> 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 > > 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 > 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 > about the transmission of this payload - it's just NSLP data being > piggybacked on the handshake, so there are no constraints (imposed > by GIST) on what can be done to it. However, GIST itself doesn't > allow changes in the GIST payloads at these intermediate points, > 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). > 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. > Hi, I think I realize what the issue is with the text. It is the usage of the word "forwarding". To me it imply that you wouldn't change the payload. Either you are NSLP aware and then you would process a request, or you are not aware and you simple forward it. But it might be the issue what is considered to be the NSLP payload. Because I do understand that a forwarding node will need to explicit mark that it has done this. But that doesn't seem to be a NSLP function, rather a GIST level object. 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 Tue Dec 04 11:54: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 1Izb2w-000256-3t; Tue, 04 Dec 2007 11:54:58 -0500 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1Izb2u-0001w9-QK for nsis-confirm+ok@megatron.ietf.org; Tue, 04 Dec 2007 11:54:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izb2u-0001vq-GS for nsis@ietf.org; Tue, 04 Dec 2007 11:54:56 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Izb2u-0005t4-1e for nsis@ietf.org; Tue, 04 Dec 2007 11:54:56 -0500 Received: (qmail invoked by alias); 04 Dec 2007 16:54:54 -0000 Received: from dhcp-16ce.ietf70.org (EHLO [130.129.22.206]) [130.129.22.206] by mail.gmx.net (mp044) with SMTP; 04 Dec 2007 17:54:54 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18PAfEQVTAPgSYUhbHeOZSzFlTMChUM1WV1YjjARK 0DAkuiiawnAURE Message-ID: <475507CD.40104@gmx.net> Date: Tue, 04 Dec 2007 08:54:53 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) 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: 4.8 (++++) X-Scan-Signature: 01485d64dfa90b45a74269b3ca9d5574 Subject: [NSIS] Meeting Minutes 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 Please take a look at the meeting minutes: http://www3.ietf.org/proceedings/07dec/minutes/nsis.txt _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Dec 04 17:06: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 1Izfui-0002dp-Sk; Tue, 04 Dec 2007 17:06:48 -0500 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1Izfuh-0002Pm-4Q for nsis-confirm+ok@megatron.ietf.org; Tue, 04 Dec 2007 17:06:47 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izfug-0002Je-IE for nsis@ietf.org; Tue, 04 Dec 2007 17:06: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 1Izfuf-00037r-Q1 for nsis@ietf.org; Tue, 04 Dec 2007 17:06: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; Wed, 05 Dec 2007 00:06:44 +0200 id 0007041C.4755CF74.00000D6E Date: Wed, 5 Dec 2007 00:06:44 +0200 (EET) From: Jukka MJ Manner To: Martin Stiemerling Subject: Re: [NSIS] WGLC: draft-ietf-nsis-nslp-natfw-16.txt In-Reply-To: <57BCC14C-53FD-4B9C-8EEE-C2D5D78B0B1F@netlab.nec.de> Message-ID: References: <57BCC14C-53FD-4B9C-8EEE-C2D5D78B0B1F@netlab.nec.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Cc: nsis 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 have reviewed that draft. I don't have any major objections to the document, just some miscellaneous comments and clarification requests. Here goes: - p.6, bullet 1: at this point in the document, it is not clear to the reader what the NSIS initiator/receiver are. Propose to use simpler terminology at this early phase in the intro. - p.6, end of page: propose to clearly say wo sends which message, e.g.: "CREATE message: send by the data sender for..." "EXTERNAL message: used by data receiver to ..." Related comment: why abbreviate EXTERNAL to "EXT"? * None of the other message are abbreviated * EXTERNAL is as long a word as "RESPONSE" (both abbreviated?) Suggest to drop the EXT-term Related to the above the document presents over and over again that EXTERNAL is EXT ("EXTERNAL (EXT)") and is a bit inconsistent in when to use EXTERNAL and when just EXT (both used here and there). - p.7.: s/body of the document, covers/body of the document cover/ - p.23: s/inSection/in Section/ - p.27: "if the node runs _it_ garbage collection cycle."? - p.27: "appropriate error of class 'Protocol error' (0x1)": 0x1 is Informational, ox3 is protocol error. - p.32: "is thus managed NSLP hop-by-hop"? - p.41: "session created by REA."? - p.41: "using CREATE Section 3.7.1" > "(see Section 3.7.1)"? - p.43: "if the like to aggregate"? - p.46, whole Section 3.7.6.1: should NR be actually DR? Including Figure 18? - P.46-47, Section 3.7.6.1: I don't really get this operation at all. Sounds a bit complex to have the EXT-session trigger a CREATE-session. Maybe some more discussion/description is needed to open up the scenario. Also, the NATFW_NONCE sounds a bit wierd, somehow. In the QoS NSLP, we have the same functionality, but it is called "session binding" and uses a similar object where the content is the SID of the primary flow. Achieves the same thing, and you can be sure there are no collisions with nonces. Does the value need to be a random value? Or could you perhaps re-use the QoS NSLP object since we have common object repository anyway? The concept in the QoS NSLP session binding is that the secondary session is valid as long as the primary session is. - Related to the above, p.48 (middle): if you have the "internal" CREATE+NONCE session and also get the e2e CREATE session, do you run both simultaneously? Or do you kill one of them? I guess you can't kill the EXT-session, since you need the forwarding at the NAT? Perhaps this needs some more description. - p.49: "back to NI according [to] the situation" - p.49: "NSLP node and the of the policy rule."? - p.51: Do the route changes really work as you describe? This may need some thinking, and probably add text to the mobility draft. - p.51: s/and sends it/and send it/ - Whole Section 4: the text talks about error cases and mandating "MUST" to send various error messages? If you must always send error messages, isn't this a use case for DoS attacks? I guess some words about when to send error messages would be needed (rate limiting, etc.). - p.57 (top of page): "Further version of this memo may allow other values for the 'sub_ports' field." I think suggestions like this should not be in a draft going to WGLC. - p.58-60: there are a lot of error codes. Should somewhere be written how and when these are used? Some of these are quite clear, but e.g. I don't understand Permanent failures 0x03, 0x05 and 0x06. Where would these be used? - p.61, Section 4.2.7: where is this object used actually? text says "possibly needed", sounds a bit wierd for a draft in WGLC. Is it needed, and where/when/why? Should this be also available for IPv6? - p.62, 3rd line: "according [to] these rules:" - p.64, Sections 4.3.1 and 4.3.2: what are these "(O)" and "(M)"? Optional and mandatory? Say it clearly. - p.64, Section 4.3.2: point c) as use case for EXT: you lost me here? Was this presented earlier? Actually, in general about EXT, should it always have the proxy bit P=1? What happens if I send an EXT message towards the DS with P=0? Does the EXT reach the DS? What happens then? - p.67: "In Section 5.1 we describe [how] the ..." - p.73: s/located to the/located at the/ Jukka _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Dec 04 17:21:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izg8T-0005Yq-5c; Tue, 04 Dec 2007 17:21:01 -0500 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1Izg8S-0005Yi-IQ for nsis-confirm+ok@megatron.ietf.org; Tue, 04 Dec 2007 17:21:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izg8S-0005YF-89 for nsis@ietf.org; Tue, 04 Dec 2007 17:21:00 -0500 Received: from mailer.gwdg.de ([134.76.10.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Izg8Q-0000f7-7F for nsis@ietf.org; Tue, 04 Dec 2007 17:21:00 -0500 Received: from gwdexc-fe1.exc.top.gwdg.de ([134.76.26.171] helo=vsmtpgwdexc.exc.top.gwdg.de) by mailer.gwdg.de with smtp (Exim 4.67) (envelope-from ) id 1Izg8P-0008Ri-DK; Tue, 04 Dec 2007 23:20:57 +0100 Received: from [130.129.16.143] ([130.129.16.143]) by vsmtpgwdexc.exc.top.gwdg.de with Microsoft SMTPSVC(6.0.3790.3959); Tue, 4 Dec 2007 23:20:57 +0100 Message-ID: <4755D2C4.4080400@cs.uni-goettingen.de> Date: Tue, 04 Dec 2007 14:20:52 -0800 From: Niklas Steinleitner User-Agent: Thunderbird 1.5.0.14pre (X11/20071023) MIME-Version: 1.0 To: Hannes Tschofenig Subject: Re: [NSIS] Meeting Minutes References: <475507CD.40104@gmx.net> In-Reply-To: <475507CD.40104@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 04 Dec 2007 22:20:57.0335 (UTC) FILETIME=[F134C870:01C836C3] X-Spam-Level: - X-Virus-Scanned: (clean) by exiscan+sophie X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 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 I will also review the NAT/FW NSLP draft asap. Regards, Niklas Hannes Tschofenig schrieb: > Please take a look at the meeting minutes: > http://www3.ietf.org/proceedings/07dec/minutes/nsis.txt > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis -- Niklas Steinleitner Tel: +49 551 3913583 Institute for Informatics steinleitner@cs.uni-goettingen.de University of G�ttingen http://www.tmg.informatik.uni-goettingen.de Lotzestrasse 16-18 D-37083 G�ttingen, Germany _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Dec 05 09:53:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izvd5-0006Dy-8Q; Wed, 05 Dec 2007 09:53:39 -0500 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1Izvd4-0006Dm-BO for nsis-confirm+ok@megatron.ietf.org; Wed, 05 Dec 2007 09:53:38 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izvd3-0006DM-Gq for nsis@ietf.org; Wed, 05 Dec 2007 09:53:37 -0500 Received: from smtp0.netlab.nec.de ([195.37.70.40]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Izvd1-0004Dn-QA for nsis@ietf.org; Wed, 05 Dec 2007 09:53:37 -0500 Received: from localhost (atlas1.office [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 37C3C2800034F; Wed, 5 Dec 2007 15:53:35 +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 TjwqbFs7Gcp8; Wed, 5 Dec 2007 15:53:35 +0100 (CET) Received: from mx1.office (mx1.office [10.1.1.23]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 17A3328000304; Wed, 5 Dec 2007 15:53:25 +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); Wed, 5 Dec 2007 15:53:23 +0100 In-Reply-To: References: <57BCC14C-53FD-4B9C-8EEE-C2D5D78B0B1F@netlab.nec.de> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: From: Martin Stiemerling Subject: Re: [NSIS] WGLC: draft-ietf-nsis-nslp-natfw-16.txt Date: Wed, 5 Dec 2007 15:53:17 +0100 To: Jukka MJ Manner X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 05 Dec 2007 14:53:23.0890 (UTC) FILETIME=[95B80120:01C8374E] X-Spam-Score: 0.6 (/) X-Scan-Signature: d2bb8c7db26f2d12109e0cd8e454db52 Cc: nsis 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="===============2064286208==" Errors-To: nsis-bounces@ietf.org --===============2064286208== Content-Type: multipart/alternative; boundary=Apple-Mail-26--484134136 --Apple-Mail-26--484134136 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi Jukka, Thanks a lot for your review! I will go through the comments today and come back if I need more information. Thanks, Martin Am 04.12.2007 um 23:06 schrieb Jukka MJ Manner: > > Hi, > > I have reviewed that draft. I don't have any major objections to the > document, just some miscellaneous comments and clarification requests. > > Here goes: > > - p.6, bullet 1: at this point in the document, it is not clear to the > reader what the NSIS initiator/receiver are. Propose to use simpler > terminology at this early phase in the intro. > > - p.6, end of page: propose to clearly say wo sends which message, > e.g.: > > "CREATE message: send by the data sender for..." > > "EXTERNAL message: used by data receiver to ..." > > Related comment: why abbreviate EXTERNAL to "EXT"? > * None of the other message are abbreviated > * EXTERNAL is as long a word as "RESPONSE" (both abbreviated?) > > Suggest to drop the EXT-term > > Related to the above the document presents over and over again that > EXTERNAL is EXT ("EXTERNAL (EXT)") and is a bit inconsistent in > when to > use EXTERNAL and when just EXT (both used here and there). > > - p.7.: s/body of the document, covers/body of the document cover/ > > - p.23: s/inSection/in Section/ > > - p.27: "if the node runs _it_ garbage collection cycle."? > > - p.27: "appropriate error of class 'Protocol error' (0x1)": 0x1 is > Informational, ox3 is protocol error. > > - p.32: "is thus managed NSLP hop-by-hop"? > > - p.41: "session created by REA."? > > - p.41: "using CREATE Section 3.7.1" > "(see Section 3.7.1)"? > > - p.43: "if the like to aggregate"? > > - p.46, whole Section 3.7.6.1: should NR be actually DR? Including > Figure > 18? > > - P.46-47, Section 3.7.6.1: I don't really get this operation at all. > Sounds a bit complex to have the EXT-session trigger a CREATE- > session. > Maybe some more discussion/description is needed to open up the > scenario. Also, the NATFW_NONCE sounds a bit wierd, somehow. In > the QoS > NSLP, we have the same functionality, but it is called "session > binding" > and uses a similar object where the content is the SID of the > primary > flow. Achieves the same thing, and you can be sure there are no > collisions with nonces. Does the value need to be a random value? Or > could you perhaps re-use the QoS NSLP object since we have common > object > repository anyway? The concept in the QoS NSLP session binding is > that > the secondary session is valid as long as the primary session is. > > - Related to the above, p.48 (middle): if you have the "internal" > CREATE+NONCE session and also get the e2e CREATE session, do you run > both simultaneously? Or do you kill one of them? I guess you > can't kill > the EXT-session, since you need the forwarding at the NAT? > Perhaps this > needs some more description. > > - p.49: "back to NI according [to] the situation" > > - p.49: "NSLP node and the of the policy rule."? > > - p.51: Do the route changes really work as you describe? This may > need > some thinking, and probably add text to the mobility draft. > > - p.51: s/and sends it/and send it/ > > - Whole Section 4: the text talks about error cases and mandating > "MUST" > to send various error messages? If you must always send error > messages, > isn't this a use case for DoS attacks? I guess some words about > when to > send error messages would be needed (rate limiting, etc.). > > - p.57 (top of page): "Further version of this memo may allow other > values > for the 'sub_ports' field." I think suggestions like this should > not be > in a draft going to WGLC. > > - p.58-60: there are a lot of error codes. Should somewhere be > written how > and when these are used? Some of these are quite clear, but e.g. I > don't understand Permanent failures 0x03, 0x05 and 0x06. Where would > these be used? > > - p.61, Section 4.2.7: where is this object used actually? text says > "possibly needed", sounds a bit wierd for a draft in WGLC. Is it > needed, > and where/when/why? Should this be also available for IPv6? > > - p.62, 3rd line: "according [to] these rules:" > > - p.64, Sections 4.3.1 and 4.3.2: what are these "(O)" and "(M)"? > Optional > and mandatory? Say it clearly. > > - p.64, Section 4.3.2: point c) as use case for EXT: you lost me > here? Was > this presented earlier? Actually, in general about EXT, should it > always > have the proxy bit P=1? What happens if I send an EXT message > towards > the DS with P=0? Does the EXT reach the DS? What happens then? > > - p.67: "In Section 5.1 we describe [how] the ..." > > - p.73: s/located to the/located at the/ > > > > Jukka 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-26--484134136 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Hi Jukka,

Thanks a = lot for your review! I will go through the comments today and come back = if I need more information.

Thanks,

=A0=A0Martin

<= div>

Am 04.12.2007 um 23:06 schrieb Jukka MJ Manner:

I have reviewed that draft. I don't have any major = objections to the=A0
document, just some miscellaneous comments and = clarification requests.

Here goes:

- p.6, = bullet 1: at this point in the document, it is not clear to the=A0

=A0 reader what the NSIS = initiator/receiver are. Propose to use simpler=A0

=A0 terminology at this early = phase in the intro.

- p.6, end of page: propose to = clearly say wo sends which message, e.g.:

"CREATE = message: send by the data sender for..."

"EXTERNAL = message: used by data receiver to ..."

Related = comment: why abbreviate EXTERNAL to "EXT"?=A0

* None of = the other message are abbreviated

* = EXTERNAL is as long a word as "RESPONSE" (both abbreviated?)

Suggest = to drop the EXT-term

Related to the above the = document presents over and over again that=A0

EXTERNAL = is EXT ("EXTERNAL (EXT)") and is a bit inconsistent in when to=A0

use = EXTERNAL and when just EXT (both used here and there).

- p.7.: = s/body of the document, covers/body of the document cover/

- p.23: = s/inSection/in Section/

- p.27: "if the node runs _it_ = garbage collection cycle."?=A0

- p.27: = "appropriate error of class 'Protocol error' (0x1)": 0x1 is=A0

=A0 Informational, ox3 is = protocol error.

- p.32: "is thus managed NSLP hop-by-hop"?

- p.41: = "session created by REA."?

- p.41: "using CREATE Section = 3.7.1" > "(see Section 3.7.1)"?

- p.43: "if the like to = aggregate"?

- p.46, whole Section 3.7.6.1: should NR be actually = DR? Including Figure=A0

=A0 18?

- = P.46-47, Section 3.7.6.1: I don't really get this operation at all.=A0

=A0 Sounds a bit complex to have = the EXT-session trigger a CREATE-session.=A0

=A0 Maybe some more = discussion/description is needed to open up the=A0

=A0 scenario. Also, the = NATFW_NONCE sounds a bit wierd, somehow. In the QoS=A0

=A0 NSLP, we have the same = functionality, but it is called "session binding"=A0

=A0 and uses a similar object = where the content is the SID of the primary=A0

=A0 flow. Achieves the same = thing, and you can be sure there are no=A0

=A0 collisions with nonces. Does = the value need to be a random value? Or=A0

=A0 could you perhaps re-use the = QoS NSLP object since we have common object=A0

=A0 repository anyway? The = concept in the QoS NSLP session binding is that=A0

=A0 the secondary session is = valid as long as the primary session is.

- Related to = the above, p.48 (middle): if you have the "internal"=A0

=A0 CREATE+NONCE session and also = get the e2e CREATE session, do you run=A0

=A0 both simultaneously? Or do = you kill one of them? I guess you can't kill=A0

=A0 the EXT-session, since you = need the forwarding at the NAT? Perhaps this=A0

=A0 needs some more = description.

- p.49: "back to NI according [to] the = situation"

- p.49: "NSLP node and the of the policy = rule."?

- p.51: Do the route changes really work as you = describe? This may need=A0

=A0 some thinking, and probably = add text to the mobility draft.

- p.51: s/and sends it/and send = it/

- Whole Section 4: the text talks about error cases = and mandating "MUST"=A0

=A0 to send various error = messages? If you must always send error messages,=A0

=A0 isn't this a use case for DoS = attacks? I guess some words about when to=A0

=A0 send error messages would be = needed (rate limiting, etc.).

- p.57 (top of page): "Further = version of this memo may allow other values=A0

=A0 for the 'sub_ports' field." I = think suggestions like this should not be=A0

=A0 in a draft going to = WGLC.

- p.58-60: there are a lot of error codes. Should = somewhere be written how=A0

=A0 and when these are used? Some = of these are quite clear, but e.g.=A0= I=A0

=A0 = don't understand Permanent failures 0x03, 0x05 and 0x06. Where = would=A0

=A0 = these be used?

- p.61, Section 4.2.7: where is = this object used actually? text says=A0

=A0 "possibly needed", sounds a = bit wierd for a draft in WGLC. Is it needed,=A0

=A0 and where/when/why? Should = this be also available for IPv6?

- p.62, 3rd line: "according = [to] these rules:"

- p.64, Sections 4.3.1 and = 4.3.2: what are these "(O)" and "(M)"? Optional=A0

=A0 and mandatory? Say it = clearly.

- p.64, Section 4.3.2: point c) as use case for EXT: = you lost me here? Was=A0

=A0 this presented earlier? = Actually, in general about EXT, should it always=A0

=A0 have the proxy bit P=3D1? = What happens if I send an EXT message towards=A0

=A0 the DS with P=3D0? Does the = EXT reach the DS? What happens then?

- p.67: "In Section 5.1 we = describe [how] the ..."

- p.73: s/located to the/located = at the/

Jukka

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-26--484134136-- --===============2064286208== 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 --===============2064286208==-- From nsis-bounces@ietf.org Thu Dec 06 17:14:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0OzW-0006eb-AG; Thu, 06 Dec 2007 17:14:46 -0500 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1J0OzU-0006eL-Th for nsis-confirm+ok@megatron.ietf.org; Thu, 06 Dec 2007 17:14:44 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0OzU-0006bB-GK for nsis@ietf.org; Thu, 06 Dec 2007 17:14:44 -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 1J0OzT-00058A-Ip for nsis@ietf.org; Thu, 06 Dec 2007 17:14:44 -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; Fri, 07 Dec 2007 00:14:42 +0200 id 000805AE.47587452.00001B2C Date: Fri, 7 Dec 2007 00:14:42 +0200 (EET) From: Jukka MJ Manner To: Roland Bless In-Reply-To: <473C4D46.7020002@tm.uka.de> Message-ID: References: <20071105200346.2BAF.SANDA.TAKAKO@jp.panasonic.com> <47343862.5040206@tm.uka.de> <473C4D46.7020002@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: 0ff9c467ad7f19c2a6d058acd7faaec8 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 Roland, I'm finally trying to figure this thread. :) See one comment below. Jukka On Thu, 15 Nov 2007, 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. [JM]: If the CN requests reliable or secure transport, GIST will send an empty Query to the next, set up routing state, and only then send the NOTIFY. This will hit QNE4. Now QNE4 does not know about the SID in question, so should it send an error back, or forward the message in the same way towards the CN? [JM]: Yet, also with unreliable/unsecure transport, what would happen, if QNE4 would actually decide not to peer? It sees a NOTIFY for a SID it doesn't know about, so it could as well forward the message further, right? The message will eventually hit a QNE (or eventually the CN), who then knows about the SID. > > > 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 Dec 06 17:26:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0PAs-0007aJ-Ol; Thu, 06 Dec 2007 17:26:30 -0500 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1J0PAs-0007aC-0M for nsis-confirm+ok@megatron.ietf.org; Thu, 06 Dec 2007 17:26:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0PAr-0007Zr-MZ for nsis@ietf.org; Thu, 06 Dec 2007 17:26:29 -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 1J0PAo-0007u4-SV for nsis@ietf.org; Thu, 06 Dec 2007 17:26:29 -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; Fri, 07 Dec 2007 00:26:23 +0200 id 000805CA.4758770F.00001ABE Date: Fri, 7 Dec 2007 00:26:21 +0200 (EET) From: Jukka MJ Manner To: Roland Bless Subject: Re: [NSIS] Re: [NSIS Mobility draft] Updating from -07 to -08 In-Reply-To: <473D7726.1070504@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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a0ecb232550b38fd41a3cf6a312fbabc 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 Hi Roland, Hong, Takako, What you are discussing is the case of MIP, and sure, here the binding update helps as the upstream trigger. But if we do not employ MIP? What about mobility within a local domain without MIP. In such a case, the MN IP will not change, but we need the upstream trigger to set up the signaling path efficiently. In that case, the upstream NOTIFY is our only help, I'd say. (In this scenario, the IP address could actually change, too, and we use e.g. SIP to re-bind the session and data streams. This comes back to the MIP case, though - some e2e signaling exists to provide a new IP address of the MN, and this would be coupled somehow with the NSIS protos.) rgs, Jukka On Fri, 16 Nov 2007, 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 From nsis-bounces@ietf.org Fri Dec 07 10:17: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 1J0exM-0007TP-MQ; Fri, 07 Dec 2007 10:17:36 -0500 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1J0exL-0007TH-6l for nsis-confirm+ok@megatron.ietf.org; Fri, 07 Dec 2007 10:17:35 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0exK-0007T9-Rx for nsis@ietf.org; Fri, 07 Dec 2007 10:17:34 -0500 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J0exK-00014c-5x for nsis@ietf.org; Fri, 07 Dec 2007 10:17:34 -0500 Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by iramx2.ira.uni-karlsruhe.de with esmtps id 1J0exE-0005A8-E9; Fri, 07 Dec 2007 16:17:30 +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 1J0exD-0001J0-8b; Fri, 07 Dec 2007 16:17:28 +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 28CB22FC00C; Fri, 7 Dec 2007 16:17:27 +0100 (CET) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1J0exC-0007fF-JR; Fri, 07 Dec 2007 16:17:26 +0100 Message-ID: <47596406.4050402@tm.uka.de> Date: Fri, 07 Dec 2007 16:17:26 +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 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: 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: irams1.ira.uni-karlsruhe.de X-ATIS-Checksum: v3zoCAcc32ckk X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: Takako Sanda , "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 Jukka, see comment inline. Jukka MJ Manner wrote: > On Thu, 15 Nov 2007, 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. > > > [JM]: If the CN requests reliable or secure transport, GIST will send an I don't know what it has to do with reliable and secure transport? > empty Query to the next, set up routing state, and only then send the > NOTIFY. This will hit QNE4. Now QNE4 does not know about the SID in > question, so should it send an error back, or forward the message in the > same way towards the CN? Please read the above text again. The problem lies in the fact that you have to send a GIST-Query _upstream_ and no routing state exists yet. So even if an MA exists, it cannot be used. This could only be done with _upstream_ Q-mode encapsulation, but this is definitely not applicable in a general way. > [JM]: Yet, also with unreliable/unsecure transport, what would happen, if > QNE4 would actually decide not to peer? It sees a NOTIFY for a SID it > doesn't know about, so it could as well forward the message further, > right? The message will eventually hit a QNE (or eventually the CN), who > then knows about the SID. See above. The GIST Query has to find its way first. This is the real problem. Regards, Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Dec 10 19:47:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1tHN-0001K2-AQ; Mon, 10 Dec 2007 19:47:21 -0500 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1J1tHM-0001HT-6R for nsis-confirm+ok@megatron.ietf.org; Mon, 10 Dec 2007 19:47:20 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1tHL-0001HL-Rg for nsis@ietf.org; Mon, 10 Dec 2007 19:47:19 -0500 Received: from smtp.mei.co.jp ([133.183.100.20]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J1tHL-0004zl-3A for nsis@ietf.org; Mon, 10 Dec 2007 19:47:19 -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-maile12) with ESMTP id lBB0l90P009849; Tue, 11 Dec 2007 09:47:09 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx1) with ESMTP id lBB0l9Q16209; Tue, 11 Dec 2007 09:47:09 +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 lBB0lBO27078; Tue, 11 Dec 2007 09:47:11 +0900 (JST) Received: by epochmail.jp.panasonic.com (8.12.11.20060308/3.7W/soml24) id lBB0l8bq007225; Tue, 11 Dec 2007 09:47:08 +0900 (JST) Received: from [10.68.136.102] by soml24.jp.panasonic.com (8.12.11.20060308/3.7W) with ESMTP id lBB0l7JM007185; Tue, 11 Dec 2007 09:47:08 +0900 (JST) Date: Tue, 11 Dec 2007 09:49:41 +0900 From: Takako Sanda To: Martin Stiemerling , nsis Subject: Re: [NSIS] WGLC: draft-ietf-nsis-nslp-natfw-16.txt In-Reply-To: <57BCC14C-53FD-4B9C-8EEE-C2D5D78B0B1F@netlab.nec.de> References: <57BCC14C-53FD-4B9C-8EEE-C2D5D78B0B1F@netlab.nec.de> Message-Id: <20071211092834.552A.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: 0a7aa2e6e558383d84476dc338324fab 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 all, Regarding NAT traversal, NSIS Mobility Applicability draft also has two open issues (as shown below). But I am not sure Mobility draft is proper place to handle these issues. I would like to ask whether these two issues can be discussed in NATFW draft. Issue 1: When MN moves, IP address and routing are changed. In this case, new NAT/FW pinhole need to be opened and old one should be torn. When and how should NSIS tear old pinhole? (For this issue, some comments were already made that the old pinhole should be torn by time out, and this prefer to be mentioned in Mobility draft.) Issue 2: In mobility scenario, it is possible that MN attaches to private network. But MN cannot know if the NAT is NSIS aware or not. Therefore should it be mandatory that MN sets S-flag when it detect attaching a private network? cheers, Takako On Fri, 23 Nov 2007 13:44:20 +0100 Martin Stiemerling wrote: > [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 > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Dec 11 06:26:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J23FT-0004uF-Ji; Tue, 11 Dec 2007 06:26:03 -0500 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1J23FS-0004u7-9T for nsis-confirm+ok@megatron.ietf.org; Tue, 11 Dec 2007 06:26:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J23FR-0004ty-Vj for nsis@ietf.org; Tue, 11 Dec 2007 06:26:01 -0500 Received: from amailer.gwdg.de ([134.76.10.18]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J23FO-00067s-Uj for nsis@ietf.org; Tue, 11 Dec 2007 06:26:01 -0500 Received: from s5.ifi.informatik.uni-goettingen.de ([134.76.81.25] helo=[172.22.0.55]) by mailer.gwdg.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1J23FH-0002cT-49; Tue, 11 Dec 2007 12:25:51 +0100 Message-ID: <475E7303.3080800@cs.uni-goettingen.de> Date: Tue, 11 Dec 2007 12:22:43 +0100 From: Niklas Steinleitner User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Martin Stiemerling Subject: Re: [NSIS] WGLC: draft-ietf-nsis-nslp-natfw-16.txt References: <57BCC14C-53FD-4B9C-8EEE-C2D5D78B0B1F@netlab.nec.de> In-Reply-To: <57BCC14C-53FD-4B9C-8EEE-C2D5D78B0B1F@netlab.nec.de> X-Authenticated: Id:nsteinl1 X-Spam-Level: - X-Virus-Scanned: (clean) by exiscan+sophie X-Spam-Score: 0.0 (/) X-Scan-Signature: 6437e26f1586b9f35812ea5ebeedf4ad Cc: nsis 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="===============1808793686==" Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. --===============1808793686== Content-Type: multipart/alternative; boundary="------------060509040903070003000100" This is a multi-part message in MIME format. --------------060509040903070003000100 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Hi Martin, all, i have reviewed the NATFW NSLP draft. Overall i think the draft is in a good shape. My three major comments: * p24: Redraw the picture! Add administrative domains or point out with node belongs to which network! Also rewrite the first paragraph! Use a easier example! This section indicates (at least to me) the usage of the proxy mode in a way which is not supported by NATFW! * p26/section 3.2.3: Why do you have this section within the draft? The listed states are not enough to implement the NATFW NSLP and may confuse reviewers/implementers. You could point to the statemachine draft! If you want to have this section inside the draft, you should update it. What is the "Dead" state good for? Such a session has to be deleted directly and not "... and the NATFW NSLP signaling session can be deleted." * regarding section 3.7.2: this section is a little bit confusing! Even with knowledge about the NATFW NSLP it is hard to follow. Maybe you should re-structure it a little bit, e.g. creating several sub-sections. You should also clearly point out that EXT can also be used to install pinholes in FWs (and not only deny rules as described later, if i don't understand this wrong (see below)). Further comments: * p2/p4: If you introduce NAT, you should do the same for FW * p8/p10: you introduce the terminology "middlebox" twice, in section 1.2. and section 1.3 * p11: meaning that there is a middlebox on the => meaning that there is _at least one_ middlebox on the * p22, first paragraph: (check local policies for authorization and authentication, possibly create policy rules) that is not right, the NF only notice the policy rules * p22, third paragraph: the NF installs the policy rule when receiving a success RESPONSE msg * p22, fourth paragraph: Ni => NI * p27: 'Protocol error' (0x1) => (0x3) * p29/p30: many recurrences here: Requested signaling session lifetime is too big, Requested signaling session lifetime is too small, with codes, the same on page 30 * p32: section 3.7: ... how to create NATFW NSLP signaling sessions, maintain them, and how to reserve addresses. => and delete * p34: NSLP forwarder: what happened if the NF can not install the pinhole? e.g. it is already installed looks like you forgot this case, there is also node error code for this case on page 58. * p40: ... an error RESPONSE of class 'Protocol error' (0x3) ... => of class signaling session failure (0x6) * p40: "The policy rule is remembered, but not activated, if the action in the NATFW_EFI object is set to 'allow'." Why? In general, i don't understand the "Firewall" paragraph. * p41: "Reservations with action 'allow' made with EXT MUST be enabled by a subsequent CREATE message." What happens if the pinhole isn't use for reservation of an external address or a NAT-binding? In this case no CREATE msg will follow. o or is this in general not allow within the NATFW NSLP? The next sentence indicates that: o "The only function of EXT is to ensure that subsequent CREATE messages traveling towards the NR will be forwarded across the public-private boundary towards the DR." o One earlier version of the NATFW NSLP supports this with the use of U-CREATE. Or is this completely remove? * p41: ...created by REA. => ... created by EXT. * p42: "The lifetime extension of a NATFW NSLP signaling session is calculated as current local time plus proposed lifetime value", really local time _*plus *_proposed? This would increase the lifetime step by step as the local lifetime is always >0! * p44: "'NATFW node is going down soon' (0x03) The NI and other NFs should be prepared for a service interruption at any time." What is this good for???? * p48/49, section 3.7.6.2: you should make clear where are the differences to the EXT msg. * p52: ... of this memo => ...of this memo. * p56: ... of class 'Signaling session error' (0x6) with ... => ... of class 'Signaling session failure' (0x6) with ... * p58: you forgot 0x04 (see 3.7.5) 'NATFW signaling session lifetime expired' * p59(and whole doc) => signaling session failures => signaling session failure (as for the other classes). * p62: The fields MUST be interpreted according these rules: => The fields MUST be interpreted according _*to *_these rules: * p62: with response code 'Mandatory object missing' (0x02) MUST => (0x04) * p76: Open issues. Should this be part of a WGLC document? Regards, Niklas Martin Stiemerling schrieb: > [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 > > > ------------------------------------------------------------------------ > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > -- Niklas Steinleitner Tel: +49 551 3913583 Institute for Informatics steinleitner@cs.uni-goettingen.de University of G�ttingen http://www.tmg.informatik.uni-goettingen.de Lotzestrasse 16-18 D-37083 G�ttingen, Germany --------------060509040903070003000100 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Martin, all,

i have reviewed the NATFW NSLP draft. Overall i think the draft is in a good shape.

My three major comments:

p24: Redraw the picture! Add administrative domains or point out with node belongs to which network! Also rewrite the first paragraph! Use a easier example! This section indicates (at least to me) the usage of the proxy mode in a way which is not supported by NATFW!
p26/section 3.2.3: Why do you have this section within the draft? The listed states are not enough to implement the NATFW NSLP and may confuse reviewers/implementers. You could point to the statemachine draft! If you want to have this section inside the draft, you should update it. What is the "Dead" state good for? Such a session has to be deleted directly and not "... and the NATFW NSLP signaling session can be deleted."
regarding section 3.7.2: this section is a little bit confusing! Even with knowledge about the NATFW NSLP it is hard to follow. Maybe you should re-structure it a little bit, e.g. creating several sub-sections. You should also clearly point out that EXT can also be used to install pinholes in FWs (and not only deny rules as described later, if i don't understand this wrong (see below)).

Further comments:

p2/p4: If you introduce NAT, you should do the same for FW
p8/p10: you introduce the terminology "middlebox" twice, in section 1.2. and section 1.3
p11: meaning that there is a middlebox on the => meaning that there is at least one middlebox on the
p22, first paragraph: (check local policies for authorization and authentication, possibly create policy rules) that is not right, the NF only notice the policy rules
p22, third paragraph: the NF installs the policy rule when receiving a success RESPONSE msg
p22, fourth paragraph: Ni => NI
p27: 'Protocol error' (0x1) => (0x3)
p29/p30: many recurrences here: Requested signaling session lifetime is too big, Requested signaling session lifetime is too small, with codes, the same on page 30
p32: section 3.7: ... how to create NATFW NSLP signaling sessions, maintain them, and how to reserve addresses. => and delete
p34: NSLP forwarder: what happened if the NF can not install the pinhole? e.g. it is already installed
looks like you forgot this case, there is also node error code for this case on page 58.
p40: ... an error RESPONSE of class 'Protocol error' (0x3) ... => of class signaling session failure (0x6)
p40: "The policy rule is remembered, but not activated, if the action in the NATFW_EFI object is set to 'allow'." Why? In general, i don't understand the "Firewall" paragraph.
p41: "Reservations with action 'allow' made with EXT MUST be enabled by a subsequent CREATE message." What happens if the pinhole isn't use for reservation of an external address or a NAT-binding? In this case no CREATE msg will follow.

or is this in general not allow within the NATFW NSLP? The next sentence indicates that:
"The only function of EXT is to ensure that subsequent CREATE messages traveling towards the NR will be forwarded across the public-private boundary towards the DR."

One earlier version of the NATFW NSLP supports this with the use of U-CREATE. Or is this completely remove?

p41: ...created by REA. => ... created by EXT.
p42: "The lifetime extension of a NATFW NSLP signaling session is calculated as current local time plus proposed lifetime value", really local time plus proposed? This would increase the lifetime step by step as the local lifetime is always >0!
p44: "'NATFW node is going down soon' (0x03) The NI and other NFs should be prepared for a service interruption at any time."
What is this good for????
p48/49, section 3.7.6.2: you should make clear where are the differences to the EXT msg.
p52: ... of this memo => ...of this memo.
p56: ... of class 'Signaling session error' (0x6) with ... => ... of class 'Signaling session failure' (0x6) with ...
p58: you forgot 0x04 (see 3.7.5) 'NATFW signaling session lifetime expired'
p59(and whole doc) => signaling session failures => signaling session failure (as for the other classes).
p62: The fields MUST be interpreted according these rules: => The fields MUST be interpreted according to these rules:
p62: with response code 'Mandatory object missing' (0x02) MUST => (0x04)
p76: Open issues. Should this be part of a WGLC document?

Regards,
Niklas

Martin Stiemerling schrieb:

[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
_______________________________________________
nsis mailing list
nsis@ietf.org
https://www1.ietf.org/mailman/listinfo/nsis
  

-- 
Niklas Steinleitner          Tel: +49 551 3913583
Institute for Informatics    steinleitner@cs.uni-goettingen.de
University of Göttingen      http://www.tmg.informatik.uni-goettingen.de
Lotzestrasse 16-18
D-37083 Göttingen, Germany

--------------060509040903070003000100-- --===============1808793686== 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 --===============1808793686==-- From nsis-bounces@ietf.org Wed Dec 12 14:28: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 1J2XGC-0006pY-10; Wed, 12 Dec 2007 14:28:48 -0500 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1J2XGA-0006ok-GW for nsis-confirm+ok@megatron.ietf.org; Wed, 12 Dec 2007 14:28:46 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2XGA-0006oc-5N for nsis@ietf.org; Wed, 12 Dec 2007 14:28:46 -0500 Received: from moutng.kundenserver.de ([212.227.126.183]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J2XG9-000180-IP for nsis@ietf.org; Wed, 12 Dec 2007 14:28:46 -0500 Received: from amd64.laiers.local (dslb-088-066-046-112.pools.arcor-ip.net [88.66.46.112]) by mrelayeu.kundenserver.de (node=mrelayeu8) with ESMTP (Nemesis) id 0ML31I-1J2XG82pdC-0002KL; Wed, 12 Dec 2007 20:28:44 +0100 From: Max Laier Organization: =?iso-8859-1?q?Universit=E4t_Karlsruhe?= (TH) To: nsis Date: Wed, 12 Dec 2007 20:28:35 +0100 User-Agent: KMail/1.9.7 MIME-Version: 1.0 Message-Id: <200712122028.42262.max.laier@tm.uka.de> X-Provags-ID: V01U2FsdGVkX19rqaBaHhndhCWeOvZZQ8PnnCqxpk1aRzb++xT kRoU58NXcXz9mKBt03OEie9OS6cwlpXeCsFadQn4Tw1YJhMYSA ioalUSlXv5uPcijxHZQos8NG8P1gDsUXPiFZNPLqkg= X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Subject: [NSIS] Mobility Implementation Question 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="===============0464733716==" Errors-To: nsis-bounces@ietf.org --===============0464733716== Content-Type: multipart/signed; boundary="nextPart2501678.0O6ZNxFppP"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit --nextPart2501678.0O6ZNxFppP Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi, we are currently pondering about how to best implement mobility aware=20 QoS-signaling. One of the first stumbling block I hit so far is that the mobility draft=20 suggests that all signaling for the route-optimized case should be done=20 using the CoA as the source/destination of the flow. i.e. signaling is=20 done for the actual flow rather than for the logical one. This certainly=20 makes sense, but any potential application that uses e.g. QoS-NSLP as a=20 service will ask for a reservation for the *logical* flow as it is=20 anaware of MobileIP (and should be). So the questions becomes where=20 should the translation from logical to actual flow take place. I believe that mobility management should be taken care of within the NTLP= =20 layer as the NSLP should not have to be concerned with the actual message=20 routing. Currently I have two possible sollutions to the problem which=20 I'd like to hear feedback about: 1) Extend the GIST-to-NSLP API with a type of NetworkNotification that is=20 able to convey Address-Binding-Information and let the NSLP figure out if=20 this information is relevant to any of it's sessions. 2) Use a similar approach as the MRITS described in [1]. This would take=20 place in the MN / CN respectively and translate the MRI according to the=20 BindingCache (and/or the routing header). I feel that the second option might be easier to implement and could help=20 to reduce the amount of duplication. i.e. this way only the NTLP has to=20 interact with the mobility layer and the NSLP can be mostly oblivious of=20 the fact that it is in fact mobile. The NTLP would obviously still have=20 to send some kind of trigger in case of a BindingUpdate, but that could=20 be a normal NetworkNotification for the HoA. Any comments greatly appreciated. P.S. How does the QoS-NSLP translate the packet classifier in a GaNAT=20 environment. I'm not completely through the nattraversal-darf, yet and=20 would appreciate any pointers. [1]http://tools.ietf.org/html/draft-pashalidis-nsis-gimps-nattraversal-05#s= ection-5.3 =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 --nextPart2501678.0O6ZNxFppP 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) iD8DBQBHYDZqXyyEoT62BG0RAok5AJ0UtdsmZtoVtsFXE1X+Sk7EJYG6wgCfS8xQ npon5pEpWbfMkj9cjVtD64g= =vwHJ -----END PGP SIGNATURE----- --nextPart2501678.0O6ZNxFppP-- --===============0464733716== 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 --===============0464733716==-- From nsis-bounces@ietf.org Wed Dec 12 14:52:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2Xcm-0001ZA-Dj; Wed, 12 Dec 2007 14:52:08 -0500 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1J2Xcl-0001Z5-C0 for nsis-confirm+ok@megatron.ietf.org; Wed, 12 Dec 2007 14:52:07 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2Xcl-0001Yx-1I for nsis@ietf.org; Wed, 12 Dec 2007 14:52:07 -0500 Received: from moutng.kundenserver.de ([212.227.126.183]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J2Xck-0001r8-Ip for nsis@ietf.org; Wed, 12 Dec 2007 14:52:06 -0500 Received: from amd64.laiers.local (dslb-088-066-046-112.pools.arcor-ip.net [88.66.46.112]) by mrelayeu.kundenserver.de (node=mrelayeu7) with ESMTP (Nemesis) id 0ML2xA-1J2Xcj3VI1-0003M4; Wed, 12 Dec 2007 20:52:06 +0100 From: Max Laier Organization: =?utf-8?q?Universit=C3=A4t_Karlsruhe?= (TH) To: nsis@ietf.org Subject: Re: [NSIS] Mobility Implementation Question Date: Wed, 12 Dec 2007 20:51:57 +0100 User-Agent: KMail/1.9.7 References: <200712122028.42262.max.laier@tm.uka.de> In-Reply-To: <200712122028.42262.max.laier@tm.uka.de> MIME-Version: 1.0 Message-Id: <200712122052.03125.max.laier@tm.uka.de> X-Provags-ID: V01U2FsdGVkX1/C/xPIXpnHvPxK3PcX6B8sdhFgaeDcyreh4qw iAxNIt4qP9um2hdnZGQcHfqBDEvGseK0YtTuCsMhZecRmvGF3r E1qms2DcR8srWKkzxxwETSEqYnL0uEigJdU/bEb8T4= X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f 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="===============1000761781==" Errors-To: nsis-bounces@ietf.org --===============1000761781== Content-Type: multipart/signed; boundary="nextPart7932095.iK5x44lWOb"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit --nextPart7932095.iK5x44lWOb Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Wednesday 12 December 2007, I wrote: > ... > > 2) Use a similar approach as the MRITS described in [1]. This would > take place in the MN / CN respectively and translate the MRI according > to the BindingCache (and/or the routing header). Correction. =A0Obviously it won't use the routing header as the translation= =20 would ensure that the message is sent from/to the CoA and thus doesn't=20 carry any routing headers. =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 --nextPart7932095.iK5x44lWOb 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) iD8DBQBHYDvjXyyEoT62BG0RAinCAJ4vrk/lVLuToGkSETpLvBOVpwysuQCfexcJ rwroibkZSLQ96vMePz5XqfI= =iJ/E -----END PGP SIGNATURE----- --nextPart7932095.iK5x44lWOb-- --===============1000761781== 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 --===============1000761781==-- From nsis-bounces@ietf.org Wed Dec 12 19:08:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2bcs-0005z0-EJ; Wed, 12 Dec 2007 19:08:30 -0500 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1J2bcr-0005yt-P3 for nsis-confirm+ok@megatron.ietf.org; Wed, 12 Dec 2007 19:08:29 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2bcr-0005yk-Do for nsis@ietf.org; Wed, 12 Dec 2007 19:08:29 -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 1J2bcq-0001Wd-J2 for nsis@ietf.org; Wed, 12 Dec 2007 19:08:29 -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; Thu, 13 Dec 2007 02:08:27 +0200 id 000805CE.476077FB.00003D85 Received: by sbz-32.cs.helsinki.fi (Postfix, from userid 50703) id 2391D155BA; Thu, 13 Dec 2007 02:08:27 +0200 (EET) Received: from localhost (localhost [127.0.0.1]) by sbz-32.cs.helsinki.fi (Postfix) with ESMTP id 20D6C155AA; Thu, 13 Dec 2007 02:08:27 +0200 (EET) Date: Thu, 13 Dec 2007 02:08:27 +0200 (EET) From: Lauri J T Liuhto To: Martin Stiemerling Subject: Re: [NSIS] WGLC: draft-ietf-nsis-nslp-natfw-16.txt In-Reply-To: <57BCC14C-53FD-4B9C-8EEE-C2D5D78B0B1F@netlab.nec.de> Message-ID: References: <57BCC14C-53FD-4B9C-8EEE-C2D5D78B0B1F@netlab.nec.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: nsis 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 On Fri, 23 Nov 2007, Martin Stiemerling wrote: > 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. Hi, I have read the document, and I did not find any big issues, mainly just some editorial things. I did not repeat findings already provided by Jukka or Niklas. Some parts of the text, mainly Section 3 (Protocol Description), was such, that I can not be sure whether I understood it completely. The text itself was quite easy to read, but I think those who have implemented this protocol can say more accurately how well the protocol actually is described. To make it short: I think the specification is in quite nice state, and needs just some editorial fixes. Here are my comments on the draft: * At page 11, line 571: 'routeable' --> 'routable' (?) * Examples in Section 2 use mainly 'MB' in figures to represent NAT and/or FW nodes. However, I think the use is not always consistent. For example, in the figure 2 'FW' is used (and I think it is ok, because the text explicitly states that this example is about FW-only cases), but figure 9 in section 2.8 has 'MB's instead. If those middle boxes in scenario 2.8 may be also NATs, I think it would be nice to have it in text. If those middle boxes are always firewalls as I think the text states, then the figure should be changed. However, I think that the text is clear enough already, and the easy fix would be to change the 'FW' boxes to 'MB' boxes in the figure 2 :) * Section 3.1 Policy Rules, first paragraph: "For firewalls the policy rule usually consists of a 5-tuple, source/ destination addresses, transport protocol, and source/destination port numbers, plus an action, such as allow or deny." At least before reading the rest of the document, the word 'usually' seems a bit odd here. Do real alternative policy rules that do not contain the 5-tuple and action exist? I also think this sentence is not too clear, some kind of reformatting would be nice. For example, something like this (still having the word 'usually'): "For firewalls the policy rule usually consists of a 5-tuple and an action such as allow or deny. The information contained in the tuple includes source/destination addresses, transport protocol and source/destination port numbers." * In addition to comments Niklas already gave on figure 11 on page 24, I want to add that the figure and its legend do not match. There is no MB2 in the figure, and NF is present in the legend only in the text. As Niklas, I also think that it would be good to point out which node belongs to which network. * Page 28, last bullet: "the lease time of the NI's IP address. The chosen NATFW NSLP signaling session lifetime must be larger than the lease time, otherwise the IP address can be re-assigned to a different node. This node may receive unwanted traffic, although it never has requested a NAT/firewall configuration, which might be an issue in mobile environments. I just can not get the idea :) Should it be 'must be smaller than the lease time' ? If not, then I think some more text is needed. * Page 45, middle bullet: "and outbound messages MUST be forwarded further inbound." -> "and outbound messages MUST be forwarded further outbound." ? * Table 1 on page 50, the last row, capitalization: left column: "IPsec SPI", right column: "ipsec-SPI" Best Regards, Lauri -- Lauri Liuhto _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Sat Dec 15 08:15: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 1J3WrK-0007pq-P3; Sat, 15 Dec 2007 08:15:14 -0500 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1J3WrK-0007ox-3V for nsis-confirm+ok@megatron.ietf.org; Sat, 15 Dec 2007 08:15:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3WrJ-0007op-Og for nsis@ietf.org; Sat, 15 Dec 2007 08:15:13 -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 1J3WrI-00041d-Qn for nsis@ietf.org; Sat, 15 Dec 2007 08:15:13 -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; Sat, 15 Dec 2007 15:15:09 +0200 id 000805DA.4763D35D.000007BD Date: Sat, 15 Dec 2007 15:15:08 +0200 (EET) From: Jukka MJ Manner To: Roland Bless Subject: Re: [NSIS] Re: [NSIS Mobility draft] Updating from -07 to -08 In-Reply-To: <47596406.4050402@tm.uka.de> Message-ID: References: <20071105200346.2BAF.SANDA.TAKAKO@jp.panasonic.com> <47343862.5040206@tm.uka.de> <473C4D46.7020002@tm.uka.de> <47596406.4050402@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: 14582b0692e7f70ce7111d04db3781c8 Cc: Takako Sanda , "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, Me and Nuutti Varis, our GIST expert, had a chat yesterday and we tried to figure out what could be a good option. I think the problem lies elsewhere, it is not a (QoS) NSLP problem. When the IP address does not change (with MIP the e2e BU solves the problem), the point is that even if we would be able to send a message upstream, we still need the routing towards the MN to be in place. There must be some routing protocol in place that sets up e.g. a new host route to the MN when it has moved. This protocol must be coupled with GIST, i.e., GIST must be able to get a notification from a routing change. This would be a cross-over router having the MN state. Once the node gets a hint that the next peer for a MN has changed, it can reissue a RESERVE towards the new path. Thus, I would say that we should not invent an NSLP solution to a mobility management protocol issue. We just need to note that GIST must be able to see when routes change, to set up the new route on the downstream. rgs, Jukka On Fri, 7 Dec 2007, Roland Bless wrote: > Hi Jukka, > > see comment inline. > > Jukka MJ Manner wrote: > > On Thu, 15 Nov 2007, 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. > > > > > > [JM]: If the CN requests reliable or secure transport, GIST will send an > > I don't know what it has to do with reliable and secure transport? > > > empty Query to the next, set up routing state, and only then send the > > NOTIFY. This will hit QNE4. Now QNE4 does not know about the SID in > > question, so should it send an error back, or forward the message in the > > same way towards the CN? > > Please read the above text again. The problem lies in the fact that > you have to send a GIST-Query _upstream_ and no routing state exists > yet. So even if an MA exists, it cannot be used. > This could only be done with _upstream_ Q-mode encapsulation, but this > is definitely not applicable in a general way. > > > [JM]: Yet, also with unreliable/unsecure transport, what would happen, if > > QNE4 would actually decide not to peer? It sees a NOTIFY for a SID it > > doesn't know about, so it could as well forward the message further, > > right? The message will eventually hit a QNE (or eventually the CN), who > > then knows about the SID. > > See above. The GIST Query has to find its way first. This is the real > problem. > > Regards, > Roland > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Sun Dec 16 22:50: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 1J46zl-0002qm-TB; Sun, 16 Dec 2007 22:50:21 -0500 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1J46zk-0002mH-HQ for nsis-confirm+ok@megatron.ietf.org; Sun, 16 Dec 2007 22:50:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J46zj-0002gg-PD for nsis@ietf.org; Sun, 16 Dec 2007 22:50:19 -0500 Received: from smtp.mei.co.jp ([133.183.100.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J46zi-0000Mo-ME for nsis@ietf.org; Sun, 16 Dec 2007 22:50:19 -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-maile12) with ESMTP id lBH3o8wx010104; Mon, 17 Dec 2007 12:50:08 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx2) with ESMTP id lBH3o7I11076; Mon, 17 Dec 2007 12:50:07 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/whitesox) with SMTP id lBH3o8615038; Mon, 17 Dec 2007 12:50:08 +0900 (JST) Received: from [127.0.0.1] ([10.81.113.75]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.1830); Mon, 17 Dec 2007 11:49:42 +0800 Message-ID: <4765F1D5.9040701@sg.panasonic.com> Date: Mon, 17 Dec 2007 11:49:41 +0800 From: Hong Cheng User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Jukka MJ Manner 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> <47596406.4050402@tm.uka.de> In-Reply-To: X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Dec 2007 03:49:42.0416 (UTC) FILETIME=[DB3A4900:01C8405F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 Cc: Roland Bless , "nsis@ietf.org" , 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 Jukka, Generally, I would agree with you that the NSLP should not be used to replace the mobility management protocol. Regarding your analysis, I would like to clarify some points. Please see inline: Jukka MJ Manner wrote: > Hi, > > Me and Nuutti Varis, our GIST expert, had a chat yesterday and we tried to > figure out what could be a good option. I think the problem lies > elsewhere, it is not a (QoS) NSLP problem. > > When the IP address does not change [Cheng] I think this is a different scenario than what we were discussing earlier. The case seems more of a re-routing issue than a mobility issue (which belongs to a different section). GIST should have dealt with the normal re-routing case. In case there are other protocols involved, different considerations would apply (see below). > (with MIP the e2e BU solves the problem), [Cheng] The MIP BU should solve the routing aspect of the problem. Possible NSIS operation sequence has been detailed in several earlier emails. However, as Roland pointed out, the description in the draft might be insufficient about the NSIS mechanism, e.g. the GIST API to inform NSLP of the new MRI after change of MIP Binding Cache, etc. > the point is that even if we would be able to send a message > upstream, we still need the routing towards the MN to be in place. There > must be some routing protocol in place that sets up e.g. a new host route > to the MN when it has moved. This protocol must be coupled with GIST, > i.e., GIST must be able to get a notification from a routing change. This > would be a cross-over router having the MN state. Once the node gets a > hint that the next peer for a MN has changed, it can reissue a RESERVE > towards the new path. [Cheng] Can you share a bit more on what is the use case/scenario you have in mind? (when MN moves but IP address does not change) Usually, to achieve this, some sort of tunneling needs to be used, e.g. network based local mobility management. If this is the case, the nodes involved would be totally different, and the analysis should also be different. It does not have to be the crossover router that issues the RESERVE. The tunnel signaling interaction must be considered here as well. cheers Cheng Hong > Thus, I would say that we should not invent an NSLP solution to a mobility > management protocol issue. We just need to note that GIST must be able to > see when routes change, to set up the new route on the downstream. > > rgs, > Jukka > > On Fri, 7 Dec 2007, Roland Bless wrote: > >> Hi Jukka, >> >> see comment inline. >> >> Jukka MJ Manner wrote: >>> On Thu, 15 Nov 2007, 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. >>> >>> [JM]: If the CN requests reliable or secure transport, GIST will send an >> I don't know what it has to do with reliable and secure transport? >> >>> empty Query to the next, set up routing state, and only then send the >>> NOTIFY. This will hit QNE4. Now QNE4 does not know about the SID in >>> question, so should it send an error back, or forward the message in the >>> same way towards the CN? >> Please read the above text again. The problem lies in the fact that >> you have to send a GIST-Query _upstream_ and no routing state exists >> yet. So even if an MA exists, it cannot be used. >> This could only be done with _upstream_ Q-mode encapsulation, but this >> is definitely not applicable in a general way. >> >>> [JM]: Yet, also with unreliable/unsecure transport, what would happen, if >>> QNE4 would actually decide not to peer? It sees a NOTIFY for a SID it >>> doesn't know about, so it could as well forward the message further, >>> right? The message will eventually hit a QNE (or eventually the CN), who >>> then knows about the SID. >> See above. The GIST Query has to find its way first. This is the real >> problem. >> >> Regards, >> Roland >> > > > _______________________________________________ > 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 Dec 17 14:10:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4LM9-000118-TZ; Mon, 17 Dec 2007 14:10:25 -0500 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1J4LM7-000106-WA for nsis-confirm+ok@megatron.ietf.org; Mon, 17 Dec 2007 14:10:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4LM7-0000zy-KV for nsis@ietf.org; Mon, 17 Dec 2007 14:10:23 -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 1J4LM5-0005MA-Ed for nsis@ietf.org; Mon, 17 Dec 2007 14:10: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; Mon, 17 Dec 2007 21:10:20 +0200 id 00080620.4766C99C.00000B0C Date: Mon, 17 Dec 2007 21:10:20 +0200 (EET) From: Jukka MJ Manner To: Hong Cheng Subject: Re: [NSIS] Re: [NSIS Mobility draft] Updating from -07 to -08 In-Reply-To: <4765F1D5.9040701@sg.panasonic.com> Message-ID: References: <20071105200346.2BAF.SANDA.TAKAKO@jp.panasonic.com> <47343862.5040206@tm.uka.de> <473C4D46.7020002@tm.uka.de> <47596406.4050402@tm.uka.de> <4765F1D5.9040701@sg.panasonic.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21 Cc: Roland Bless , "nsis@ietf.org" , 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, a few answers below. Jukka On Mon, 17 Dec 2007, Hong Cheng wrote: > Hi Jukka, > > Generally, I would agree with you that the NSLP should not be used to > replace the mobility management protocol. > > Regarding your analysis, I would like to clarify some points. Please see > inline: > > Jukka MJ Manner wrote: > > Hi, > > > > Me and Nuutti Varis, our GIST expert, had a chat yesterday and we tried to > > figure out what could be a good option. I think the problem lies > > elsewhere, it is not a (QoS) NSLP problem. > > > > When the IP address does not change > > [Cheng] I think this is a different scenario than what we were > discussing earlier. The case seems more of a re-routing issue than a > mobility issue (which belongs to a different section). GIST should have > dealt with the normal re-routing case. In case there are other protocols > involved, different considerations would apply (see below). > > > (with MIP the e2e BU solves the problem), > > [Cheng] The MIP BU should solve the routing aspect of the problem. > Possible NSIS operation sequence has been detailed in several earlier > emails. However, as Roland pointed out, the description in the draft > might be insufficient about the NSIS mechanism, e.g. the GIST API to > inform NSLP of the new MRI after change of MIP Binding Cache, etc. [JM]: This may be so, I haven't thought about how the GIST API fits with MIP. I trust Roland that there is a problem. > > > the point is that even if we would be able to send a message > > upstream, we still need the routing towards the MN to be in place. There > > must be some routing protocol in place that sets up e.g. a new host route > > to the MN when it has moved. This protocol must be coupled with GIST, > > i.e., GIST must be able to get a notification from a routing change. This > > would be a cross-over router having the MN state. Once the node gets a > > hint that the next peer for a MN has changed, it can reissue a RESERVE > > towards the new path. > > [Cheng] Can you share a bit more on what is the use case/scenario you > have in mind? (when MN moves but IP address does not change) Usually, to > achieve this, some sort of tunneling needs to be used, e.g. network > based local mobility management. If this is the case, the nodes involved > would be totally different, and the analysis should also be different. > It does not have to be the crossover router that issues the RESERVE. The > tunnel signaling interaction must be considered here as well. [JM]: You could per-host forwarding within a local domain based on tunnels, or you could update just per-host routes in the domain routers. Both have their interactions with GIST. I don't think we should try to figure out all possible local (micro) mobility schemes and see how they would work. Just the general considerations are enough, IMO. > > cheers > > Cheng Hong > > > > > Thus, I would say that we should not invent an NSLP solution to a mobility > > management protocol issue. We just need to note that GIST must be able to > > see when routes change, to set up the new route on the downstream. > > > > rgs, > > Jukka > > > > On Fri, 7 Dec 2007, Roland Bless wrote: > > > >> Hi Jukka, > >> > >> see comment inline. > >> > >> Jukka MJ Manner wrote: > >>> On Thu, 15 Nov 2007, 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. > >>> > >>> [JM]: If the CN requests reliable or secure transport, GIST will send an > >> I don't know what it has to do with reliable and secure transport? > >> > >>> empty Query to the next, set up routing state, and only then send the > >>> NOTIFY. This will hit QNE4. Now QNE4 does not know about the SID in > >>> question, so should it send an error back, or forward the message in the > >>> same way towards the CN? > >> Please read the above text again. The problem lies in the fact that > >> you have to send a GIST-Query _upstream_ and no routing state exists > >> yet. So even if an MA exists, it cannot be used. > >> This could only be done with _upstream_ Q-mode encapsulation, but this > >> is definitely not applicable in a general way. > >> > >>> [JM]: Yet, also with unreliable/unsecure transport, what would happen, if > >>> QNE4 would actually decide not to peer? It sees a NOTIFY for a SID it > >>> doesn't know about, so it could as well forward the message further, > >>> right? The message will eventually hit a QNE (or eventually the CN), who > >>> then knows about the SID. > >> See above. The GIST Query has to find its way first. This is the real > >> problem. > >> > >> Regards, > >> Roland > >> > > > > > > _______________________________________________ > > 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 Dec 19 09:39: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 1J505H-0000rK-1h; Wed, 19 Dec 2007 09:39:43 -0500 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1J505G-0000rF-1a for nsis-confirm+ok@megatron.ietf.org; Wed, 19 Dec 2007 09:39:42 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J505F-0000r7-M8 for nsis@ietf.org; Wed, 19 Dec 2007 09:39:41 -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 1J505E-0003Ue-Sy for nsis@ietf.org; Wed, 19 Dec 2007 09:39:41 -0500 Received: from sbz-31.cs.helsinki.fi (sbz-31.cs.helsinki.fi [128.214.9.99]) (AUTH: PLAIN cs-relay, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Wed, 19 Dec 2007 16:39:39 +0200 id 00070459.47692D2B.000054C7 Received: by sbz-31.cs.helsinki.fi (Postfix, from userid 52520) id 6AB37153B2; Wed, 19 Dec 2007 16:39:39 +0200 (EET) Received: from localhost (localhost [127.0.0.1]) by sbz-31.cs.helsinki.fi (Postfix) with ESMTP id 665681405E; Wed, 19 Dec 2007 16:39:39 +0200 (EET) Date: Wed, 19 Dec 2007 16:39:39 +0200 (EET) From: Teemu Huovila To: Martin Stiemerling Subject: Re: [NSIS] WGLC: draft-ietf-nsis-nslp-natfw-16.txt In-Reply-To: <57BCC14C-53FD-4B9C-8EEE-C2D5D78B0B1F@netlab.nec.de> Message-ID: References: <57BCC14C-53FD-4B9C-8EEE-C2D5D78B0B1F@netlab.nec.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Cc: nsis 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 I have read the draft and I do not have any major objections. I think it is very extensive and considers, in great detail, all necessary aspects of the protocol. I am very sorry, that my comments are overdue. I hope they can still be of some use for the working group. This was my first review of the draft and it took much longer to read, than I had estimated. I have divided my comments into two categories. One group of regular nits and another of more insignificant details. I include the comments below. Before nits I will just add my 2 cents to the 5-tuple/policy rule discussion. As mentioned by Lauri, it is defined somewhat unclearly on page 20. It is, however, in my opinion defined more clearly on page 10. It is also worth to note, that the first definition uses "and", where the second uses '/'. ----- nits: * page 6, paragraph 2: "This message .... intercepts these messages," -> *this message* * page 7: "If the data receiver resides in a private addressing realm or firewall" --> *behind a* firewall ? * page 8: the second sentence in the definition of "Firewall" is superfluous. * page 9: In bullet about NATFW NSLP peer the term "NSIS adjacency" is vague. I suggest "NSLP adjacency" (or GIST/NTLP adjacency, if that was intended). [2] defines GIST adjacency and "adjacent peer" * page 25, 3.2.1, 3rd bullet: What are "inbound NATFW peers"? Does "inbound" here mean towards the NI? (it became clear later, in section 3.7.5) * page 30, 2nd paragraph: Error conditions are quite correctly defined for both too low and too high session lifetimes, but the text states: "The forwarders MUST accept the granted NATFW NSLP signaling session lifetime, as long as this value is less than or equal to the acceptable value." later "lower or equal" is mentioned. Should these maybe be "if the lifetime value is within the acceptable range", or something similar? If not, I have great trouble understanding this. How are NFs on the path towards NR informed, if a node rejects the lifetime suggested in the RESPONSE? A NOTIFY with the same error code? Can NOTIFY be sent towards NR? Page 66 says "The NOTIFY message is routed towards the NI..." Im very sorry, if I have overlooked some central detail about this. * page 33, 5th bullet, sub-bullet: "If no matching reservation can be found, i.e. no reservation has been made in advance, the NSLP MUST return an error RESPONSE of class 'Signaling session failure' (0x6) with response code 'No reservation found matching the MRI of the CREATE request' (0x03) MUST be generated." --> "MUST be generated" is superfluous? (already "MUST return") * page 39-40: processing of EXT on NI(page 39) says: "When the data sender's IP address is not known, the NI+ MUST NOT include a NATFW_DTINFO object." later, on page 40 it is stated: "The edge-NAT or any other NAT MUST reject EXT messages not carrying a NATFW_DTINFO object..." Was the "LE-MRM, DS unknown etc" case DTINFO object added by somebody in the middle? A NAT before the edge-NAT? But arent those included in "or any other NAT"? Also, NATFW_DTINFO is specified as mandatory, in 4.3.2 (page 64) Maybe I have overlooked something here as well. The section, as Niklas mentioned, is not very easy to read. * page 46: "This proxy mode of operation must terminate the NATFW NSLP signaling as topologically close to the terminal for which it is proxying and proxy all messages." --> *as possible* or something similar seems to be missing from that sentence. (It only says "as close..." ) Also, what does this sentence mean? All proxy mode signaling is terminated at the NI+/NI side edge-device, if I understood the section correctly. ------------------------ insignificant/uncertain: * page 7: "one or other" --> one or *the* other ? * page 9: The "SDA" did not become clear to me until page 36( with dr, dr+ etc). Though admittedly it is difficult to write a clear terminology section, if no knowledge can be expected from the reader, i.e. me. :) * page 11: "on the data path from... and the external network" "and" could be *to*? (i.e. on the data path from ...to) or change "from" to *between*? * page 22, bullet 4: "Ni" -> *NI* * page 31, 3rd paragraph: "NSLP MUST update its stored state accordingly, if permitted by all security checks (see Section 3.6), and stores" --> *store*? * page 53: "The NSLP header is carried in all NATFW NSLP message and objects... " --> *messages* * page 63: "Objects defined in this memo carry always the flag combination" --> *always carry* ? * page 80: "The rest of this section is giving" --> *gives* ? * page 80: "It necessary to differentiate" --> It *is* best regards, Teemu Huovila -- Teemu Huovila _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Dec 19 09:58:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J50Nj-0005TY-VY; Wed, 19 Dec 2007 09:58:47 -0500 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1J50Nj-0005TR-0p for nsis-confirm+ok@megatron.ietf.org; Wed, 19 Dec 2007 09:58:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J50Ni-0005TJ-NJ for nsis@ietf.org; Wed, 19 Dec 2007 09:58:46 -0500 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J50Ng-0007Zp-VC for nsis@ietf.org; Wed, 19 Dec 2007 09:58:46 -0500 Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by iramx2.ira.uni-karlsruhe.de with esmtps id 1J50Na-0004WV-79; Wed, 19 Dec 2007 15:58:41 +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 1J50NZ-0004I3-1y; Wed, 19 Dec 2007 15:58: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 E749A2FC00C; Wed, 19 Dec 2007 15:58:36 +0100 (CET) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1J50NY-0008Uh-Km; Wed, 19 Dec 2007 15:58:36 +0100 Message-ID: <4769319C.8010007@tm.uka.de> Date: Wed, 19 Dec 2007 15:58: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: Jukka MJ Manner 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> <47596406.4050402@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: irams1.ira.uni-karlsruhe.de X-ATIS-Checksum: v3zoCAcc32ckk X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: "nsis@ietf.org" , 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 Jukka, Jukka MJ Manner wrote: > Me and Nuutti Varis, our GIST expert, had a chat yesterday and we tried to > figure out what could be a good option. I think the problem lies > elsewhere, it is not a (QoS) NSLP problem. Yep. We (Martin Roehricht, Max Laier and me) also discussed mobility scenarios a lot in the past days and came to the conclusion that it would be good to solve mobility issues at GIST layer as much as possible since it is the appropriate place for message routing issues. > When the IP address does not change (with MIP the e2e BU solves the > problem), the point is that even if we would be able to send a message > upstream, we still need the routing towards the MN to be in place. There > must be some routing protocol in place that sets up e.g. a new host route > to the MN when it has moved. This protocol must be coupled with GIST, > i.e., GIST must be able to get a notification from a routing change. This > would be a cross-over router having the MN state. Once the node gets a > hint that the next peer for a MN has changed, it can reissue a RESERVE > towards the new path. > > Thus, I would say that we should not invent an NSLP solution to a mobility > management protocol issue. We just need to note that GIST must be able to > see when routes change, to set up the new route on the downstream. The problem is that we need some linkage between the data path and the control path (QoS NSLP). Usually path-coupled signaling tries to solve this, but if no signaling message for the new flow is generated, path-coupled signaling would not help. I see the following setups (assuming that both ends support QoS NSLP): - Application is mobility-aware and tries to manage mobility itself (no use of MobileIP, but e.g., SIP mobility) => no problem then because, RESERVE and QUERY message can be generated as soon as the MN moves. The CN can be notified by some application level signaling protocol. - MN and CN are using MobileIP and route optimization => mobility events should be reported to GIST which in turn should notify the affected NSLPs. They can initiate new RESERVE/QUERY messages upon such a NetworkNotification. This works for all four cases. - MN uses MobileIP, CN is not using MobileIP or does not support RO. => Then the home agent must split the reservations and could act upon receiving binding updates by re-initiating reservations for the tunnel to the MN as in the previous case. Regards, Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Dec 20 16:52: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 1J5TJO-0001T4-Ug; Thu, 20 Dec 2007 16:52:14 -0500 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1J5TJN-0001De-LN for nsis-confirm+ok@megatron.ietf.org; Thu, 20 Dec 2007 16:52:13 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5TJN-00018B-5n for nsis@ietf.org; Thu, 20 Dec 2007 16:52:13 -0500 Received: from amailer.gwdg.de ([134.76.10.18]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J5TJM-0004Ct-Cm for nsis@ietf.org; Thu, 20 Dec 2007 16:52:13 -0500 Received: from p5b03cc6f.dip0.t-ipconnect.de ([91.3.204.111] helo=[192.168.0.183]) by mailer.gwdg.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1J5TJL-0005rf-KB for nsis@ietf.org; Thu, 20 Dec 2007 22:52:11 +0100 Message-ID: <476AE403.7030005@cs.uni-goettingen.de> Date: Thu, 20 Dec 2007 22:52:03 +0100 From: Xiaoming Fu User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: nsis Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated: Id:xfu X-Spam-Level: - X-Virus-Scanned: (clean) by exiscan+sophie X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Subject: [NSIS] CFP: IEEE Network Special Issue on Implications and Control of Middleboxes in the Internet 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 ... please find below a CFP which may be related to NSIS. our apologies if you receive multiple copies. --------------------------------------------------------- Call for Papers IEEE Network Magazine Special Issue on Implications and Control of Middleboxes in the Internet Important Dates =============== Manuscript Submission Due: March 1, 2008 Acceptance Notification: June 1, 2008 Final Manuscript Due: July 15, 2008 Special Issue Publication Date: September/October 2008 Call for Papers =============== Network Address Translators (NAT) and IP firewalls have been introduced to the Internet some time ago, and over the time become an integral part of the Internet architecture. Moreover, there are also other types of middleboxes, such as Virtual Private Network (VPN) gateways, Application Layer Gateways (ALG), Performance Enhancing Proxies (PEP) and web proxies. These intermediary boxes perform functions different from normal IP packet treatment, which can even change the content of packets or do rerouting of IP packets. There have been diverse views on the value of middleboxes. Some believe that middleboxes introduce problems for network applications as well as challenges to the traditional end-to-end Internet architecture. These issues range, for instance, but not limited to, from naming and addressing of nodes behind NATs, directionality of communication establishment, and performance impairments. On the other hand, many administrators and operators see the middleboxes represent an important part for their network operations. For example, firewalls are widely deployed with the intention of securing enterprise, campus and home networks, so as to block attacks to nodes or keep nodes from sending malicious traffic. The Internet community has acknowledged the emergence of the middleboxes and developed middlebox control and coordination protocols that allow end hosts (or application proxies) to learn about the presence of middleboxes and communicate their needs (i.e. required packet treatment) to those devices. A number of middlebox control protocols, such as UPnP, MIDCOM and STUN, have been developed over the years and are partially used in current deployments. The papers in this special issue will focus on the state-of-the-art research in various aspects of middleboxes and middlebox control mechanisms, which help to understand their impact to the Internet architecture and network operations, and how they can be further integrated, or leveraged for different purposes, such as load balancing and mobile network environments, among the others. Specifically, within the aforementioned context in Internet middleboxes and their control mechanisms, the special issue will present tutorials, surveys and original research articles (written in a tutorial manner readable by non-specialists) that cover the following subjects, but not limited to: * Middlebox-supported network architectures vs. other Internet evolution alternatives (e.g., IPv6) * Design and/or performance evaluation of middlebox software architectures * Control and coordination across middleboxes and their traversal mechanisms * Security, including authentication, authorization and accounting issues with middlebox control/traversal mechanisms * Scalability and performance studies of middlebox control/traversal mechanisms * Deployment scenarios and case studies (corporate, ISP, content providers, mobile environments etc.) based on middleboxes * Interaction and implications with other network protocols and components * Interaction and implications with end-to-end applications and services * Related standardization efforts Manuscript Submission ===================== With regard to both the content and formatting style of the submissions, prospective contributors must follow the IEEE Network guidelines for authors that can be found at http://www.comsoc.org/pubs/net/ntwrk/authors.html. Submitted papers must be original and must not be under current consideration for publication in other venues. Authors should submit a PDF format of their complete papers via http://www.edas.info/newPaper.php?c=6198. Guest Editors ============= Prof. Xiaoming Fu Institute for Computer Science University of Goettingen Goettingen Germany Email: fu@cs.uni-goettingen.de Martin Stiemerling NEC Europe Laboratories Network Research Division Heidelberg Germany Email: stiemerling@netlab.nec.de Prof. Henning Schulzrinne Department of Computer Science Columbia University New York, NY USA Email: hgs@cs.columbia.edu _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Dec 21 10:57: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 1J5kFz-0006e9-5f; Fri, 21 Dec 2007 10:57:51 -0500 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1J5kFx-0006Sn-Dn for nsis-confirm+ok@megatron.ietf.org; Fri, 21 Dec 2007 10:57:49 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5kFx-0006Sc-1c for nsis@ietf.org; Fri, 21 Dec 2007 10:57:49 -0500 Received: from u-173-c156.cs.uni-tuebingen.de ([134.2.173.156] helo=smtp.cs.uni-tuebingen.de) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J5kFv-0004aS-FS for nsis@ietf.org; Fri, 21 Dec 2007 10:57:48 -0500 Received: from u-172-c174.cs.uni-tuebingen.de ([134.2.172.174]) by smtp.cs.uni-tuebingen.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.60) (envelope-from ) id 1J5kFp-0002Ah-64; Fri, 21 Dec 2007 16:57:41 +0100 Message-ID: <476BE274.9030307@uni-tuebingen.de> Date: Fri, 21 Dec 2007 16:57:40 +0100 From: Ali Fessi User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Martin Stiemerling Subject: Re: [NSIS] WGLC: draft-ietf-nsis-nslp-natfw-16.txt References: <57BCC14C-53FD-4B9C-8EEE-C2D5D78B0B1F@netlab.nec.de>

In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 17e5edc4dfd335965c1d21372171c01c Cc: nsis 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 Dear Martin and NATFW NSLP co-authors, I have read the draft and have only few comments: - First, I think the draft needs some editorial polishing and needs to become a bit more reader-friendly where possible. As already mentioned in some emails before, some sections are difficult to understand even with background knowledge in NATFW NSLP. Some more cross references to different sections within the draft itself or to sections in other drafts considered as background knowledge, e.g. GIST, could be helpful to make life easier for the reader. - The solution described for the scenario "2.6 Both End Hosts Behind Same NAT" is not efficient. I guess you know what I am talking about here. All the traffic will go through the external gateway. I remember we had some discussions with Cedric about 4 years ago about using something like ICE (at that time ICE was pretty new, I think) in order to discover whether the peer is within the same network in order to perform direct signaling and route the traffic directly between the peers. - The text in "C.4. NSLP Handling of Twice-NAT" is a bit confusing. e.g. "The dynamic configuration of twice-NATs requires application level support, as stated in Section 2.5. The NATFW NSLP cannot be used for configuring twice-NATs if application level support is needed." does this mean that the NATFW NSLP does not supports twice-NATs and it is left to application layer support? or "The NSLP is probably able to traverse the twice-NAT" (I guess with "probably" here, you mean it depends on whether the twice-NAT is NATFW NSLP aware or not. This could be clarified better). - The text about CMS in the security section is a bit confusing: "Additionally, security protection of certain payloads may be required between non-neighboring signaling entities and the Cryptographic Message Syntax (CMS) [14] might be a potential solution. Payload protection using CMS is not described in this document." This sounds like: "you could use CMS, but we are not sure if it will solve your problems, or we don't know even how to use it here, and which message parts you will need to protect". I am not sure here, but I think that if you use CMS, you will use it to protect the authorizations tokens, so the use of CMS could be moved the NSLP authorization draft. What do you think? Otherwise, I hope that the effort of several years will be fruiful and that we will have a successful protocol! :-) Cheers and Merry Christmas, Ali Martin Stiemerling wrote: > Hi Jukka, > > Thanks a lot for your review! I will go through the comments today and > come back if I need more information. > > Thanks, > > Martin > > Am 04.12.2007 um 23:06 schrieb Jukka MJ Manner: > >> >> Hi, >> >> I have reviewed that draft. I don't have any major objections to the >> document, just some miscellaneous comments and clarification requests. >> >> Here goes: >> >> - p.6, bullet 1: at this point in the document, it is not clear to the >> reader what the NSIS initiator/receiver are. Propose to use simpler >> terminology at this early phase in the intro. >> >> - p.6, end of page: propose to clearly say wo sends which message, e.g.: >> >> "CREATE message: send by the data sender for..." >> >> "EXTERNAL message: used by data receiver to ..." >> >> Related comment: why abbreviate EXTERNAL to "EXT"? >> * None of the other message are abbreviated >> * EXTERNAL is as long a word as "RESPONSE" (both abbreviated?) >> >> Suggest to drop the EXT-term >> >> Related to the above the document presents over and over again that >> EXTERNAL is EXT ("EXTERNAL (EXT)") and is a bit inconsistent in when to >> use EXTERNAL and when just EXT (both used here and there). >> >> - p.7.: s/body of the document, covers/body of the document cover/ >> >> - p.23: s/inSection/in Section/ >> >> - p.27: "if the node runs _it_ garbage collection cycle."? >> >> - p.27: "appropriate error of class 'Protocol error' (0x1)": 0x1 is >> Informational, ox3 is protocol error. >> >> - p.32: "is thus managed NSLP hop-by-hop"? >> >> - p.41: "session created by REA."? >> >> - p.41: "using CREATE Section 3.7.1" > "(see Section 3.7.1)"? >> >> - p.43: "if the like to aggregate"? >> >> - p.46, whole Section 3.7.6.1: should NR be actually DR? Including Figure >> 18? >> >> - P.46-47, Section 3.7.6.1: I don't really get this operation at all. >> Sounds a bit complex to have the EXT-session trigger a CREATE-session. >> Maybe some more discussion/description is needed to open up the >> scenario. Also, the NATFW_NONCE sounds a bit wierd, somehow. In the QoS >> NSLP, we have the same functionality, but it is called "session >> binding" >> and uses a similar object where the content is the SID of the primary >> flow. Achieves the same thing, and you can be sure there are no >> collisions with nonces. Does the value need to be a random value? Or >> could you perhaps re-use the QoS NSLP object since we have common >> object >> repository anyway? The concept in the QoS NSLP session binding is that >> the secondary session is valid as long as the primary session is. >> >> - Related to the above, p.48 (middle): if you have the "internal" >> CREATE+NONCE session and also get the e2e CREATE session, do you run >> both simultaneously? Or do you kill one of them? I guess you can't kill >> the EXT-session, since you need the forwarding at the NAT? Perhaps this >> needs some more description. >> >> - p.49: "back to NI according [to] the situation" >> >> - p.49: "NSLP node and the of the policy rule."? >> >> - p.51: Do the route changes really work as you describe? This may need >> some thinking, and probably add text to the mobility draft. >> >> - p.51: s/and sends it/and send it/ >> >> - Whole Section 4: the text talks about error cases and mandating "MUST" >> to send various error messages? If you must always send error messages, >> isn't this a use case for DoS attacks? I guess some words about when to >> send error messages would be needed (rate limiting, etc.). >> >> - p.57 (top of page): "Further version of this memo may allow other >> values >> for the 'sub_ports' field." I think suggestions like this should not be >> in a draft going to WGLC. >> >> - p.58-60: there are a lot of error codes. Should somewhere be written >> how >> and when these are used? Some of these are quite clear, but e.g. I >> don't understand Permanent failures 0x03, 0x05 and 0x06. Where would >> these be used? >> >> - p.61, Section 4.2.7: where is this object used actually? text says >> "possibly needed", sounds a bit wierd for a draft in WGLC. Is it >> needed, >> and where/when/why? Should this be also available for IPv6? >> >> - p.62, 3rd line: "according [to] these rules:" >> >> - p.64, Sections 4.3.1 and 4.3.2: what are these "(O)" and "(M)"? >> Optional >> and mandatory? Say it clearly. >> >> - p.64, Section 4.3.2: point c) as use case for EXT: you lost me here? >> Was >> this presented earlier? Actually, in general about EXT, should it >> always >> have the proxy bit P=1? What happens if I send an EXT message towards >> the DS with P=0? Does the EXT reach the DS? What happens then? >> >> - p.67: "In Section 5.1 we describe [how] the ..." >> >> - p.73: s/located to the/located at the/ >> >> >> >> Jukka > > 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 > > > ------------------------------------------------------------------------ > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis -- Ali Fessi Computer Networks and Internet University of Tuebingen, Germany Phone: +49 7071 29-70576 / Fax: +49 7071 29-5220 EMail: ali.fessi@uni-tuebingen.de Web: http://net.informatik.uni-tuebingen.de/~fessi/ _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis