From nsis-bounces@ietf.org Mon Aug 01 01:59:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzTKq-00060J-O1; Mon, 01 Aug 2005 01:59:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzTKo-00060B-DI for nsis@megatron.ietf.org; Mon, 01 Aug 2005 01:59:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12932 for ; Mon, 1 Aug 2005 01:59:28 -0400 (EDT) Received: from smtp2.mei.co.jp ([133.183.129.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzTqw-00052q-DE for nsis@ietf.org; Mon, 01 Aug 2005 02:32:47 -0400 Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp2.mei.co.jp (8.12.10/3.7W/jazz) with ESMTP id j715wma8003153; Mon, 1 Aug 2005 14:58:48 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx1) with ESMTP id j715wmJ23529; Mon, 1 Aug 2005 14:58:48 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/dodgers) with SMTP id j715wmo06997; Mon, 1 Aug 2005 14:58:48 +0900 (JST) Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [NSIS] Draft on NSIS Operation Over IP Tunnels X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Mon, 1 Aug 2005 13:56:24 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BD4B1E17@pslexc01.psl.local> Thread-topic: [NSIS] Draft on NSIS Operation Over IP Tunnels Thread-index: AcWV7T4LKpalQjkgQJCRRVO6TT204wAaddrw From: "Cheng Hong" To: "Charles Shen" , "Takako Sanda" , "Hancock, Robert" , , X-Spam-Score: 0.9 (/) X-Scan-Signature: 4ad60914b71abd47c285b3604f8c8304 Cc: Toyoki Ue , Qijie Huang 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="===============1380101558==" Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. --===============1380101558== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5965D.C0209758" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5965D.C0209758 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi Charles, =20 > Wouldn't the MRI change every time you have an address change? Does this draft keep the assumption that MRI and Flow ID are tied togher?=20 =20 The draft keeps the assumption that MRI and Flow ID are tied together. The sentence you quoted is trying to state the fact that if the Filter List is employed, the Flow ID's dependency on the address information can be relaxed, and it would result in less state management, e.g. new path discovery. Some points about this was discussed in the mailing list after last Interim meeting. We should have expanded the text to explain it.=20 =20 > Also it seems to me we will have one session with one SESSION ID and possibly multiple FLOW IDs, then each FLOW ID may have multiple FILTER SPECS?=20 > Please correct me if I misunderstood it.=20 =20 You are correct that there may be multiple Flows within one Session, according to the definition of Session and Flow in NSIS, e.g. due to mobility, multihoming, and host decisions. How these Flows relate to each other is the question addressed in draft draft-sanda-nsis-path-type-02.txt. It talks about a logic Path Type that can be used to correlate certain flows within a Session (instead of implicitly assuming all the Flows within the Session are bound together). In this aspects, it related to the intra-session association idea in your draft draft-shen-nsis-tunnel-00.txt, although looking at a separate problem. It is trying to solve those mobility related issues.=20 =20 =20 Also, within a same flow, there may need several Filter Specs to accurately reflect the addresses involved. This is the issue address in the draft-cheng-nsis-flowid-issues-01. Several scenarios/use cases were described to illustrates the needs for this. =20 > Indeed, I feel that the FILTER_LIST approach with its ADD action might serve a similar function as ASSOCIATE_FLOW_SESSION. However, the action name might=20 > need to be made more specific. i.e, to indicate whether this is for NSIS-tunnel handling or for other purposes. =20 =20 I have the same feeling here. Especially for a aggregated case, the Filter_List approach may be useful to handle the possible disagreement between Flow ID and FCI. I agree that to use it for that purpose, some modifications is necessary. Takako, one of the co-author of the draft, will attend the IETF meeting this week. So, some face to face discussion may be able to sort out the details. =20 cheers =20 Cheng Hong =20 =20 =20 =20 =20 =20 =20 ________________________________ From: Charles Shen [mailto:charles@cs.columbia.edu]=20 Sent: Monday, August 01, 2005 12:33 AM To: 'Hancock, Robert'; john.loughney@nokia.com; Cheng Hong; nsis@ietf.org Subject: RE: [NSIS] Draft on NSIS Operation Over IP Tunnels =09 =09 Hi Robert, =20 I see them as related yet slightly different issues. =20 According to my understanding, generally Flow (packet) Classfication Information is assumed to be derived from the flow MRI. draft-cheng-nsis-flowid-issues-01.txt discussed cases where this might not be sufficient and it might be desired to separate the flow classification information from MRI.=20 =20 In fact there is a related case in the NSIS tunneling analysis. Packets inside the tunnel carry tunnel MRI in the outer header and the e2e MRI in the innner header. The separation of the tunnel MRI and tunnel flow classification information will occur if flows inside the tunnel are to be classified based on the inner header. (Although note that our chosen approach is to perform tunnel flow classification based on the outer header due to the fact that most routers won't look at the inner header.) =20 =20 Two basic solutions to the above issue seem to be either extending the current MRI definition or having a separate flow classification information object. The Filter_List represents one of the latter approaches. I have a few questions about this Filter_List mechanism and would appreciate if the authors of draft-cheng-nsis-flowid-issues-01.txt can clarify. Sec. 6.1 says:=20 =20 Since the NTLP does not need to modify the Flow ID or MRI every time the address changes, the state maintained on the NSIS nodes will be more stable, and thus requires less operation in updating.=20 =20 Wouldn't the MRI change every time you have an address change? Does this draft keep the assumption that MRI and Flow ID are tied togher? Also it seems to me we will have one session with one SESSION ID and possibly multiple FLOW IDs, then each FLOW ID may have multiple FILTER SPECS? Please correct me if I misunderstood it.=20 =20 =20 draft-shen-nsis-tunnel-00.txt discusses intra-session associaiton, i.e. to associate different FLOW IDs (for flow classification) with the same SESSION ID. The association may be done for different purposes, such as supporting NSIS operation over IP tunnels. The association can be achieved in different ways given different assumptions about the relationship between flow classification information and MRI. Indeed, I feel that the FILTER_LIST approach with its ADD action might serve a similar function as ASSOCIATE_FLOW_SESSION. However, the action name might need to be made more specific. i.e, to indicate whether this is for NSIS-tunnel handling or for other purposes. =20 Thanks. =09 Charles=20 -----Original Message----- From: Hancock, Robert [mailto:robert.hancock@roke.co.uk] Sent: Saturday, July 30, 2005 9:20 AM To: john.loughney@nokia.com; charles@cs.columbia.edu; nsis@ietf.org Subject: RE: [NSIS] Draft on NSIS Operation Over IP Tunnels =09 =09 Hi,=20 One thing it would be interesting to get the viewpoints of the=20 various sets of authors on is whether the use case for the=20 BOUND_FLOW_SESSION (in this draft) is related to the use case=20 for the "Filter List" from draft-cheng-nsis-flowid-issues-01.txt=20 or "Path Type" from draft-sanda-nsis-path-type-02.txt. All of=20 these things seem to be about ways to link together multiple=20 signalling sessions in various ways. One feels that generic=20 (multi-NSLP) solutions should be possible, but it is not clear=20 to me exactly how many different problems there are (or how=20 many different solutions are needed).=20 Robert H.=20 > -----Original Message-----=20 > From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On=20 > Behalf Of john.loughney@nokia.com=20 > Sent: 30 July 2005 11:09=20 > To: charles@cs.columbia.edu; nsis@ietf.org=20 > Subject: RE: [NSIS] Draft on NSIS Operation Over IP Tunnels=20 >=20 >=20 > Hi Charles,=20 >=20 > Thanks for the draft, I think this is quite a useful=20 > analysis. As tunneling, like multihoming, can be related to=20 > mobility, I wonder if the analysis could go into the Mobility=20 > Applicability Statement document. =20 >=20 > After that, for the BOUND_FLOW_SESSION object, do you think=20 > that this would be a general object for all NSLPs that might=20 > run over a tunnel? One option would be to add this to the=20 > existing NSLPs, or to write a very short document registering=20 > this as a NSLP object in the NSIS IANA registry (when there is one).=20 >=20 > What does the rest of the wg think?=20 >=20 > thanks,=20 > John=20 >=20 > > -----Original Message-----=20 > > From: nsis-bounces@ietf.org=20 > [mailto:nsis-bounces@ietf.org]On Behalf Of=20 > > ext Charles Shen=20 > > Sent: 14 July, 2005 07:45=20 > > To: nsis@ietf.org=20 > > Subject: [NSIS] Draft on NSIS Operation Over IP Tunnels=20 > >=20 > >=20 > > Dear all,=20 > >=20 > > We've submitted a draft on "NSIS Operation Over IP Tunnels".=20 > > The abstract is=20 > > as follows:=20 > >=20 > > In this draft we briefly review various IP Tunnelling=20 > > mechanisms and=20 > > discuss the main problems with signaling operation over=20 > IP tunnels.=20 > > We also summarize the existing RSVP operation over IP tunnels=20 > > mechanism. Then we present the design details and case=20 > examples of=20 > > an NSIS operation over IP tunnels scheme. QoS NSLP is=20 > > assumed as the=20 > > NSIS signaling application in our discussion.=20 > >=20 > > The document is available at=20 > >=20 > > http://www.ietf.org/internet-drafts/draft-shen-nsis-tunnel-00.txt=20 > >=20 > > Any comments are greatly appreciated!=20 > >=20 > > Best regards,=20 > >=20 > > Charles=20 > >=20 > >=20 > >=20 > > _______________________________________________=20 > > nsis mailing list=20 > > nsis@ietf.org=20 > > https://www1.ietf.org/mailman/listinfo/nsis=20 > >=20 >=20 > _______________________________________________=20 > nsis mailing list=20 > nsis@ietf.org=20 > https://www1.ietf.org/mailman/listinfo/nsis=20 >=20 ------_=_NextPart_001_01C5965D.C0209758 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Message
Hi=20 Charles,
 
>=20 Wouldn't the MRI change every time you have an address change? Does this = draft=20 keep the assumption that MRI and Flow ID are tied togher? =
 
The=20 draft keeps the assumption that MRI and Flow ID are tied together. The = sentence=20 you quoted is trying to state the fact that if the Filter List is = employed,=20 the Flow ID's dependency on the address information can be relaxed, and = it would=20 result in less state management, e.g. new path discovery. Some=20 points about this was discussed in the mailing list after last = Interim=20 meeting. We should have expanded the text to explain=20 it. 
 
>=20 Also it seems to me we will have one session with one SESSION ID and = possibly=20 multiple FLOW IDs, then each FLOW ID may have multiple FILTER SPECS?=20
>=20 Please correct me if I misunderstood it.
 
You=20 are correct that there may be multiple Flows within one Session, = according to=20 the definition of Session and Flow in NSIS, e.g. due to mobility,=20 multihoming, and host decisions. How these Flows relate to each other is = the=20 question addressed in draft draft-sanda-nsis-path-type-02.txt.  It talks about = a logic=20 Path Type that can be used to correlate certain flows within a = Session=20 (instead of implicitly assuming all the Flows within the Session are = bound=20 together).  In this=20 aspects, it related to the intra-session association idea in your = draft=20 draft-shen-nsis-tunnel-00.txt, = although looking=20 at a separate problem. It = is trying=20 to solve those mobility related=20 issues. 
 
 
Also,=20 within a same flow, there may need several Filter Specs to accurately = reflect=20 the addresses involved. This is the issue address in the=20 draft-cheng-nsis-flowid-issues-01. Several scenarios/use cases were = described=20 to illustrates the needs for this.
 
>=20 Indeed, I feel that the = FILTER_LIST=20 approach with its ADD action might = serve a similar function as ASSOCIATE_FLOW_SESSION. However, the = action=20 name might
>=20 need to be made more specific. i.e, to indicate whether this is = for=20 NSIS-tunnel handling or for other purposes. 
 
I have=20 the same feeling here. Especially for a aggregated case, the Filter_List = approach may be useful to handle the possible disagreement between Flow = ID=20 and FCI. I agree that to use it for that purpose, some = modifications=20 is necessary. Takako, one of the co-author of the draft, will attend the = IETF=20 meeting this week. So, some face to face discussion may be able to sort = out the=20 details.
 
cheers
 
Cheng=20 Hong
 
 
 
   
 
 
 

From: Charles Shen=20 [mailto:charles@cs.columbia.edu]
Sent: Monday, August 01, = 2005=20 12:33 AM
To: 'Hancock, Robert'; john.loughney@nokia.com; = Cheng Hong;=20 nsis@ietf.org
Subject: RE: [NSIS] Draft on NSIS Operation = Over IP=20 Tunnels

Hi = Robert,
 
I = see them as related yet slightly different issues.
 
According to my understanding, = generally Flow=20 (packet) Classfication Information is assumed to be derived from the = flow MRI.=20 draft-cheng-nsis-flowid-issues-01.txt discussed cases where this might = not be=20 sufficient and it might be desired to separate the flow classification = information from MRI.
 
In fact there is a = related case in=20 the NSIS tunneling analysis. Packets inside the tunnel carry tunnel = MRI in the=20 outer header and the e2e MRI in the innner header. The separation of = the=20 tunnel MRI and tunnel flow classification information will occur = if flows inside the tunnel are to be classified based on the inner = header.=20 (Although note that our chosen approach is to perform = tunnel flow classification based on the = outer header=20 due to the fact that most routers won't look at the inner = header.) =20
 
Two basic solutions = to=20 the above issue seem to = be either=20 extending the current MRI = definition or having a separate flow classification information = object. The=20 Filter_List represents = one of the=20 latter approaches. I have a=20 few questions = about this=20 Filter_List mechanism and would appreciate if the authors of=20 draft-cheng-nsis-flowid-issues-01.txt can clarify. Sec. 6.1 says:=20
 
   Since = the NTLP does=20 not need to modify the Flow ID or MRI every time the address changes, = the=20 state maintained on the NSIS nodes will be more stable, and thus = requires less=20 operation in updating.
 
Wouldn't = the MRI change=20 every time you have an address change? Does this draft keep the = assumption=20 that MRI and Flow ID are tied togher? Also it seems to me we will have = one=20 session with one SESSION ID and possibly multiple FLOW IDs, then each = FLOW ID=20 may have multiple FILTER SPECS? Please correct me if I misunderstood = it.=20
 
 
draft-shen-nsis-tunnel-00.txt=20 discusses intra-session associaiton, i.e. to associate different FLOW = IDs (for=20 flow classification) with the same SESSION ID.=20 The association may be done for different = purposes, such as supporting NSIS = operation=20 over IP tunnels. The=20 association can be achieved in different ways given = different=20 assumptions about the relationship between flow classification = information and=20 MRI. Indeed, I feel = that the=20 FILTER_LIST approach with its ADD action might serve a similar function as=20 ASSOCIATE_FLOW_SESSION. However, the action name might need to be made = more=20 specific. i.e, to indicate whether this = is for=20 NSIS-tunnel handling or for other purposes. 
 
Thanks.

Charles
-----Original Message-----
From: = Hancock,=20 Robert [mailto:robert.hancock@roke.co.uk]
Sent: Saturday, = July=20 30, 2005 9:20 AM
To: john.loughney@nokia.com;=20 charles@cs.columbia.edu; nsis@ietf.org
Subject: RE: [NSIS] = Draft=20 on NSIS Operation Over IP Tunnels

Hi,

One thing it would be interesting to get the = viewpoints of=20 the
various sets of authors on is whether = the use=20 case for the
BOUND_FLOW_SESSION (in this = draft) is=20 related to the use case
for the "Filter = List" from=20 draft-cheng-nsis-flowid-issues-01.txt
or = "Path Type"=20 from draft-sanda-nsis-path-type-02.txt. All of
these=20 things seem to be about ways to link together multiple =
signalling sessions in various ways. One feels that generic =
(multi-NSLP) solutions should be possible, = but it is=20 not clear
to me exactly how many different = problems=20 there are (or how
many different solutions = are=20 needed).

Robert H.

> -----Original Message-----
>=20 From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] = On=20
> Behalf Of = john.loughney@nokia.com=20
> Sent: 30 July 2005 11:09
>=20 To: charles@cs.columbia.edu; nsis@ietf.org
>=20 Subject: RE: [NSIS] Draft on NSIS Operation Over IP Tunnels =
>
>
> Hi=20 Charles,
>
> Thanks=20 for the draft, I think this is quite a useful
>=20 analysis.  As tunneling, like multihoming, can be related to=20
> mobility, I wonder if the analysis = could go=20 into the Mobility
> Applicability = Statement=20 document. 
>
>=20 After that, for the BOUND_FLOW_SESSION object, do you think =
> that this would be a general object for all NSLPs that = might=20
> run over a tunnel?  One option = would be to=20 add this to the
> existing NSLPs, or to = write a=20 very short document registering
> this = as a NSLP=20 object in the NSIS IANA registry (when there is one). =
>
> What does the rest of = the wg=20 think?
>
> = thanks,
> John
>=20
> > -----Original = Message-----=20
> > From: nsis-bounces@ietf.org =
> [mailto:nsis-bounces@ietf.org]On= =20 Behalf Of
> > ext Charles = Shen=20
> > Sent: 14 July, 2005 07:45 =
> > To: nsis@ietf.org
> = >=20 Subject: [NSIS] Draft on NSIS Operation Over IP Tunnels =
> >
> > =
> > Dear all,
> >=20
> > We've submitted a draft on "NSIS = Operation=20 Over IP Tunnels".
> > The abstract = is=20
> > as follows:
> >=20
> >    In this draft = we briefly=20 review various IP Tunnelling
> > = mechanisms=20 and
> >    discuss = the main=20 problems with signaling operation over
> IP=20 tunnels.
> >    We = also=20 summarize the existing RSVP operation over IP tunnels =
> >    mechanism.  Then we = present the=20 design details and case
> examples = of=20
> >    an NSIS operation = over IP=20 tunnels scheme.  QoS NSLP is
> = > assumed=20 as the
> >    NSIS = signaling=20 application in our discussion.
> >=20
> > The document is available = at=20
> >
> > http://www.ietf.org/internet-drafts/draft-shen-nsis-tunnel-00.txt=20
> >
> > Any = comments=20 are greatly appreciated!
> > =
> > Best regards,
> > =
> > Charles
> >=20
> >
> = >=20
> >=20 _______________________________________________
>=20 > nsis mailing list
> >=20 nsis@ietf.org
> > https://www1.ietf.or= g/mailman/listinfo/nsis=20
> >
> =
> _______________________________________________ =
> nsis mailing list
>=20 nsis@ietf.org
> https://www1.ietf.or= g/mailman/listinfo/nsis=20
> =

------_=_NextPart_001_01C5965D.C0209758-- --===============1380101558== 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 --===============1380101558==-- From nsis-bounces@ietf.org Mon Aug 01 09:37:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzaU1-0000vd-7f; Mon, 01 Aug 2005 09:37:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzaTy-0000of-Ru for nsis@megatron.ietf.org; Mon, 01 Aug 2005 09:37:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08769 for ; Mon, 1 Aug 2005 09:37:29 -0400 (EDT) Received: from mail126.messagelabs.com ([216.82.254.83]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Dzb0B-0000yH-52 for nsis@ietf.org; Mon, 01 Aug 2005 10:10:52 -0400 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-4.tower-126.messagelabs.com!1122903379!5481745!10 X-StarScan-Version: 5.4.15; banners=-,-,- X-Originating-IP: [192.128.133.132] Received: (qmail 3769 invoked from network); 1 Aug 2005 13:37:12 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (192.128.133.132) by server-4.tower-126.messagelabs.com with SMTP; 1 Aug 2005 13:37:12 -0000 Received: from kcclust06evs1.ugd.att.com (135.38.164.88) by attrh3i.attrh.att.com (7.2.052) id 42E3BC2B001FA429; Mon, 1 Aug 2005 09:37:11 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] RE: I-D ACTION:draft-ash-nsis-vertical-interface-00.txt Date: Mon, 1 Aug 2005 08:37:11 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA060CE6AB@KCCLUST06EVS1.ugd.att.com> Thread-Topic: [NSIS] RE: I-D ACTION:draft-ash-nsis-vertical-interface-00.txt Thread-Index: AcWGWB4FZXf0zJtCQoiay2jpPBLJrAABXVAAA6EgH/AAbl/MQA== From: "Ash, Gerald R \(Jerry\), ALABS" To: , X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: quoted-printable Cc: "Ash, Gerald R \(Jerry\), ALABS" 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: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi John, Thanks a lot for your review, comments, and suggestions. > I had a quick reading of this draft, it looks fairly=20 > interesting, but I would need to re-read and analysis the > scenario in a bit more detail. >=20 > The scope of the document is somewhat confusing though. I=20 > originally thought this would be a more general solution, > for example, proposing how to use NSIS QoS NSLP with SIP > signaling, but you do focus on the ETS case. Perhaps > better clarifying this in the revision would helpful. Your original interpretation is correct, the draft proposes how to use NSIS QoS NSLP with SIP signaling to achieve a 'vertical interface protocol (VIP)'. I agree that we need to clarify that VIP proposal is *not* limited to the ETS case. > Depending upon what your target is, illustrating the basic > QoS NSLP operation for consumer VOIP, without such a > specific network deployment, "DiffServ-enabled MPLS traffic=20 > engineering (DSTE) [RFC3564] tunnel ..." for example, would=20 > be a good idea. Agreed, specific mechanisms such as DSTE are not part of the VIP proposal, that needs to be made clear by dropping mention of such mechanisms in the examples. > I'd suggest for a revision that you include a terminology=20 > section, as there are a lot of acronyms, and terminology > that are not immediately recognizable. OK, will add terminology section. =20 > Any consideration on discussing this draft in ieprep, at=20 > least to verify the use case? This seems like it would be > of interest there. Thanks for the suggestion. I agree that IEPREP folks may have interest/comments on the VIP proposal and example use case. Also, in the IETF63/IEPREP meeting this morning, there was some discussion of the relationship between IEPREP requirements for 'priority/precedence', and the work of NSIS on QoS NSLP/QSPEC, see http://www1.ietf.org/mail-archive/web/ieprep/current/msg02350.html. Thanks, Regards, Jerry _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Aug 01 10:51:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzbdN-0006i6-8v; Mon, 01 Aug 2005 10:51:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzbdM-0006hs-4b for nsis@megatron.ietf.org; Mon, 01 Aug 2005 10:51:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13949 for ; Mon, 1 Aug 2005 10:51:14 -0400 (EDT) Received: from mail.saic-abingdon.com ([12.167.146.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dzc9e-0004A0-2r for nsis@ietf.org; Mon, 01 Aug 2005 11:24:38 -0400 Received: from no.name.available by mail.saic-abingdon.com via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with ESMTP; Mon, 1 Aug 2005 10:52:44 -0400 Received: from bh-exchange02.saic-abingdon.com ([172.17.10.226]) by bh-exchangefe.saic-abingdon.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 1 Aug 2005 10:53:07 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: [NSIS] Inter-Domain QOS Signaling and QSPEC Draft Date: Mon, 1 Aug 2005 10:53:01 -0400 Message-ID: <2FE23D25B7292B489A217D1965CDA866089830@bh-exchange02.saic-abingdon.com> Thread-Topic: [NSIS] Inter-Domain QOS Signaling and QSPEC Draft Thread-Index: AcWU8wkR+VB7T6plRcamb3rqlV1joABcEV+QAA76HOA= From: "Roy, Radhika \(AEAD\)" To: "John Loughney" X-OriginalArrivalTime: 01 Aug 2005 14:53:07.0320 (UTC) FILETIME=[BA3D9F80:01C596A8] X-Spam-Score: 0.3 (/) X-Scan-Signature: 841b5d6ad57042632519d2198f34cc8d Cc: henry@pulver.com, 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="===============0391468269==" Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. --===============0391468269== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C596A8.B6870020" This is a multi-part message in MIME format. ------_=_NextPart_001_01C596A8.B6870020 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable John: In a different context, I am attaching an email from the SIPPING WG with respect to Inter-Domain SIP signaling. In this respect, we wonder how far we would be willing to go for inter-domain QOS signaling despite some problems as discussed in threads like - RE: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-05.txt ,=20 In this NSIS thread, we have made a modest proposal to split the QSPEC draft into two as follows: 1. The first draft will deal with only QSPEC only for NSIS QOS signaling on end-to-end basis with no restrictions of any values of any parameters per NSIS charter. 2. The second draft may deal with all those restrictions for forming inter-domain [e.g., NSIS (IETF) - Y.xxx (ITU-T)] QOS signaling as they wish. Best regards, Radhika -----Original Message----- From: sipping-bounces@ietf.org [mailto:sipping-bounces@ietf.org] On Behalf Of henry@sinnreich.net Sent: Monday, August 01, 2005 2:45 AM To: 'Juha Heinanen'; henry@pulver.com Cc: 'Avshalom Houri'; 'Aki Niemi'; 'Michael Hammer (mhammer)'; 'ext Dean Willis'; 'Paul Kyzivat'; sipping@ietf.org Subject: RE: [Sipping] Inter-Domain Requirements for SIP/SIMPLE Sorry, I forgot to add that inter-domain agreements are not only a non-scalable approach, but as Aki Niemi has pointed out, large providers may refuse to give attention to small providers. VoIP Peering can therefore be a tool for discrimination against smaller competitors, and may be misused for monopoly behavior IMHO. The IETF would therefore be well advised to develop BCPs exposing these pitfalls. Thanks, Henry -----Original Message----- From: Juha Heinanen [mailto:jh@tutpro.com]=20 Sent: Saturday, July 30, 2005 12:36 PM To: henry@pulver.com Cc: 'Avshalom Houri'; 'Aki Niemi'; 'Michael Hammer (mhammer)'; 'ext Dean Willis'; 'Paul Kyzivat'; sipping@ietf.org Subject: RE: [Sipping] Inter-Domain Requirements for SIP/SIMPLE Henry Sinnreich writes: > Yes, you hit it the nail on the head. Running IP services on biletaral > agreements is not scalalble and should not be legitimized in the IETF in > any shape or form. i fully support that position. ietf should not get involved with developing mechanisms for walled gardens. the focus should be how on to make sip/simple work securely between any internet nodes without any non-scalable bilateral or clearing house agreements. there is nothing special in sip or simple as compared, for example, to email. -- juha _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP ------_=_NextPart_001_01C596A8.B6870020 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable [NSIS] Inter-Domain QOS Signaling and QSPEC Draft

John:

In a = different context, I am attaching an email from the SIPPING WG with = respect to Inter-Domain SIP signaling. In this respect, we wonder how far we would be willing to go for = inter-domain QOS signaling despite some = problems as discussed in threads like - = RE: [NSIS] I-D = ACTION:draft-ietf-nsis-qspec-05.txt,

In = this = NSIS thread, we have made a modest proposal to split = the QSPEC draft into two as follows:

1.      = The first draft will deal with only QSPEC = only for NSIS QOS signaling on end-to-end basis with = no restrictions of any values of any parameters per NSIS charter.

2.      The second draft may deal with all those restrictions for forming = inter-domain [e.g., NSIS (IETF) - Y.xxx = (ITU-T)] QOS signaling as they wish.

Best = regards,

Radhika

-----Original Message-----
From: sipping-bounces@ietf.org [mailto:sipping-bounces@ietf.org<= /A>] On Behalf Of henry@sinnreich.net
Sent: Monday, August 01, 2005 2:45 AM
To: 'Juha Heinanen'; henry@pulver.com
Cc: 'Avshalom Houri'; 'Aki Niemi'; 'Michael Hammer (mhammer)'; 'ext Dean = Willis'; 'Paul Kyzivat'; sipping@ietf.org
Subject: RE: [Sipping] Inter-Domain Requirements for = SIP/SIMPLE

Sorry, I forgot to add that inter-domain agreements are = not only a

non-scalable approach, but as Aki Niemi has pointed out, = large providers may

refuse to give attention to small = providers.

VoIP = Peering can therefore be a tool for discrimination against = smaller

competitors, and may be misused for monopoly behavior = IMHO. The IETF would

therefore be well advised to develop BCPs exposing these = pitfalls.

Thanks, Henry



-----Original Message-----

From: = Juha Heinanen [mailto:jh@tutpro.com] =

Sent: = Saturday, July 30, 2005 12:36 PM

To: = henry@pulver.com

Cc: = 'Avshalom Houri'; 'Aki Niemi'; 'Michael Hammer (mhammer)'; 'ext = Dean

Willis'; 'Paul Kyzivat'; = sipping@ietf.org

Subject: RE: [Sipping] Inter-Domain Requirements for = SIP/SIMPLE

Henry = Sinnreich writes:

 > Yes, you hit it the nail on the head. Running = IP services on biletaral

 > agreements is not scalalble and should not be = legitimized in the IETF

in

 > any shape or form.

i = fully support that position.  ietf should not get involved = with

developing mechanisms for walled gardens.  the focus = should be how on to

make = sip/simple work securely between any internet nodes without = any

non-scalable bilateral or clearing house = agreements.  there is nothing

special in sip or simple as compared, for example, to = email.

-- = juha

_______________________________________________

Sipping mailing list  https://www1.ietf= .org/mailman/listinfo/sipping

This = list is for NEW development of the application of SIP

Use = sip-implementors@cs.columbia.edu for questions on current = sip

Use = sip@ietf.org for new developments of core SIP




_______________________________________________

Sipping mailing list  https://www1.ietf= .org/mailman/listinfo/sipping

This = list is for NEW development of the application of SIP

Use = sip-implementors@cs.columbia.edu for questions on current = sip

Use = sip@ietf.org for new developments of core SIP

------_=_NextPart_001_01C596A8.B6870020-- --===============0391468269== 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 --===============0391468269==-- From nsis-bounces@ietf.org Mon Aug 01 11:58:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzcgm-00037c-GS; Mon, 01 Aug 2005 11:58:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzcgk-00037R-KO for nsis@megatron.ietf.org; Mon, 01 Aug 2005 11:58:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20119 for ; Mon, 1 Aug 2005 11:58:48 -0400 (EDT) Message-Id: <200508011558.LAA20119@ietf.org> Received: from relaygw1.kornet.net ([61.74.75.196]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzdD2-000815-3f for nsis@ietf.org; Mon, 01 Aug 2005 12:32:13 -0400 Received: from [211.48.62.134] ([211.48.62.134]) by relaygw1.kornet.net ([61.74.75.196]) with ESMTP id 2005080200:58:28:590500.1133.32779184 for ; Tue, 02 Aug 2005 00:58:28 +0900 (KST) Received: from [203.253.70.47] ([203.253.70.47]) by relay7.kornet.net ([211.48.62.134]) with ESMTP id 2005080200:58:27:650431.6095.75684784 for ; Tue, 02 Aug 2005 00:58:27 +0900 (KST) From: "Seong-Ho Jeong" To: Date: Tue, 2 Aug 2005 00:56:24 +0900 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcWWsZE0SZMMmPPEQSanZrqfJmzrwA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-TERRACE-SPAMMARK: NOT spam-marked. (by Terrace) X-Spam-Score: 0.1 (/) X-Scan-Signature: 9af087f15dbdd4c64ae6bbcdbc5b1d44 Subject: [NSIS] 3GPP QOSM (-01 version) 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="===============1863733163==" Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. --===============1863733163== Content-Type: multipart/alternative; boundary="----=_NextPart_000_000E_01C596FD.01BC3110" This is a multi-part message in MIME format. ------=_NextPart_000_000E_01C596FD.01BC3110 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Dear all, At the last NSIS WG interim meeting held in May, 2005, many of the participants were interested in the 3GPP QOSM draft. We have updated the document and it can be found at http://www.ietf.org/internet-drafts/draft-jeong-nsis-3gpp-qosm-01.txt. I would like to introduce the draft briefly before presentation at the NSIS WG meeting. The main objective of the draft is to describe a QoS-NSLP QoS model based on 3GPP QoS classes and bearer service attributes, and propose additional optional QSPEC parameters for the 3GPP QoS model (QOSM). The changes made since -00 version are as follows. - Reduced the text for overview - Added QoS mapping between 3GPP TS 23.107 and RMD-QOSM - Updated additional optional QSPEC parameters - Updated interworking Scenarios for End-to-End QoS Support - Added Future Issues Any comments/suggestions are welcome. Thanks and regards, Seong-Ho ------=_NextPart_000_000E_01C596FD.01BC3110 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Dear=20 all,

 

At the last NSIS WG interim meeting held in May, = 2005,=20

many of the participants were interested in the = 3GPP=20

QOSM draft. We have updated the document and it can = be=20 found

at=20 http://www.ietf.org/internet-drafts/draft-jeong-nsis-3gpp-qosm-01.txt.

I would like to introduce the draft briefly before=20 presentation at

the NSIS WG meeting.

 

The main objective of the draft is to describe a = QoS-NSLP QoS=20

model based on 3GPP QoS classes and bearer service=20 attributes,

and propose additional optional QSPEC parameters = for the 3GPP=20

QoS model (QOSM).

 

The changes made since -00 version are as=20 follows.

 

- Reduced the text for = overview

- Added QoS mapping between 3GPP TS 23.107 and=20 RMD-QOSM

- Updated additional optional QSPEC=20 parameters

- Updated interworking Scenarios for End-to-End QoS = Support

- Added Future Issues

 

Any comments/suggestions are=20 welcome.

 

Thanks and regards,

Seong-Ho

------=_NextPart_000_000E_01C596FD.01BC3110-- --===============1863733163== 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 --===============1863733163==-- From nsis-bounces@ietf.org Tue Aug 02 10:23:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzxg8-0007ja-5D; Tue, 02 Aug 2005 10:23:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzxg6-0007jV-Bs for nsis@megatron.ietf.org; Tue, 02 Aug 2005 10:23:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22999 for ; Tue, 2 Aug 2005 10:23:31 -0400 (EDT) Received: from pollux.ietf63.ietf.org ([86.255.2.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzyCa-0001yW-L8 for nsis@ietf.org; Tue, 02 Aug 2005 10:57:09 -0400 Received: from your2c8aef7fc3 (open-25-115.ietf63.ietf.org [86.255.25.115]) by pollux.ietf63.ietf.org (Postfix) with ESMTP id E18E737; Tue, 2 Aug 2005 07:23:27 -0700 (PDT) Message-ID: <000f01c5976d$b8fd88e0$7319ff56@your2c8aef7fc3> From: "Suwon Lee" To: Subject: RE: [NSIS] New Draft: NSIS Signaling Protocols in Multihomed MobileNetworks Date: Tue, 2 Aug 2005 23:23:15 +0900 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 2.2 (++) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: john.loughney@nokia.com X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0228354133==" Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org --===============0228354133== Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 SGkgSm9obiwNCg0KVGhhbmtzIGEgbG90IGZvciB5b3VyIHJldmlldywgY29tbWVudHMsIGFuZCBz dWdnZXN0aW9ucy4NClBsZWFzZSByZWZlciB0byBteSByZXNwb25zZSBpbiBsaW5lLg0KDQpUaGFu a3MsDQoNClN1d29uDQoNCj4tLS0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0tLQ0KPlNlbmRl ciA6IGpvaG4ubG91Z2huZXlAbm9raWEuY29tPGpvaG4ubG91Z2huZXlAbm9raWEuY29tPiANCj5E YXRlICAgOiAyMDA1LTA3LTMwIDE4OjAzDQo+VGl0bGUgIDogUkU6IFtOU0lTXSBOZXcgRHJhZnQ6 IE5TSVMgU2lnbmFsaW5nIFByb3RvY29scyBpbiBNdWx0aWhvbWVkDQo+IE1vYmlsZU5ldHdvcmtz DQo+DQo+SGkgU3V3b24sDQo+DQo+VGhhbmtzIGZvciB0aGF0IGRyYWZ0LiAgVGhpcyBpcyBxdWl0 ZSBhIHVzZWZ1bCBkcmFmdCwgc28gSSBob3BlIHdlIGNhbiBoYXZlDQo+c29tZSBkaXNjdXNzaW9u IG9uIGl0LiAgV2hlbiByZWFkaW5nLCBJIHdhbnRlZCB0byBjb21tZW50IG9uIGEgZmV3IHRoaW5n cy4NCg0KVGhhbmsgeW91LiBJIGhvcGUgdGhpcyBkcmFmdCB3b3VsZCBiZSBoZWxwZnVsIGZvciB0 aGUgZGVzaWduIG9mIE5TSVMgDQpwcm90b2NvbHMuDQoNCj4NCj5JbiB0aGUgaW50cm86DQo+DQo+ ICJNdWx0aWhvbWluZyByZWZlcnMgdG8gYSBzaXR1YXRpb24gd2hlcmUgYW4gZW5kIG5vZGUgaGFz IHNldmVyYWwNCj4gcGFyYWxsZWwgY29tbXVuaWNhdGlvbiBwYXRocyB0byB1c2UuIg0KPg0KPkkg dGhpbmsgSSdkIG1vZGlmeSB0aGlzIGRlZmluaXRpb24gYSBiaXQuICBSRkMgMzU4MiBoYXMgYSBk ZWZpbml0aW9uDQo+Zm9yIHNpdGUtbXVsdGlob21pbmcsIHNvIHlvdSBtaWdodCB3YW50IHRvIHJl ZmVyZW5jZSB0aGlzLiAgSWYgd2Ugd2FudA0KPnRvIHRhbGsgYWJvdXQgaG9zdC1tdWx0aWhvbWlu ZywgaXQgdXN1YWxseSByZWZlcnMgdG8gYSBob3N0IHRoYXQNCj5oYXMgbXVsdGlwbGUsIGFjdGl2 ZSAob3IgcG90ZW50aWFsbHkgYWN0aXZlKSBpbnRlcmZhY2VzIGNvbm5lY3RlZA0KPnRvIGRpZmZl cmVudCBzdWJuZXRzIHdoaWNoIHRoZW4gaW1wbGllcyBtdWx0aXBsZSBjb21tdW5pY2F0aW9uIHBh dGhzLg0KPg0KDQpJIGFncmVlIHdpdGggeW91ciBvcGluaW9uLiBUaGUgZGVmaW5pdGlvbiBvZiBt dWx0aWhvbWluZyBpbiBSRkMgMzU4MiANCndpbGwgYmUgYWRkZWQgaW4gdGhlIG5leHQgdmVyc2lv bi4gSW4gdGhlIGN1cnJlbnQgdmVyc2lvbiBvZiB0aGlzIGRyYWZ0LCANCm11bHRpaG9taW5nIGlz IGNvbnNpZGVyZWQgb25seSBmb3IgbW9iaWxlIGVudmlyb25tZW50IGJ1dCBpdCBjb3VsZCANCmFs c28gYmUgYXBwbGljYWJsZSB0byBmaXhlZCBlbnZpcm9ubWVudC4gVGhlIHNpdGUtbXVsdGlob21p bmcgY2FzZSANCndpbGwgYmUgY29uc2lkZXJlZCBpbiBmdXR1cmUgdmVyc2lvbi4gDQoNCj5BbHNv LCBpbiB0aGUgaW50cm8sIEkgdGhpbmsgSSB3b3VsZG4ndCB3YW50IHRvIGV4cGxhaW4gd2h5IGhv c3RzIC8gdXNlcnMgLw0KPm5ldHdvcmtzIG1pZ2h0IHdhbnQgdG8gYmUgbXVsdGlob21lZCAoaS5l LiAtIHRoZSBhZHZhbnRhZ2VzIG9mIG11bHRpaG9taW5nKQ0KPmJ1dCByYXRoZXIgZGlzY3VzcyB0 aGUgaW1wbGljYXRpb25zIG9mIG11bHRpaG9taW5nLiAgTXVsdGlob21pbmcgaGFzIGludGVyZXN0 aW5nDQo+aW1wbGljYXRpb25zIGZvciBwYXRoLW9yaWVudGVkIHNpZ25hbGluZywgYW5kIHBhdGgt b3JpZW50ZWQgc2lnbmFsaW5nIGNhbg0KPmJyaW5nIGJlbmVmaXRzIGZvciBhIG11bHRpaG9tZWQg aG9zdC4gIEZvciBleGFtcGxlLCBhIGhvc3QgbWlnaHQgaGF2ZSBib3RoIGFuDQo+YWN0aXZlIDgw Mi4xMSBpbnRlcmZhY2UgYW5kIFdDRE1BIGludGVyZmFjZS4gIElmIHRoZSA4MDIuMTEgaW50ZXJm YWNlIG1pZ2h0IGJlIGJlaGluZCANCj5hIHNsb3cgRFNMIGxpbmUsIG1ha2luZyB0aGUgbmV0d29y ayBwYXRoIG9uIHRoZSBXQ0RNQSBpbnRlcmZhY2UgJ2JldHRlcicuICBJZiB0aGUgaG9zdCANCj5o YXMgb25seSBrbm93bGVkZ2UgYWJvdXQgdGhlIGxpbmsgY29uZGl0aW9ucywgaXQgd2lsbCBub3Qg a25vdyBlbm91Z2ggYWJvdXQgdGhlIHBhdGggDQo+Y29uZGl0aW9ucyB0byBtYWtlIGFuIGluZm9y bWVkIGRlY2lzaW9uIGFib3V0IHdoaWNoIGludGVyZmFjZSAoYW5kIGJ5IGV4dGVudGlvbiwgd2hp Y2gNCj5wYXRoKSBpcyAnYmV0dGVyJy4NCj4NCg0KSSBkZWZpbml0ZWx5IGFncmVlIHdpdGggeW91 ciBvcGluaW9uIG9uIHRoZSBpbXBsaWNhdGlvbiBvZiBtdWx0aWhvbWluZyBmb3IgDQpwYXRoLW9y aWVudGVkIHNpZ25hbGluZy4gVGhvdWdoIHRoaXMgaXMgbm90IGV4cGxpY2l0bHkgZGVzY3JpYmVk IGluIHRoZSBkcmFmdCwgDQp3ZSBpZGVudGlmaWVkIHRoZSBmZWF0dXJlIGFuZCBtZWFudCB0byBl bXBoYXNpemUgdGhlIHNpZ25pZmljYW5jZSBvZiBoYXZpbmcgDQptdWx0aXBsZSBwYXRocyB3aXRo IGZ1bGwga25vd2xlZGdlLiBXZSB3b3VsZCBleHBsaWNpdGx5IG1lbnRpb24gdGhpcyBpbiB0aGUg DQpuZXh0IHZlcnNpb24gb2YgdGhlIGRyYWZ0LiANCg0KPkluIHNlY3Rpb24gMywgUHJvYmxlbSBT dGF0ZW1lbnQsICJSZWdpc3RyYXRpb24gb2YgTXVsdGlwbGUgQ29BcyIgbWlnaHQgbm90IHJlYWxs eQ0KPmJlIGluLXNjb3BlIG9mIE5TSVMuDQoNCkkgYWdyZWUuIFRob3VnaCBtdWx0aXBsZSBDb0Eg cmVnaXN0cmF0aW9uIGlzIG9uZSBvZiB0aGUgbW9zdCB1cmdlbnQgcHJvYmVtcyANCnRvIGJlIHNv bHZlZCBpbiBtdWx0aWhvbWluZyBpbiBtb2JpbGUgZW52aXJvbm1lbnQsIHRoaXMgaXMgbm90IE5T SVMtc3BlY2lmaWMgDQpwcm9ibGVtLiBUaHVzIHRoZSBkcmFmdCB3aWxsIG5vdCBwcm92aWRlIGFu eSBzb2x1dGlvbiBmb3IgdGhpcy4gDQoNCj4NCj5JIHRoaW5rIHF1aXRlIGEgYml0IG9mIHNlY3Rp b24gNCwgd2hpY2ggaXMgZ29vZCwgc2VlbXMgdG8gYmUgcXVpdGUgY2xvc2VseSByZWxhdGVkDQo+ dG8gdGhlIE1vYmlsaXR5IEFwcGxpY2FiaWxpdHkgc3RhdGVtZW50LiAgRG9lcyB0aGUgZ3JvdXAg ZmVlbCBsaWtlIGl0IHdvdWxkIGJlIHVzZWZ1bA0KPnRvIGNhcHR1cmUgdGhpcyBpbmZvcm1hdGlv biBpbiB0aGF0IGRvY3VtZW50Pw0KDQpJbiBteSBvcGluaW9uLCBzb21lIHBhcnRzIG9mIHRoZSBk cmFmdCB3b3VsZCBmaXQgd2l0aCB0aGUgTW9iaWxpdHkgDQpBcHBsaWNhYmlsaXR5IFN0YXRlbWVu dCBkcmFmdCBzbyB0aGF0IHRoZXkgbWlnaHQgYmUgbW92ZWQgaW50byB0aGF0IGRyYWZ0LiANCkhv d2V2ZXIsIHRoZSBtdWx0aWhvbWluZyBpbiBmaXhlZCBlbnZpcm9ubWVudCB0aGF0IHdvdWxkIGJl IGRlYWx0IHdpdGggaW4gdGhlIA0KZnV0dXJlIHZlcnNpb24gd291bGQgbm90IGZpbHQgd2VsbCB3 aXRoIHRoZSBNb2JpbGl0eSBBcHBsaWNhYmlsaXR5IGRyYWZ0LiBJbiBhZGRpdGlvbiwgDQptdWx0 aWhvbWluZyBpdHNlbGYgaGFzIGEgbG90IG9mIGlzc3VlcyB0byBiZSB0YWNrbGVkIChlLmcuLCBz aXRlLW11bHRpaG9taW5nIHNjZW5hcmlvcykuIA0KU28sIGluIG15IG9waW5pb24sIHRvIGtlZXAg dGhlIGNvbnNpc3RlbmN5IG9mIHByb2JsZW1zIGFuZCBzb2x1dGlvbnMgaXQgd291bGQgYmUgDQpi ZXR0ZXIgdG8gaGFuZGxlIHRoZSBtdWx0aWhvbWluZy1yZWxhdGVkIGlzc3VlcyBpbiBhIHNlcGFy YXRlZCBkb2N1bWVudC4gIA0KDQoNCj4NCj50aGFua3MsDQo+Sm9obg0KPg0KPj4gLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCj4+IEZyb206IG5zaXMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRv Om5zaXMtYm91bmNlc0BpZXRmLm9yZ11PbiBCZWhhbGYgT2YNCj4+IGV4dCBTdXdvbiBMZWUNCj4+ IFNlbnQ6IDE0IEp1bHksIDIwMDUgMDY6NDYNCj4+IFRvOiBuc2lzQGlldGYub3JnDQo+PiBTdWJq ZWN0OiBbTlNJU10gTmV3IERyYWZ0OiBOU0lTIFNpZ25hbGluZyBQcm90b2NvbHMgaW4gTXVsdGlo b21lZA0KPj4gTW9iaWxlTmV0d29ya3MNCj4+IA0KPj4gDQo+PiBEZWFyIEFsbCwgDQo+PiANCj4+ IFdlIHdvdWxkIGxpa2UgdG8gYWRkcmVzcyB0aGF0IGEgbmV3IGRyYWZ0ICJOU0lTIFNpZ25hbGlu ZyANCj4+IFByb3RvY29scyBpbiANCj4+IE11bHRpaG9tZWQgTW9iaWxlIE5ldHdvcmtzIiB3YXMg c3VibWl0dGVkLg0KPj4gKCANCj4+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRz L2RyYWZ0LWxlZS1uc2lzLW11bHRpaG9taW5nDQo+PiAtbW9iaWxpdHktMDAudHh0ICkNCj4+IFdl IHdvdWxkIGFwcHJlY2lhdGUgaXQgaWYgeW91IHdvdWxkIHJldmlldyBhbmQgY29tbWVudCBvbiB0 aGUgZHJhZnQuDQo+PiANCj4+IFRoZSBkcmFmdCBkZWFscyB3aXRoOg0KPj4gLSBQb3NzaWJsZSBp c3N1ZXMgb24gTlNJUyBzaWduYWxpbmcgaW4gdGhlIG11bHRpaG9tZWQgZW52aXJvbm1lbnRzDQo+ PiAgIC0gTlNJUyBvcGVyYXRpb25zIGluIG11bHRpaG9tZWQgbmV0d29ya3MNCj4+ICAgLSBSZWNl aXZlci1pbml0aWF0ZWQgcmVzZXJ2YXRpb24NCj4+ICAgLSBTZW5kZXItaW5pdGlhdGVkIHJlc2Vy dmF0aW9uDQo+PiAtIE5TSVMgQXBwbGljYWJpbGl0eSBpbiBtdWx0aWhvbWVkIHNjZW5hcmlvcw0K Pj4gICAtIExpbmsvbm9kZSBmYWlsdXJlDQo+PiAgIC0gTG9hZCBiYWxhbmNpbmcNCj4+ICAgLSBM b2FkIHNoYXJpbmcNCj4+IA0KPj4gQWJzdHJhY3Q6DQo+PiBBIGhvc3QgdGhhdCBpcyBhbiBpbml0 aWF0b3Igb3IgcmVzcG9uZGVyIG9mIE5TSVMgc2lnbmFsaW5nIA0KPj4gbWVzc2FnZXMgY2FuIGJl IG5vdCANCj4+IG9ubHkgbW9iaWxlIGJ1dCBhbHNvIG11bHRpaG9tZWQuICBNdWx0aWhvbWVkIGhv c3RzIGFuZCANCj4+IHNjZW5hcmlvcyBtYXkgYmUgY29tbW9uDQo+PiBpbiB0aGUgZnV0dXJlIElQ djYtYmFzZWQgSW50ZXJuZXQuICBCZW5lZml0cyBvZiBtdWx0aWhvbWluZyANCj4+IGluY2x1ZGUg aW5jcmVhc2VkIA0KPj4gYmFuZHdpZHRoLCBsb2FkIGJhbGFuY2luZywgbG9hZCBzaGFyaW5nLCB1 YmlxdWl0b3VzIGFjY2VzcywgDQo+PiBiaS1jYXN0aW5nLCANCj4+IHJlc2lsaWVuY2UsIGFuZCBl dGMuICBOU0lTIHNpZ25hbGluZyBzaG91bGQgYmUgYWJsZSB0byANCj4+IHN1cHBvcnQgdmFyaW91 cyANCj4+IG11bHRpaG9taW5nIHNjZW5hcmlvcy4gVGhpcyBkcmFmdCBkZXNjcmliZXMgTlNJUyBv cGVyYXRpb25zIA0KPj4gYW5kIGFwcGxpY2FiaWxpdHkgDQo+PiBpbiBtdWx0aWhvbWVkIGVudmly b25tZW50cy4NCj4+IA0KPj4gUmVnYXJkcywNCj4+IA0KPj4gU3V3b24gTGVlDQo+PiANCj4+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBuc2lzIG1h aWxpbmcgbGlzdA0KPj4gbnNpc0BpZXRmLm9yZw0KPj4gaHR0cHM6Ly93d3cxLmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vbnNpcw0KPj4= --===============0228354133== 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 --===============0228354133==-- From nsis-bounces@ietf.org Tue Aug 02 11:48:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzz0k-0004eG-JL; Tue, 02 Aug 2005 11:48:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzz0i-0004eB-Uv for nsis@megatron.ietf.org; Tue, 02 Aug 2005 11:48:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00557 for ; Tue, 2 Aug 2005 11:48:54 -0400 (EDT) Received: from mail120.messagelabs.com ([216.82.255.211]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1DzzXD-0006aZ-Gr for nsis@ietf.org; Tue, 02 Aug 2005 12:22:32 -0400 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-7.tower-120.messagelabs.com!1122997703!4823523!13 X-StarScan-Version: 5.4.15; banners=-,-,- X-Originating-IP: [192.128.133.132] Received: (qmail 29666 invoked from network); 2 Aug 2005 15:48:44 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (192.128.133.132) by server-7.tower-120.messagelabs.com with SMTP; 2 Aug 2005 15:48:44 -0000 Received: from kcclust06evs1.ugd.att.com (135.38.164.88) by attrh3i.attrh.att.com (7.2.052) id 42E3BC2B00235B70; Tue, 2 Aug 2005 11:48:43 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] 3GPP QOSM (-01 version) Date: Tue, 2 Aug 2005 10:48:43 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA060CE6B2@KCCLUST06EVS1.ugd.att.com> Thread-Topic: [NSIS] 3GPP QOSM (-01 version) Thread-Index: AcWWsZE0SZMMmPPEQSanZrqfJmzrwAAxrHRg From: "Ash, Gerald R \(Jerry\), ALABS" To: "Seong-Ho Jeong" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: quoted-printable Cc: "Ash, Gerald R \(Jerry\), ALABS" 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: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi Seong-Ho, The updated draft looks good. I have one brief suggestion. IMO, it would be good to indicate the relationship of the parameters you introduce in Section 5 and corresponding parameters in the QSPEC I-D http://ietf.org/internet-drafts/draft-ietf-nsis-qspec-05.txt. In particular, it would good to indicate the relationship between: - 3GPP-QOSM Transfer Delay (Section 5.6), and QSPEC Path Latency Parameter (Section 6.9) - 3GPP-QOSM Packet Loss Ratio (Section 5.7), and QSPEC Path BER Parameter (Section 6.11) - 3GPP-QOSM Traffic Handling Priority (Section 5.8), and QSPEC Priority Parameters (Preemption Priority, Defending Priority, Reservation Priority) (Section 6.8). If the QSPEC parameters can be re-used that would be great. If the 3GPP-QOSM parameters are different from the corresponding QSPEC parameters, it would be useful to point out the differences. Thanks, Regards, Jerry ________________________________ From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On Behalf Of Seong-Ho Jeong Sent: Monday, August 01, 2005 11:56 AM To: nsis@ietf.org Subject: [NSIS] 3GPP QOSM (-01 version) Dear all, At the last NSIS WG interim meeting held in May, 2005,=20 many of the participants were interested in the 3GPP=20 QOSM draft. We have updated the document and it can be found at http://www.ietf.org/internet-drafts/draft-jeong-nsis-3gpp-qosm-01.txt. I would like to introduce the draft briefly before presentation at=20 the NSIS WG meeting. The main objective of the draft is to describe a QoS-NSLP QoS=20 model based on 3GPP QoS classes and bearer service attributes,=20 and propose additional optional QSPEC parameters for the 3GPP=20 QoS model (QOSM). The changes made since -00 version are as follows. - Reduced the text for overview - Added QoS mapping between 3GPP TS 23.107 and RMD-QOSM - Updated additional optional QSPEC parameters - Updated interworking Scenarios for End-to-End QoS Support - Added Future Issues Any comments/suggestions are welcome. Thanks and regards, Seong-Ho _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Aug 03 09:03:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0Itt-0006ia-Ny; Wed, 03 Aug 2005 09:03:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0Ito-0006hr-4I for nsis@megatron.ietf.org; Wed, 03 Aug 2005 09:03:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13148 for ; Wed, 3 Aug 2005 09:03:05 -0400 (EDT) Message-Id: <200508031303.JAA13148@ietf.org> Received: from relaygw1.kornet.net ([61.74.75.196]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0JQR-0007m7-R0 for nsis@ietf.org; Wed, 03 Aug 2005 09:36:54 -0400 Received: from [211.48.62.134] ([211.48.62.134]) by relaygw1.kornet.net ([61.74.75.196]) with ESMTP id 2005080322:02:40:022411.11767.103365552 for ; Wed, 03 Aug 2005 22:02:40 +0900 (KST) Received: from [86.255.29.97] ([86.255.29.97]) by relay7.kornet.net ([211.48.62.134]) with ESMTP id 2005080322:02:38:719490.11685.68950960 for ; Wed, 03 Aug 2005 22:02:37 +0900 (KST) From: "Seong-Ho Jeong" To: "'Ash, Gerald R \(Jerry\), ALABS'" , Subject: RE: [NSIS] 3GPP QOSM (-01 version) Date: Wed, 3 Aug 2005 22:02:30 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcWWsZE0SZMMmPPEQSanZrqfJmzrwAAxrHRgACVievA= In-Reply-To: <9473683187ADC049A855ED2DA739ABCA060CE6B2@KCCLUST06EVS1.ugd.att.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-TERRACE-SPAMMARK: NOT spam-marked. (by Terrace) X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Content-Transfer-Encoding: 7bit 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: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi Jerry, Thanks a lot for the good comments. I basically agree with your opinion on the parameters. Please see my replies inline. Regards, Seong-Ho > -----Original Message----- > From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On Behalf Of > Ash, Gerald R (Jerry), ALABS > Sent: Wednesday, August 03, 2005 12:49 AM > To: Seong-Ho Jeong; nsis@ietf.org > Cc: Ash, Gerald R (Jerry), ALABS > Subject: RE: [NSIS] 3GPP QOSM (-01 version) > > Hi Seong-Ho, > > The updated draft looks good. I have one brief suggestion. > > IMO, it would be good to indicate the relationship of the parameters you > introduce in Section 5 and corresponding parameters in the QSPEC I-D > http://ietf.org/internet-drafts/draft-ietf-nsis-qspec-05.txt. In > particular, it would good to indicate the relationship between: > > - 3GPP-QOSM Transfer Delay (Section 5.6), and QSPEC Path Latency > Parameter (Section 6.9) I agree that it is related to QSPEC Path Latency Parameter, and therefore, IMO, the QSPEC parameter may be re-used. Georgios might want to clarify this further. > - 3GPP-QOSM Packet Loss Ratio (Section 5.7), and QSPEC Path BER > Parameter (Section 6.11). IMO, The Path BER parameter is focused on the bit error characteristics of packets while the Packet Loss Ratio parameter is related to the loss characteristics of packets. Although the errored packets may be considered as lost packets (if they are not recovered), it might be good to distinguish between them in general. > - 3GPP-QOSM Traffic Handling Priority (Section 5.8), and QSPEC Priority > Parameters (Preemption Priority, Defending Priority, Reservation > Priority) (Section 6.8). Traffic handling priority is useful in particular in congestion situations. I agree that it is related to the QSPEC priority parameters, so I think the the QSPEC parameters may be re-used. Georgios might also want to clarify this further. > If the QSPEC parameters can be re-used that would be great. If the > 3GPP-QOSM parameters are different from the corresponding QSPEC > parameters, it would be useful to point out the differences. > > Thanks, > Regards, > Jerry > > ________________________________ > > From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On Behalf Of > Seong-Ho Jeong > Sent: Monday, August 01, 2005 11:56 AM > To: nsis@ietf.org > Subject: [NSIS] 3GPP QOSM (-01 version) > > Dear all, > > At the last NSIS WG interim meeting held in May, 2005, > many of the participants were interested in the 3GPP > QOSM draft. We have updated the document and it can be found > at > http://www.ietf.org/internet-drafts/draft-jeong-nsis-3gpp-qosm-01.txt. > > I would like to introduce the draft briefly before presentation at > the NSIS WG meeting. > > The main objective of the draft is to describe a QoS-NSLP QoS > model based on 3GPP QoS classes and bearer service attributes, > and propose additional optional QSPEC parameters for the 3GPP > QoS model (QOSM). > > The changes made since -00 version are as follows. > - Reduced the text for overview > - Added QoS mapping between 3GPP TS 23.107 and RMD-QOSM > - Updated additional optional QSPEC parameters > - Updated interworking Scenarios for End-to-End QoS Support > - Added Future Issues > > Any comments/suggestions are welcome. > > Thanks and regards, > > Seong-Ho > > _______________________________________________ > 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 Aug 03 09:37:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0JRG-0005qr-Ol; Wed, 03 Aug 2005 09:37:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0JRF-0005qm-Fu for nsis@megatron.ietf.org; Wed, 03 Aug 2005 09:37:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16161 for ; Wed, 3 Aug 2005 09:37:39 -0400 (EDT) Received: from pollux.ietf63.ietf.org ([86.255.2.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0Jxw-0001IW-30 for nsis@ietf.org; Wed, 03 Aug 2005 10:11:28 -0400 Received: from happy (open-30-129.ietf63.ietf.org [86.255.30.129]) by pollux.ietf63.ietf.org (Postfix) with ESMTP id 7C47B48 for ; Wed, 3 Aug 2005 06:37:35 -0700 (PDT) Message-ID: <001901c59830$e4ce88c0$811eff56@happy> From: "Sung-Hyuck Lee" To: Date: Wed, 3 Aug 2005 22:40:21 +0900 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 1.1 (+) X-Scan-Signature: 25620135586de10c627e3628c432b04a Subject: [NSIS] NSIS-mobility Issue #11: Mobility Object 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="===============1498575244==" Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org --===============1498575244== Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 SGkgYWxsLA0KDQpOU0lTLW1vYmlsaXR5IGRyYWZ0IGF1dGhvcnMgaGF2ZSBuZXdseSBpZGVudGlm aWVkIHRoZSBmb2xsb3dpbmcgaXNzdWVzIA0Kd2hpY2ggbmVlZCB0byBiZSBhZGRyZXNzZWQuDQoN CjEuIFBpbmctcG9uZyB0eXBlIGhhbmRvdmVyLXJlbGF0ZWQgaXNzdWVzLg0KDQogIDEuMSBOT19S RVBMQUNFIGZsYWcgYW5kIHJlbGF0ZWQtaGludCBpbmZvcm1hdGlvbg0KDQotIERlc2NyaXB0aW9u OiBBbiBORSAoZS5nLiwgUU5FKSBjYW4gZGV0ZXJtaW5lIGlmIGl0IGlzIGEgbWVyZ2luZyBwb2lu dCANCiAgIChpLmUuIGFuIE5TTFAgQ1JOKSBvZiB0aGUgb2xkIGFuZCBuZXcgcGF0aHMsIGFuZCB0 aGVuIGl0IGNhbiANCiAgIHBlcmZvcm0gYW4gaW52b2x2ZWQgc3RhdGUgc2V0dXAgb24gdGhlIG5l dyBwYXRoIGFuZCBzdGF0ZSB0ZWFyZG93biANCiAgIG9uIHRoZSBvbGQgcGF0aC4gSG93ZXZlciwg aWYgdGhlIFFORSByZWNlaXZlcyBhbiBOU0lTIG1lc3NhZ2UgDQogICAoZS5nLiwgUkVTRVJWRSkg d2l0aCBhIHNwZWNpYWwgZmxhZyAoZS5nLiwgTk9fUkVQTEFDRSBmbGFnKSBzZXQgYnV0IA0KICAg d2l0aCB0aGUgZGlmZmVyZW50IFNJSSwgc3RhdGUgdGVhcmRvd24gb24gdGhlIG9sZCBwYXRoIHNo b3VsZCBub3QgDQogICBoYXBwZW4uIFRoaXMgbWF5IGFwcGx5IHRvIGEgcGluZy1wb25nIHR5cGUg aGFuZG92ZXIgd2hlcmUgdGhlIE1OIA0KICAgd2lzaGVzIHRvIGtlZXAgc3RhdGUgdG8gaXRzIG9s ZCBhdHRhY2htZW50IHBvaW50IGluIGNhc2UgaXQgbW92ZXMgDQogICBiYWNrIHRoZXJlLiBGb3Ig aW50ZXJhY3Rpb24gd2l0aCB0aGUgcGluZy1wb25nIHR5cGUgaGFuZG92ZXIsIA0KICAgUW9TLU5T TFAgc2hvdWxkIGRldGVybWluZSB3aGVuIHRvIHNldCB0aGUgTk9fUkVQTEFDRSBmbGFnIA0KICAg ZGVwZW5kaW5nIG9uIHdoZW4gYW5kIHdoZXJlIHRoZSBNTiBoYW5kb3ZlcnMuICBJdCBtYXkgcmVx dWlyZSANCiAgIE5UTFAgdG8gbW9uaXRvciBvciByZWFjdCBvbiB0aGUgbW9iaWxpdHkgZXZlbnRz IG92ZXIgcG9zc2libGUgQVBJcyANCiAgIGFuZCB0byBub3RpZnkgUW9TLU5TTFAgb2YgdGhlIG1v YmlsaXR5IGV2ZW50cyB3aXRoICJwcmltaXRpdmVzIi4gSXQgaXMgDQogICBzdGlsbCBhbiBvcGVu IGlzc3VlIGFuZCBuZWVkcyB0byBiZSBkaXNjdXNzZWQgZnVydGhlci4NCiAgDQotICBRdWVzdGlv biAxOiBpcyB0aGlzIGFuIGltcGxlbWVudGF0aW9uLXNwZWNpZmljIGlzc3VlPw0KIA0KMS4yIFJT Ti1yZWxhdGVkIGlzc3Vlcw0KDQotIEluIHNlY3Rpb24gNS40LCB0aGUgdXNhZ2Ugb2YgUlNOIHdh cyBkZXNjcmliZWQgdG8gY29wZSB3aXRoIGEgDQogIHBpbmctcG9uZyB0eXBlIGhhbmRvdmVyLiBI b3dldmVyLCBpdCBkb2VzIG5vdCBzZWVtcyB0byBiZSANCiAgYXBwcm9wcmlhdGUgdG8gdXNlIFJT TiBmb3IgdGhlIHBpbmctcG9uZyB0eXBlIGhhbmRvdmVyIGJlY2F1c2UgdGhlIA0KICBSU04gTVVT VCBiZSBpbmNyZW1lbnRlZCBmb3IgZWFjaCBuZXcgUkVTRVJWRSBtZXNzYWdlIHdoZXJlIA0KICB0 aGUgcmVzZXJ2YXRpb24gZm9yIHRoZSBzZXNzaW9uIGNoYW5nZXMuIFRoZXJlZm9yZSwgdGhlIFJT Ti1yZWxhdGVkIA0KICB0ZXh0cyBuZWVkIHRvIGJlIHJlbW92ZWQuIFdoYXQgZG8geW91IHRoaW5r Pw0KDQogMi4gTW9iaWxpdHkgb2JqZWN0IGZvcm1hdA0KDQoyLjEgTW9iaWxpdHlfRXZlbnRfQ291 bnRlciAoTUVDKSANCg0KICBBIGNlcnRhaW4gb2JqZWN0IG5lZWRzIHRvIGJlIGNvbnNpZGVyZWQg aW4gb3JkZXIgZm9yIHNvbWUgbm9kZXMgDQogIChlLmcuLCBDUk4pIG9uIHRoZSBzZXNzaW9uIHBh dGggdG8gZGV0ZXJtaW5lIHdoaWNoIFJFU0VSVkUgbWVzc2FnZSANCiAgaXMgbGF0ZXN0IGluIHRo ZSBwaW5nLXBvbmcgdHlwZSBoYW5kb3ZlciBzY2VuYXJpb3MuIFRoZSBNb2JpbGl0eSBvYmplY3Qg DQogIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDQuMi4yIGNhbiBiZSBzb21lIHBvc3NpYmxlIHNvbHV0 aW9uLiBUaGUgTW9iaWxpdHkgDQogIG9iamVjdCBtYXkgYmUgZGVmaW5lZCBpbiB0aGUgTlRMUCAo ZS5nLiwgaW4gR0lNUFMgcGF5bG9hZCkgb3IgTlNMUCANCiAgbWVzc2FnZXMgdG8gbm90aWZ5IG9m IGFueSBtb2JpbGl0eSBldmVudCBleHBsaWNpdGx5LCBhbmQgaXQgbWF5IGNvbnRhaW4gDQogIHZh cmlvdXMgbW9iaWxpdHktcmVsYXRlZCBmaWVsZHMsIGUuZy4sIG1vYmlsaXR5X2V2ZW50X2NvdW50 ZXIgKE1FQykuIFRoZSANCiAgTUVDIGZpZWxkIGNhbiBpbmZvcm0gdGhlIENSTiBvZiB3aGljaCBp bmNvbWluZyBtYXNzYWdlIGlzIHRoZSBsYXRlc3QgDQogIGFuZCBzbyBpdCBpcyB1c2VmdWwgdG8g ZGV0ZWN0IHRoZSBsYXRlc3QgaGFuZG92ZXIgZXZlbnQgZm9yIGF2b2lkaW5nIGFueQ0KICAgY29u ZnVzaW9uIGFib3V0IHdoZXJlIHRvIHNlbmQgYSBjb25maXJtYXRpb24gbWVzc2FnZSBhbmQgdG8g aGFuZGxlDQogICB0aGUgcGluZy1wb25nIHR5cGUgb2YgbW92ZW1lbnQuDQogDQoyLjIgSGFuZG92 ZXJfSW5pdCAoSEkpDQoNCiAgLSAgTW9iaWxpdHkgb2JqZWN0IGlzIGFsc28gdXNlZCB0byBjb3Bl IHdpdGggdGhlICJJbnZhbGlkIE5SIHByb2JsZW0gKHRoZSBsYXN0IA0KICAgICBub2RlIGRldGVj dGlvbiBwcm9ibGVtKSIgYXMgZm9sbG93cy4NCiANCiAgICAgIElmIHRoZSBNTiBtb3ZlcywgY2Fy ZSBzaG91bGQgYmUgdGFrZW4gdG8gcHJldmVudCB0aGUgdGVhcmRvd24gb2YgTlNJUw0KICAgICAg c3RhdGUgb24gdGhlIG9sZCBwYXRoIGJlZm9yZSB0aGUgTlNJUyBzdGF0ZSBpcyByZS1lc3RhYmxp c2hlZCBvbg0KICAgICAgdGhlIG5ldyBwYXRoLiAgSW4gdGhpcyBjYXNlLCBhbiBlcnJvciBtZXNz YWdlIChvciByZWZyZXNoDQogICAgICB0aW1lb3V0KSBzaG91bGQgbm90IGJlIGdlbmVyYXRlZCAo b3IgaGFwcGVuKSB0byBhdm9pZCBhbnkgdGVhcmRvd24NCiAgICAgIG9uIHRoZSBvbGQgcGF0aCBh bmQgY29tbW9uIHBhdGguICBUaGUgcHJvYmxlbSBjYW4gYmUgc29sdmVkIGJ5DQogICAgICB1c2lu ZyBoYW5kb3Zlcl9pbml0IChISSkgZmllbGQgb2YgdGhlIE1vYmlsaXR5IG9iamVjdCBkZXNjcmli ZWQgaW4NCiAgICAgIFNlY3Rpb24gNS40LiAgVGhlIEhJIGZpZWxkIGNhbiBleHBsaWNpdGx5IGlu Zm9ybSBBUiAob3IgQ1JOKSB0aGF0DQogICAgICBhIGhhbmRvdmVyIGlzIG5vdyBpbml0aWF0ZWQs IGFuZCB0aHVzIHRoZSBBUiBkb2VzIG5vdCBpbml0aWF0ZSBhbnkNCiAgICAgIGVycm9yIG1lc3Nh Z2VzIChvciByZWZyZXNoIHRpbWVvdXQpIHdoZW4gaXQgZG9lcyBub3QgcmVjZWl2ZQ0KICAgICAg cmVzcG9uc2VzIHRvIHJlZnJlc2ggbWVzc2FnZXMgZnJvbSB0aGUgTU4uICBJbiB0aGlzIGNhc2Us IHRoZXJlIGFyZQ0KICAgICAgdHdvIGFwcHJvYWNoZXMgd2hpY2ggQVIgY2FuIG1ha2UuIE9uZSBv ZiB0aGUgcG9zc2libGUgYXBwcm9hY2hlcyANCiAgICAgIG1heSBiZSBhIHByb3h5IGZvciB0aGUg TU4gKHRoZSBsYXN0IG5vZGUpIGFuZCBpdCBtYXkgYmUgYWJsZSB0byBzZW5kIA0KICAgICAgUkVT UE9OU0UgbWVzc2FnZXMgaW4gcmVzcG9uc2UgdG8gUkVGUkVTSCAob3IgUkVTRVJWRSkgDQogICAg ICBtZXNzYWdlcyBmcm9tIGEgdXBzdHJlYW0gbm9kZS4gIEFSIG1heSBhbHNvIGZvcndhcmQgdGhl DQogICAgICBlcnJvciBtZXNzYWdlIGluY2x1ZGluZyB0aGUgSEkgZmllbGQgdG93YXJkIENOIHRv IHByZXZlbnQgdGhlIE5JDQogICAgICBmcm9tIHJlbW92aW5nIHRoZSBOU0lTIHN0YXRlLiAgSG93 ZXZlciwgaXQgaXMgc2lsbCBhbiBvcGVuIGlzc3VlDQogICAgICB3aGV0aGVyIHRoZSBoaW50IGlu Zm9ybWF0aW9uIHN1Y2ggYXMgdGhlIEhJIGZpZWxkIHRocm91Z2ggTlNJUw0KICAgICAgc2lnbmFs aW5nIG1lc3NhZ2VzIG5lZWRzIHRvIGJlIGZvcndhcmRlZC4NCiANCiAgICAgIFEuMyBUaG9zZSBp c3N1ZXMgYXJlIHJlbGF0ZWQgdG8gdGhlIHVzYWdlLXJlbGF0ZWQgaXNzdWUgb2YgDQogICAgICBN b2JpbGl0eSBvYmplY3QuIERvZXMgdGhlIG1vYmlsaXR5IG9iamVjdCBuZWVkIHRvIGJlIGluY2x1 ZGVkIGluIE54TFAgDQogICAgICBtZXNzYWdlcz8uDQoNCg0KIFRoYW5rcywNCg0KU3VuZy1IeXVj aw== --===============1498575244== 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 --===============1498575244==-- From nsis-bounces@ietf.org Wed Aug 03 09:44:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0JXX-0008SF-Sl; Wed, 03 Aug 2005 09:44:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0JXW-0008Rq-J0 for nsis@megatron.ietf.org; Wed, 03 Aug 2005 09:44:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16619 for ; Wed, 3 Aug 2005 09:44:08 -0400 (EDT) Received: from pollux.ietf63.ietf.org ([86.255.2.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0K4D-0001d5-DL for nsis@ietf.org; Wed, 03 Aug 2005 10:17:57 -0400 Received: from happy (open-30-129.ietf63.ietf.org [86.255.30.129]) by pollux.ietf63.ietf.org (Postfix) with ESMTP id 9D1A437 for ; Wed, 3 Aug 2005 06:44:04 -0700 (PDT) Message-ID: <002101c59831$ccb8cdd0$811eff56@happy> From: "Sung-Hyuck Lee" To: Date: Wed, 3 Aug 2005 22:46:50 +0900 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 1.1 (+) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Subject: [NSIS] NSIS mobility issue#12 "Path Update" Terminology issue 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="===============0903071020==" Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org --===============0903071020== Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 SXNzdWVzIzEyOiB0aGUgdGVybWlub2xvZ3ksICJQYXRoIFVwZGF0ZSIgDQogICANCi0gIFRoZSB0 ZXJtLCAiUGF0aCBVcGRhdGUiIGhhcyBiZWVuIGNob3NlbiAgc2luY2UgdGhlIGluaXRpYWwgDQog ICAgKE5TSVMtbW9iaWxpdHkpIG1hbnlmb2xrcy1kcmFmdCwgYnV0IHNvbWUgZm9sa3MgdGhpbmsg dGhhdCANCiAgICB0aGUgdGVybSBkb2VzIG5vdCBhcHByb3ByaWF0ZWx5IHJlcHJlc2VudCB0aGUg bWVhbmluZyBvZiANCiAgICBOU0lTIHN0YXRlIHJlY292ZXJ5LiAgQXV0aG9ycyB3b3VsZCBsaWtl IHRvIGtub3cgd2hldGhlciANCiAgICB0aGUgdGVybSAiUGF0aCBVcGRhdGUiIG5lZWRzIHRvIGJl IGNoYW5nZWQgb3Igbm90LiBXaGF0IA0KICAgIGRvIHlvdSB0aGluaz8NCiANCiAgICBUaGUgY2Fu ZGlkYXRlcyBmb3Igc3Vic3RpdHV0aW9uIG9mIHRoZSB0ZXJtIGFyZSAiU3RhdGUgUmVjb3Zlcnki IGFuZCANCiAgICAiU3RhdGUgVXBkYXRlIi4NCg0KDQogVGhhbmtzLA0KKEthbS1zYS1oYXAtbmkt ZGEpDQoNClN1bmctSHl1Y2sg --===============0903071020== 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 --===============0903071020==-- From nsis-bounces@ietf.org Wed Aug 03 12:51:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0MSW-0005ND-UY; Wed, 03 Aug 2005 12:51:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0MSW-0005N3-5j for nsis@megatron.ietf.org; Wed, 03 Aug 2005 12:51:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00727 for ; Wed, 3 Aug 2005 12:51:09 -0400 (EDT) Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0MzD-0001oQ-JC for nsis@ietf.org; Wed, 03 Aug 2005 13:25:01 -0400 Received: from open-31-127.ietf63.ietf.org (open-31-127.ietf63.ietf.org [86.255.31.127]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 09CDB1BAC99; Wed, 3 Aug 2005 18:51:00 +0200 (CEST) Date: Wed, 03 Aug 2005 18:50:57 +0200 From: Martin Stiemerling To: "McDonald, Andrew" , nsis@ietf.org Subject: Re: [NSIS] QoS NSLP Issues 20 and 17 - sequence numbers, etc Message-ID: X-Mailer: Mulberry/3.1.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Content-Transfer-Encoding: 7bit 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: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi Andrew, | Some thoughts related mainly to issue 20 (RSN wrap around) and partly to | issue 17 (failure and restart handling). | | At IETF62, when I brought up the issue of sequence number handling, Dave | Oran said "do what the routing people do". I'm not sure it's quite so | obvious. :-) | | As I understand it, the main point that Dave was getting at with his | comment, was a suggestion to use a linear sequence number space rather | than a circular one. Auxiliary questions relate to what happens when | RSNs reach their maximum possible value, what happens when nodes | restart, etc. I have a question about the node restart case. If a node restarts, a new full D-Mode exchange (plus probably C-MODE etc) would been started between these two nodes. Couldn't this knowledge been used to be at least aware of a new start of the RSN value? | | The idea of a circular sequence space would need to be discounted | immediately if the ARPANET sequence bug scenario could be applied [see | footnote]. As far as I can tell, this does not appear to be the case. | The ARPANET sequence bug issue principally stems from the fact that a | router can receive the same piece of routing information from multiple | different sources (i.e. its neighbouring routers), and these all come | from the same sequence space. In the case of the QoS NSLP the sequence | numbers are peer-to-peer (with the peer identified by the SII), so this | issue does not apply. | | If we were to use a circular sequence space, then wrapping would likely | be done as described in RFC1982. Even then, wrapping isn't going to be | very common - assuming the RSN is incremented once every 30s then a | 32-bit RSN would give us about 4000 years. | | Like TCP, SCTP uses a circular sequence space (as per RFC1982). DCCP | also wraps sequence numbers, but uses an asymmetric window with losses | assumed to be more common than reordering. | | This leaves the question of what to do when the 'sending' node restarts. | If the new sequence number is 'bigger' than the old one, then things | would simply proceed. If it is 'smaller' then a method of | resynchronizing would be required. One method might be for the receiving | node to send an error message back informing the sender of the current | sequence number. However, this would also be sent in the event of | reordered messages. A better method might be to use an epoch identifier. | | OSPF uses a linear sequence space. When the sequence number reaches the | maximum value then the Link State Advertisement instance must first be | deleted, and then it restarts LSA flooding with the initial sequence | number. This would be a problem for the QoS NSLP since RSNs are | peer-to-peer (within the context of a session), but sessions are | end-to-end. However, you could possibly propagate an error back to the | QNI. | | When a router restarts it can learn the value of the LS sequence number | from seeing its own LSAs sent back to it. The nearest equivalent for the | QoS NSLP would probably be for the receiver to send an error back giving | the current sequence number so that the sender can reschronize. Another | alternative is to add an epoch number to the RSN that is incremented on | each reboot (effectively extending the sequence space). | | I haven't currently got a strong preference either way. | | The principle of the linear sequence space is "reaching the maximum | never happens, so we don't need to worry about it too much". However, it | seems to me that we still have to say something about what happens. It | shouldn't get totally wedged because you can always just leave the soft | state to expire. Is that good enough? You may be able to pass an error | back along the path to allow something better. | | Using a circular sequence space requires the definition of the wrapping | rules. I'm fine with a circular sequence space and the fact that wrapping rules are needed. However, if people think that 32 bits are too small and will result in wrapping happening to often, I wouldn't mind to go to 64 bit. My believe is, that 32 bits and wrapping rules are good. | | If I had to go for one or the other, I'd probably currently pick a | circular sequence space on the principle that we can just reference | RFC1982. | | In either case, the use of an epoch number to identify node restarts | seems like a good idea. As to whether this should be in GIMPS or the | NSLP (NTLP issue #43), I'd probably go with the NSLP using a common | object used by multiple NSLPs. If your internal software architecture is | suitable, you can just have one epoch number for all the NSLPs you have, | or you can have a different one for each. | | Note: Currently the NAT/FW draft just says 'wrap' and nothing more than | that. So, some of the same thinking may need to be done there. The MSN handling is somewhat different in the NATFW NSLP case compared to QoS in the sense of restarts. (the wrapping problem is the same). The MSNs are generated by the NI , maintained by it, and have only a significance within a single sessions. If now a node in between reboots, there is no harm out of the MSNs, since they are used end-to-end. If the NI reboots, it is very likely that the session used afterwards by the NI has a different session ID and thus the MSN value out of the old session does not matter. Martin _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Aug 03 12:51:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0MSX-0005Nc-CA; Wed, 03 Aug 2005 12:51:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0MSW-0005N4-7k for nsis@megatron.ietf.org; Wed, 03 Aug 2005 12:51:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00728 for ; Wed, 3 Aug 2005 12:51:09 -0400 (EDT) Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0MzC-0001oP-Ir for nsis@ietf.org; Wed, 03 Aug 2005 13:25:01 -0400 Received: from open-31-127.ietf63.ietf.org (open-31-127.ietf63.ietf.org [86.255.31.127]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 981391BAC4D; Wed, 3 Aug 2005 18:50:59 +0200 (CEST) Date: Wed, 03 Aug 2005 18:46:45 +0200 From: Martin Stiemerling To: "McDonald, Andrew" , nsis@ietf.org Subject: Re: [NSIS] QoS NSLP Issues 20 and 17 - sequence numbers, etc Message-ID: <13C69862E1AE122C9CCA832A@open-31-127.ietf63.ietf.org> In-Reply-To: <42E78C72.5040408@roke.co.uk> References: <42E78C72.5040408@roke.co.uk> X-Mailer: Mulberry/3.1.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Content-Transfer-Encoding: 7bit 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: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi Andrew, | Some thoughts related mainly to issue 20 (RSN wrap around) and partly to | issue 17 (failure and restart handling). | | At IETF62, when I brought up the issue of sequence number handling, Dave | Oran said "do what the routing people do". I'm not sure it's quite so | obvious. :-) | | As I understand it, the main point that Dave was getting at with his | comment, was a suggestion to use a linear sequence number space rather | than a circular one. Auxiliary questions relate to what happens when | RSNs reach their maximum possible value, what happens when nodes | restart, etc. I have a question about the node restart case. If a node restarts, a new full D-Mode exchange (plus probably C-MODE etc) would been started between these two nodes. Couldn't this knowledge been used to be at least aware of a new start of the RSN value? | | The idea of a circular sequence space would need to be discounted | immediately if the ARPANET sequence bug scenario could be applied [see | footnote]. As far as I can tell, this does not appear to be the case. | The ARPANET sequence bug issue principally stems from the fact that a | router can receive the same piece of routing information from multiple | different sources (i.e. its neighbouring routers), and these all come | from the same sequence space. In the case of the QoS NSLP the sequence | numbers are peer-to-peer (with the peer identified by the SII), so this | issue does not apply. | | If we were to use a circular sequence space, then wrapping would likely | be done as described in RFC1982. Even then, wrapping isn't going to be | very common - assuming the RSN is incremented once every 30s then a | 32-bit RSN would give us about 4000 years. | | Like TCP, SCTP uses a circular sequence space (as per RFC1982). DCCP | also wraps sequence numbers, but uses an asymmetric window with losses | assumed to be more common than reordering. | | This leaves the question of what to do when the 'sending' node restarts. | If the new sequence number is 'bigger' than the old one, then things | would simply proceed. If it is 'smaller' then a method of | resynchronizing would be required. One method might be for the receiving | node to send an error message back informing the sender of the current | sequence number. However, this would also be sent in the event of | reordered messages. A better method might be to use an epoch identifier. | | OSPF uses a linear sequence space. When the sequence number reaches the | maximum value then the Link State Advertisement instance must first be | deleted, and then it restarts LSA flooding with the initial sequence | number. This would be a problem for the QoS NSLP since RSNs are | peer-to-peer (within the context of a session), but sessions are | end-to-end. However, you could possibly propagate an error back to the | QNI. | | When a router restarts it can learn the value of the LS sequence number | from seeing its own LSAs sent back to it. The nearest equivalent for the | QoS NSLP would probably be for the receiver to send an error back giving | the current sequence number so that the sender can reschronize. Another | alternative is to add an epoch number to the RSN that is incremented on | each reboot (effectively extending the sequence space). | | I haven't currently got a strong preference either way. | | The principle of the linear sequence space is "reaching the maximum | never happens, so we don't need to worry about it too much". However, it | seems to me that we still have to say something about what happens. It | shouldn't get totally wedged because you can always just leave the soft | state to expire. Is that good enough? You may be able to pass an error | back along the path to allow something better. | | Using a circular sequence space requires the definition of the wrapping | rules. I'm fine with a circular sequence space and the fact that wrapping rules are needed. However, if people think that 32 bits are too small and will result in wrapping happening to often, I wouldn't mind to go to 64 bit. My believe is, that 32 bits and wrapping rules are good. | | If I had to go for one or the other, I'd probably currently pick a | circular sequence space on the principle that we can just reference | RFC1982. | | In either case, the use of an epoch number to identify node restarts | seems like a good idea. As to whether this should be in GIMPS or the | NSLP (NTLP issue #43), I'd probably go with the NSLP using a common | object used by multiple NSLPs. If your internal software architecture is | suitable, you can just have one epoch number for all the NSLPs you have, | or you can have a different one for each. | | Note: Currently the NAT/FW draft just says 'wrap' and nothing more than | that. So, some of the same thinking may need to be done there. The MSN handling is somewhat different in the NATFW NSLP case compared to QoS in the sense of restarts. (the wrapping problem is the same). The MSNs are generated by the NI , maintained by it, and have only a significance within a single sessions. If now a node in between reboots, there is no harm out of the MSNs, since they are used end-to-end. If the NI reboots, it is very likely that the session used afterwards by the NI has a different session ID and thus the MSN value out of the old session does not matter. Martin _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Aug 03 14:25:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0Nvl-0003tP-Ls; Wed, 03 Aug 2005 14:25:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0Nvi-0003sj-UK; Wed, 03 Aug 2005 14:25:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05125; Wed, 3 Aug 2005 14:25:25 -0400 (EDT) Received: from difra-computer.de ([81.169.157.103] helo=www.difra-computer.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0OSP-0005YN-6L; Wed, 03 Aug 2005 14:59:16 -0400 Received: from win2003.dickmann2003.home (p548A311C.dip.t-dialin.net [84.138.49.28]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by www.difra-computer.de (Postfix) with ESMTP id EA9783E402B; Wed, 3 Aug 2005 20:22:03 +0200 (CEST) Received: from noti ([192.168.25.2]) by win2003.dickmann2003.home with Microsoft SMTPSVC(6.0.3790.211); Wed, 3 Aug 2005 20:19:46 +0200 From: "Christian Dickmann" To: , Date: Wed, 3 Aug 2005 20:22:25 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcWYWEwsCvsHLJI9QZmaDX+hW2VJtg== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Message-ID: X-OriginalArrivalTime: 03 Aug 2005 18:19:47.0000 (UTC) FILETIME=[EDDA2380:01C59857] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit Cc: "'Andreas W.'" , nsis_imp@cs.uni-goettingen.de, 'Xiaoming Fu' , 'Bernd Schloer' , 'Tschofenig Hannes' Subject: [NSIS] Bugfix-Release of NSIS implementation (v0.1.1) 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: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi all, we are pleased to announce the availability of the NSIS suite release 0.1.1, currently implementing GIMPS-06 I-D and the Ping Tool "NSLP"-01, running on the Linux. http://user.informatik.uni-goettingen.de/~nsis/ The new version contains a lot of bugfixes, including: - Improved support of the message formats - Improved message validation - Improved message processing - A lot of small bugfixes In addition, the new version contains a script to create TLS cerificates and a section in the README file on how to use TLS. The new release of the NSIS implementation is accompanied by a new release of our Ethereal dissector. It now supports draft 06 and contains a lot of bugfixes and extensions. The new conversation tracking allows to dissect sessions using any TCP port. You will find both releases at the URL provided above. Christian Dickmann University of Goettingen Acknowledgements ============================================================== Thanks to all community members who contributed ideas, reported problems, provided assitance, and have helped us greatly to reach the status of this release. For further information =================================================================== Questions, enquiries, comments, please kindly report to the following mailing list: nsis_imp@cs.uni-goettingen.de _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Aug 04 02:16:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0Z2J-0003SD-NG; Thu, 04 Aug 2005 02:16:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0Z2H-0003S2-K4 for nsis@megatron.ietf.org; Thu, 04 Aug 2005 02:16:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27309 for ; Thu, 4 Aug 2005 02:16:56 -0400 (EDT) Received: from smtp2.mei.co.jp ([133.183.129.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0ZZ3-00074z-Lm for nsis@ietf.org; Thu, 04 Aug 2005 02:50:50 -0400 Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp2.mei.co.jp (8.12.10/3.7W/bulls) with ESMTP id j746GTRj017983; Thu, 4 Aug 2005 15:16:29 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx2) with ESMTP id j746GU404996; Thu, 4 Aug 2005 15:16:30 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/astros) with ESMTP id j746GTt10275; Thu, 4 Aug 2005 15:16:29 +0900 (JST) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [NSIS] NSIS-mobility Issue #11: Mobility Object Date: Thu, 4 Aug 2005 14:14:10 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BD4B23CA@pslexc01.psl.local> Thread-topic: [NSIS] NSIS-mobility Issue #11: Mobility Object Thread-index: AcWYMF2/dKlofhMdS0+KP2POXGrdkgAih92w From: "Cheng Hong" To: "Sung-Hyuck Lee" , X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Content-Transfer-Encoding: quoted-printable 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: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi Sung-Hyuck, Regarding the point 1.1, I think from standards point of view, the API details should be left to implementation. But, the "primitives" and the functional requirements on the interaction between NTLP, QoS-NSLP should be defined clearly. (assuming you are referring to the API part of the text ?:) cheers Cheng Hong =20 > -----Original Message----- > From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On=20 > Behalf Of Sung-Hyuck Lee > Sent: Wednesday, August 03, 2005 9:40 PM > To: nsis@ietf.org > Subject: [NSIS] NSIS-mobility Issue #11: Mobility Object=20 >=20 > Hi all, >=20 > NSIS-mobility draft authors have newly identified the=20 > following issues which need to be addressed. >=20 > 1. Ping-pong type handover-related issues. >=20 > 1.1 NO_REPLACE flag and related-hint information >=20 > - Description: An NE (e.g., QNE) can determine if it is a=20 > merging point=20 > (i.e. an NSLP CRN) of the old and new paths, and then it can=20 > perform an involved state setup on the new path and state teardown=20 > on the old path. However, if the QNE receives an NSIS message=20 > (e.g., RESERVE) with a special flag (e.g., NO_REPLACE=20 > flag) set but=20 > with the different SII, state teardown on the old path should not=20 > happen. This may apply to a ping-pong type handover where the MN=20 > wishes to keep state to its old attachment point in case it moves=20 > back there. For interaction with the ping-pong type handover,=20 > QoS-NSLP should determine when to set the NO_REPLACE flag=20 > depending on when and where the MN handovers. It may require=20 > NTLP to monitor or react on the mobility events over possible APIs=20 > and to notify QoS-NSLP of the mobility events with=20 > "primitives". It is=20 > still an open issue and needs to be discussed further. > =20 > - Question 1: is this an implementation-specific issue? > =20 > 1.2 RSN-related issues >=20 > - In section 5.4, the usage of RSN was described to cope with a > ping-pong type handover. However, it does not seems to be > appropriate to use RSN for the ping-pong type handover because the > RSN MUST be incremented for each new RESERVE message where > the reservation for the session changes. Therefore, the RSN-related > texts need to be removed. What do you think? >=20 > 2. Mobility object format >=20 > 2.1 Mobility_Event_Counter (MEC)=20 >=20 > A certain object needs to be considered in order for some nodes > (e.g., CRN) on the session path to determine which RESERVE message > is latest in the ping-pong type handover scenarios. The=20 > Mobility object > described in Section 4.2.2 can be some possible solution.=20 > The Mobility > object may be defined in the NTLP (e.g., in GIMPS payload) or NSLP > messages to notify of any mobility event explicitly, and it=20 > may contain > various mobility-related fields, e.g.,=20 > mobility_event_counter (MEC). The > MEC field can inform the CRN of which incoming massage is the latest > and so it is useful to detect the latest handover event for=20 > avoiding any > confusion about where to send a confirmation message and to handle > the ping-pong type of movement. > =20 > 2.2 Handover_Init (HI) >=20 > - Mobility object is also used to cope with the "Invalid=20 > NR problem (the last=20 > node detection problem)" as follows. > =20 > If the MN moves, care should be taken to prevent the=20 > teardown of NSIS > state on the old path before the NSIS state is re-established on > the new path. In this case, an error message (or refresh > timeout) should not be generated (or happen) to avoid=20 > any teardown > on the old path and common path. The problem can be solved by > using handover_init (HI) field of the Mobility object=20 > described in > Section 5.4. The HI field can explicitly inform AR (or=20 > CRN) that > a handover is now initiated, and thus the AR does not=20 > initiate any > error messages (or refresh timeout) when it does not receive > responses to refresh messages from the MN. In this=20 > case, there are > two approaches which AR can make. One of the possible=20 > approaches=20 > may be a proxy for the MN (the last node) and it may be=20 > able to send=20 > RESPONSE messages in response to REFRESH (or RESERVE)=20 > messages from a upstream node. AR may also forward the > error message including the HI field toward CN to prevent the NI > from removing the NSIS state. However, it is sill an open issue > whether the hint information such as the HI field through NSIS > signaling messages needs to be forwarded. > =20 > Q.3 Those issues are related to the usage-related issue of=20 > Mobility object. Does the mobility object need to be=20 > included in NxLP=20 > messages?. >=20 >=20 > Thanks, >=20 > Sung-Hyuck >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Aug 04 02:57:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0Zfz-0000Mt-3W; Thu, 04 Aug 2005 02:57:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0Zfx-0000MN-U3; Thu, 04 Aug 2005 02:57:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05551; Thu, 4 Aug 2005 02:57:56 -0400 (EDT) Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0aCn-0000Nb-6i; Thu, 04 Aug 2005 03:31:54 -0400 Received: from open-31-127.ietf63.ietf.org (open-28-255.ietf63.ietf.org [86.255.28.255]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 2C72F1BAC4D; Thu, 4 Aug 2005 08:57:47 +0200 (CEST) Date: Thu, 04 Aug 2005 08:57:39 +0200 From: Martin Stiemerling To: nsis Message-ID: <616439DE1ED0F9AC4306C691@753F3B888A9969457862729D> X-Mailer: Mulberry/3.1.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Content-Transfer-Encoding: 7bit Cc: NSIS Implemeters Subject: [NSIS] Slides NSIS Interop Paris 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: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Dear all, The slides about the NSIS/NTLP Interop Event held in Paris are available here: http://www.stiemerling.org/ietf/ietf63/ietf63_nsis_interop.ppt Martin _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Aug 04 03:20:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0a1X-00019t-0S; Thu, 04 Aug 2005 03:20:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0a1V-00019o-PJ for nsis@megatron.ietf.org; Thu, 04 Aug 2005 03:20:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07025 for ; Thu, 4 Aug 2005 03:20:09 -0400 (EDT) Received: from gecko.sbs.de ([194.138.37.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0aYH-0001NU-NU for nsis@ietf.org; Thu, 04 Aug 2005 03:54:08 -0400 Received: from mail1.sbs.de (mail1.sbs.de [192.129.41.35]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id j747JrFh032436 for ; Thu, 4 Aug 2005 09:19:53 +0200 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id j747JrZO024549 for ; Thu, 4 Aug 2005 09:19:53 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.0); Thu, 4 Aug 2005 09:19:53 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 4 Aug 2005 09:19:53 +0200 Message-ID: Thread-Topic: slides Thread-Index: AcWYxOd//MnvcPJMTWW9XHk7vUUfEQ== From: "Tschofenig, Hannes" To: X-OriginalArrivalTime: 04 Aug 2005 07:19:53.0561 (UTC) FILETIME=[E8BC8C90:01C598C4] X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Content-Transfer-Encoding: quoted-printable Subject: [NSIS] slides 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: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org hi all, the nsis slides can be found at:=20 http://www.ietf-nsis.org/nsis/IETF63/ please send me your slides (if you haven't done already).=20 ciao hannes _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Aug 04 04:37:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0bE9-0005XQ-Vc; Thu, 04 Aug 2005 04:37:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0bE7-0005XK-Lo for nsis@megatron.ietf.org; Thu, 04 Aug 2005 04:37:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12233 for ; Thu, 4 Aug 2005 04:37:17 -0400 (EDT) Received: from mail121.messagelabs.com ([216.82.241.195]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1E0bkt-0005Kc-Bj for nsis@ietf.org; Thu, 04 Aug 2005 05:11:16 -0400 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-2.tower-121.messagelabs.com!1123144624!3954921!1 X-StarScan-Version: 5.4.15; banners=-,-,- X-Originating-IP: [192.128.133.132] Received: (qmail 700 invoked from network); 4 Aug 2005 08:37:04 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (192.128.133.132) by server-2.tower-121.messagelabs.com with SMTP; 4 Aug 2005 08:37:04 -0000 Received: from kcclust06evs1.ugd.att.com (135.38.164.88) by attrh3i.attrh.att.com (7.2.052) id 42E3BC2B0027CB73; Thu, 4 Aug 2005 04:37:03 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 4 Aug 2005 03:37:02 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA060CE6B7@KCCLUST06EVS1.ugd.att.com> Thread-Topic: Y.1541-QOSM -- Link to Recommendation Y.1541 Thread-Index: AcWXNXSSVouKhWpLTAeKaluoMHGN7wBmQvqA From: "Ash, Gerald R \(Jerry\), ALABS" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: quoted-printable Cc: "Ash, Gerald R \(Jerry\), ALABS" , "Morton, Alfred C, JR \(Al\), ALABS" , mankin@psg.com Subject: [NSIS] Y.1541-QOSM -- Link to Recommendation Y.1541 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: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org All, ICW NSIS work on the Y.1541-QOSM http://ietf.org/internet-drafts/draft-ash-nsis-y1541-qosm-00.txt, Allison requested that Recommendation Y.1541 be made (easily) available as a liaison from ITU-T to IETF. This is underway and I'll notify the list when available. In the meantime, Al Morton has kindly posted a pre-submission copy of the revised Y.1541 at http://home.comcast.net/~acmacm/IDcheck/y1541_Rev_04.doc. Thanks, Jerry _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Aug 04 05:10:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0bkg-00021C-RS; Thu, 04 Aug 2005 05:10:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0bkf-00020B-47 for nsis@megatron.ietf.org; Thu, 04 Aug 2005 05:10:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14841 for ; Thu, 4 Aug 2005 05:10:54 -0400 (EDT) From: john.loughney@nokia.com Received: from mgw-ext04.nokia.com ([131.228.20.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0cHV-0007As-8g for nsis@ietf.org; Thu, 04 Aug 2005 05:44:54 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j7494YtX002926 for ; Thu, 4 Aug 2005 12:04:40 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Aug 2005 12:10:03 +0300 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Aug 2005 12:10:02 +0300 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 4 Aug 2005 12:10:02 +0300 Message-ID: <1AA39B75171A7144A73216AED1D7478D6CEAE0@esebe100.NOE.Nokia.com> Thread-Topic: GIMPS is now GIST Thread-Index: AcWY1EtnzmSkmhDuTsG5plr5+PZcfg== To: X-OriginalArrivalTime: 04 Aug 2005 09:10:02.0787 (UTC) FILETIME=[4C246730:01C598D4] X-Spam-Score: 0.3 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: quoted-printable Subject: [NSIS] GIMPS is now GIST 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: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi all, At the NSIS meeting today, there was a discussion about the NTLP name. = The current NTLP name, GIMPS, has negative connetations in American English. Robert had = a slide of=20 potential names, and the sense of the room was that GIST - General = Internet Signaling Transport - was a sound name, thanks Henning. If anyone has any issues with this name, please speak-up or I will ask = Robert to resubmit the draft with new name. Thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Aug 04 07:29:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0dvD-0003lX-Mq; Thu, 04 Aug 2005 07:29:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0dvC-0003lS-OV for nsis@megatron.ietf.org; Thu, 04 Aug 2005 07:29:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28179 for ; Thu, 4 Aug 2005 07:29:57 -0400 (EDT) Received: from mail.saic-abingdon.com ([12.167.146.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0eS5-0005hB-Ad for nsis@ietf.org; Thu, 04 Aug 2005 08:03:57 -0400 Received: from no.name.available by mail.saic-abingdon.com via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with ESMTP; Thu, 4 Aug 2005 07:31:26 -0400 Received: from bh-exchange02.saic-abingdon.com ([172.17.10.226]) by bh-exchangefe.saic-abingdon.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 4 Aug 2005 07:31:52 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [NSIS] Y.1541-QOSM -- Link to Recommendation Y.1541 Date: Thu, 4 Aug 2005 07:30:36 -0400 Message-ID: <2FE23D25B7292B489A217D1965CDA86672641B@bh-exchange02.saic-abingdon.com> Thread-Topic: Y.1541-QOSM -- Link to Recommendation Y.1541 Thread-Index: AcWXNXSSVouKhWpLTAeKaluoMHGN7wBmQvqAAAZbo7s= From: "Roy, Radhika \(AEAD\)" To: X-OriginalArrivalTime: 04 Aug 2005 11:31:52.0750 (UTC) FILETIME=[1C79B4E0:01C598E8] X-Spam-Score: 0.8 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Cc: mankin@psg.com X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0642553482==" Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. --===============0642553482== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C598E8.1A5C7F12" This is a multi-part message in MIME format. ------_=_NextPart_001_01C598E8.1A5C7F12 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, all: =20 I like to appreciate Allison to take a step for accessing the non-IETF = standard documents by the IETF members. It is extremely important for = all of us should the standard bodies/fora need work cooperatively with = the IETF. =20 Best regards, Radhika ________________________________ From: nsis-bounces@ietf.org on behalf of Ash, Gerald R (Jerry), ALABS Sent: Thu 8/4/2005 4:37 AM To: nsis@ietf.org Cc: Ash, Gerald R (Jerry), ALABS; Morton, Alfred C,JR (Al), ALABS; = mankin@psg.com Subject: [NSIS] Y.1541-QOSM -- Link to Recommendation Y.1541 All, ICW NSIS work on the Y.1541-QOSM http://ietf.org/internet-drafts/draft-ash-nsis-y1541-qosm-00.txt, Allison requested that Recommendation Y.1541 be made (easily) available as a liaison from ITU-T to IETF. This is underway and I'll notify the list when available. In the meantime, Al Morton has kindly posted a pre-submission copy of the revised Y.1541 at http://home.comcast.net/~acmacm/IDcheck/y1541_Rev_04.doc. Thanks, Jerry _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis ------_=_NextPart_001_01C598E8.1A5C7F12 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A= =0A= =0A= [NSIS] Y.1541-QOSM -- Link to Recommendation Y.1541=0A= =0A= =0A=
=0A=
=0A=
=0A=
Hi, = all:
=0A=
 
=0A=
I like to appreciate Allison = to take a step =0A= for accessing the non-IETF standard documents by the IETF members. It is =0A= extremely important for all of us should the standard bodies/fora need = work =0A= cooperatively with the IETF.
=0A=
 
=0A=
Best regards,
=0A=
Radhika
=0A=

=0A=
=0A= From: nsis-bounces@ietf.org on = behalf of Ash, =0A= Gerald R (Jerry), ALABS
Sent: Thu 8/4/2005 4:37 = AM
To: =0A= nsis@ietf.org
Cc: Ash, Gerald R (Jerry), ALABS; Morton, Alfred = C,JR =0A= (Al), ALABS; mankin@psg.com
Subject: [NSIS] Y.1541-QOSM -- = Link to =0A= Recommendation Y.1541

=0A=
=0A=

All,

ICW NSIS work on the Y.1541-QOSM
http://ietf.org/internet-drafts/draft-ash-nsis-y1541-qosm-00.txt,Allison =0A= requested that Recommendation Y.1541 be made (easily) available
as a = liaison =0A= from ITU-T to IETF.  This is underway and I'll notify the
list = when =0A= available.

In the meantime, Al Morton has kindly posted a = pre-submission =0A= copy of
the revised Y.1541 at
http://= home.comcast.net/~acmacm/IDcheck/y1541_Rev_04.doc.

Thanks,
= Jerry



_______________________________________________
n= sis =0A= mailing list
nsis@ietf.org
https://www1.ietf.or= g/mailman/listinfo/nsis

=0A= =0A= =0A= ------_=_NextPart_001_01C598E8.1A5C7F12-- --===============0642553482== 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 --===============0642553482==-- From nsis-bounces@ietf.org Thu Aug 04 11:38:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0hnP-0006Cc-TF; Thu, 04 Aug 2005 11:38:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0hnO-0006CU-Lf for nsis@megatron.ietf.org; Thu, 04 Aug 2005 11:38:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19860 for ; Thu, 4 Aug 2005 11:38:08 -0400 (EDT) Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0iKF-0007Rh-QC for nsis@ietf.org; Thu, 04 Aug 2005 12:12:11 -0400 Received: from rsys005a.comm.ad.roke.co.uk ([193.118.193.85]) by rsys001x.roke.co.uk (8.12.8/8.12.8) with ESMTP id j74FbVFt007505; Thu, 4 Aug 2005 16:37:31 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Received: from [127.0.0.1] (orion.roke.co.uk [193.118.192.66]) by rsys002a.roke.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id PJSG1VR5; Thu, 4 Aug 2005 16:40:14 +0100 MIME-Version: 1.0 Content-class: urn:content-classes:message Subject: Re: [NSIS] QoS NSLP Issues 20 and 17 - sequence numbers, etc Date: Thu, 4 Aug 2005 16:36:15 +0100 Message-ID: <42F235EF.1050308@roke.co.uk> Thread-Topic: [NSIS] QoS NSLP Issues 20 and 17 - sequence numbers, etc Thread-Index: AcWZCs5zby9M5OOuQP22IamGxqykfA== From: "McDonald, Andrew" To: "Martin Stiemerling" X-MailScanner-rsys001x: Found to be clean X-MailScanner-From: andrew.mcdonald@roke.co.uk X-Spam-Score: 0.8 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 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="===============1718002074==" Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. --===============1718002074== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5990A.CE500300" Content-class: urn:content-classes:message This is a multi-part message in MIME format. ------_=_NextPart_001_01C5990A.CE500300 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Martin Stiemerling wrote: >I have a question about the node restart case. If a node restarts, >a new full D-Mode exchange (plus probably C-MODE etc) would been >started between these two nodes. Couldn't this knowledge been used to = be >at least aware of a new start of the RSN value? > > =20 > I'm not sure that this event necessarily indicates a node restart.=20 Depending on how the various timers (NSLP state timer, routing state=20 timeout, MA timeout) are configured, I would have thought that it would=20 be possible for a full D-mode exchange to occur without actually having=20 a node restart. Andrew ------_=_NextPart_001_01C5990A.CE500300 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [NSIS] QoS NSLP Issues 20 and 17 - sequence numbers, = etc

Martin Stiemerling wrote:

>I have a question about the node restart case. If = a node restarts,
>a new full D-Mode exchange (plus probably C-MODE = etc) would been
>started between these two nodes. Couldn't this = knowledge been used to be
>at least aware of a new start of the RSN = value?
>
> 
>
I'm not sure that this event necessarily indicates a = node restart.
Depending on how the various timers (NSLP state = timer, routing state
timeout, MA timeout) are configured, I would have = thought that it would
be possible for a full D-mode exchange to occur = without actually having
a node restart.

Andrew

------_=_NextPart_001_01C5990A.CE500300-- --===============1718002074== 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 --===============1718002074==-- From nsis-bounces@ietf.org Thu Aug 04 14:35:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0kZS-0003Qq-Jf; Thu, 04 Aug 2005 14:35:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0kZR-0003Qh-AJ for nsis@megatron.ietf.org; Thu, 04 Aug 2005 14:35:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28449 for ; Thu, 4 Aug 2005 14:35:55 -0400 (EDT) Received: from iramx1.ira.uni-karlsruhe.de ([141.3.10.80] ident=[U2FsdGVkX19LXzoNI70vWeM4FHJWh9S8I5TiQ3m5rt8=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0l6M-0003aW-Fr for nsis@ietf.org; Thu, 04 Aug 2005 15:09:59 -0400 Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by iramx1.ira.uni-karlsruhe.de with esmtps id 1E0kZF-0006uh-3e for ; Thu, 04 Aug 2005 20:35:53 +0200 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 C6C29BEA2 for ; Thu, 4 Aug 2005 20:35:44 +0200 (CEST) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1E0kZE-0007zM-FR for nsis@ietf.org; Thu, 04 Aug 2005 20:35:44 +0200 Message-ID: <42F2604A.9070109@tm.uka.de> Date: Thu, 04 Aug 2005 20:36:58 +0200 From: Roland Bless Organization: Institute of Telematics, University of Karlsruhe User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050716) X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: nsis@ietf.org X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Spam-Score: -5.4 (-----) X-Spam-Status: No X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Subject: [NSIS] GIST: On Reverse Path Attacker, NTLP issue #17 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: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi, (see http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue17 for more details) as I already expressed in http://www1.ietf.org/mail-archive/web/nsis/current/msg05085.html I'm in favor of Roberts approach, to document it as residual threat. So I'm not agreeing on Hannes opinion "let's do it". Sure we technically can, but I don't think it is really worth spending the effort, because it is more or less a special type of man in the middle attack, which cannot be prevented anyway by NTLP. Maybe Hannes could elaborate a little bit more...furthermore: maybe some guy from the Security Area could give advise what to do about this issue. Regards, Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Aug 05 03:30:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0weZ-00038V-De; Fri, 05 Aug 2005 03:30:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0weY-00038J-Ts for nsis@megatron.ietf.org; Fri, 05 Aug 2005 03:30:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22122 for ; Fri, 5 Aug 2005 03:30:01 -0400 (EDT) Received: from gecko.sbs.de ([194.138.37.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0xBa-0005kd-Pa for nsis@ietf.org; Fri, 05 Aug 2005 04:04:12 -0400 Received: from mail1.sbs.de (mail1.sbs.de [192.129.41.35]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id j757TjWY022415 for ; Fri, 5 Aug 2005 09:29:45 +0200 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id j757TjDl000825 for ; Fri, 5 Aug 2005 09:29:45 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.0); Fri, 5 Aug 2005 09:29:45 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Fri, 5 Aug 2005 09:29:43 +0200 Message-ID: Thread-Topic: interaction between nsis and sip Thread-Index: AcWZj3GzxcpCebrpTD2H+ug1ZyGAVQ== From: "Tschofenig, Hannes" To: X-OriginalArrivalTime: 05 Aug 2005 07:29:45.0612 (UTC) FILETIME=[740A1CC0:01C5998F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: quoted-printable Subject: [NSIS] interaction between nsis and sip 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: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org hi all,=20 this is the document i mentioned during the meeting. http://www.ietf-nsis.org/cache/draft-martin-nsis-nslp-natfw-sip-01.txt we did something similar by looking at the interaction between mipv6 and the natfw nslp: http://www.ietf.org/internet-drafts/draft-thiruvengadam-nsis-mip6-fw-02. txt ciao hannes _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Aug 05 04:04:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0xBs-0003JM-AK; Fri, 05 Aug 2005 04:04:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0xBr-0003JH-4t for nsis@megatron.ietf.org; Fri, 05 Aug 2005 04:04:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23768 for ; Fri, 5 Aug 2005 04:04:23 -0400 (EDT) Received: from lizzard.sbs.de ([194.138.37.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0xit-0006pg-7V for nsis@ietf.org; Fri, 05 Aug 2005 04:38:35 -0400 Received: from mail2.sbs.de (mail2.sbs.de [192.129.41.66]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id j7584EEl000943; Fri, 5 Aug 2005 10:04:14 +0200 Received: from fthw9xpa.ww002.siemens.net (fthw9xpa.ww002.siemens.net [157.163.133.222]) by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id j7584DcC001095; Fri, 5 Aug 2005 10:04:13 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.0); Fri, 5 Aug 2005 10:04:13 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: AW: [NSIS] GIST: On Reverse Path Attacker, NTLP issue #17 Date: Fri, 5 Aug 2005 10:02:37 +0200 Message-ID: Thread-Topic: [NSIS] GIST: On Reverse Path Attacker, NTLP issue #17 Thread-Index: AcWZI69PfNFO1c9yTmWt8LcDYThxzQAbz6Jg From: "Tschofenig, Hannes" To: "Roland Bless" , X-OriginalArrivalTime: 05 Aug 2005 08:04:13.0365 (UTC) FILETIME=[44842E50:01C59994] X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: quoted-printable 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: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org hi roland,=20 i think that the additional effort is mostly in a small piece of = protocol specification.=20 there is almost no difference from a computational point of view.=20 =20 ciao hannes > -----Urspr=FCngliche Nachricht----- > Von: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] Im=20 > Auftrag von Roland Bless > Gesendet: Donnerstag, 4. August 2005 20:37 > An: nsis@ietf.org > Betreff: [NSIS] GIST: On Reverse Path Attacker, NTLP issue #17 >=20 >=20 > Hi, >=20 > (see=20 > http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue17 > for more details) >=20 > as I already expressed in > http://www1.ietf.org/mail-archive/web/nsis/current/msg05085.html >=20 > I'm in favor of Roberts approach, to document it as residual > threat. So I'm not agreeing on Hannes opinion "let's do it". > Sure we technically can, but > I don't think it is really worth spending the effort, because > it is more or less a special type of man in the middle attack, > which cannot be prevented anyway by NTLP. Maybe Hannes could > elaborate a little bit more...furthermore: maybe some guy > from the Security Area could give advise what to do about this > issue. >=20 > Regards, > Roland >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Aug 05 04:19:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0xQF-000874-Kj; Fri, 05 Aug 2005 04:19:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0xQD-00086q-8K for nsis@megatron.ietf.org; Fri, 05 Aug 2005 04:19:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24983 for ; Fri, 5 Aug 2005 04:19:15 -0400 (EDT) Received: from gecko.sbs.de ([194.138.37.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0xxF-0007S2-MD for nsis@ietf.org; Fri, 05 Aug 2005 04:53:27 -0400 Received: from mail1.sbs.de (mail1.sbs.de [192.129.41.35]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id j758J6pb005101 for ; Fri, 5 Aug 2005 10:19:06 +0200 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id j758J4PR019345 for ; Fri, 5 Aug 2005 10:19:06 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.0); Fri, 5 Aug 2005 10:18:57 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Fri, 5 Aug 2005 10:18:55 +0200 Message-ID: Thread-Topic: please send me your nsis slides Thread-Index: AcWZllE4vp3qjbBBQbWodMOtmKSO1w== From: "Tschofenig, Hannes" To: X-OriginalArrivalTime: 05 Aug 2005 08:18:57.0561 (UTC) FILETIME=[5389C890:01C59996] X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Content-Transfer-Encoding: quoted-printable Subject: [NSIS] please send me your nsis slides 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: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org hi all,=20 for the meeting minutes i need your slides.=20 i will put them at http://www.ietf-nsis.org/nsis/IETF63/ please send them to me.=20 ciao hannes _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Aug 05 04:19:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0xL2-0005fg-7u; Fri, 05 Aug 2005 04:13:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0xKz-0005eo-Mb for nsis@megatron.ietf.org; Fri, 05 Aug 2005 04:13:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24427 for ; Fri, 5 Aug 2005 04:13:51 -0400 (EDT) Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0xs2-00079P-7z for nsis@ietf.org; Fri, 05 Aug 2005 04:48:03 -0400 Received: from w1xmeridian-8-108.ietf63.ietf.org (open-25-68.ietf63.ietf.org [86.255.25.68]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 8435D1BAC4D for ; Fri, 5 Aug 2005 10:13:29 +0200 (CEST) Date: Fri, 05 Aug 2005 10:13:22 +0200 From: Martin Stiemerling To: nsis Message-ID: X-Mailer: Mulberry/3.1.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Content-Transfer-Encoding: 7bit Subject: [NSIS] IETF 63 NATFW NSLP slides 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: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Dear all, The slides on NATFW NSLP are available here: http://www.stiemerling.org/ietf/ietf63/IETF63-NATFWNSLP-07vca.ppt Martin _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Aug 05 04:26:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0xX6-0000m5-Dl; Fri, 05 Aug 2005 04:26:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0xX4-0000m0-IC for nsis@megatron.ietf.org; Fri, 05 Aug 2005 04:26:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25342 for ; Fri, 5 Aug 2005 04:26:20 -0400 (EDT) Received: from iramx1.ira.uni-karlsruhe.de ([141.3.10.80] ident=[U2FsdGVkX1/JNXwoOpaCssXqhW/PBsNtjQ+BxV72cMM=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0y47-0007gu-3J for nsis@ietf.org; Fri, 05 Aug 2005 05:00:32 -0400 Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by iramx1.ira.uni-karlsruhe.de with esmtps id 1E0xWy-00012o-1D; Fri, 05 Aug 2005 10:26:19 +0200 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 C33E7BE01; Fri, 5 Aug 2005 10:26:15 +0200 (CEST) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1E0xWx-0000p0-HQ; Fri, 05 Aug 2005 10:26:15 +0200 Message-ID: <42F322F6.2070505@tm.uka.de> Date: Fri, 05 Aug 2005 10:27:34 +0200 From: Roland Bless Organization: Institute of Telematics, University of Karlsruhe User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050716) X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: "Tschofenig, Hannes" Subject: Re: AW: [NSIS] GIST: On Reverse Path Attacker, NTLP issue #17 References: In-Reply-To: X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -5.4 (-----) X-Spam-Status: No X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit 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: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Tschofenig, Hannes schrieb: > i think that the additional effort is mostly in a small piece of protocol specification. > there is almost no difference from a computational point of view. AFAIK this would require an additional cookie mechanism. What about additional implementation complexity etc.?? Robert seemed also to be reluctant to change the current spec (for these reasons, other others? What's your opionion on spec/implementation complexity?). I very much like to follow the KISS principle here: since we do not really can avoid a MitM attack in general, we should avoid this "additional" security mechanism -> reduces implementation complexity...and saves some paragraphs(?) in the protocol spec. Regards, Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Aug 05 04:32:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0xcf-0002Eq-Mp; Fri, 05 Aug 2005 04:32:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0xce-0002C8-9e for nsis@megatron.ietf.org; Fri, 05 Aug 2005 04:32:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25731 for ; Fri, 5 Aug 2005 04:32:06 -0400 (EDT) Received: from lizzard.sbs.de ([194.138.37.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0y9g-0007sr-Rj for nsis@ietf.org; Fri, 05 Aug 2005 05:06:18 -0400 Received: from mail2.sbs.de (mail2.sbs.de [192.129.41.66]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id j758VqlO028197; Fri, 5 Aug 2005 10:31:52 +0200 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id j758Vq0K024344; Fri, 5 Aug 2005 10:31:52 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.0); Fri, 5 Aug 2005 10:31:51 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: AW: AW: [NSIS] GIST: On Reverse Path Attacker, NTLP issue #17 Date: Fri, 5 Aug 2005 10:31:49 +0200 Message-ID: Thread-Topic: AW: [NSIS] GIST: On Reverse Path Attacker, NTLP issue #17 Thread-Index: AcWZl17Wv5hWSLBBRBGjmRgYORdG4AAAGSvw From: "Tschofenig, Hannes" To: "Roland Bless" X-OriginalArrivalTime: 05 Aug 2005 08:31:51.0117 (UTC) FILETIME=[209D0FD0:01C59998] X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: quoted-printable 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: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org hi roland,=20 > Tschofenig, Hannes schrieb: > > i think that the additional effort is mostly in a small=20 > piece of protocol specification.=20 > > there is almost no difference from a computational point of view.=20 >=20 > AFAIK this would require an additional cookie mechanism. > What about additional implementation complexity etc.?? a few lines of codes and no additional mechanisms. just a few clarifications regarding the cookie processing.=20 > Robert seemed also to be reluctant to change the current spec > (for these reasons, other others? What's your opionion on > spec/implementation complexity?). i think that he just wanted to get some feedback without indicating his opinion.=20 > I very much like to follow the KISS principle here: > since we do not really can avoid a MitM attack in general, > we should avoid this "additional" security mechanism > -> reduces implementation complexity...and saves some > paragraphs(?) in the protocol spec. it is not that easy. if you look at the message flow then you will notice that there are two places for a man-in-the-middle adversary. =20 ciao hannes >=20 > Regards, > Roland >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Aug 05 04:36:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0xhL-0004Am-36; Fri, 05 Aug 2005 04:36:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0xhH-00047Y-Eb for nsis@megatron.ietf.org; Fri, 05 Aug 2005 04:36:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26028 for ; Fri, 5 Aug 2005 04:36:53 -0400 (EDT) Received: from iramx1.ira.uni-karlsruhe.de ([141.3.10.80] ident=[U2FsdGVkX18FhCuRHFg5fCW5aiGX/RnvxdjVEojLjg4=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0yEJ-00083D-T6 for nsis@ietf.org; Fri, 05 Aug 2005 05:11:05 -0400 Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by iramx1.ira.uni-karlsruhe.de with esmtps id 1E0xh8-0001jp-Ut for ; Fri, 05 Aug 2005 10:36:52 +0200 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 B6531BE01 for ; Fri, 5 Aug 2005 10:36:46 +0200 (CEST) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1E0xh8-0000px-FN for nsis@ietf.org; Fri, 05 Aug 2005 10:36:46 +0200 Message-ID: <42F3256D.8060806@tm.uka.de> Date: Fri, 05 Aug 2005 10:38:05 +0200 From: Roland Bless Organization: Institute of Telematics, University of Karlsruhe User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050716) X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: nsis@ietf.org X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Spam-Score: -5.4 (-----) X-Spam-Status: No X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit Subject: [NSIS] Open issue draft-ietf-nsis-qspec-05.txt X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi, I did not see this point on Cornelias slides: > Future versions of this document will describe how can > be used by the QNI to send a discrete set of desired parameters. So this is an open issue, right? Any proposals so far? Might be good to set up a draft issue tracker.. Regards, Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Aug 05 04:55:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0xyv-0000cn-Np; Fri, 05 Aug 2005 04:55:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0xyq-0000cD-Hn for nsis@megatron.ietf.org; Fri, 05 Aug 2005 04:55:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27006 for ; Fri, 5 Aug 2005 04:55:02 -0400 (EDT) Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0yVt-0000AV-LV for nsis@ietf.org; Fri, 05 Aug 2005 05:29:14 -0400 Received: from rsys005a.comm.ad.roke.co.uk ([193.118.193.85]) by rsys001x.roke.co.uk (8.12.8/8.12.8) with ESMTP id j758sXFt027008; Fri, 5 Aug 2005 09:54:33 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Received: from ac78840 (orion.roke.co.uk [193.118.192.66]) by rsys002a.roke.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id PJSG1V4R; Fri, 5 Aug 2005 09:57:18 +0100 MIME-Version: 1.0 Content-class: urn:content-classes:message Subject: RE: AW: [NSIS] GIST: On Reverse Path Attacker, NTLP issue #17 Date: Fri, 5 Aug 2005 09:54:25 +0100 Message-ID: <003801c5999b$48555660$6b1cff56@comm.ad.roke.co.uk> Thread-Topic: AW: [NSIS] GIST: On Reverse Path Attacker, NTLP issue #17 Thread-Index: AcWZm69Dg3SboBXeRkmsYaitoajSrw== From: "Hancock, Robert" To: "Tschofenig, Hannes" , "Roland Bless" X-MailScanner-rsys001x: Found to be clean X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.5 (/) X-Scan-Signature: 4fc59e88b356924367ae169e6a06365d 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="===============0617282483==" Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. --===============0617282483== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5999B.AEB4EB00" Content-class: urn:content-classes:message This is a multi-part message in MIME format. ------_=_NextPart_001_01C5999B.AEB4EB00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable hi all, > hi roland,=20 >=20 >=20 > > Tschofenig, Hannes schrieb: > > > i think that the additional effort is mostly in a small=20 > > piece of protocol specification.=20 > > > there is almost no difference from a computational point of view.=20 > >=20 > > AFAIK this would require an additional cookie mechanism. > > What about additional implementation complexity etc.?? >=20 > a few lines of codes and no additional mechanisms. just a few > clarifications regarding the cookie processing.=20 to be precise, you need to define formally in the spec=20 a) a set of objects that you care about being protected b) a rule for serialising them into a byte stream c) an additional nonce field in the Query (or something like it) d) a hash function for putting (b) and (c) together e) another object for carrying this in the Response there is an alternative approach of similar complexity (without more objects but with a more complex specification of the existing ones); the details are all in http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/file1/GIMPS%2= 0Co okies.htm i think this is more than just 'clarifications'. the current specification makes the cookie generation/verification process an implementation-local issue. these changes would make it an interoperability issue. >=20 > > Robert seemed also to be reluctant to change the current spec > > (for these reasons, other others? What's your opionion on > > spec/implementation complexity?). >=20 > i think that he just wanted to get some feedback without=20 > indicating his > opinion.=20 clearly, henning and i work at the pleasure of the group. one particular thing i'm concerned about is: how this feature plays w.r.t. the general question of specification evolution. in particular - new optional objects get added which logically require the same protection - how to define whether they get included in the calculation - how to cope with the *expected* situation that we get the security details of the specification wrong first time, xref steve bellovin's talk at the plenary :-) >=20 >=20 > > I very much like to follow the KISS principle here: > > since we do not really can avoid a MitM attack in general, > > we should avoid this "additional" security mechanism > > -> reduces implementation complexity...and saves some > > paragraphs(?) in the protocol spec. > it is not that easy. if you look at the message flow then you will > notice that there are two places for a man-in-the-middle adversary. =20 i think it is clear that this is a new attack. however, IMHO it is a less serious attack than others which we already have to cope with by other mechanisms. in other words, to the space=20 in which the addition has a benefit is rather limited: - there is a bad guy in the network - he wants to attack a specific flow for which he is on the reverse but not forward path - the 'legitimate' end nodes believe there is no MitM problem on the forwards path and so aren't using any upper layer=20 protection in the end, this is always a cost benefit analysis. r. >=20 > ciao > hannes >=20 > >=20 > > Regards, > > Roland > >=20 >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 ------_=_NextPart_001_01C5999B.AEB4EB00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: AW: [NSIS] GIST: On Reverse Path Attacker, NTLP issue = #17

hi all,

> hi roland,
>
>
> > Tschofenig, Hannes schrieb:
> > > i think that the additional effort is = mostly in a small
> > piece of protocol specification.
> > > there is almost no difference from a = computational point of view.
> >
> > AFAIK this would require an additional = cookie mechanism.
> > What about additional implementation = complexity etc.??
>
> a few lines of codes and no additional = mechanisms. just a few
> clarifications regarding the cookie processing. =

to be precise, you need to define formally in the spec =
a) a set of objects that you care about being = protected
b) a rule for serialising them into a byte = stream
c) an additional nonce field in the Query (or = something like it)
d) a hash function for putting (b) and (c) = together
e) another object for carrying this in the = Response

there is an alternative approach of similar = complexity
(without more objects but with a more complex = specification of
the existing ones); the details are all in
http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/= file1/GIMPS%20Co
okies.htm

i think this is more than just 'clarifications'. the = current
specification makes the cookie = generation/verification process
an implementation-local issue. these changes would = make it an
interoperability issue.

>
> > Robert seemed also to be reluctant to = change the current spec
> > (for these reasons, other others? What's = your opionion on
> > spec/implementation complexity?).
>
> i think that he just wanted to get some feedback = without
> indicating his
> opinion.

clearly, henning and i work at the pleasure of the = group.

one particular thing i'm concerned about is: how this = feature
plays w.r.t. the general question of specification = evolution.
in particular
- new optional objects get added which logically = require the
same protection - how to define whether they get = included in
the calculation
- how to cope with the *expected* situation that we = get the
security details of the specification wrong first = time,
xref steve bellovin's talk at the plenary :-)

>
>
> > I very much like to follow the KISS = principle here:
> > since we do not really can avoid a MitM = attack in general,
> > we should avoid this "additional" = security mechanism
> > -> reduces implementation = complexity...and saves some
> > paragraphs(?) in the protocol spec.
> it is not that easy. if you look at the message = flow then you will
> notice that there are two places for a = man-in-the-middle adversary. 

i think it is clear that this is a new attack. = however, IMHO
it is a less serious attack than others which we = already have
to cope with by other mechanisms. in other words, to = the space
in which the addition has a benefit is rather = limited:
- there is a bad guy in the network
- he wants to attack a specific flow for which he is = on the
  reverse but not forward path
- the 'legitimate' end nodes believe there is no MitM = problem
  on the forwards path and so aren't using any = upper layer
  protection

in the end, this is always a cost benefit = analysis.

r.

>
> ciao
> hannes
>
> >
> > Regards,
> >  Roland
> >
>
> = _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.or= g/mailman/listinfo/nsis
>

------_=_NextPart_001_01C5999B.AEB4EB00-- --===============0617282483== 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 --===============0617282483==-- From nsis-bounces@ietf.org Fri Aug 05 06:03:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0z39-0002Cq-NT; Fri, 05 Aug 2005 06:03:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0z37-0002Ci-Sx for nsis@megatron.ietf.org; Fri, 05 Aug 2005 06:03:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00185 for ; Fri, 5 Aug 2005 06:03:30 -0400 (EDT) Received: from mailrelay1.lrz-muenchen.de ([129.187.254.106]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0zaB-00024y-8N for nsis@ietf.org; Fri, 05 Aug 2005 06:37:44 -0400 Received: from uranus.ze.tum.de (uranus.ze.tum.de [129.187.39.18]) by mailout.lrz-muenchen.de with ESMTP for nsis@ietf.org; Fri, 5 Aug 2005 12:03:23 +0200 To: nsis@ietf.org From: Tseno Tsenov Date: Fri, 05 Aug 2005 12:03:23 +0200 Mime-version: 1.0 Content-type: Multipart/mixed; boundary="===============0443801799==" Message-Id: X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Subject: [NSIS] QSPEC extensibility and re-use of multiple instances of defined parameters 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: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org You will not see this in a MIME-aware mail reader. --===============0443801799== Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Hi, = In my opinion, the current QSPEC draft miss flexibility for multiple usage = of QSPEC parameters of one type. Currently, for usage of two token bucket = in DiffServ EF PH QoS model, two separate mandatory token buckets are defin= ed (ID=3D5 and 6). And for example, if a new QoS model requires 3 token buc= kets at some later point, it must define an additional optional token bucke= t parameter. = Why don't the QSPEC template provide a method for multiple usage of one alr= eady defined parameter, if a QoS model needs it. This could be done in the = following way: 1. According to the QSPEC draft, each defined QSPEC parameter has a speci= fied fixed value length - bandwidth - 4bytes, token bucket -20 bytes, etc. = 2. The structure of a QSPEC parameter may carry multiple values of a QSPE= C parameter. Different values will be parsed based on the known fixed lengt= h of the parameter value. 3. Length field of the parameter structure will carry total length of the= parameters values. = The format for bandwidth would be this: | Object ID | Parameter ID =3D 3 | Length =3D 8 bytes | Bandwidth value 1 |= Bandwidth value 2 | For interoperability, if a mandatory parameter with such multiple-value str= ucture is used, all nodes must interpret the first value. If a node support= s the QoS model that uses such multiple-value parameter it makes use of all= values. I hope I don't misunderstand the QSPEC usage. Greetings, tseno_ --===============0443801799== 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 --===============0443801799==-- From nsis-bounces@ietf.org Fri Aug 05 06:49:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0zlt-0004EP-NX; Fri, 05 Aug 2005 06:49:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0zlg-0004EF-O5 for nsis@megatron.ietf.org; Fri, 05 Aug 2005 06:49:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02355 for ; Fri, 5 Aug 2005 06:49:33 -0400 (EDT) Received: from mailrelay1.lrz-muenchen.de ([129.187.254.106]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E10Ik-0003HC-HO for nsis@ietf.org; Fri, 05 Aug 2005 07:23:47 -0400 Received: from neptun.ze.tum.de (neptun.ze.tum.de [129.187.39.20]) by mailout.lrz-muenchen.de with ESMTP for nsis@ietf.org; Fri, 5 Aug 2005 12:49:33 +0200 To: nsis@ietf.org From: Tseno Tsenov Date: Fri, 05 Aug 2005 12:49:33 +0200 Mime-version: 1.0 Content-type: Multipart/mixed; boundary="===============0032829225==" Message-Id: X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Subject: [NSIS] 3gpp qos model and SIP/SDP session description 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: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org You will not see this in a MIME-aware mail reader. --===============0032829225== Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Hi, = Since SIP/SDP session description must be mapped to signalled QoS model (3g= pp, y.1541. etc), should we specify a SDP QoS model and its mapping to the = existing QoS models? Or include this in the 3gpp qos model document for exa= mple? 3gpp has already mapping of SDP session description to Y.1541 and to = 3gpp QoS parameters and classes. = = This might allow for usage of QSPEC parameters for QoS provisioning in addi= tion to the QoS signaling. Greetings, tseno --===============0032829225== 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 --===============0032829225==-- From nsis-bounces@ietf.org Fri Aug 05 10:13:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E12ul-00019O-A8; Fri, 05 Aug 2005 10:11:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E12ui-000189-Ta for nsis@megatron.ietf.org; Fri, 05 Aug 2005 10:11:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12397 for ; Fri, 5 Aug 2005 10:11:06 -0400 (EDT) Received: from mail.saic-abingdon.com ([12.167.146.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E13Rp-0000AI-GD for nsis@ietf.org; Fri, 05 Aug 2005 10:45:21 -0400 Received: from no.name.available by mail.saic-abingdon.com via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with ESMTP; Fri, 5 Aug 2005 10:12:36 -0400 Received: from bh-exchange02.saic-abingdon.com ([172.17.10.226]) by bh-exchangefe.saic-abingdon.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 5 Aug 2005 10:13:09 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [NSIS] 3gpp qos model and SIP/SDP session description Date: Fri, 5 Aug 2005 10:13:05 -0400 Message-ID: <2FE23D25B7292B489A217D1965CDA866726424@bh-exchange02.saic-abingdon.com> Thread-Topic: [NSIS] 3gpp qos model and SIP/SDP session description Thread-Index: AcWZq+umOFknFF7lRPmjrFEYSoIdMwAGY2Hl From: "Roy, Radhika \(AEAD\)" To: "Tseno Tsenov" , X-OriginalArrivalTime: 05 Aug 2005 14:13:09.0468 (UTC) FILETIME=[CEA971C0:01C599C7] X-Spam-Score: 0.5 (/) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0851167677==" Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. --===============0851167677== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C599C7.CC5E186C" This is a multi-part message in MIME format. ------_=_NextPart_001_01C599C7.CC5E186C Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Tseno: =20 Why do you want to map to a specific QOS model that uses some "specific = values" of some "limited" performance parameters? =20 By the way, what is a QOS Model? Does it not contain some specific = "values" some parameters like delay, delay jitter, losses (Packet, BER), = etc? If so, what is the fun about it when each QOS model published so = far has deficiencies because they struggle to standardize only the = "specific values" for which there are no "specific technical context" = when we look in terms of end-to-end cellular, satellite, ad hoc, and/or = wired networking. =20 SIP/SDP is end-to-end and does not limit itself in a "wallet garden" = like so called "specific values" of a particular QOS Model. =20 So, why do you NOT generalize how to signal/map end-to-end delay, delay = jitter, losses (Packet, BER), etc. in general terms in SIP/SDP instead = of mapping to "specific values" of a given QOS model?=20 =20 In this way, you become free from the nightmare of mapping business for = every set of "specific values" of all so-called QOS models to the best = interest of the IETF. =20 Best regards, Radhika ________________________________ From: nsis-bounces@ietf.org on behalf of Tseno Tsenov Sent: Fri 8/5/2005 6:49 AM To: nsis@ietf.org Subject: [NSIS] 3gpp qos model and SIP/SDP session description Hi, Since SIP/SDP session description must be mapped to signalled QoS model = (3gpp, y.1541. etc), should we specify a SDP QoS model and its mapping = to the existing QoS models? Or include this in the 3gpp qos model = document for example? 3gpp has already mapping of SDP session = description to Y.1541 and to 3gpp QoS parameters and classes. =20 This might allow for usage of QSPEC parameters for QoS provisioning in = addition to the QoS signaling. Greetings, tseno ------_=_NextPart_001_01C599C7.CC5E186C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A= =0A= =0A= [NSIS] 3gpp qos model and SIP/SDP session description=0A= =0A= =0A=
=0A=
Tseno:
=0A=
 
=0A=
Why do you want to map to a = specific QOS =0A= model that uses some "specific values" of  some "limited" = performance =0A= parameters?
=0A=
 
=0A=
By the way, what is a QOS = Model? Does it =0A= not contain some specific "values" some parameters like delay, = delay =0A= jitter, losses (Packet, BER), etc? If so, what is the fun about it when = each QOS =0A= model published so far has deficiencies because they struggle to = standardize =0A= only the "specific values" for which there are no "specific technical = context" =0A= when we look in terms of end-to-end cellular, satellite, ad hoc, and/or = wired =0A= networking.
=0A=
 
=0A=
SIP/SDP is end-to-end and = does not limit =0A= itself in a "wallet garden" like so called "specific values" of a = particular QOS =0A= Model.
=0A=
 
=0A=
So, why do you NOT generalize = how to =0A= signal/map end-to-end delay, delay jitter, losses (Packet, BER), etc. in = general =0A= terms in SIP/SDP instead of mapping to "specific values" of a given QOS = model? =0A=
=0A=
 
=0A=
In this way, you become free = from the =0A= nightmare of mapping business for every set of "specific values" of all =0A= so-called QOS models to the best interest of the = IETF.
=0A=
 
=0A=
Best regards,
=0A=
Radhika
=0A=

=0A=
=0A= From: nsis-bounces@ietf.org on = behalf of Tseno =0A= Tsenov
Sent: Fri 8/5/2005 6:49 AM
To: =0A= nsis@ietf.org
Subject: [NSIS] 3gpp qos model and SIP/SDP = session =0A= description

=0A=

=0A=

Hi,

Since SIP/SDP session description must be = mapped to =0A= signalled QoS model (3gpp, y.1541. etc), should we specify a SDP QoS = model and =0A= its mapping to the existing QoS models? Or include this in the 3gpp qos = model =0A= document for example? 3gpp has already mapping of SDP session = description to =0A= Y.1541 and to 3gpp QoS parameters and classes.
 
This might = allow for =0A= usage of QSPEC parameters for QoS provisioning in addition to the QoS =0A= signaling.

Greetings,
tseno

=0A= =0A= =0A= ------_=_NextPart_001_01C599C7.CC5E186C-- --===============0851167677== 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 --===============0851167677==-- From nsis-bounces@ietf.org Sat Aug 06 18:44:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E1XOa-0002Qn-NW; Sat, 06 Aug 2005 18:44:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E1XOZ-0002O5-RT for nsis@megatron.ietf.org; Sat, 06 Aug 2005 18:44:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17801 for ; Sat, 6 Aug 2005 18:43:57 -0400 (EDT) Received: from mail120.messagelabs.com ([216.82.255.211]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1E1Xvs-0001sr-CH for nsis@ietf.org; Sat, 06 Aug 2005 19:18:29 -0400 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-10.tower-120.messagelabs.com!1123368207!4996129!5 X-StarScan-Version: 5.4.15; banners=-,-,- X-Originating-IP: [192.128.133.132] Received: (qmail 27582 invoked from network); 6 Aug 2005 22:43:44 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (192.128.133.132) by server-10.tower-120.messagelabs.com with SMTP; 6 Aug 2005 22:43:44 -0000 Received: from kcclust06evs1.ugd.att.com (135.38.164.88) by attrh3i.attrh.att.com (7.2.052) id 42E3BC2B0031BBAD; Sat, 6 Aug 2005 18:43:43 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] QSPEC extensibility and re-use of multiple instances of defined parameters Date: Sat, 6 Aug 2005 17:43:43 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA09FA91C3@KCCLUST06EVS1.ugd.att.com> Thread-Topic: [NSIS] QSPEC extensibility and re-use of multiple instances of defined parameters Thread-Index: AcWZpTKN6Z3QOefsSPGiqYFNYN0BhQBMpSuw From: "Ash, Gerald R \(Jerry\), ALABS" To: "Tseno Tsenov" , X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: quoted-printable Cc: "Ash, Gerald R \(Jerry\), ALABS" 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: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Tseno, I like your suggestion. I think it both simplifies and generalizes the QSPEC to handle multiple instances of the same parameter. The second and higher instances of any parameter could be defined as optional. Procedures for multiple uses of a QSPEC parameter would have to be defined by a given QOSM. What do others think? Thanks, Jerry=20 -----Original Message----- From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On Behalf Of Tseno Tsenov Sent: Friday, August 05, 2005 6:03 AM To: nsis@ietf.org Subject: [NSIS] QSPEC extensibility and re-use of multiple instances of defined parameters Hi,=20 In my opinion, the current QSPEC draft miss flexibility for multiple usage of QSPEC parameters of one type. Currently, for usage of two token bucket in DiffServ EF PH QoS model, two separate mandatory token buckets are defined (ID=3D5 and 6). And for example, if a new QoS model requires 3 token buckets at some later point, it must define an additional optional token bucket parameter.=20 Why don't the QSPEC template provide a method for multiple usage of one already defined parameter, if a QoS model needs it. This could be done in the following way: 1. According to the QSPEC draft, each defined QSPEC parameter has a specified fixed value length - bandwidth - 4bytes, token bucket -20 bytes, etc.=20 2. The structure of a QSPEC parameter may carry multiple values of a QSPEC parameter. Different values will be parsed based on the known fixed length of the parameter value. 3. Length field of the parameter structure will carry total length of the parameters values.=20 The format for bandwidth would be this: | Object ID | Parameter ID =3D 3 | Length =3D 8 bytes | Bandwidth value = 1 | Bandwidth value 2 | For interoperability, if a mandatory parameter with such multiple-value structure is used, all nodes must interpret the first value. If a node supports the QoS model that uses such multiple-value parameter it makes use of all values. I hope I don't misunderstand the QSPEC usage. Greetings, tseno_ _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Sat Aug 06 19:30:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E1Y7R-0003YQ-Ru; Sat, 06 Aug 2005 19:30:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E1Y7Q-0003YL-SC for nsis@megatron.ietf.org; Sat, 06 Aug 2005 19:30:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19511 for ; Sat, 6 Aug 2005 19:30:17 -0400 (EDT) Received: from mail131.messagelabs.com ([216.82.242.99]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1E1Yeo-0002lD-1n for nsis@ietf.org; Sat, 06 Aug 2005 20:04:51 -0400 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-7.tower-131.messagelabs.com!1123371009!7016557!1 X-StarScan-Version: 5.4.15; banners=-,-,- X-Originating-IP: [192.128.133.132] Received: (qmail 1200 invoked from network); 6 Aug 2005 23:30:10 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (192.128.133.132) by server-7.tower-131.messagelabs.com with SMTP; 6 Aug 2005 23:30:10 -0000 Received: from kcclust06evs1.ugd.att.com (135.38.164.88) by attrh3i.attrh.att.com (7.2.052) id 42E3BC2B0031D48D; Sat, 6 Aug 2005 19:30:09 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] Open issue draft-ietf-nsis-qspec-05.txt Date: Sat, 6 Aug 2005 18:30:09 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA060CE6BA@KCCLUST06EVS1.ugd.att.com> Thread-Topic: [NSIS] Open issue draft-ietf-nsis-qspec-05.txt Thread-Index: AcWZmR/6nQXB2w1QSJaxmFB1XtdilwBQa+LA From: "Ash, Gerald R \(Jerry\), ALABS" To: "Roland Bless" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: quoted-printable Cc: "Ash, Gerald R \(Jerry\), ALABS" 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: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi Roland, > I did not see this point on Cornelias slides: > > Future versions of this document will describe how can > > be used by the QNI to send a discrete set of desired parameters. > So this is an open issue, right? Any proposals so far? I don't think this is an open issue according to the resolution of the "Issue #5" discussion that was initiated last January: Issue #5. Do we need support for signaling a discrete set of possible values for parameters (in connection with using ? Thread starts at: http://www1.ietf.org/mail-archive/web/nsis/current/msg04588.html Status (as reported at IETF-62, see http://www3.ietf.org/proceedings/05mar/slides/nsis-9/sld5.htm):=20 o some support, approaches suggested by Roland Bless & Dave Oran; some opposition, continuous (not discrete) values OK o Changes TBD: if agreed, describe mechanism to signal multiple choices of parameter values IMO the sentence you quote should be removed from the draft, given the lack of consensus to add this feature to the QSPEC at this point. I think such functionality should be considered along with other proposals for future extensions of the QSPEC. =20 In general, at this point I think we should try to 'avoid feature creep', as Cornelia mentioned in her last slide. Thanks, Regards, Jerry _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Aug 09 04:20:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2PLJ-0006MZ-9C; Tue, 09 Aug 2005 04:20:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2PLG-0006IM-Qz for nsis@megatron.ietf.org; Tue, 09 Aug 2005 04:20:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21305 for ; Tue, 9 Aug 2005 04:20:08 -0400 (EDT) Received: from thoth.sbs.de ([192.35.17.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2Pt8-0007iF-AN for nsis@ietf.org; Tue, 09 Aug 2005 04:55:10 -0400 Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by thoth.sbs.de (8.12.6/8.12.6) with ESMTP id j798K0Gx019105; Tue, 9 Aug 2005 10:20:00 +0200 Received: from mhpahx0c.ww002.siemens.net (mhpahx0c.ww002.siemens.net [139.25.165.42]) by mail3.siemens.de (8.12.6/8.12.6) with ESMTP id j798K0x1019116; Tue, 9 Aug 2005 10:20:00 +0200 Received: from blns00fa.ww002.siemens.net ([147.54.45.102]) by mhpahx0c.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.211); Tue, 9 Aug 2005 10:18:40 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] QSPEC extensibility and re-use of multiple instances ofdefined parameters Date: Tue, 9 Aug 2005 10:17:02 +0200 Message-ID: <391E6FBF5E786940B9E2F7CA6376C7086C1603@blns00fa.ww002.siemens.net> Thread-Topic: [NSIS] QSPEC extensibility and re-use of multiple instances ofdefined parameters Thread-Index: AcWZpTKN6Z3QOefsSPGiqYFNYN0BhQBMpSuwAHhh+XA= From: "Kappler, Cornelia" To: "Ash, Gerald R \(Jerry\), ALABS" , "Tseno Tsenov" , X-OriginalArrivalTime: 09 Aug 2005 08:18:40.0687 (UTC) FILETIME=[F32203F0:01C59CBA] X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Content-Transfer-Encoding: quoted-printable 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: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi Tseno,=20 if we expect multiple instances of the same parameter are something that is frequent in QOSMs I think we should go for your proposal which is a rather efficient way of coding it. On the other hand, I am not sure how likely it is that a QoS Model needs e.g. multiple values of QoS Classes? Isnt the token bucket quite a special case? All QOSMs we looked at so far, except DiffServ, dont need this feature. In any event we probably should make (if at all) mandatory only the first instance (i.e. a QNE implementing a QoS Model that doesnt need any (or multiple) instances of this parameter should only be forced to interpret the first occurrance.)=20 A related question:=20 What if a QNI wishes to code e.g. QoS Class, and has a very good idea that it wants a specific PHB from QNEs implementing the DiffServ QOSM, a specific Y.1541 QoS Class from QNEs implementing the Y.1441 QOSM etc. Is it allowed to include values for each type of QoS class it knows about? This is another usage of "multiple instances" (in fact it is more like "multiple values". Note this means a QNE would have to parse all these values to find out whether one specific to its QOSM is included. May be too much feature creep.=20 Cornelia > -----Original Message----- > From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On=20 > Behalf Of Ash, Gerald R (Jerry), ALABS > Sent: Sonntag, 7. August 2005 00:44 > To: Tseno Tsenov; nsis@ietf.org > Cc: Ash, Gerald R (Jerry), ALABS > Subject: RE: [NSIS] QSPEC extensibility and re-use of=20 > multiple instances ofdefined parameters >=20 >=20 > Tseno, >=20 > I like your suggestion. I think it both simplifies and=20 > generalizes the > QSPEC to handle multiple instances of the same parameter. The second > and higher instances of any parameter could be defined as optional. > Procedures for multiple uses of a QSPEC parameter would have to be > defined by a given QOSM. >=20 > What do others think? >=20 > Thanks, > Jerry=20 >=20 > -----Original Message----- > From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On=20 > Behalf Of > Tseno Tsenov > Sent: Friday, August 05, 2005 6:03 AM > To: nsis@ietf.org > Subject: [NSIS] QSPEC extensibility and re-use of multiple=20 > instances of > defined parameters >=20 > Hi,=20 >=20 > In my opinion, the current QSPEC draft miss flexibility for multiple > usage of QSPEC parameters of one type. Currently, for usage of two > token bucket in DiffServ EF PH QoS model, two separate mandatory token > buckets are defined (ID=3D5 and 6). And for example, if a new QoS = model > requires 3 token buckets at some later point, it must define an > additional optional token bucket parameter.=20 > Why don't the QSPEC template provide a method for multiple=20 > usage of one > already defined parameter, if a QoS model needs it. This could be done > in the following way: > 1. According to the QSPEC draft, each defined QSPEC parameter has a > specified fixed value length - bandwidth - 4bytes, token bucket -20 > bytes, etc.=20 > 2. The structure of a QSPEC parameter may carry multiple values of a > QSPEC parameter. Different values will be parsed based on the known > fixed length of the parameter value. > 3. Length field of the parameter structure will carry total=20 > length of > the parameters values.=20 >=20 > The format for bandwidth would be this: > | Object ID | Parameter ID =3D 3 | Length =3D 8 bytes | Bandwidth=20 > value 1 | > Bandwidth value 2 | >=20 > For interoperability, if a mandatory parameter with such=20 > multiple-value > structure is used, all nodes must interpret the first value. If a node > supports the QoS model that uses such multiple-value=20 > parameter it makes > use of all values. >=20 > I hope I don't misunderstand the QSPEC usage. >=20 > Greetings, >=20 > tseno_ >=20 >=20 >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Aug 09 08:57:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2TfV-0001WY-8Y; Tue, 09 Aug 2005 08:57:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2TfS-0001WT-7m for nsis@megatron.ietf.org; Tue, 09 Aug 2005 08:57:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04294 for ; Tue, 9 Aug 2005 08:57:16 -0400 (EDT) Received: from mail.saic-abingdon.com ([12.167.146.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2UDM-0006e8-5E for nsis@ietf.org; Tue, 09 Aug 2005 09:32:20 -0400 Received: from no.name.available by mail.saic-abingdon.com via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with ESMTP; Tue, 9 Aug 2005 08:58:41 -0400 Received: from bh-exchange02.saic-abingdon.com ([10.42.81.226]) by bh-exchangefe.saic-abingdon.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 9 Aug 2005 08:59:23 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [NSIS] QSPEC extensibility and re-use of multiple instancesofdefined parameters Date: Tue, 9 Aug 2005 08:59:17 -0400 Message-ID: <2FE23D25B7292B489A217D1965CDA86672642F@bh-exchange02.saic-abingdon.com> Thread-Topic: [NSIS] QSPEC extensibility and re-use of multiple instancesofdefined parameters Thread-Index: AcWZpTKN6Z3QOefsSPGiqYFNYN0BhQBMpSuwAHhh+XAACSLXXg== From: "Roy, Radhika \(AEAD\)" To: X-OriginalArrivalTime: 09 Aug 2005 12:59:23.0234 (UTC) FILETIME=[2A12BC20:01C59CE2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 21f6736b171db90b7af90d77f0c0e285 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="===============0012501078==" Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. --===============0012501078== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C59CE2.26A0A4B2" This is a multi-part message in MIME format. ------_=_NextPart_001_01C59CE2.26A0A4B2 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Tseno: =20 The fundamental problems are as follows: =20 1. QoS models defined so far in all cases of all standards are NOT = unique because they consider as a set of performance parameters = arbitrarily depending on which standard fora/bodies they belong to. =20 2. If you ask what is the define of QoS model, you will get different = answers because it is a matter of grouping some performance parameters = here and there. For example, some has delay parameters, some has delay = and delay jitter, some has delay, jitter, and packet losses, etc. So, = why do you run after those QoS models in the first place while you are = doing standardization works for "QoS signaling" works in the IETF when = you cannot generalize the QoS model? =20 3. It is "funny" to see that draft does NOT define what a QoS model is. = As if, anything ever defined on the earth in the name of QoS model can = be included in QSPEC because the draft itself does NOT know what is = meant by QoS model. As a result, the draft has created a funny = situations that contradict itself for the "same" performance parameter: = i. Use values with no Restrictions and ii. Use values with Restrictions. =20 4. Again, QoS classes of a given QoS model are defined based on some = "specific values" for which there is no technical context in terms of = wireless LANs, cellular, satellite, ad hoc, and/or wired line networks. = Here lies another set of contradictions because "values" cannot be used = by users as they may contradict.=20 =20 For example, in related threads I explained (John L. also agreed that = users will do so if values for the inter-domains communications are not = carefully constructed) why there should be restrictions in use of those = values in the first place.=20 =20 6. To remove this, I have proposed to split the draft into two parts: a. = Where values do not contradict following the "generalized" principles of = NSIS QoS signaling charter as all of us including yourself want, and b. = Where values can be restricted in funny ways and let the users restrict = themselves as they suppose to do for inter-domain QoS signaling where = nothing can be "generalized" as you have observed (Or, remove this part = from the draft altogether). =20 Hope this clarifies the things. =20 Best regards, Radhika ________________________________ From: nsis-bounces@ietf.org on behalf of Kappler, Cornelia Sent: Tue 8/9/2005 4:17 AM To: Ash, Gerald R (Jerry), ALABS; Tseno Tsenov; nsis@ietf.org Subject: RE: [NSIS] QSPEC extensibility and re-use of multiple = instancesofdefined parameters Hi Tseno, if we expect multiple instances of the same parameter are something that is frequent in QOSMs I think we should go for your proposal which is a rather efficient way of coding it. On the other hand, I am not sure how likely it is that a QoS Model needs e.g. multiple values of QoS Classes? Isnt the token bucket quite a special case? All QOSMs we looked at so far, except DiffServ, dont need this feature. In any event we probably should make (if at all) mandatory only the first instance (i.e. a QNE implementing a QoS Model that doesnt need any (or multiple) instances of this parameter should only be forced to interpret the first occurrance.) A related question: What if a QNI wishes to code e.g. QoS Class, and has a very good idea that it wants a specific PHB from QNEs implementing the DiffServ QOSM, a specific Y.1541 QoS Class from QNEs implementing the Y.1441 QOSM etc. Is it allowed to include values for each type of QoS class it knows about? This is another usage of "multiple instances" (in fact it is more like "multiple values". Note this means a QNE would have to parse all these values to find out whether one specific to its QOSM is included. May be too much feature creep. Cornelia > -----Original Message----- > From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On > Behalf Of Ash, Gerald R (Jerry), ALABS > Sent: Sonntag, 7. August 2005 00:44 > To: Tseno Tsenov; nsis@ietf.org > Cc: Ash, Gerald R (Jerry), ALABS > Subject: RE: [NSIS] QSPEC extensibility and re-use of > multiple instances ofdefined parameters > > > Tseno, > > I like your suggestion. I think it both simplifies and > generalizes the > QSPEC to handle multiple instances of the same parameter. The second > and higher instances of any parameter could be defined as optional. > Procedures for multiple uses of a QSPEC parameter would have to be > defined by a given QOSM. > > What do others think? > > Thanks, > Jerry > > -----Original Message----- > From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On > Behalf Of > Tseno Tsenov > Sent: Friday, August 05, 2005 6:03 AM > To: nsis@ietf.org > Subject: [NSIS] QSPEC extensibility and re-use of multiple > instances of > defined parameters > > Hi, > > In my opinion, the current QSPEC draft miss flexibility for multiple > usage of QSPEC parameters of one type. Currently, for usage of two > token bucket in DiffServ EF PH QoS model, two separate mandatory token > buckets are defined (ID=3D5 and 6). And for example, if a new QoS = model > requires 3 token buckets at some later point, it must define an > additional optional token bucket parameter. > Why don't the QSPEC template provide a method for multiple > usage of one > already defined parameter, if a QoS model needs it. This could be done > in the following way: > 1. According to the QSPEC draft, each defined QSPEC parameter has a > specified fixed value length - bandwidth - 4bytes, token bucket -20 > bytes, etc. > 2. The structure of a QSPEC parameter may carry multiple values of a > QSPEC parameter. Different values will be parsed based on the known > fixed length of the parameter value. > 3. Length field of the parameter structure will carry total > length of > the parameters values. > > The format for bandwidth would be this: > | Object ID | Parameter ID =3D 3 | Length =3D 8 bytes | Bandwidth > value 1 | > Bandwidth value 2 | > > For interoperability, if a mandatory parameter with such > multiple-value > structure is used, all nodes must interpret the first value. If a node > supports the QoS model that uses such multiple-value > parameter it makes > use of all values. > > I hope I don't misunderstand the QSPEC usage. > > Greetings, > > tseno_ > > > > _______________________________________________ > 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 ------_=_NextPart_001_01C59CE2.26A0A4B2 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A= =0A= =0A= RE: [NSIS] QSPEC extensibility and re-use of multiple = instancesofdefined parameters=0A= =0A= =0A=
=0A=
Tseno:
=0A=
=0A=
 
=0A=
The = fundamental =0A= problems are as follows:
=0A=
 
=0A=
1. QoS models defined so far = in all cases =0A= of all standards are NOT unique because they consider as a set of = performance =0A= parameters arbitrarily depending on which standard fora/bodies they = belong =0A= to.
=0A=
 
=0A=
2. If you ask what is the = define of QoS =0A= model, you will get different answers because it is a matter of grouping = some =0A= performance parameters here and there. For example, some has delay = parameters, =0A= some has delay and delay jitter, some has delay, jitter, and packet = losses, etc. =0A= So, why do you run after those QoS models in the first place while you = are doing =0A= standardization works for "QoS signaling" works in the IETF when you = cannot =0A= generalize the QoS model?
=0A=
 
=0A=
3. It is "funny" to see that = draft does NOT =0A= define what a QoS model is. As if, anything ever defined on the earth in = the =0A= name of QoS model can be included in QSPEC because the draft itself does = NOT =0A= know what is meant by QoS model. As a result, the draft has created a = funny =0A= situations that contradict itself for the "same" performance parameter: = i. Use =0A= values with no Restrictions and ii. Use values with = Restrictions.
=0A=
 
=0A=
4. Again, QoS classes of a = given QoS model =0A= are defined based on some "specific values" for which there is no = technical =0A= context in terms of wireless LANs, cellular, satellite, ad hoc, and/or = wired =0A= line networks. Here lies another set of contradictions because "values" = cannot =0A= be used by users as they may contradict.
=0A=
 
=0A=
For example, in related = threads I explained =0A= (John L. also agreed that users will do so if values for the = inter-domains =0A= communications are not carefully constructed) why there should be = restrictions =0A= in use of those values in the first place.
=0A=
 
=0A=
6. To remove this, I have = proposed to split =0A= the draft into two parts: a. Where values do not contradict following = the =0A= "generalized" principles of NSIS QoS signaling charter as all of us = including =0A= yourself want, and b. Where values can be restricted in funny ways and = let the =0A= users restrict themselves as they suppose to do for inter-domain QoS = signaling =0A= where nothing can be "generalized" as you have observed (Or, remove this = part =0A= from the draft altogether).
=0A=
 
=0A=
Hope this clarifies the =0A= things.
=0A=
 
=0A=
Best regards,
=0A=
Radhika
=0A=

=0A=
=0A= From: nsis-bounces@ietf.org on = behalf of =0A= Kappler, Cornelia
Sent: Tue 8/9/2005 4:17 AM
To: = Ash, Gerald =0A= R (Jerry), ALABS; Tseno Tsenov; nsis@ietf.org
Subject: RE: = [NSIS] =0A= QSPEC extensibility and re-use of multiple instancesofdefined =0A= parameters

=0A=
=0A=

Hi Tseno,

if we expect multiple instances of = the same =0A= parameter are something that
is frequent in QOSMs I think we should = go for =0A= your proposal which is a
rather efficient way of coding it. On the = other =0A= hand, I am not sure how
likely it is that a QoS Model needs e.g. = multiple =0A= values of QoS Classes?
Isnt the token bucket quite a special case? = All QOSMs =0A= we looked at so
far, except DiffServ, dont need this = feature.

In any =0A= event we probably should make (if at all) mandatory only the
first = instance =0A= (i.e. a QNE implementing a QoS Model that doesnt need any
(or = multiple) =0A= instances of this parameter should only be forced to
interpret the = first =0A= occurrance.)

A related question:
What if a QNI wishes to code = e.g. QoS =0A= Class, and has a very good idea
that it wants a specific PHB from = QNEs =0A= implementing the DiffServ QOSM, a
specific Y.1541 QoS Class from QNEs =0A= implementing the Y.1441 QOSM etc. Is
it allowed to include values for = each =0A= type of QoS class it knows about?
This is another usage of "multiple =0A= instances" (in fact it is more like
"multiple values". Note this = means a QNE =0A= would have to parse all these
values to find out whether one specific = to its =0A= QOSM is included. May be
too much feature = creep.

Cornelia

> =0A= -----Original Message-----
> From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] = On
> =0A= Behalf Of Ash, Gerald R (Jerry), ALABS
> Sent: Sonntag, 7. August = 2005 =0A= 00:44
> To: Tseno Tsenov; nsis@ietf.org
> Cc: Ash, Gerald R = (Jerry), =0A= ALABS
> Subject: RE: [NSIS] QSPEC extensibility and re-use = of
> =0A= multiple instances ofdefined parameters
>
>
> =0A= Tseno,
>
> I like your suggestion.  I think it both = simplifies =0A= and
> generalizes the
> QSPEC to handle multiple instances = of the =0A= same parameter.  The second
> and higher instances of any = parameter =0A= could be defined as optional.
> Procedures for multiple uses of a = QSPEC =0A= parameter would have to be
> defined by a given = QOSM.
>
> What =0A= do others think?
>
> Thanks,
> Jerry
>
> =0A= -----Original Message-----
> From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] = On
> =0A= Behalf Of
> Tseno Tsenov
> Sent: Friday, August 05, 2005 = 6:03 =0A= AM
> To: nsis@ietf.org
> Subject: [NSIS] QSPEC extensibility = and =0A= re-use of multiple
> instances of
> defined =0A= parameters
>
> Hi,
>
> In my opinion, the = current QSPEC =0A= draft miss flexibility for multiple
> usage of QSPEC parameters of = one =0A= type.  Currently, for usage of two
> token bucket in DiffServ = EF PH =0A= QoS model, two separate mandatory token
> buckets are defined = (ID=3D5 and =0A= 6). And for example, if a new QoS model
> requires 3 token buckets = at some =0A= later point, it must define an
> additional optional token bucket =0A= parameter.
> Why don't the QSPEC template provide a method for =0A= multiple
> usage of one
> already defined parameter, if a = QoS model =0A= needs it. This could be done
> in the following = way:
>   =0A= 1. According to the QSPEC draft, each defined QSPEC parameter has = a
> =0A= specified fixed value length - bandwidth - 4bytes, token bucket = -20
> =0A= bytes, etc.
>   2. The structure of a QSPEC parameter = may carry =0A= multiple values of a
> QSPEC parameter. Different values will be = parsed =0A= based on the known
> fixed length of the parameter =0A= value.
>   3. Length field of the parameter structure = will carry =0A= total
> length of
> the parameters values.
>
> = The =0A= format for bandwidth would be this:
> | Object ID | Parameter ID = =3D 3 | =0A= Length =3D 8 bytes | Bandwidth
> value 1 |
> Bandwidth value = 2 =0A= |
>
> For interoperability, if a mandatory parameter with =0A= such
> multiple-value
> structure is used, all nodes must = interpret =0A= the first value. If a node
> supports the QoS model that uses such =0A= multiple-value
> parameter it makes
> use of all =0A= values.
>
> I hope I don't misunderstand the QSPEC =0A= usage.
>
> Greetings,
>
> =0A= tseno_
>
>
>
> =0A= _______________________________________________
> nsis mailing =0A= list
> nsis@ietf.org
> https://www1.ietf.or= g/mailman/listinfo/nsis
>

______________________________= _________________
nsis =0A= mailing list
nsis@ietf.org
https://www1.ietf.or= g/mailman/listinfo/nsis

=0A= =0A= =0A= ------_=_NextPart_001_01C59CE2.26A0A4B2-- --===============0012501078== 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 --===============0012501078==-- From nsis-bounces@ietf.org Tue Aug 09 15:11:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2ZVQ-0001qP-Kv; Tue, 09 Aug 2005 15:11:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2ZVO-0001q8-2w for nsis@megatron.ietf.org; Tue, 09 Aug 2005 15:11:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00853 for ; Tue, 9 Aug 2005 15:11:15 -0400 (EDT) Received: from mtassp3.ncr.disa.mil ([164.117.82.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2a3K-0001T8-FB for nsis@ietf.org; Tue, 09 Aug 2005 15:46:23 -0400 Received: from mtassp3.ncr.disa.mil by mtassp3.ncr.disa.mil via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with ESMTP; Tue, 9 Aug 2005 15:07:58 -0400 Received: by mtassp3.ncr.disa.mil with Internet Mail Service (5.5.2657.72) id ; Tue, 9 Aug 2005 15:11:12 -0400 Message-ID: <7F18415E4D63CB45BB9B3A591F68D12D0E52068F@emshqs1.ncr.disa.mil> From: "Nguyen, An" To: "'john.loughney@nokia.com'" Subject: RE: [NSIS] RE: I-D ACTION:draft-ash-nsis-vertical-interface-00.tx t Date: Tue, 9 Aug 2005 15:10:59 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Cc: gash@att.com, "Andre, Nick" , nsis@ietf.org, "Bain, Gregory" , 'Arthur Webster' , "Perschau, Stephen" , "Taylor, Carol-Lyn" 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: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org John, I agreed this draft would be of interest to the IEPREP. An -----Original Message----- From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] Sent: Saturday, July 30, 2005 4:50 AM To: gash@att.com; nsis@ietf.org Subject: RE: [NSIS] RE: I-D ACTION:draft-ash-nsis-vertical-interface-00.txt Jerry, I had a quick reading of this draft, it looks fairly interesting, but I would need to re-read and analysis the scenario in a bit more detail. The scope of the document is somewhat confusing though. I orignally thought this would be a more general solution, for example, proposing how to use NSIS QoS NSLP with SIP signaling, but you do focus on the ETS case. Perhaps better clarifying this in the revision would helpful. Depending upon what your target is, illustrating the basic QoS NSLP operation for consumer VOIP, without such a specific network deployment, "DiffServ-enabled MPLS traffic engineering (DSTE) [RFC3564] tunnel ..." for example, would be a good idea. I'd suggest for a revision that you include a terminology section, as there are a lot of acronyms, and terminology that are not immediately recognizable. Any consideration on discussing this draft in ieprep, at least to verify the usecase? This seems like it would be of interest there. thanks, John > -----Original Message----- > From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org]On Behalf Of > ext Ash, Gerald R (Jerry), ALABS > Sent: 12 July, 2005 00:38 > To: nsis@ietf.org > Cc: Ash, Gerald R (Jerry), ALABS > Subject: [NSIS] RE: I-D > ACTION:draft-ash-nsis-vertical-interface-00.txt > > > Hi All, > > Please review and comment on the draft 'User Application-to-User Plane > Vertical Interface' > (http://www.ietf.org/internet-drafts/draft-ash-nsis-vertical-i > nterface-0 > 0.txt). > > The draft proposes requirements for communicating QoS > parameters/attributes between the user application layer down to the > user plane to create an NSIS session. For this discussion, SIP is the > signaling protocol assumed at the user application layer and QoS-NSIS > signaling layer protocol (QoS-NSLP) is assumed at the user > plane layer. > > Thanks, > Jerry > > -----Original Message----- > From: i-d-announce-bounces@ietf.org > [mailto:i-d-announce-bounces@ietf.org] On Behalf Of > Internet-Drafts@ietf.org > Sent: Monday, July 11, 2005 3:50 PM > To: i-d-announce@ietf.org > Subject: I-D ACTION:draft-ash-nsis-vertical-interface-00.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : User Application-to-User Plane Vertical > Interface > Author(s) : J. Ash, et al. > Filename : draft-ash-nsis-vertical-interface-00.txt > Pages : 11 > Date : 2005-7-11 > > This draft describes a mechanism to map QoS requirements from the > User application layer down to the user plane to create an NSIS > session. This 'vertical signaling interface' between the user > application layer and user plane is needed to communicate these QoS > requirements, such as flow priority values, to user plane network > elements. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ash-nsis-vertical-in terface-00 .txt _______________________________________________ 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 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Aug 10 06:59:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2oIt-0007zX-6z; Wed, 10 Aug 2005 06:59:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2oIr-0007zP-In for nsis@megatron.ietf.org; Wed, 10 Aug 2005 06:59:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19840 for ; Wed, 10 Aug 2005 06:59:18 -0400 (EDT) Received: from difra-computer.de ([81.169.157.103] helo=www.difra-computer.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2oqw-0002F8-GG for nsis@ietf.org; Wed, 10 Aug 2005 07:34:35 -0400 Received: from win2003.dickmann2003.home (p548A5F19.dip.t-dialin.net [84.138.95.25]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by www.difra-computer.de (Postfix) with ESMTP id CCF9F3E402B for ; Wed, 10 Aug 2005 12:55:20 +0200 (CEST) Received: from christian ([192.168.0.2]) by win2003.dickmann2003.home with Microsoft SMTPSVC(6.0.3790.211); Wed, 10 Aug 2005 12:54:46 +0200 From: "Christian Dickmann" To: Date: Wed, 10 Aug 2005 12:55:05 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcWdmfcKSfOIyVBOSHOWBNMEj+9ziQ== Message-ID: X-OriginalArrivalTime: 10 Aug 2005 10:54:46.0430 (UTC) FILETIME=[EBF6BBE0:01C59D99] X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit Subject: [NSIS] Qos NSLP questions and comments X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi WG, I have some questions and comments on the QoS NSLP draft 07. - "Sender-receiver initiation" (title of 3.2.2) This section title is not well chosen. I really did not know what you meant when reading the document for the first time. - "Before sending the RESERVE, the sender of the data first sends a QUERY message that creates the required GIMPS path state." (3.2.2) It is not clear, that you only send a QUERY in the receiver initiated case. To my mind, you should create 2 paragraphs for the two cases. - "If a message contains an object of an unrecognised type, then the behaviour depends on the object type value. The usual operation is to skip unknown objects. See the GIMPS specification for more information." (5.2.3) If I do not know the type, how should I depend on the type to determine what to do? The Object Header in QoS lacks the A and B flags that GIST uses, so I do not see what you mean here. - "Any node may include a request for a RESPONSE in its RESERVE messages. It does so by including a Request Identification Information (RII) object in the RESERVE message." (4.1) As I understand the message format, only one RII is allowed per RESERVE message, right? This text makes me wonder if I am correct. - 5.1.2.1 has different RESERVE format than 5.4.1 Christian Dickmann _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Aug 10 09:16:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2qRV-0002R7-2k; Wed, 10 Aug 2005 09:16:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2qRT-0002Pd-CU for nsis@megatron.ietf.org; Wed, 10 Aug 2005 09:16:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26546 for ; Wed, 10 Aug 2005 09:16:21 -0400 (EDT) Received: from mailrelay2.lrz-muenchen.de ([129.187.254.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2qzY-0005wY-Qi for nsis@ietf.org; Wed, 10 Aug 2005 09:51:38 -0400 Received: from pluto.ze.tum.de (pluto.ze.tum.de [129.187.39.19]) by mailout.lrz-muenchen.de with ESMTP; Wed, 10 Aug 2005 15:16:05 +0200 To: RoyR@saic-abingdon.com, From: Tseno Tsenov Subject: =?iso-8859-1?q?RE=3A_=5BNSIS=5D_QSPEC_extensibility_and_re-use_of_multipl?= =?iso-8859-1?q?e=09instancesofdefined_parameters?= Date: Wed, 10 Aug 2005 15:16:04 +0200 Mime-version: 1.0 Content-type: Multipart/mixed; boundary="===============1157781551==" Message-Id: X-Spam-Score: 0.0 (/) X-Scan-Signature: 6a45e05c1e4343200aa6b327df2c43fc 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: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org You will not see this in a MIME-aware mail reader. --===============1157781551== Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Hi Roy, How I understand the idea of QSPEC and QoS model: QSPEC template defines a number of QoS parameters that describe certain QoS= /resources, priority,.../. A QoS Model, use these parameters as well as define its own QoS parameters = in order to signal/achieve QoS in its domain using its QoS methods. It must= define how to import from the received QSPEC template parameters the QoS d= escription and how to map it to its QoS parameters in the ingress node. The= n in the egress node it must define how to export the QoS description resul= ting from its intra domain QoS signaling method to the QSPEC template param= eters. As such, I see the mandatory QoS parameters defined in the QSPEC tem= plate as anchor parameters from which any QoS model can derive the required= /available/reserved QoS description. And even if a given QoS model can't r= e-use any of the present QSPEC parameters but have to define its own option= al set, it should map properly its parameters to the mandatory ones in the = egress node of its domain. For such mandatory QSPEC parameters are used QoS parameters of well-known Q= oS models such as Intserv or Diffserv. And therefore there is overlapping b= etween the QSPEC template and these QoS models. = I hope, there is something correct in this. Greetings, Tseno Original Message: Tseno:
=
The fundamental problems are as follows:
=
1. QoS models defined so far in all cases of all standards are NOT un= ique because they consider as a set of performance parameters arbitrarily d= epending on which standard fora/bodies they belong to.
=
2. If you ask what is the define of QoS model, you will get different= answers because it is a matter of grouping some performance parameters her= e and there. For example, some has delay parameters, some has delay and del= ay jitter, some has delay, jitter, and packet losses, etc. So, why do you r= un after those QoS models in the first place while you are doing standardiz= ation works for "QoS signaling" works in the IETF when you cannot generaliz= e the QoS model?
=
3. It is "funny" to see that draft does NOT define what a QoS model i= s. As if, anything ever defined on the earth in the name of QoS model can b= e included in QSPEC because the draft itself does NOT know what is meant by= QoS model. As a result, the draft has created a funny situations that cont= radict itself for the "same" performance parameter: i. Use values with no R= estrictions and ii. Use values with Restrictions.
=
4. Again, QoS classes of a given QoS model are defined based on some = "specific values" for which there is no technical context in terms of wirel= ess LANs, cellular, satellite, ad hoc, and/or wired line networks. Here lie= s another set of contradictions because "values" cannot be used by users as= they may contradict. =
=
For example, in related threads I explained (John L. also agreed that= users will do so if values for the inter-domains communications are not ca= refully constructed) why there should be restrictions in use of those value= s in the first place. =
=
6. To remove this, I have proposed to split the draft into two parts:= a. Where values do not contradict following the "generalized" principles o= f NSIS QoS signaling charter as all of us including yourself want, and b. W= here values can be restricted in funny ways and let the users restrict them= selves as they suppose to do for inter-domain QoS signaling where nothing c= an be "generalized" as you have observed (Or, remove this part from the dra= ft altogether).
=
Hope this clarifies the things.
=
Best regards,
Radhika

________________________________

From: nsis-bounces@ietf.org on behalf of Kappler, Cornelia
Sent: Tue 8/9/2005 4:17 AM
To: Ash, Gerald R (Jerry), ALABS; Tseno Tsenov; nsis@ietf.org
Subject: RE: [NSIS] QSPEC extensibility and re-use of multiple instan= cesofdefined parameters



Hi Tseno,

if we expect multiple instances of the same parameter are something t= hat
is frequent in QOSMs I think we should go for your proposal which is a
rather efficient way of coding it. On the other hand, I am not sure h= ow
likely it is that a QoS Model needs e.g. multiple values of QoS Class= es?
Isnt the token bucket quite a special case? All QOSMs we looked at so
far, except DiffServ, dont need this feature.

In any event we probably should make (if at all) mandatory only the
first instance (i.e. a QNE implementing a QoS Model that doesnt need = any
(or multiple) instances of this parameter should only be forced to
interpret the first occurrance.)

A related question:
What if a QNI wishes to code e.g. QoS Class, and has a very good idea
that it wants a specific PHB from QNEs implementing the DiffServ QOSM= , a
specific Y.1541 QoS Class from QNEs implementing the Y.1441 QOSM etc.= Is
it allowed to include values for each type of QoS class it knows abou= t?
This is another usage of "multiple instances" (in fact it is more like
"multiple values". Note this means a QNE would have to parse all these
values to find out whether one specific to its QOSM is included. May = be
too much feature creep.

Cornelia

> -----Original Message-----
> From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On
> Behalf Of Ash, Gerald R (Jerry), ALABS
> Sent: Sonntag, 7. August 2005 00:44
> To: Tseno Tsenov; nsis@ietf.org
> Cc: Ash, Gerald R (Jerry), ALABS
> Subject: RE: [NSIS] QSPEC extensibility and re-use of
> multiple instances ofdefined parameters
>
>
> Tseno,
>
> I like your suggestion. I think it both simplifies and
> generalizes the
> QSPEC to handle multiple instances of the same parameter. The seco= nd
> and higher instances of any parameter could be defined as optional.
> Procedures for multiple uses of a QSPEC parameter would have to be
> defined by a given QOSM.
>
> What do others think?
>
> Thanks,
> Jerry
>
> -----Original Message-----
> From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On
> Behalf Of
> Tseno Tsenov
> Sent: Friday, August 05, 2005 6:03 AM
> To: nsis@ietf.org
> Subject: [NSIS] QSPEC extensibility and re-use of multiple
> instances of
> defined parameters
>
> Hi,
>
> In my opinion, the current QSPEC draft miss flexibility for multiple
> usage of QSPEC parameters of one type. Currently, for usage of two
> token bucket in DiffServ EF PH QoS model, two separate mandatory to= ken
> buckets are defined (ID=3D5 and 6). And for example, if a new QoS m= odel
> requires 3 token buckets at some later point, it must define an
> additional optional token bucket parameter.
> Why don't the QSPEC template provide a method for multiple
> usage of one
> already defined parameter, if a QoS model needs it. This could be d= one
> in the following way:
> 1. According to the QSPEC draft, each defined QSPEC parameter has= a
> specified fixed value length - bandwidth - 4bytes, token bucket -20
> bytes, etc.
> 2. The structure of a QSPEC parameter may carry multiple values o= f a
> QSPEC parameter. Different values will be parsed based on the known
> fixed length of the parameter value.
> 3. Length field of the parameter structure will carry total
> length of
> the parameters values.
>
> The format for bandwidth would be this:
> | Object ID | Parameter ID =3D 3 | Length =3D 8 bytes | Bandwidth
> value 1 |
> Bandwidth value 2 |
>
> For interoperability, if a mandatory parameter with such
> multiple-value
> structure is used, all nodes must interpret the first value. If a n= ode
> supports the QoS model that uses such multiple-value
> parameter it makes
> use of all values.
>
> I hope I don't misunderstand the QSPEC usage.
>
> Greetings,
>
> tseno_
>
>
>
> _______________________________________________
> 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


--===============1157781551== 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 --===============1157781551==-- From nsis-bounces@ietf.org Wed Aug 10 14:49:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2vdT-000180-VE; Wed, 10 Aug 2005 14:49:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2vdS-00011T-17 for nsis@megatron.ietf.org; Wed, 10 Aug 2005 14:49:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17747 for ; Wed, 10 Aug 2005 14:49:04 -0400 (EDT) Received: from mail-in-05.arcor-online.net ([151.189.21.45]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2wBZ-0007nw-G0 for nsis@ietf.org; Wed, 10 Aug 2005 15:24:23 -0400 Received: from mail-in-06-z2.arcor-online.net (mail-in-06-z2.arcor-online.net [151.189.8.18]) by mail-in-05.arcor-online.net (Postfix) with ESMTP id 9F671676D1; Wed, 10 Aug 2005 20:48:47 +0200 (CEST) Received: from mail-in-09.arcor-online.net (mail-in-09.arcor-online.net [151.189.21.49]) by mail-in-06-z2.arcor-online.net (Postfix) with ESMTP id 86324120246; Wed, 10 Aug 2005 20:48:48 +0200 (CEST) Received: from Tseno (dsl-084-057-009-052.arcor-ip.net [84.57.9.52]) by mail-in-09.arcor-online.net (Postfix) with SMTP id D41A749717; Wed, 10 Aug 2005 20:48:46 +0200 (CEST) Message-ID: <005a01c59ddc$1f2aed00$0c00a8c0@Tseno> From: "Tseno Tsenov" To: "Kappler, Cornelia" , "Ash, Gerald R \(Jerry\), ALABS" , References: <391E6FBF5E786940B9E2F7CA6376C7086C1603@blns00fa.ww002.siemens.net> Subject: Re: [NSIS] QSPEC extensibility and re-use of multiple instances ofdefined parameters Date: Wed, 10 Aug 2005 20:30:06 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1506 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Spam-Score: 0.0 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f Content-Transfer-Encoding: 7bit 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: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi Cornelia, I agree that currently there might be no QoS model that uses multiple values of one QoS parameter (except the DiffServ case). However the current encoding approach restricts the extensibility of the QSPEC. Your example with usage of two different QoS classes which are mandatory parameters (and are redundant in some sense) raises other question for me: Again, we have a new QoS model does not use any of the mandatory QSPEC parameters and defines its own set of optional QSPEC parameters. Then, is it expected that some mandatory QSPEC parameters will be "artificially" included which will provide interoperability with other QoS models? greetings, Tseno_ ----- Original Message ----- From: "Kappler, Cornelia" To: "Ash, Gerald R (Jerry), ALABS" ; "Tseno Tsenov" ; Sent: Tuesday, August 09, 2005 10:17 AM Subject: RE: [NSIS] QSPEC extensibility and re-use of multiple instances ofdefined parameters Hi Tseno, if we expect multiple instances of the same parameter are something that is frequent in QOSMs I think we should go for your proposal which is a rather efficient way of coding it. On the other hand, I am not sure how likely it is that a QoS Model needs e.g. multiple values of QoS Classes? Isnt the token bucket quite a special case? All QOSMs we looked at so far, except DiffServ, dont need this feature. In any event we probably should make (if at all) mandatory only the first instance (i.e. a QNE implementing a QoS Model that doesnt need any (or multiple) instances of this parameter should only be forced to interpret the first occurrance.) A related question: What if a QNI wishes to code e.g. QoS Class, and has a very good idea that it wants a specific PHB from QNEs implementing the DiffServ QOSM, a specific Y.1541 QoS Class from QNEs implementing the Y.1441 QOSM etc. Is it allowed to include values for each type of QoS class it knows about? This is another usage of "multiple instances" (in fact it is more like "multiple values". Note this means a QNE would have to parse all these values to find out whether one specific to its QOSM is included. May be too much feature creep. Cornelia > -----Original Message----- > From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On > Behalf Of Ash, Gerald R (Jerry), ALABS > Sent: Sonntag, 7. August 2005 00:44 > To: Tseno Tsenov; nsis@ietf.org > Cc: Ash, Gerald R (Jerry), ALABS > Subject: RE: [NSIS] QSPEC extensibility and re-use of > multiple instances ofdefined parameters > > > Tseno, > > I like your suggestion. I think it both simplifies and > generalizes the > QSPEC to handle multiple instances of the same parameter. The second > and higher instances of any parameter could be defined as optional. > Procedures for multiple uses of a QSPEC parameter would have to be > defined by a given QOSM. > > What do others think? > > Thanks, > Jerry > > -----Original Message----- > From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On > Behalf Of > Tseno Tsenov > Sent: Friday, August 05, 2005 6:03 AM > To: nsis@ietf.org > Subject: [NSIS] QSPEC extensibility and re-use of multiple > instances of > defined parameters > > Hi, > > In my opinion, the current QSPEC draft miss flexibility for multiple > usage of QSPEC parameters of one type. Currently, for usage of two > token bucket in DiffServ EF PH QoS model, two separate mandatory token > buckets are defined (ID=5 and 6). And for example, if a new QoS model > requires 3 token buckets at some later point, it must define an > additional optional token bucket parameter. > Why don't the QSPEC template provide a method for multiple > usage of one > already defined parameter, if a QoS model needs it. This could be done > in the following way: > 1. According to the QSPEC draft, each defined QSPEC parameter has a > specified fixed value length - bandwidth - 4bytes, token bucket -20 > bytes, etc. > 2. The structure of a QSPEC parameter may carry multiple values of a > QSPEC parameter. Different values will be parsed based on the known > fixed length of the parameter value. > 3. Length field of the parameter structure will carry total > length of > the parameters values. > > The format for bandwidth would be this: > | Object ID | Parameter ID = 3 | Length = 8 bytes | Bandwidth > value 1 | > Bandwidth value 2 | > > For interoperability, if a mandatory parameter with such > multiple-value > structure is used, all nodes must interpret the first value. If a node > supports the QoS model that uses such multiple-value > parameter it makes > use of all values. > > I hope I don't misunderstand the QSPEC usage. > > Greetings, > > tseno_ > > > > _______________________________________________ > 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 Aug 10 15:50:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2wab-0002rn-56; Wed, 10 Aug 2005 15:50:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2waR-0002lX-Nc; Wed, 10 Aug 2005 15:50:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24207; Wed, 10 Aug 2005 15:50:01 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2x8b-0001wi-IF; Wed, 10 Aug 2005 16:25:22 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1E2waQ-0007jN-3L; Wed, 10 Aug 2005 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 10 Aug 2005 15:50:02 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: nsis@ietf.org Subject: [NSIS] I-D ACTION:draft-ietf-nsis-y1541-qosm-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: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Next Steps in Signaling Working Group of the IETF. Title : Y.1541-QOSM -- Y.1541 QoS Model for Networks Using Y.1541 QoS Classes Author(s) : J. Ash, et al. Filename : draft-ietf-nsis-y1541-qosm-00.txt Pages : 12 Date : 2005-8-10 This draft describes a QoS-NSLP QoS model (QOSM) based on ITU-T Recommendation Y.1541 QoS signaling requirements. Y.1541 specifies 6 standard QoS classes, and the Y.1541-QOSM extensions include additional QSPEC parameters and QOSM control processing guidelines. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nsis-y1541-qosm-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-ietf-nsis-y1541-qosm-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-ietf-nsis-y1541-qosm-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: <2005-8-10114020.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nsis-y1541-qosm-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nsis-y1541-qosm-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-8-10114020.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --NextPart-- From nsis-bounces@ietf.org Fri Aug 12 09:26:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3ZYZ-0007OK-1k; Fri, 12 Aug 2005 09:26:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3ZYX-0007OC-5t for nsis@megatron.ietf.org; Fri, 12 Aug 2005 09:26:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21585 for ; Fri, 12 Aug 2005 09:26:38 -0400 (EDT) Received: from iramx1.ira.uni-karlsruhe.de ([141.3.10.80] ident=[U2FsdGVkX19UU6p5FSTtJS8aSF6M5xEPbl8LyqNZBeQ=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3a72-0000jL-SX for nsis@ietf.org; Fri, 12 Aug 2005 10:02:22 -0400 Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by iramx1.ira.uni-karlsruhe.de with esmtps id 1E3ZYK-0002Yk-Rc for ; Fri, 12 Aug 2005 15:26:34 +0200 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 860AEBDEA for ; Fri, 12 Aug 2005 15:26:28 +0200 (CEST) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1E3ZYK-0007j9-7o for nsis@ietf.org; Fri, 12 Aug 2005 15:26:28 +0200 Message-ID: <42FCA383.9070101@tm.uka.de> Date: Fri, 12 Aug 2005 15:26:27 +0200 From: Roland Bless Organization: Institute of Telematics, University of Karlsruhe User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050716) X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: "nsis@ietf.org" X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Spam-Score: -5.4 (-----) X-Spam-Status: No X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Subject: [NSIS] QoS NSLP 5.4.3 Response w/o RSN and RII 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: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi, Markus Ott, who currently implements the QoS NSLP, asked himself what to do when he receives a RESPONSE without RSN and RII. Section 5.4.3 (draft-qos-nslp-07) describes only what to do when either RSN or RII is present. But how should a RESPONSE be processed if both are missing (which is ok due to the current RESPONSE ABNF Spec)? Another case when this may occur: when a RESERVE comes in but has no RSN. In this case the node should/could respond with a RESPONSE (Error Mandatory object missing). Technically one can use the Source SII-Handle to send it back. But how long is it forwarded along the path since no QNE can match this RESPONSE to a REQUEST etc.? I guess it should not be forwarded, but there should be a sentence stating that: "On receipt of a RESPONSE message containing neither an RII nor AN RSN object, the RESPONSE MUST NOT be forwarded further along the path." Are there any cases that have different requirements? Best regards, Roland & Markus _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Aug 12 10:06:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3aB3-0001Dw-MX; Fri, 12 Aug 2005 10:06:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3aB0-0001DH-V3 for nsis@megatron.ietf.org; Fri, 12 Aug 2005 10:06:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24579 for ; Fri, 12 Aug 2005 10:06:24 -0400 (EDT) Received: from mailrelay2.lrz-muenchen.de ([129.187.254.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3ajW-0001zW-3v for nsis@ietf.org; Fri, 12 Aug 2005 10:42:07 -0400 Received: from pluto.ze.tum.de (pluto.ze.tum.de [129.187.39.19]) by mailout.lrz-muenchen.de with ESMTP; Fri, 12 Aug 2005 16:06:10 +0200 To: bless@tm.uka.de, "nsis@ietf.org" From: Tseno Tsenov Subject: =?iso-8859-1?q?Re=3A_=5BNSIS=5D_QoS_NSLP_5=2E4=2E3_Response_w/o_RSN_and_R?= =?iso-8859-1?q?II?= Date: Fri, 12 Aug 2005 16:06:09 +0200 Mime-version: 1.0 Content-type: Multipart/mixed; boundary="===============1396828193==" Message-Id: X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 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: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org You will not see this in a MIME-aware mail reader. --===============1396828193== Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Hi, A related issues that I faced in the work on the QoS-NSLP FSM: Section 5.4.3./the last paragraph/ of QoS NSLP draft states: " On receipt of a RESPONSE message containing an RSN object, the QNE MUST compare the RSN to that of the appropriate signaling session. If the match succeeds then the ERROR_SPEC MUST be processed. The RESPONSE message MUST NOT be forwarded further along the path whether or not the match succeeds. " In case a QNE receives RESERVE message without RII and it does not have eno= ugh resources to meet the QoS requested with the RESERVE message, it should= send back a RESPONSE with the RSN(from the RESERVE) and an appropriate ERR= OR_SPEC. Following the above rules, this RESPONSE message must be stopped i= n the upstream neighbor QNE. Then, how is the unsuccessful reservation repo= rted to the upstream QNEs and QNI? greetings, Tseno Original Message: Hi, Markus Ott, who currently implements the QoS NSLP, asked himself what to do when he receives a RESPONSE without RSN and RII. Section 5.4.3 (draft-qos-nslp-07) describes only what to do when either RSN or RII is present. But how should a RESPONSE be processed if both are missing (which is ok due to the current RESPONSE ABNF Spec)? Another case when this may occur: when a RESERVE comes in but has no RSN. In this case the node should/could respond with a RESPONSE (Error Mandatory object missing). Technically one can use the Source SII-Handle to send it back. But how long is it forwarded along the path since no QNE can match this RESPONSE to a REQUEST etc.? I guess it should not be forwarded, but there should be a sentence stating that: "On receipt of a RESPONSE message containing neither an RII nor AN RSN object, the RESPONSE MUST NOT be forwarded further along the path." Are there any cases that have different requirements? Best regards, Roland & Markus _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --===============1396828193== 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 --===============1396828193==-- From nsis-bounces@ietf.org Fri Aug 12 10:48:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3apN-0005LS-VQ; Fri, 12 Aug 2005 10:48:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3apM-0005Ij-IU for nsis@megatron.ietf.org; Fri, 12 Aug 2005 10:48:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28912 for ; Fri, 12 Aug 2005 10:48:02 -0400 (EDT) Received: from gecko.sbs.de ([194.138.37.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3bNp-0003Vm-Vi for nsis@ietf.org; Fri, 12 Aug 2005 11:23:46 -0400 Received: from mail1.sbs.de (mail1.sbs.de [192.129.41.35]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id j7CEljNK029545 for ; Fri, 12 Aug 2005 16:47:45 +0200 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id j7CElgFI018496 for ; Fri, 12 Aug 2005 16:47:42 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.0); Fri, 12 Aug 2005 16:47:33 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 12 Aug 2005 16:47:33 +0200 Message-ID: Thread-Topic: NAT traversal at the GIST Layer: which approach to take? Thread-Index: AcWfR1V29+dQANEoSEyNpGtVjKeRiAABStHQ From: "Pashalidis, Andreas" To: X-OriginalArrivalTime: 12 Aug 2005 14:47:33.0730 (UTC) FILETIME=[C5F31420:01C59F4C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 202a3ece0492a8c7e7c8672d5214398f Content-Transfer-Encoding: quoted-printable Subject: [NSIS] NAT traversal at the GIST Layer: which approach to take? 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: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Dear WG, As some of you may remember, in the last meeting a question arose about which approach(es) to use for NAT traversal at the GIST layer. The purpose of this e-mail is for the WG to obtain "rough consensus" about answering this question, so that the appropriate text can be put into the next version of the "NAT traversal for GIST" draft (the current version is available at http://www.ietf.org/internet-drafts/draft-pashalidis-nsis-gimps-nattrave rsal-00.txt) =3D=3D=3D=3D The two approaches concern GIST-aware NATs (GaNATS) only; (i.e. they do not apply to "NSIS-unaware" NATs). I will now briefly outline the two approaches. 1) The GaNAT includes an additional "NAT Traversal" payload into the GIST header of the GIST QUERY, RESPONSE and CONFIRM messages. The GIST peers either side of the NAT use the information in this payload in order to map subsequent signalling messages to the data flows they refer to.=20 2) The GaNAT replaces GIST header fields in a way consistent with the translation of data traffic, as necessary. The GaNAT does this for D-mode as well as for C-mode messages throughout the duration of the signalling session. Note that the first approach is more closely aligned with what is outlined in section 7.3 of the current GIMPS/GIST draft. I will now list potential advantages and disadvantages of each approach. Please feel free to add or delete items from/to these lists. Potential advantages of the first approach include the following. *) As the GaNAT has to inspect only certain D-mode GIMPS messages, the processing overhead imposed on it is minimal. *) The amount of per-signalling session state that the GaNAT has to maintain is less compared to the second approach. *) The approach works in the presence of cryptographically protected signalling traffic. Potential disadvantages of the first approach include the following. *) Non-NAT GIST nodes must be NAT-aware, i.e. all GIST nodes need to implement the mechanism that follows this approach. *) Internal network details may be revealed to untrusted parts of the network. This is because the original GIST header fields remain in the message that leaves the GaNAT. *) At some point the GaNAT installs a NAT binding for the signalling traffic. From that point onwards, the GaNAT treats signalling traffic like any other type of traffic. This may be an opportunity for an intruder to inject non-signalling traffic into the internal network in scenarios where the GaNAT also acts as a firewall. *)The testing of implementations (e.g. via manual packet analysis) in complex environments may be non-trivial as the correspondence between=20 signalling and data traffic is only visible in the packets that carry the initial GIST QUERY/RESPONSE/CONFIRM messages. Potential advantages of the second approach include the following. *) GaNATs remain transparent to other GIST nodes. As a result, non-NAT GIST nodes do not need to implement any mechanisms apart from the basic GIST specification. *) As a result of the above, cascades of such GaNATs are also handled in a straightforward manner. *) Testing by packet analysis may be easier as the IP header in the data flow in consistent with the MRI in the GIST header of signalling messages throughout the network. *) In contrast to the first approach, the GaNAT verifies that all signalling traffic actually carries a GIST header after the transport layer header. This advantage should be contrasted to the third disadvantage of the first approach. Potential disadvantages of the second approach include the following. *) The approach does not work in the presence of cryptographically protected signalling traffic. This is because the replacement of GIST header fields by the GaNAT causes cryptographic checks to fail at the receiving GIST peer.=20 *) The GaNAT has to process all (as opposed to only a small subset of) GIST headers of signalling messages.=20 *) The amount of per signalling session state that the GaNAT maintains is larger compared to the first approach. *) The GaNAT may be exposed to service denial attacks to a higher degree compared to the first approach. Both approaches are adopted in the current draft. That is, a GaNAT implements the mechanisms that implement both approaches. It can then adopt the correct behaviour, based on whether or not cryptographic protection is required for the signalling traffic between two GIST peers. If such protection is not required, the GaNAT adopts the mechanisms that follow the first approach; if it is, it follows the mechanisms implementing the second approach. The GaNAT can tell whether or not cryptographic protection is required from the stack proposals that are exchanged in the GIST QUERY and RESPONSE messages; inclusion of IPsec or TLS proposals amount to cryptographic protection being required.=20 For those that may want some more information in order to contribute their view on this matter (but do not necessarily want to read the current draft), a more detailed explanation of how new signalling session are handled by the NAT can be found in the "trailer" of this email. =3D=3D=3D=3D=3D =20 Question to the WG: It remains unclear whether or not it is desirable to specify both the above approaches=20 (for example, because there may be scenarios the requirements of which are better met by one or the other). What does the WG think. (a) Both approaches should be mandantory to implement. (b) One approach only should be taken (which one?) (c) One approach should be mandantory to implement (which one?) and one should be optional (which one?) (d) Another approach is better (please describe the approach) =3D=3D=3D=3D=3D=3D Many thanks for your time and response! START OF TRAILER The following three paragraphs clarify how the GaNAT handles new signalling sessions and how the selection of the "correct" behaviour is supposed to work. Regardless of which approach is taken, after a GIST response passes through the GaNAT, the GaNAT should expect a messaging association to be set up between the two involved GIST peers. For this to happen, the GaNAT has to allow traffic to traverse it. From a security perspective, the GaNAT should allow the minimum necessary traffic types to traverse. Additionally, the amount of per signalling session state that is allocated at a GaNAT should be minimised for reasons of efficiency and resistance to service denial attacks. For these reasons, it makes sense for the GaNAT to be able to predict with certainty which of the GIST responder's stack proposal will be used by the initiator for the establishement of a messaging association. This can be accomplished by having the GaNAT=20 modify the stack configuration object in the GIST response as it passes though it such that the initiator is forced to use a particular stack proposal and, if applicable, a particular transport layer destination port.=20 =20 The reason why it is preferable for the GaNAT to modify only the stack configuration data object (as opposed to the stack proposal object) is that the GIST responder expects its original stack proposal to be included in the GIST CONFIRM message. The initiator would not be able to echo that object as it would not have seen it and, if signalling=20 messages are cryptographically protected, then the GaNAT cannot replace the stack proposal in the GIST CONFIRM message=20 with the one the responder expect, without causing cryptographic checks to fail at the responder. Thus, the approach taken in this document is for the GaNAT to render invalid all but one stack configuration data objects in the GIST RESPONSE message. A stack configuration object is rendered invalid by setting the port number to zero.=20 A question arises due to the fact that the stack proposal carried by a GIST RESPONSE may include multiple messaging=20 associations of which some provide cryptographic protection for signalling traffic and some do not. Which behaviour should the GaNAT assume in this case? In other words, which stack configuration objects should the GaNAT render invalid in this case? The GaNAT SHOULD render invalid all stack configuration objects except the first that refers to a stack proposal that offers cryptographic protection.=20 END OF TRAILER Andreas and Hannes _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Aug 12 11:50:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3bnm-0007sI-43; Fri, 12 Aug 2005 11:50:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3bnk-0007sD-K4 for nsis@megatron.ietf.org; Fri, 12 Aug 2005 11:50:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02214 for ; Fri, 12 Aug 2005 11:50:29 -0400 (EDT) Received: from difra-computer.de ([81.169.157.103] helo=www.difra-computer.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3cMH-0005UH-7v for nsis@ietf.org; Fri, 12 Aug 2005 12:26:14 -0400 Received: from win2003.dickmann2003.home (p548A757C.dip.t-dialin.net [84.138.117.124]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by www.difra-computer.de (Postfix) with ESMTP id 951A53E402B for ; Fri, 12 Aug 2005 17:46:12 +0200 (CEST) Received: from christian ([192.168.0.2]) by win2003.dickmann2003.home with Microsoft SMTPSVC(6.0.3790.211); Fri, 12 Aug 2005 17:44:48 +0200 From: "Christian Dickmann" To: "'Pashalidis, Andreas'" , Subject: RE: [NSIS] NAT traversal at the GIST Layer: which approach to take? Date: Fri, 12 Aug 2005 17:44:54 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcWfR1V29+dQANEoSEyNpGtVjKeRiAABStHQAAGtQRA= In-Reply-To: Message-ID: X-OriginalArrivalTime: 12 Aug 2005 15:44:48.0958 (UTC) FILETIME=[C58145E0:01C59F54] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 7bit 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: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi Andreas, > Potential disadvantages of the first approach include the following. > > *)The testing of implementations (e.g. via manual packet analysis) in > complex environments may be non-trivial as the correspondence between > signalling and data traffic is only visible in the packets that carry > the initial GIST QUERY/RESPONSE/CONFIRM messages. I do not think, that there is really an issue here. > Potential advantages of the second approach include the following. > > *) GaNATs remain transparent to other GIST nodes. As a result, non-NAT > GIST nodes do not need to implement any mechanisms > apart from the basic GIST specification. I think this statement is just not true. The solution has to be flexible enough to work in all scenarios and this includes profiles referring to secure connections (like TCP/TLS). Your second approach does not work for this scenario. > Question to the WG: It remains unclear whether or not it is desirable to > specify both the above approaches > (for example, because there may be scenarios the requirements of which > are better met by one or the other). What does the WG think. > > (a) Both approaches should be mandantory to implement. > (b) One approach only should be taken (which one?) > (c) One approach should be mandantory to implement (which one?) and one > should be optional (which one?) I prefer (c). Make the first approach mandatory and the second one optional. As said, the second one is not flexible enough to handle all scenarios, so the draft MUST contain an alternative approach for those cases. In contrast, the first approach works in all scenarios and therefore it should be the mandatory one. But as you outlines in your analysis GaNATs might prefer the second approach in special cases. So the draft could contain a section about this approach and descripe roughly how it works and in which cases it is applicable. To summarize my opinion: My first choice would be (c) and alternatively (b). Christian Dickmann _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Aug 17 03:01:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5HvR-00076w-Qf; Wed, 17 Aug 2005 03:01:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5HvP-00076d-9O for nsis@megatron.ietf.org; Wed, 17 Aug 2005 03:01:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10735 for ; Wed, 17 Aug 2005 03:01:21 -0400 (EDT) From: john.loughney@nokia.com Received: from mgw-ext04.nokia.com ([131.228.20.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5IUt-0004wH-Ky for nsis@ietf.org; Wed, 17 Aug 2005 03:38:04 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j7H6ec8w000713; Wed, 17 Aug 2005 09:40:40 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 17 Aug 2005 09:40:54 +0300 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 17 Aug 2005 09:40:53 +0300 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] QSPEC extensibility and re-use of multiple instances ofdefined parameters Date: Wed, 17 Aug 2005 09:40:55 +0300 Message-ID: <1AA39B75171A7144A73216AED1D7478D9EF1C7@esebe100.NOE.Nokia.com> Thread-Topic: [NSIS] QSPEC extensibility and re-use of multiple instances ofdefined parameters Thread-Index: AcWZpTKN6Z3QOefsSPGiqYFNYN0BhQBMpSuwAgeix8A= To: , , X-OriginalArrivalTime: 17 Aug 2005 06:40:53.0672 (UTC) FILETIME=[9D6C9280:01C5A2F6] X-Spam-Score: 0.3 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: quoted-printable 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: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org =20 Jerry, >I like your suggestion. I think it both simplifies and=20 >generalizes the QSPEC to handle multiple instances of the same=20 >parameter. The second and higher instances of any parameter=20 >could be defined as optional. >Procedures for multiple uses of a QSPEC parameter would have=20 >to be defined by a given QOSM. > >What do others think? I think it's a trade-off. I am worried about making things too complex. Are multiple instances really useful or needed? The risk of supplying too many options and too much extensibility is that managing the QoS parameters in a network & inter-working between different networks will be quite complex. I think we should only support this if there is a real need.=20 John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Aug 17 04:22:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5JC0-0007jl-FH; Wed, 17 Aug 2005 04:22:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5JBy-0007jg-1o for nsis@megatron.ietf.org; Wed, 17 Aug 2005 04:22:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14639 for ; Wed, 17 Aug 2005 04:22:31 -0400 (EDT) Received: from goliath.siemens.de ([192.35.17.28]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5JlQ-0007VY-Bv for nsis@ietf.org; Wed, 17 Aug 2005 04:59:14 -0400 Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by goliath.siemens.de (8.12.6/8.12.6) with ESMTP id j7H8MPww009478; Wed, 17 Aug 2005 10:22:25 +0200 Received: from mhpahx0c.ww002.siemens.net (mhpahx0c.ww002.siemens.net [139.25.165.42]) by mail1.siemens.de (8.12.6/8.12.6) with ESMTP id j7H8MOYT026759; Wed, 17 Aug 2005 10:22:24 +0200 Received: from blns00fa.ww002.siemens.net ([147.54.45.102]) by mhpahx0c.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.211); Wed, 17 Aug 2005 10:21:00 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] QSPEC extensibility and re-use of multiple instances ofdefined parameters Date: Wed, 17 Aug 2005 10:22:20 +0200 Message-ID: <391E6FBF5E786940B9E2F7CA6376C7086C1646@blns00fa.ww002.siemens.net> Thread-Topic: [NSIS] QSPEC extensibility and re-use of multiple instances ofdefined parameters Thread-Index: AcWd3C0rfXniEI+ZScaG5v9vZ62C3AFJR4nw From: "Kappler, Cornelia" To: "Tseno Tsenov" , "Ash, Gerald R \(Jerry\), ALABS" , X-OriginalArrivalTime: 17 Aug 2005 08:21:00.0671 (UTC) FILETIME=[99DFE0F0:01C5A304] X-Spam-Score: 0.0 (/) X-Scan-Signature: ccfb4541e989aa743998098cd315d0fd Content-Transfer-Encoding: quoted-printable 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: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi Tseno - and John and Jerry,=20 so there doesnt seem to be much concrete use for this additional kind of extensibility. Therefore my suggestion is to not support it.=20 Regarding your (Tseno) 2nd paragraph:=20 In the QSPEC we tried to balance two mutually exclusive requirements - accomodate as many QoS Models as possible - make the QSPEC as widely understood as possible without defining too many parameters.=20 We solved this problem by defining mandatory parameters which we expect to be used in most QOSMs (e.g. bandwidth); and by requesting all QNEs to _understand_ the mandatory parameters. That is, for a QOSM that has no use of the mandatory parameters (which is quite unlikely by the way) these parameters _dont need to be included_ in the QSPEC. However this makes it unlikely that this QSPEC will be understood outside the domain of this QOSM.=20 I guess we have to explain this better in our document as this is not the first time somebody (particularly someone really familiar with NSIS) didnt really get the idea. Cornelia > -----Original Message----- > From: Tseno Tsenov [mailto:tseno.tsenov@mytum.de]=20 > Sent: Mittwoch, 10. August 2005 20:30 > To: Kappler, Cornelia; Ash, Gerald R (Jerry), ALABS; nsis@ietf.org > Subject: Re: [NSIS] QSPEC extensibility and re-use of=20 > multiple instances ofdefined parameters >=20 >=20 > Hi Cornelia, >=20 > I agree that currently there might be no QoS model that uses=20 > multiple values > of one QoS parameter (except the DiffServ case). However the current > encoding approach restricts the extensibility of the QSPEC. >=20 > Your example with usage of two different QoS classes which=20 > are mandatory > parameters (and are redundant in some sense) raises other=20 > question for me: > Again, we have a new QoS model does not use any of the mandatory QSPEC > parameters and defines its own set of optional QSPEC=20 > parameters. Then, is it > expected that some mandatory QSPEC parameters will be "artificially" > included which will provide interoperability with other QoS models? >=20 > greetings, > Tseno_ >=20 > ----- Original Message -----=20 > From: "Kappler, Cornelia" > To: "Ash, Gerald R (Jerry), ALABS" ; "Tseno Tsenov" > ; > Sent: Tuesday, August 09, 2005 10:17 AM > Subject: RE: [NSIS] QSPEC extensibility and re-use of=20 > multiple instances > ofdefined parameters >=20 >=20 > Hi Tseno, >=20 > if we expect multiple instances of the same parameter are=20 > something that > is frequent in QOSMs I think we should go for your proposal which is a > rather efficient way of coding it. On the other hand, I am=20 > not sure how > likely it is that a QoS Model needs e.g. multiple values of=20 > QoS Classes? > Isnt the token bucket quite a special case? All QOSMs we looked at so > far, except DiffServ, dont need this feature. >=20 > In any event we probably should make (if at all) mandatory only the > first instance (i.e. a QNE implementing a QoS Model that=20 > doesnt need any > (or multiple) instances of this parameter should only be forced to > interpret the first occurrance.) >=20 > A related question: > What if a QNI wishes to code e.g. QoS Class, and has a very good idea > that it wants a specific PHB from QNEs implementing the=20 > DiffServ QOSM, a > specific Y.1541 QoS Class from QNEs implementing the Y.1441=20 > QOSM etc. Is > it allowed to include values for each type of QoS class it=20 > knows about? > This is another usage of "multiple instances" (in fact it is more like > "multiple values". Note this means a QNE would have to parse all these > values to find out whether one specific to its QOSM is=20 > included. May be > too much feature creep. >=20 > Cornelia >=20 > > -----Original Message----- > > From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On > > Behalf Of Ash, Gerald R (Jerry), ALABS > > Sent: Sonntag, 7. August 2005 00:44 > > To: Tseno Tsenov; nsis@ietf.org > > Cc: Ash, Gerald R (Jerry), ALABS > > Subject: RE: [NSIS] QSPEC extensibility and re-use of > > multiple instances ofdefined parameters > > > > > > Tseno, > > > > I like your suggestion. I think it both simplifies and > > generalizes the > > QSPEC to handle multiple instances of the same parameter. =20 > The second > > and higher instances of any parameter could be defined as optional. > > Procedures for multiple uses of a QSPEC parameter would have to be > > defined by a given QOSM. > > > > What do others think? > > > > Thanks, > > Jerry > > > > -----Original Message----- > > From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On > > Behalf Of > > Tseno Tsenov > > Sent: Friday, August 05, 2005 6:03 AM > > To: nsis@ietf.org > > Subject: [NSIS] QSPEC extensibility and re-use of multiple > > instances of > > defined parameters > > > > Hi, > > > > In my opinion, the current QSPEC draft miss flexibility for multiple > > usage of QSPEC parameters of one type. Currently, for usage of two > > token bucket in DiffServ EF PH QoS model, two separate=20 > mandatory token > > buckets are defined (ID=3D5 and 6). And for example, if a new=20 > QoS model > > requires 3 token buckets at some later point, it must define an > > additional optional token bucket parameter. > > Why don't the QSPEC template provide a method for multiple > > usage of one > > already defined parameter, if a QoS model needs it. This=20 > could be done > > in the following way: > > 1. According to the QSPEC draft, each defined QSPEC=20 > parameter has a > > specified fixed value length - bandwidth - 4bytes, token bucket -20 > > bytes, etc. > > 2. The structure of a QSPEC parameter may carry multiple=20 > values of a > > QSPEC parameter. Different values will be parsed based on the known > > fixed length of the parameter value. > > 3. Length field of the parameter structure will carry total > > length of > > the parameters values. > > > > The format for bandwidth would be this: > > | Object ID | Parameter ID =3D 3 | Length =3D 8 bytes | Bandwidth > > value 1 | > > Bandwidth value 2 | > > > > For interoperability, if a mandatory parameter with such > > multiple-value > > structure is used, all nodes must interpret the first=20 > value. If a node > > supports the QoS model that uses such multiple-value > > parameter it makes > > use of all values. > > > > I hope I don't misunderstand the QSPEC usage. > > > > Greetings, > > > > tseno_ > > > > > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > >=20 >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Aug 17 14:15:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5SRD-0000Ec-ML; Wed, 17 Aug 2005 14:14:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5SRB-0000D0-5T for nsis@megatron.ietf.org; Wed, 17 Aug 2005 14:14:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15457 for ; Wed, 17 Aug 2005 14:14:51 -0400 (EDT) Received: from mclmx2.mail.saic.com ([149.8.64.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5T0k-0007Pt-8q for nsis@ietf.org; Wed, 17 Aug 2005 14:51:40 -0400 Received: from [149.8.64.21] by mclmx2.mail.saic.com; Wed, 17 Aug 2005 14:14:26 -0400 Received: from mclmx.mail.saic.com ([149.8.64.10]) by mcl-its-ieg01.mail.saic.com (SMSSMTP 4.0.5.66) with SMTP id M2005081714142501121 ; Wed, 17 Aug 2005 14:14:25 -0400 Received: from [149.8.64.21] by mclmx.mail.saic.com with ESMTP; Wed, 17 Aug 2005 14:14:25 -0400 Received: from bh-exchange02.saic-abingdon.com ([10.42.81.226]) by bh-exchangefe.saic-abingdon.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 17 Aug 2005 14:16:40 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [NSIS] QSPEC extensibility and re-use of multiple instances of defined parameters Date: Wed, 17 Aug 2005 14:16:37 -0400 Message-Id: <2FE23D25B7292B489A217D1965CDA866089875@bh-exchange02.saic-abingdon.com> Thread-Topic: [NSIS] QSPEC extensibility and re-use of multiple instances of defined parameters Thread-Index: AcWd3C0rfXniEI+ZScaG5v9vZ62C3AFJR4nwABQVUxA= From: "Roy, Radhika \(AEAD\)" To: "Kappler, Cornelia" X-OriginalArrivalTime: 17 Aug 2005 18:16:40.0392 (UTC) FILETIME=[D0688480:01C5A357] X-Spam-Score: 0.2 (/) X-Scan-Signature: 8bebc843ecf489bb7d907f63ccb001af 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="===============1026967208==" Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. --===============1026967208== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5A357.CEC71344" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5A357.CEC71344 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cornelia: In response to one of Tseno's questions, you have mentioned as follows: ".. accommodate as many QoS Models as possible .." In fact, it is NOT true. Even the QOS model like Y.1541 that has been trying to be accommodated fully in the draft has been failed. Please see the following draft:=20 http://www.ietf.org/internet-drafts/draft-ietf-nsis-y1541-qosm-00.txt The above draft shows that more extensions in QSPEC template are needed. The basic question is this: Why do you want to include the QOS model-specific extensions in the "generalized" QSPEC template draft? What you have done is this: Included Y1541 QOS model (which is also incomplete) and DSTE QOS model (a cheap shot - basically only one parameter).=20 Tseno has mentioned the most fundamental QOS models of the IETF: IntServ and DiffServ. You have failed to explain why you have not included those in the draft. What do you mean that you have accommodated as many QOS models as possible? Why do you NOT "delete" all so-called QOS model-specific extensions from this draft? The way you should proceed is as follows: 1. Make the draft-ietf-nsis-y1541-qosm-00.txt complete including "all" extensions QSPEC specific to y1541using all "specific values." Also, show how to create y1541 domains using specific values without contradicting the end-to-end values from end users' and/or applications' point of view so that people can implement without creating any confusions or contradictions. 2. Do the same writing another draft for DSTE model as explained in item 1. 3. Delete all QOS model-specific extensions in the generalized QSPEC draft. In this way, all drafts will be clean. If you have any questions, please let us know. Best regards, Radhika PS: I also explained in earlier emails (John L. also agreed) that the use of both generalized QSPEC template and QOS model-specific QSPEC template will create contradictions if domains are not created carefully. The present QSPEC draft does not explain how to create respective QOS domains using specific values in the first place. -----Original Message----- From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On Behalf Of Kappler, Cornelia Sent: Wednesday, August 17, 2005 4:22 AM To: Tseno Tsenov; Ash, Gerald R (Jerry), ALABS; nsis@ietf.org Subject: RE: [NSIS] QSPEC extensibility and re-use of multiple instances of defined parameters Hi Tseno - and John and Jerry,=20 so there doesnt seem to be much concrete use for this additional kind of extensibility. Therefore my suggestion is to not support it.=20 Regarding your (Tseno) 2nd paragraph:=20 In the QSPEC we tried to balance two mutually exclusive requirements - accommodate as many QoS Models as possible - make the QSPEC as widely understood as possible without defining too many parameters.=20 We solved this problem by defining mandatory parameters which we expect to be used in most QOSMs (e.g. bandwidth); and by requesting all QNEs to _understand_ the mandatory parameters. That is, for a QOSM that has no use of the mandatory parameters (which is quite unlikely by the way) these parameters _dont need to be included_ in the QSPEC. However this makes it unlikely that this QSPEC will be understood outside the domain of this QOSM.=20 I guess we have to explain this better in our document as this is not the first time somebody (particularly someone really familiar with NSIS) didn't really get the idea. Cornelia > -----Original Message----- > From: Tseno Tsenov [mailto:tseno.tsenov@mytum.de]=20 > Sent: Mittwoch, 10. August 2005 20:30 > To: Kappler, Cornelia; Ash, Gerald R (Jerry), ALABS; nsis@ietf.org > Subject: Re: [NSIS] QSPEC extensibility and re-use of=20 > multiple instances ofdefined parameters >=20 >=20 > Hi Cornelia, >=20 > I agree that currently there might be no QoS model that uses=20 > multiple values > of one QoS parameter (except the DiffServ case). However the current > encoding approach restricts the extensibility of the QSPEC. >=20 > Your example with usage of two different QoS classes which=20 > are mandatory > parameters (and are redundant in some sense) raises other=20 > question for me: > Again, we have a new QoS model does not use any of the mandatory QSPEC > parameters and defines its own set of optional QSPEC=20 > parameters. Then, is it > expected that some mandatory QSPEC parameters will be "artificially" > included which will provide interoperability with other QoS models? >=20 > greetings, > Tseno_ ------_=_NextPart_001_01C5A357.CEC71344 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: [NSIS] QSPEC extensibility and re-use of multiple instances = of defined parameters

Cornelia:

In response to one of Tseno's questions, you have mentioned as = follows:

".. accommodate as many QoS = Models as possible = .."

In fact, it is NOT true. Even the QOS = model like Y.1541 that has been trying to be = accommodated fully in = the draft has been failed. Please see the = following draft: =

http://www.ietf.org/internet-drafts/draft-ietf-nsis-y1541-qosm-00.= txt

The above draft shows that more extensions in = QSPEC = template are = needed.

The basic question is this: Why do you want to = include = the QOS model-specific = extensions = in the "generalized" = QSPEC template draft?

What you have done is this: Included Y1541 QOS model (which is = also incomplete) and DSTE QOS model (a cheap = shot - basically only one = parameter). =

Tseno has mentioned the most fundamental QOS models of the IETF: IntServ and DiffServ. = You have failed to explain why you have not included those in = the draft.

What do you mean that you have accommodated as many QOS models as = possible?

Why do you = NOT "delete" all so-called QOS = model-specific extensions from this = draft?

The way you should proceed is as follows:

1.      = Make the = draft-ietf-nsis-y1541-qosm-00.txt complete including "all" = extensions = QSPEC specific to = y1541using all = "specific values." Also, show how to create y1541 domains using specific values = without contradicting the end-to-end values from end users' and/or = applications' point of view = so that people can implement without creating any confusions or = contradictions.

2.      = Do the same writing another = draft = for DSTE model as explained in = item = 1.

3.      = Delete all QOS model-specific = extensions in the generalized QSPEC draft.

In this way, all drafts will be clean.

If you have any questions, please let us know.

Best regards,

Radhika

PS: I also explained in earlier emails (John L. also agreed) = that = the use of both generalized QSPEC template and QOS model-specific = QSPEC template will = create contradictions = if domains are not created carefully. The present QSPEC draft does not = explain how to create respective QOS = domains using specific = values in the first place.

-----Original Message-----
From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] = On Behalf Of Kappler, Cornelia
Sent: Wednesday, August 17, 2005 4:22 AM
To: Tseno Tsenov; Ash, Gerald R (Jerry), ALABS; nsis@ietf.org
Subject: RE: [NSIS] QSPEC extensibility and re-use of multiple = instances = of defined = parameters

Hi Tseno - and John and Jerry,

so there doesnt seem to be much concrete use for this additional = kind of

extensibility. Therefore my suggestion is to not support it. =

Regarding your (Tseno) 2nd paragraph:

In the QSPEC we tried to balance two mutually exclusive = requirements

- = accommodate as many QoS Models as possible

- make the QSPEC as widely understood as possible without = defining too

many parameters.

We solved this problem by defining mandatory parameters which we = expect

to be used in most QOSMs (e.g. bandwidth); and by requesting all = QNEs to

_understand_ the mandatory parameters. That is, for a QOSM that = has no

use of the mandatory parameters (which is quite unlikely by the = way)

these parameters _dont need to be included_ in the QSPEC. However = this

makes it unlikely that this QSPEC will be understood outside the = domain

of this QOSM.

I guess we have to explain this better in our document as this is = not

the first time somebody (particularly someone really familiar = with NSIS)

didn't really get the = idea.

Cornelia

> -----Original Message-----

> From: Tseno Tsenov [mailto:tseno.tsenov@mytum.de] =

> Sent: Mittwoch, 10. August 2005 20:30

> To: Kappler, Cornelia; Ash, Gerald R (Jerry), ALABS; = nsis@ietf.org

> Subject: Re: [NSIS] QSPEC extensibility and re-use of =

> multiple instances ofdefined parameters

>

>

> Hi Cornelia,

>

> I agree that currently there might be no QoS model that uses =

> multiple values

> of one QoS parameter (except the DiffServ case). However the = current

> encoding approach restricts the extensibility of the = QSPEC.

>

> Your example with usage of two different QoS classes which =

> are mandatory

> parameters (and are redundant in some sense) raises other =

> question for me:

> Again, we have a new QoS model does not use any of the = mandatory QSPEC

> parameters and defines its own set of optional QSPEC =

> parameters. Then, is it

> expected that some mandatory QSPEC parameters will be = "artificially"

> included which will provide interoperability with other QoS = models?

>

> greetings,

> Tseno_

------_=_NextPart_001_01C5A357.CEC71344-- --===============1026967208== 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 --===============1026967208==-- From nsis-bounces@ietf.org Wed Aug 17 14:44:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5SuJ-0000GK-Ef; Wed, 17 Aug 2005 14:44:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5SuI-0000Fz-9h for nsis@megatron.ietf.org; Wed, 17 Aug 2005 14:44:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16899 for ; Wed, 17 Aug 2005 14:44:56 -0400 (EDT) Received: from mclmx.mail.saic.com ([149.8.64.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5TTs-0008Co-5t for nsis@ietf.org; Wed, 17 Aug 2005 15:21:45 -0400 Received: from [149.8.64.21] by mclmx.mail.saic.com; Wed, 17 Aug 2005 14:44:41 -0400 Received: from mclmx2.mail.saic.com ([149.8.64.32]) by 0015-its-ieg02.mail.saic.com (SMSSMTP 4.0.5.66) with SMTP id M2005081714444023889 ; Wed, 17 Aug 2005 14:44:41 -0400 Received: from [149.8.64.21] by mclmx2.mail.saic.com with ESMTP; Wed, 17 Aug 2005 14:44:40 -0400 Received: from bh-exchange02.saic-abingdon.com ([10.42.81.226]) by bh-exchangefe.saic-abingdon.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 17 Aug 2005 14:46:55 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [NSIS] QSPEC extensibility and re-use of multiple instances of defined parameters Date: Wed, 17 Aug 2005 14:46:52 -0400 Message-Id: <2FE23D25B7292B489A217D1965CDA866089876@bh-exchange02.saic-abingdon.com> Thread-Topic: [NSIS] QSPEC extensibility and re-use of multiple instances of defined parameters Thread-Index: AcWZpTKN6Z3QOefsSPGiqYFNYN0BhQBMpSuwAgeix8AAGOYxwA== From: "Roy, Radhika \(AEAD\)" To: , , , X-OriginalArrivalTime: 17 Aug 2005 18:46:55.0658 (UTC) FILETIME=[0A6420A0:01C5A35C] X-Spam-Score: 0.1 (/) X-Scan-Signature: 453b1bfcf0292bffe4cab90ba115f503 Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2070067010==" Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. --===============2070067010== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5A35C.08B91756" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5A35C.08B91756 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable John: You are right. The multiple instances of the same parameter will create a nightmare all by itself even we do not need interoperability. The reasons are simple (because what will be the criteria for using multiple instances of the same parameter?):=20 1. Is it due to time dependence? 2. Is it due to time dependence where no QOS domains like IntServ and DiffServ or QOS model-specific domains like y1541 are used? 3. Is it due to different kinds of QOS domains like IntServ and DiffSeve?=20 4. Is it due to different kinds of QOS model-specific domains like y1541 that are based on some values? 5. Is it due to combination of items 1 and 2? 6. Others? Best regards, Radhika -----Original Message----- From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On Behalf Of john.loughney@nokia.com Sent: Wednesday, August 17, 2005 2:41 AM To: gash@att.com; tseno.tsenov@mytum.de; nsis@ietf.org Subject: RE: [NSIS] QSPEC extensibility and re-use of multiple instances of defined parameters =20 Jerry, >I like your suggestion. I think it both simplifies and=20 >generalizes the QSPEC to handle multiple instances of the same=20 >parameter. The second and higher instances of any parameter=20 >could be defined as optional. >Procedures for multiple uses of a QSPEC parameter would have=20 >to be defined by a given QOSM. > >What do others think? I think it's a trade-off. I am worried about making things too complex. Are multiple instances really useful or needed? The risk of supplying too many options and too much extensibility is that managing the QoS parameters in a network & inter-working between different networks will be quite complex. I think we should only support this if there is a real need.=20 John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis ------_=_NextPart_001_01C5A35C.08B91756 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: [NSIS] QSPEC extensibility and re-use of multiple instances = of defined parameters

John:

You are right.

The multiple instances of the same parameter will create a = nightmare all by itself even we do not need = interoperability.

The reasons = are simple = (because what will be the = criteria for using multiple instances of the same = parameter?): =

1.      = Is it due to time = dependence?
2.      Is it due to time dependence where no QOS = domains like IntServ and = DiffServ or QOS = model-specific domains like y1541 are used?

3.      = Is it due to different kinds of = QOS domains like IntServ and = DiffSeve? =
4.      = Is it due to different kinds of QOS model-specific = domains = like y1541 that are based = on some values?
5.      Is it due to = combination of items 1 and 2?
6.      Others?

Best regards,

Radhika

-----Original Message-----
From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] = On Behalf Of john.loughney@nokia.com
Sent: Wednesday, August 17, 2005 2:41 AM
To: gash@att.com; tseno.tsenov@mytum.de; nsis@ietf.org
Subject: RE: [NSIS] QSPEC extensibility and re-use of multiple = instances = of defined = parameters

 

Jerry,

>I like your suggestion.  I think it both simplifies and =

>generalizes the QSPEC to handle multiple instances of the = same

>parameter.  The second and higher instances of any = parameter

>could be defined as optional.

>Procedures for multiple uses of a QSPEC parameter would have =

>to be defined by a given QOSM.

>

>What do others think?

I think it's a trade-off.  I am worried about making things = too complex.

Are multiple instances really useful or needed?  The risk of = supplying

too many options and too much extensibility is that managing = the

QoS parameters in a network & inter-working between different = networks

will be quite complex.  I think we should only support this = if there is

a real need.

John

_______________________________________________

nsis mailing list

nsis@ietf.org

https://www1.ietf.or= g/mailman/listinfo/nsis

------_=_NextPart_001_01C5A35C.08B91756-- --===============2070067010== 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 --===============2070067010==-- From nsis-bounces@ietf.org Wed Aug 17 15:06:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5TFQ-0005vL-2z; Wed, 17 Aug 2005 15:06:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5TFN-0005vG-Ia for nsis@megatron.ietf.org; Wed, 17 Aug 2005 15:06:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17983 for ; Wed, 17 Aug 2005 15:06:43 -0400 (EDT) Received: from mclmx2.mail.saic.com ([149.8.64.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5Toy-0000If-E1 for nsis@ietf.org; Wed, 17 Aug 2005 15:43:32 -0400 Received: from [149.8.64.21] by mclmx2.mail.saic.com; Wed, 17 Aug 2005 15:06:33 -0400 Received: from mclmx2.mail.saic.com ([149.8.64.32]) by 0015-its-ieg02.mail.saic.com (SMSSMTP 4.0.5.66) with SMTP id M2005081715063326469 ; Wed, 17 Aug 2005 15:06:33 -0400 Received: from [149.8.64.21] by mclmx2.mail.saic.com with ESMTP; Wed, 17 Aug 2005 15:06:33 -0400 Received: from bh-exchange02.saic-abingdon.com ([10.42.81.226]) by bh-exchangefe.saic-abingdon.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 17 Aug 2005 15:08:47 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [NSIS] QSPEC extensibility and re-use of multiple instances of defined parameters Date: Wed, 17 Aug 2005 15:08:45 -0400 Message-Id: <2FE23D25B7292B489A217D1965CDA866089878@bh-exchange02.saic-abingdon.com> Thread-Topic: [NSIS] QSPEC extensibility and re-use of multiple instances of defined parameters Thread-Index: AcWdrfS1gPWJEL6rQ+S0A/3SThNwdQEADh+QAGwzytA= From: "Roy, Radhika \(AEAD\)" To: "Tseno Tsenov" X-OriginalArrivalTime: 17 Aug 2005 19:08:47.0955 (UTC) FILETIME=[1894C230:01C5A35F] X-Spam-Score: 0.8 (/) X-Scan-Signature: 83867a50fd8f547996ccdaf89af24437 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="===============0489490003==" Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. --===============0489490003== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5A35F.16F59FC6" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5A35F.16F59FC6 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Tseno: QSPEC and QoS Model are two different things. 1. QSPEC Template and NSIS QOS Signaling Messages QSPEC defines the templates for carrying QOS parameters, and each QOS parameter will have its "specific" value to meet the needs of the application (e.g., SIP/SDP). SIP/SDP defines the codecs that need to be supported on end-to-end basis (e.g., codec-to-codec). Each codec type has its own performance (e.g., delay, jitter, losses) requirements on end-to-end basis (codec-to-codec) as can be seen in each codec spec. In addition, if specific QOS cannot be met per pre-specified codec standards, end users will be able to negotiate the QOS requirements.=20 SIP/SDP allows to negotiate codecs, but the specific QOS parameters of each codec either as pre-specified or through negotiation. So, NSIS QOS signaling including QSPEC templates will be used to do so. Per NSIS charter, QSPEC needs to have signaling template messages to satisfy the above because NSIS QOS signaling is to meet application's needs. You can observe two things as follows: * No restrictions in putting the "values" in signaling messages. * QOS models do NOT come into the picture of the NSIS QOS signaling messages. 2. QOS Models QOS models developed so far are usually are "network centric." That is, they usually deal with networks and are decouples from the applications. They do not deal with applications directly. However, IETF's IntServ and DiffServ QOS models are "perfect" because they define the signaling messages without providing any restrictions in "values" of any performance parameters. So, if you want to use QSPEC "generic" templates in conjunction with the IETF's IntServ and DiffServ QOS models, it is OK. However, it is NOT the case with non-IETF QOS models like Y.1541, and the earlier threads of mine explain clearly how contradictions come into play. So, models like Y.1541 must NOT be a part of the QSPEC template draft that is generic. You are right that each QOS model needs to describe how it will import all the QSPEC templates in "network centric environments" that are not end-to-end and decoupled from the applications.=20 That is why, each QOS model needs to create a "separate" draft known as "use case" of QSPEC and NSIS signaling messages (not to "dump" as it is done now in the present QSPEC draft). Hope this clarifies the things once more. Best regards, Radhika -----Original Message----- From: Tseno Tsenov [mailto:tseno.tsenov@mytum.de]=20 Sent: Wednesday, August 10, 2005 9:16 AM To: Roy, Radhika (AEAD); nsis@ietf.org Subject: RE: [NSIS] QSPEC extensibility and re-use of multiple instances of defined parameters Hi Roy, How I understand the idea of QSPEC and QoS model: QSPEC template defines a number of QoS parameters that describe certain QoS/resources, priority,.../. A QoS Model, use these parameters as well as define its own QoS parameters in order to signal/achieve QoS in its domain using its QoS methods. It must define how to import from the received QSPEC template parameters the QoS description and how to map it to its QoS parameters in the ingress node. Then in the egress node it must define how to export the QoS description resulting from its intra domain QoS signaling method to the QSPEC template parameters. As such, I see the mandatory QoS parameters defined in the QSPEC template as anchor parameters from which any QoS model can derive the required/available/reserved QoS description. And even if a given QoS model can't re-use any of the present QSPEC parameters but have to define its own optional set, it should map properly its parameters to the mandatory ones in the egress node of its domain. For such mandatory QSPEC parameters are used QoS parameters of well-known QoS models such as Intserv or Diffserv. And therefore there is overlapping between the QSPEC template and these QoS models.=20 I hope, there is something correct in this. Greetings, Tseno ------_=_NextPart_001_01C5A35F.16F59FC6 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: [NSIS] QSPEC extensibility and re-use of multiple instances = of defined parameters

Hi, Tseno:

QSPEC and QoS Model are two different things.

1.      QSPEC = Template and NSIS QOS Signaling Messages

QSPEC defines the templates for carrying QOS parameters, and each = QOS parameter will have its "specific" value to meet the needs = of the application (e.g., SIP/SDP).

SIP/SDP defines the codecs that need to be supported on = end-to-end basis (e.g., codec-to-codec). Each codec type has its own = performance (e.g., delay, jitter, losses) requirements on end-to-end = basis (codec-to-codec) as can be seen in each codec = spec.

In addition, if specific QOS cannot be met per pre-specified = codec standards, end users will be able to negotiate the QOS = requirements.

SIP/SDP allows to negotiate codecs, but the specific QOS = parameters of each codec either as pre-specified or through negotiation. = So, NSIS QOS signaling including QSPEC templates will be used to do = so.

Per NSIS charter, QSPEC needs to have signaling template messages = to satisfy the above because NSIS QOS signaling is to meet application's = needs.

You can observe two things as follows:

·       No restrictions in putting the "values" in = signaling messages.
·       = QOS models do NOT come into the = picture of the NSIS QOS signaling messages.

2.      QOS = Models

QOS models developed so far are usually are "network = centric." That is, they usually deal with networks and are = decouples from the applications. They do not deal with applications = directly.

However, IETF's IntServ and DiffServ QOS models are = "perfect" because they define the signaling messages without = providing any restrictions in "values" of any performance = parameters.

So, if you want to use QSPEC "generic" templates in = conjunction with the IETF's IntServ and DiffServ QOS models, it is = OK.

However, it is NOT the case with non-IETF QOS models like Y.1541, = and the earlier threads of mine explain clearly how contradictions come = into play. So, models like Y.1541 must NOT be a part of the QSPEC = template draft that is generic.

You are right that each QOS model needs to describe how it will = import all the QSPEC templates in "network centric = environments" that are not end-to-end and decoupled from the = applications.

That is why, each QOS model needs to create a = "separate" draft known as "use case" of QSPEC and = NSIS signaling messages (not to "dump" as it is done now in = the present QSPEC draft).

Hope this clarifies the things once more.

Best regards,

Radhika

-----Original Message-----
From: Tseno Tsenov [mailto:tseno.tsenov@mytum.de] Sent: Wednesday, August 10, 2005 9:16 AM
To: Roy, Radhika (AEAD); nsis@ietf.org
Subject: RE: [NSIS] QSPEC extensibility and re-use of multiple instances = of defined parameters


Hi Roy,

How I understand the idea of QSPEC and QoS = model:

QSPEC template defines a number of QoS parameters that describe = certain QoS/resources, priority,.../.

A QoS Model, use these parameters as well as define its own QoS = parameters in order to signal/achieve QoS in its domain using its QoS = methods. It must define how to import from the received QSPEC template = parameters the QoS description and how to map it to its QoS parameters = in the ingress node. Then in the egress node it must define how to = export the QoS description resulting from its intra domain QoS signaling = method to the QSPEC template parameters. As such, I see the mandatory = QoS parameters defined in the QSPEC template as anchor parameters from = which any QoS model can derive the required/available/reserved QoS = description.  And even if a given QoS model can't re-use any of the = present QSPEC parameters but have to define its own optional set, it = should map properly its parameters to the mandatory ones in the egress = node of its domain.

For such mandatory QSPEC parameters are used QoS parameters of = well-known QoS models such as Intserv or Diffserv. And therefore there = is overlapping between the QSPEC template and these QoS models. =

I hope, there is something correct in this.

Greetings,

Tseno

------_=_NextPart_001_01C5A35F.16F59FC6-- --===============0489490003== 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 --===============0489490003==-- From nsis-bounces@ietf.org Thu Aug 18 04:15:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5fXd-00030E-6v; Thu, 18 Aug 2005 04:14:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5fXb-000301-27 for nsis@megatron.ietf.org; Thu, 18 Aug 2005 04:14:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18569 for ; Thu, 18 Aug 2005 04:14:21 -0400 (EDT) Received: from thoth.sbs.de ([192.35.17.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5g7H-00088c-VR for nsis@ietf.org; Thu, 18 Aug 2005 04:51:17 -0400 Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by thoth.sbs.de (8.12.6/8.12.6) with ESMTP id j7I8EEZr004250; Thu, 18 Aug 2005 10:14:14 +0200 Received: from mhpahx0c.ww002.siemens.net (mhpahx0c.ww002.siemens.net [139.25.165.42]) by mail1.siemens.de (8.12.6/8.12.6) with ESMTP id j7I8EE8x014543; Thu, 18 Aug 2005 10:14:14 +0200 Received: from blns00fa.ww002.siemens.net ([147.54.45.102]) by mhpahx0c.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.211); Thu, 18 Aug 2005 10:12:49 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [NSIS] QSPEC extensibility and re-use of multiple instances of defined parameters Date: Thu, 18 Aug 2005 10:14:13 +0200 Message-ID: <391E6FBF5E786940B9E2F7CA6376C7086C1656@blns00fa.ww002.siemens.net> Thread-Topic: [NSIS] QSPEC extensibility and re-use of multiple instances of defined parameters Thread-Index: AcWd3C0rfXniEI+ZScaG5v9vZ62C3AFJR4nwABQVUxAAHrH4MA== From: "Kappler, Cornelia" To: "Roy, Radhika \(AEAD\)" X-OriginalArrivalTime: 18 Aug 2005 08:12:49.0843 (UTC) FILETIME=[9FBB3830:01C5A3CC] X-Spam-Score: 0.3 (/) X-Scan-Signature: 9404aa2ccc871248c2288463bebdd6b9 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="===============1716882481==" Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. --===============1716882481== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5A3CC.D16E5E9C" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5A3CC.D16E5E9C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Radhika,=20 =20 frankly, I dont see the point of your questions, and my impression is nor does anybody else. Rather than taking a lot of time trying to explain (again) everything I'd like to quote rough working group consensus that the QSPEC is ok the way it is.=20 =20 Cornelia -----Original Message----- From: Roy, Radhika (AEAD) [mailto:RoyR@saic-abingdon.com]=20 Sent: Mittwoch, 17. August 2005 20:17 To: Kappler, Cornelia Cc: Tseno Tsenov; nsis@ietf.org Subject: RE: [NSIS] QSPEC extensibility and re-use of multiple instances of defined parameters =09 =09 Cornelia: In response to one of Tseno's questions, you have mentioned as follows: ".. accommodate as many QoS Models as possible .." In fact, it is NOT true. Even the QOS model like Y.1541 that has been trying to be accommodated fully in the draft has been failed. Please see the following draft:=20 =09 http://www.ietf.org/internet-drafts/draft-ietf-nsis-y1541-qosm-00.txt =20 The above draft shows that more extensions in QSPEC template are needed. The basic question is this: Why do you want to include the QOS model-specific extensions in the "generalized" QSPEC template draft? What you have done is this: Included Y1541 QOS model (which is also incomplete) and DSTE QOS model (a cheap shot - basically only one parameter).=20 Tseno has mentioned the most fundamental QOS models of the IETF: IntServ and DiffServ. You have failed to explain why you have not included those in the draft. What do you mean that you have accommodated as many QOS models as possible? Why do you NOT "delete" all so-called QOS model-specific extensions from this draft? The way you should proceed is as follows: 1. Make the draft-ietf-nsis-y1541-qosm-00.txt complete including "all" extensions QSPEC specific to y1541using all "specific values." Also, show how to create y1541 domains using specific values without contradicting the end-to-end values from end users' and/or applications' point of view so that people can implement without creating any confusions or contradictions. 2. Do the same writing another draft for DSTE model as explained in item 1.=20 3. Delete all QOS model-specific extensions in the generalized QSPEC draft.=20 In this way, all drafts will be clean. If you have any questions, please let us know. Best regards, Radhika PS: I also explained in earlier emails (John L. also agreed) that the use of both generalized QSPEC template and QOS model-specific QSPEC template will create contradictions if domains are not created carefully. The present QSPEC draft does not explain how to create respective QOS domains using specific values in the first place. -----Original Message----- From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On Behalf Of Kappler, Cornelia Sent: Wednesday, August 17, 2005 4:22 AM To: Tseno Tsenov; Ash, Gerald R (Jerry), ALABS; nsis@ietf.org Subject: RE: [NSIS] QSPEC extensibility and re-use of multiple instances of defined parameters Hi Tseno - and John and Jerry,=20 so there doesnt seem to be much concrete use for this additional kind of extensibility. Therefore my suggestion is to not support it.=20 Regarding your (Tseno) 2nd paragraph:=20 In the QSPEC we tried to balance two mutually exclusive requirements - accommodate as many QoS Models as possible - make the QSPEC as widely understood as possible without defining too many parameters.=20 We solved this problem by defining mandatory parameters which we expect to be used in most QOSMs (e.g. bandwidth); and by requesting all QNEs to _understand_ the mandatory parameters. That is, for a QOSM that has no use of the mandatory parameters (which is quite unlikely by the way) these parameters _dont need to be included_ in the QSPEC. However this makes it unlikely that this QSPEC will be understood outside the domain of this QOSM.=20 I guess we have to explain this better in our document as this is not the first time somebody (particularly someone really familiar with NSIS) didn't really get the idea. Cornelia > -----Original Message----- > From: Tseno Tsenov [mailto:tseno.tsenov@mytum.de]=20 > Sent: Mittwoch, 10. August 2005 20:30 > To: Kappler, Cornelia; Ash, Gerald R (Jerry), ALABS; nsis@ietf.org > Subject: Re: [NSIS] QSPEC extensibility and re-use of=20 > multiple instances ofdefined parameters >=20 >=20 > Hi Cornelia, >=20 > I agree that currently there might be no QoS model that uses=20 > multiple values > of one QoS parameter (except the DiffServ case). However the current > encoding approach restricts the extensibility of the QSPEC. >=20 > Your example with usage of two different QoS classes which=20 > are mandatory > parameters (and are redundant in some sense) raises other=20 > question for me: > Again, we have a new QoS model does not use any of the mandatory QSPEC > parameters and defines its own set of optional QSPEC=20 > parameters. Then, is it > expected that some mandatory QSPEC parameters will be "artificially" > included which will provide interoperability with other QoS models? >=20 > greetings, > Tseno_ ------_=_NextPart_001_01C5A3CC.D16E5E9C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Hi=20 Radhika,
 
frankly, I dont see the point of your questions, and my = impression is nor=20 does anybody else. Rather than taking a lot of time trying to explain = (again)=20 everything I'd like to quote rough working group consensus that the = QSPEC is ok=20 the way it is.
 
Cornelia
-----Original Message-----
From: Roy, = Radhika=20 (AEAD) [mailto:RoyR@saic-abingdon.com]
Sent: Mittwoch, 17. = August=20 2005 20:17
To: Kappler, Cornelia
Cc: Tseno Tsenov; = nsis@ietf.org
Subject: RE: [NSIS] QSPEC extensibility and = re-use of=20 multiple instances of defined parameters

Cornelia:

In response=20 to one of Tseno's questions, you have mentioned as = follows:

".. accommodate as=20 many QoS Models as possible = .."

In fact, it=20 is NOT = true. Even the QOS = model like=20 Y.1541 that has been=20 trying to be = accommodated = fully in = the = draft has been failed. Please see the following=20 draft:

http://www.ietf.org/internet-drafts/draft-ietf-nsis-y1541-qosm-0= 0.txt

The above=20 draft shows that more extensions in QSPEC template are = needed.

The basic=20 question is this: Why do you want to include the QOS model-specific=20 extensions in=20 the "generalized" QSPEC=20 template draft?

What you=20 have done is this: Included Y1541 QOS model (which is also incomplete) = and=20 DSTE QOS model (a cheap=20 shot - basically only one=20 parameter).

Tseno has=20 mentioned the most fundamental QOS models of the IETF: = IntServ and=20 DiffServ. You have failed to explain why you have not included those = in=20 the draft.

What do you=20 mean that you have accommodated as many QOS models as=20 possible?

Why do=20 you NOT = "delete" all=20 so-called = QOS = model-specific extensions from this draft?

The way you=20 should proceed is as follows:

1.      = Make the = draft-ietf-nsis-y1541-qosm-00.txt=20 complete including=20 "all" = extensions=20 QSPEC specific to = y1541using=20 all "specific values." Also, show how = to create y1541=20 domains using specific values without contradicting the end-to-end = values from=20 end users' and/or=20 applications' point of view so that people can = implement=20 without creating any confusions or contradictions.

2.      = Do the = same writing another draft for DSTE model = as explained in=20 item 1. =

3.      = Delete all QOS model-specific = extensions in the=20 generalized QSPEC draft.

In this=20 way, all drafts will be clean.

If you have=20 any questions, please let us know.

Best=20 regards,

Radhika

PS: I also=20 explained in earlier emails (John L. also agreed) = that the use of both generalized QSPEC = template and QOS=20 model-specific QSPEC template will = create=20 contradictions if domains are not created carefully. The present QSPEC = draft=20 does not explain how to create respective QOS=20 domains using specific values in the first=20 place.

-----Original Message-----
From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] = On=20 Behalf Of Kappler, Cornelia
Sent: Wednesday, August 17, 2005 4:22 = AM
To:=20 Tseno Tsenov; Ash, Gerald R (Jerry), ALABS; nsis@ietf.org
Subject: = RE:=20 [NSIS] QSPEC extensibility and re-use of multiple = instances = of defined parameters

Hi Tseno -=20 and John and Jerry,

so there=20 doesnt seem to be much concrete use for this additional kind=20 of

extensibility. Therefore my suggestion is to not support it.=20

Regarding=20 your (Tseno) 2nd paragraph:

In the=20 QSPEC we tried to balance two mutually exclusive=20 requirements

- = accommodate as=20 many QoS Models as possible

- make the=20 QSPEC as widely understood as possible without defining = too

many=20 parameters.

We solved=20 this problem by defining mandatory parameters which we=20 expect

to be used=20 in most QOSMs (e.g. bandwidth); and by requesting all QNEs=20 to

_understand_ the mandatory parameters. That is, for a QOSM = that has=20 no

use of the=20 mandatory parameters (which is quite unlikely by the = way)

these=20 parameters _dont need to be included_ in the QSPEC. However=20 this

makes it=20 unlikely that this QSPEC will be understood outside the=20 domain

of this=20 QOSM.

I guess we=20 have to explain this better in our document as this is = not

the first=20 time somebody (particularly someone really familiar with=20 NSIS)

didn't really get the = idea.

Cornelia

>=20 -----Original Message-----

> From:=20 Tseno Tsenov [mailto:tseno.tsenov@mytum.de]=20

> Sent:=20 Mittwoch, 10. August 2005 20:30

> To:=20 Kappler, Cornelia; Ash, Gerald R (Jerry), ALABS;=20 nsis@ietf.org

>=20 Subject: Re: [NSIS] QSPEC extensibility and re-use of =

>=20 multiple instances ofdefined parameters

>=20

>=20

> Hi=20 Cornelia,

>=20

> I=20 agree that currently there might be no QoS model that uses =

>=20 multiple values

> of one=20 QoS parameter (except the DiffServ case). However the=20 current

>=20 encoding approach restricts the extensibility of the = QSPEC.

>=20

> Your=20 example with usage of two different QoS classes which =

> are=20 mandatory

>=20 parameters (and are redundant in some sense) raises other =

>=20 question for me:

> Again,=20 we have a new QoS model does not use any of the mandatory=20 QSPEC

>=20 parameters and defines its own set of optional QSPEC =

>=20 parameters. Then, is it

>=20 expected that some mandatory QSPEC parameters will be=20 "artificially"

>=20 included which will provide interoperability with other QoS=20 models?

>=20

>=20 greetings,

>=20 Tseno_

------_=_NextPart_001_01C5A3CC.D16E5E9C-- --===============1716882481== 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 --===============1716882481==-- From VIYKMYBSTXH@yahoo.com Thu Aug 18 04:15:11 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5fXr-00031d-Gs; Thu, 18 Aug 2005 04:14:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18586; Thu, 18 Aug 2005 04:14:37 -0400 (EDT) Received: from [63.224.70.149] (helo=SCHDIMENSION) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1E5g7X-00088d-8I; Thu, 18 Aug 2005 04:51:33 -0400 Received: from . ...es ([83.22.90.160] helo=.mail.desty.org) by smtp4.desty.org with esmtp id 2A502j-0431FN-00; Thu, 18 Aug 2005 11:12:32 +0200 Message-Id: Sender: VIYKMYBSTXH@yahoo.com Date: Thu, 18 Aug 2005 02:07:32 -0700 In-Reply-To: Your message of "Thu, 18 Aug 2005 04:09:32 -0500." <20031002150239.GG32185@asuka.tech.sitadelle.com> From: "Cathryn Kincaid" To: smime-archive@ietf.org Subject: Wow...Shiny Teeth YSJTTY X-Spam-Score: 1.1 (+) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 The revolution "Whitelight" teeth whitening which guarantees: - Fast Results and easy to use - works great against all sorts of stains (coffee, smoking) - Boost your confidence with great white smile - Used by dentist and millions worldwide - Satisfaction Guarantees...NO Risk! Why waiting? Check us out! http://e-globalproducts.info/wlr 1o From nsis-bounces@ietf.org Thu Aug 18 14:14:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5oqM-0004eD-TI; Thu, 18 Aug 2005 14:10:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5oqL-0004e4-TN for nsis@megatron.ietf.org; Thu, 18 Aug 2005 14:10:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20964 for ; Thu, 18 Aug 2005 14:10:20 -0400 (EDT) Received: from mta7.srv.hcvlny.cv.net ([167.206.4.202]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5pQ8-0000oh-TF for nsis@ietf.org; Thu, 18 Aug 2005 14:47:21 -0400 Received: from DDH79V51 (ool-44c04858.dyn.optonline.net [68.192.72.88]) by mta7.srv.hcvlny.cv.net (Sun Java System Messaging Server 6.2-2.06 (built May 11 2005)) with ESMTP id <0ILF006YLJSUV6CY@mta7.srv.hcvlny.cv.net> for nsis@ietf.org; Thu, 18 Aug 2005 14:10:12 -0400 (EDT) Date: Thu, 18 Aug 2005 14:10:10 -0400 From: Radhika Roy Subject: RE: RE: [NSIS] QSPEC extensibility and re-use of multiple instances of defined parameters To: nsis@ietf.org Message-id: <0ILF006YNJSZV6CY@mta7.srv.hcvlny.cv.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-index: AcWkHZwO5C4Nd072QmGQ1kCOv0FAmwAAJoqwAABS0dA= X-Spam-Score: 0.5 (/) X-Scan-Signature: 9724479da43a8325ad975c1a9b841870 Cc: radhika.r.roy@saic.com X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1325996461==" Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. --===============1325996461== Content-type: multipart/alternative; boundary="Boundary_(ID_JRxl9V3C6wO0mMmV/3pvgw)" This is a multi-part message in MIME format. --Boundary_(ID_JRxl9V3C6wO0mMmV/3pvgw) Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7BIT Hi, Cornelia: Whatever you may say, the draft is NOT technically consistent with respect to QSPEC extensions specific to QOS models as you yourself has admitted (e.g., you tried .. ".. accommodate as many QoS Models as possible .." You will be better off to delete those QOS model-specific specific parts of draft as John L. has also admitted that it will create problems if domains are NOT constructed carefully. Tseno has suggested to generalize the extensions related QOS models for making draft consistent. Jerry suggested to use multiple instances to take care of this problem. John L. has gone further in explaining why Jerry's suggestions for multiple instances of the same parameter is NOT acceptable. So, where is the consensus unless you remove those technical inconsistencies through deleting the QOS specific extension part of the draft? Best regards, Radhika Title: Message Hi Radhika, frankly, I dont see the point of your questions, and my impression is nor does anybody else. Rather than taking a lot of time trying to explain (again) everything I'd like to quote rough working group consensus that the QSPEC is ok the way it is. Cornelia -----Original Message----- From: Roy, Radhika (AEAD) [mailto:RoyR at saic-abingdon.com] Sent: Mittwoch, 17. August 2005 20:17 To: Kappler, Cornelia Cc: Tseno Tsenov; nsis at ietf.org Subject: RE: [NSIS] QSPEC extensibility and re-use of multiple instances of defined parameters Cornelia: In response to one of Tseno's questions, you have mentioned as follows: ".. accommodate as many QoS Models as possible .." In fact, it is NOT true. Even the QOS model like Y.1541 that has been trying to be accommodated fully in the draft has been failed. Please see the following draft: http://www.ietf.org/internet-drafts/draft-ietf-nsis-y1541-qosm-00.txt The above draft shows that more extensions in QSPEC template are needed. The basic question is this: Why do you want to include the QOS model-specific extensions in the "generalized" QSPEC template draft? What you have done is this: Included Y1541 QOS model (which is also incomplete) and DSTE QOS model (a cheap shot - basically only one parameter). Tseno has mentioned the most fundamental QOS models of the IETF: IntServ and DiffServ. You have failed to explain why you have not included those in the draft. What do you mean that you have accommodated as many QOS models as possible? Why do you NOT "delete" all so-called QOS model-specific extensions from this draft? The way you should proceed is as follows: 1. Make the draft-ietf-nsis-y1541-qosm-00.txt complete including "all" extensions QSPEC specific to y1541using all "specific values." Also, show how to create y1541 domains using specific values without contradicting the end-to-end values from end users' and/or applications' point of view so that people can implement without creating any confusions or contradictions. 2. Do the same writing another draft for DSTE model as explained in item 1. 3. Delete all QOS model-specific extensions in the generalized QSPEC draft. In this way, all drafts will be clean. If you have any questions, please let us know. Best regards, Radhika PS: I also explained in earlier emails (John L. also agreed) that the use of both generalized QSPEC template and QOS model-specific QSPEC template will create contradictions if domains are not created carefully. The present QSPEC draft does not explain how to create respective QOS domains using specific values in the first place. -----Original Message----- From: nsis-bounces at ietf.org [mailto:nsis-bounces at ietf.org] On Behalf Of Kappler, Cornelia Sent: Wednesday, August 17, 2005 4:22 AM To: Tseno Tsenov; Ash, Gerald R (Jerry), ALABS; nsis at ietf.org Subject: RE: [NSIS] QSPEC extensibility and re-use of multiple instances of defined parameters Hi Tseno - and John and Jerry, so there doesnt seem to be much concrete use for this additional kind of extensibility. Therefore my suggestion is to not support it. Regarding your (Tseno) 2nd paragraph: In the QSPEC we tried to balance two mutually exclusive requirements - accommodate as many QoS Models as possible - make the QSPEC as widely understood as possible without defining too many parameters. We solved this problem by defining mandatory parameters which we expect to be used in most QOSMs (e.g. bandwidth); and by requesting all QNEs to _understand_ the mandatory parameters. That is, for a QOSM that has no use of the mandatory parameters (which is quite unlikely by the way) these parameters _dont need to be included_ in the QSPEC. However this makes it unlikely that this QSPEC will be understood outside the domain of this QOSM. I guess we have to explain this better in our document as this is not the first time somebody (particularly someone really familiar with NSIS) didn't really get the idea. Cornelia --Boundary_(ID_JRxl9V3C6wO0mMmV/3pvgw) Content-type: text/html; charset=us-ascii Content-Transfer-Encoding: 7BIT
Hi, Cornelia:

Whatever you may say, the draft is NOT technically consistent with respect to QSPEC extensions specific to QOS models as you yourself has admitted (e.g., you tried .. ".. accommodate as many QoS Models as possible .."

You will be better off to delete those QOS model-specific specific parts of draft as John L. has also admitted that it will create problems if domains are NOT constructed carefully.
 
Tseno has suggested to generalize the extensions related QOS models for making draft consistent. Jerry suggested to use multiple instances to take care of this problem. John L. has gone further in explaining why Jerry’s suggestions for multiple instances of the same parameter is NOT acceptable.
 
So, where is the consensus unless you remove those technical inconsistencies through deleting the QOS specific extension part of the draft?
 
Best regards,
Radhika
 
Title: Message

Hi Radhika,

 

frankly, I dont see the point of your questions, and my impression is nor does anybody else. Rather than taking a lot of time trying to explain (again) everything I'd like to quote rough working group consensus that the QSPEC is ok the way it is.

 

Cornelia

-----Original Message-----
From: Roy, Radhika (AEAD) [mailto:RoyR at saic-abingdon.com]
Sent: Mittwoch, 17. August 2005 20:17
To: Kappler, Cornelia
Cc: Tseno Tsenov; nsis at ietf.org
Subject: RE: [NSIS] QSPEC extensibility and re-use of multiple instances of defined parameters

Cornelia:

In response to one of Tseno's questions, you have mentioned as follows:

".. accommodate as many QoS Models as possible .."

In fact, it is NOT true. Even the QOS model like Y.1541 that has been trying to be accommodated fully in the draft has been failed. Please see the following draft:

http://www.ietf.org/internet-drafts/draft-ietf-nsis-y1541-qosm-00.txt

The above draft shows that more extensions in QSPEC template are needed.

The basic question is this: Why do you want to include the QOS model-specific extensions in the "generalized" QSPEC template draft?

What you have done is this: Included Y1541 QOS model (which is also incomplete) and DSTE QOS model (a cheap shot - basically only one parameter).

Tseno has mentioned the most fundamental QOS models of the IETF: IntServ and DiffServ. You have failed to explain why you have not included those in the draft.

What do you mean that you have accommodated as many QOS models as possible?

Why do you NOT "delete" all so-called QOS model-specific extensions from this draft?

The way you should proceed is as follows:

1.      Make the draft-ietf-nsis-y1541-qosm-00.txt complete including "all" extensions QSPEC specific to y1541using all "specific values." Also, show how to create y1541 domains using specific values without contradicting the end-to-end values from end users' and/or applications' point of view so that people can implement without creating any confusions or contradictions.

2.      Do the same writing another draft for DSTE model as explained in item 1.

3.      Delete all QOS model-specific extensions in the generalized QSPEC draft.

In this way, all drafts will be clean.

If you have any questions, please let us know.

Best regards,

Radhika

PS: I also explained in earlier emails (John L. also agreed) that the use of both generalized QSPEC template and QOS model-specific QSPEC template will create contradictions if domains are not created carefully. The present QSPEC draft does not explain how to create respective QOS domains using specific values in the first place.

-----Original Message-----
From: nsis-bounces at ietf.org [mailto:nsis-bounces at ietf.org] On Behalf Of Kappler, Cornelia
Sent: Wednesday, August 17, 2005 4:22 AM
To: Tseno Tsenov; Ash, Gerald R (Jerry), ALABS; nsis at ietf.org
Subject: RE: [NSIS] QSPEC extensibility and re-use of multiple instances of defined parameters

Hi Tseno - and John and Jerry,

so there doesnt seem to be much concrete use for this additional kind of

extensibility. Therefore my suggestion is to not support it.

Regarding your (Tseno) 2nd paragraph:

In the QSPEC we tried to balance two mutually exclusive requirements

- accommodate as many QoS Models as possible

- make the QSPEC as widely understood as possible without defining too

many parameters.

We solved this problem by defining mandatory parameters which we expect

to be used in most QOSMs (e.g. bandwidth); and by requesting all QNEs to

_understand_ the mandatory parameters. That is, for a QOSM that has no

use of the mandatory parameters (which is quite unlikely by the way)

these parameters _dont need to be included_ in the QSPEC. However this

makes it unlikely that this QSPEC will be understood outside the domain

of this QOSM.

I guess we have to explain this better in our document as this is not

the first time somebody (particularly someone really familiar with NSIS)

didn't really get the idea.

Cornelia

 

--Boundary_(ID_JRxl9V3C6wO0mMmV/3pvgw)-- --===============1325996461== 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 --===============1325996461==-- From nsis-bounces@ietf.org Thu Aug 18 19:54:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5uDV-00059G-9G; Thu, 18 Aug 2005 19:54:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5uDU-00059A-21 for nsis@megatron.ietf.org; Thu, 18 Aug 2005 19:54:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17528 for ; Thu, 18 Aug 2005 19:54:34 -0400 (EDT) Received: from iramx1.ira.uni-karlsruhe.de ([141.3.10.80] ident=[U2FsdGVkX18BVFU8yKopkfw9Rz+I3ZSxe5EeifXyBGw=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5unK-0004nA-Ch for nsis@ietf.org; Thu, 18 Aug 2005 20:31:38 -0400 Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by iramx1.ira.uni-karlsruhe.de with esmtps id 1E5uDJ-0006kV-Uo for ; Fri, 19 Aug 2005 01:54:29 +0200 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 C28738542 for ; Fri, 19 Aug 2005 01:54:25 +0200 (CEST) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1E5uDJ-0001c9-GP for nsis@ietf.org; Fri, 19 Aug 2005 01:54:25 +0200 Message-ID: <4305201E.1020606@tm.uka.de> Date: Fri, 19 Aug 2005 01:56:14 +0200 From: Roland Bless Organization: Institute of Telematics, University of Karlsruhe User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050716) X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: nsis@ietf.org X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Spam-Score: -5.4 (-----) X-Spam-Status: No X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: 7bit Subject: [NSIS] Some QoS NSLP draft-07 issues 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: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi, I have some questions/remarks which may need clarification: p. 21, sec 4.3: QNE. The same processing is performed at further QNEs along the path, up to the receiver, which in this situation is the QNR. The QNR detects that this QUERY message does not carry an RII object and shouldn't this read twice _QNI_ instead of QNR (this is at least what the figure says)? If not then the text should be clarified (i.e. you mean QNR for the QUERY?). sec. 5.2.1: SII for each upstream and downstream peer The SII is a large identifier (minimum 128 bits) generated by the QoS NSLP and passed over the API. This seems to be not consistent with the GIST spec: As far as I understood, the SII is managed by the GIST implementation and passed over the API so for the above text s/NSLP/NTLP. Furthermore, here is requirement for its length >128bits which cannot be found in the GIST spec? p. 43, sec. 5.3.2: When sending a message containing an RII object the sending node MUST remember the value used in the RII to match back any RESPONSE received. It SHOULD use a timer to identify situations where it has taken too long to receive the expected RESPONSE. If the timer expires without receiving a RESPONSE it MAY perform a retransmission. the text needs clarification. IMHO only the QNI should start a retransmission. As the text currently reads every QNE may also perform a retransmission. Furthermore: should a node generate an error message if - RII timeout went off and no RESPONSE came back - a RESPONSE came in too late, i.e. RII timeout? How should this response be handled (ignore, forward or dropp)? IMHO no error message should be generated and the QNI should retransmit the original message two times with increasing backoff. sec. 5.4.1: There is currently no text specifying how RESERVE with RII must be processed in QNEs, e.g. nodes could take advantage of interpreting returned RESPONSES indicating failure, so that QNEs can tear down state in case the initial reservation failed downstream. sec. 5.4.3: that's the same issue that Tseno already mentioned: how should a RESPONSE ever get forwarded to the QNI if we follow: On receipt of a RESPONSE message containing an RII object, the QNE MUST attempt to match it to the outstanding response requests for that signalling session. If the match succeeds, then the RESPONSE MUST NOT be forwarded further along the path. If the match fails, that makes no sense to me... Questions over questions... Regards, Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Aug 18 20:19:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5ubc-0003n3-89; Thu, 18 Aug 2005 20:19:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5uba-0003mG-Lc for nsis@megatron.ietf.org; Thu, 18 Aug 2005 20:19:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18559 for ; Thu, 18 Aug 2005 20:19:29 -0400 (EDT) Received: from iramx1.ira.uni-karlsruhe.de ([141.3.10.80] ident=[U2FsdGVkX1+cO7+4o96myq5mbMLDStwwVswWGdjRgeo=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5vBQ-0005US-BR for nsis@ietf.org; Thu, 18 Aug 2005 20:56:33 -0400 Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by iramx1.ira.uni-karlsruhe.de with esmtps id 1E5ubU-0007iB-KP for ; Fri, 19 Aug 2005 02:19:27 +0200 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 6C65787EC for ; Fri, 19 Aug 2005 02:19:24 +0200 (CEST) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1E5ubU-0001di-3j for nsis@ietf.org; Fri, 19 Aug 2005 02:19:24 +0200 Message-ID: <430525F8.80608@tm.uka.de> Date: Fri, 19 Aug 2005 02:21:12 +0200 From: Roland Bless Organization: Institute of Telematics, University of Karlsruhe User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050716) X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: nsis@ietf.org X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Spam-Score: -5.4 (-----) X-Spam-Status: No X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: 7bit Subject: [NSIS] GIST NAT traversal object 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: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi, just a quick question related to sec. C.4.8: Length of opaque NLI info. Is this specified in bytes or words? (I assume the latter, but a clear statement in the doc would be nice). Regards, Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Aug 19 06:33:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E64BU-0007Y0-UM; Fri, 19 Aug 2005 06:33:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E64BT-0007X0-J8 for nsis@megatron.ietf.org; Fri, 19 Aug 2005 06:33:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24740 for ; Fri, 19 Aug 2005 06:33:08 -0400 (EDT) Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E64lO-0004Us-3T for nsis@ietf.org; Fri, 19 Aug 2005 07:10:20 -0400 Received: from rsys005a.comm.ad.roke.co.uk ([193.118.193.85]) by rsys001x.roke.co.uk (8.12.8/8.12.8) with ESMTP id j7JAWmFt013521; Fri, 19 Aug 2005 11:32:48 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] GIST NAT traversal object Date: Fri, 19 Aug 2005 11:32:48 +0100 Message-ID: Thread-Topic: [NSIS] GIST NAT traversal object Thread-Index: AcWkU9Lxv2JCVWntShKksBO5AsfvJwATkG/g From: "Hancock, Robert" To: "Roland Bless" , X-MailScanner-rsys001x: Found to be clean X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: quoted-printable 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: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Roland, well caught. #complete words after the length field seems reasonable (so byte length will be 4*length + 2). http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue65 r. > -----Original Message----- > From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On=20 > Behalf Of Roland Bless > Sent: 19 August 2005 01:21 > To: nsis@ietf.org > Subject: [NSIS] GIST NAT traversal object >=20 >=20 > Hi, >=20 > just a quick question related to sec. C.4.8: > Length of opaque NLI info. > Is this specified in bytes or words? > (I assume the latter, but a clear statement > in the doc would be nice). >=20 > Regards, > Roland >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Aug 19 06:44:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E64MP-0001d4-7j; Fri, 19 Aug 2005 06:44:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E64MN-0001cv-6c for nsis@megatron.ietf.org; Fri, 19 Aug 2005 06:44:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25293 for ; Fri, 19 Aug 2005 06:44:24 -0400 (EDT) Received: from difra-computer.de ([81.169.157.103] helo=www.difra-computer.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E64wI-0004oq-Db for nsis@ietf.org; Fri, 19 Aug 2005 07:21:35 -0400 Received: from win2003.dickmann2003.home (p548A4AB4.dip.t-dialin.net [84.138.74.180]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by www.difra-computer.de (Postfix) with ESMTP id 8B1E63E402B for ; Fri, 19 Aug 2005 12:39:23 +0200 (CEST) Received: from christian ([192.168.0.2]) by win2003.dickmann2003.home with Microsoft SMTPSVC(6.0.3790.211); Fri, 19 Aug 2005 12:39:12 +0200 From: "Christian Dickmann" To: "'Hancock, Robert'" , "'Roland Bless'" , Subject: RE: [NSIS] GIST NAT traversal object Date: Fri, 19 Aug 2005 12:39:13 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcWkU9Lxv2JCVWntShKksBO5AsfvJwATkG/gAAHd01A= In-Reply-To: Message-ID: X-OriginalArrivalTime: 19 Aug 2005 10:39:12.0996 (UTC) FILETIME=[3D4FC240:01C5A4AA] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: 7bit 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: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi Robert, as you told me, an implementation could write anything into that field. So to my mind, the length should be specified in bytes and the block (length + value) should be padded to words. (Which is similar to PeerIdentity in NLI) One question remains: Where should padding be applied? after the length field or after the NLI info? Christian > -----Original Message----- > From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On Behalf Of > Hancock, Robert > Sent: Friday, August 19, 2005 12:33 PM > To: Roland Bless; nsis@ietf.org > Subject: RE: [NSIS] GIST NAT traversal object > > Roland, > > well caught. #complete words after the length field > seems reasonable (so byte length will be 4*length + 2). > > http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue65 > > r. > > > -----Original Message----- > > From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On > > Behalf Of Roland Bless > > Sent: 19 August 2005 01:21 > > To: nsis@ietf.org > > Subject: [NSIS] GIST NAT traversal object > > > > > > Hi, > > > > just a quick question related to sec. C.4.8: > > Length of opaque NLI info. > > Is this specified in bytes or words? > > (I assume the latter, but a clear statement > > in the doc would be nice). > > > > 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 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Aug 19 07:00:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E64c5-0005Tx-Fh; Fri, 19 Aug 2005 07:00:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E64c3-0005Tp-SP for nsis@megatron.ietf.org; Fri, 19 Aug 2005 07:00:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26178 for ; Fri, 19 Aug 2005 07:00:36 -0400 (EDT) Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E65By-0005Ho-Pb for nsis@ietf.org; Fri, 19 Aug 2005 07:37:48 -0400 Received: from rsys005a.comm.ad.roke.co.uk ([193.118.193.85]) by rsys001x.roke.co.uk (8.12.8/8.12.8) with ESMTP id j7JB09Ft018773; Fri, 19 Aug 2005 12:00:09 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] GIST NAT traversal object Date: Fri, 19 Aug 2005 12:00:09 +0100 Message-ID: Thread-Topic: [NSIS] GIST NAT traversal object Thread-Index: AcWkU9Lxv2JCVWntShKksBO5AsfvJwATkG/gAAHd01AAANoJ4A== From: "Hancock, Robert" To: "Christian Dickmann" , "Roland Bless" , X-MailScanner-rsys001x: Found to be clean X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Content-Transfer-Encoding: quoted-printable 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: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org hi christian, that (bytes) is another possibility, and then a rule about where the padding must end.=20 we don't need to be that specific about how to do the padding;=20 the information elements are only interpreted at the node which inserts them, so the padding details can be implementation defined. r. > -----Original Message----- > From: Christian Dickmann [mailto:mail@christian-dickmann.de]=20 > Sent: 19 August 2005 11:39 > To: Hancock, Robert; 'Roland Bless'; nsis@ietf.org > Subject: RE: [NSIS] GIST NAT traversal object >=20 >=20 > Hi Robert, >=20 > as you told me, an implementation could write anything into=20 > that field. So > to my mind, the length should be specified in bytes and the=20 > block (length + > value) should be padded to words. (Which is similar to=20 > PeerIdentity in NLI) > One question remains: Where should padding be applied? after=20 > the length > field or after the NLI info? >=20 > Christian >=20 > > -----Original Message----- > > From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org]=20 > On Behalf Of > > Hancock, Robert > > Sent: Friday, August 19, 2005 12:33 PM > > To: Roland Bless; nsis@ietf.org > > Subject: RE: [NSIS] GIST NAT traversal object > >=20 > > Roland, > >=20 > > well caught. #complete words after the length field > > seems reasonable (so byte length will be 4*length + 2). > >=20 > > http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue65 > >=20 > > r. > >=20 > > > -----Original Message----- > > > From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On > > > Behalf Of Roland Bless > > > Sent: 19 August 2005 01:21 > > > To: nsis@ietf.org > > > Subject: [NSIS] GIST NAT traversal object > > > > > > > > > Hi, > > > > > > just a quick question related to sec. C.4.8: > > > Length of opaque NLI info. > > > Is this specified in bytes or words? > > > (I assume the latter, but a clear statement > > > in the doc would be nice). > > > > > > Regards, > > > Roland > > > > > > _______________________________________________ > > > nsis mailing list > > > nsis@ietf.org > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > >=20 > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis >=20 >=20 >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Aug 19 11:39:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E68y5-0004rf-OF; Fri, 19 Aug 2005 11:39:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E68y2-0004ra-Oz for nsis@megatron.ietf.org; Fri, 19 Aug 2005 11:39:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10200 for ; Fri, 19 Aug 2005 11:39:35 -0400 (EDT) Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E69Xy-0004r2-GW for nsis@ietf.org; Fri, 19 Aug 2005 12:16:49 -0400 Received: from rsys005a.comm.ad.roke.co.uk ([193.118.193.85]) by rsys001x.roke.co.uk (8.12.8/8.12.8) with ESMTP id j7JFd1Ft022790; Fri, 19 Aug 2005 16:39:01 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In-Reply-To: X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-OlkEid: EB44FD2968B0702958C32D4684805BA147C24D9D Content-class: urn:content-classes:message Subject: RE: [NSIS] NAT traversal at the GIST Layer: which approach to take? Date: Fri, 19 Aug 2005 16:39:01 +0100 Message-ID: Thread-Topic: [NSIS] NAT traversal at the GIST Layer: which approach to take? Thread-Index: AcWk1B7zFmBbsb6lTHmY9XB5LL4KIg== From: "Hancock, Robert" To: "Pashalidis, Andreas" , X-MailScanner-rsys001x: Found to be clean X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 8eeb555810cda1f2c5989480370dc4ca Content-Transfer-Encoding: quoted-printable 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: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org hi all, I have to say that I broadly agree with Christian's views (in a parallel branch of this thread). But apart from commenting on the particular issues listed below, I think there is also a slightly higher-level perspective on the two alternatives,=20 which are not really alternatives in the specification sense. One approach is to construct a genuinely transparent NAT, which=20 is not visible to the GIST nodes either side. *By definition*, this won't have any impact on the GIST specification; people=20 may implement such things and we won't necessarily even ever know about it. [Whether we should encourage such behaviour is another matter, which I'll come back to.] The only possible interaction with the specification would be if there was something we could do to GIST to make it easier to construct such a NAT; however, we already know that there are at least some scenarios where such a NAT cannot function, so at best we are talking about tweaking boundaries here. The other approach is to to have a non-transparent NAT, which is visible to other GIST nodes and does impact the GIST=20 specification. We know (to a high degree of confidence) that=20 this approach can always be made to work, although some more validation would be nice. This is the approach taken in the current spec. These approaches are not either/or alternatives. The 'invisible' approach (by definition) can be developed independently, and deployed in conjunction with the 'visible' approach. Indeed, I would expect to see both exist.=20 Apart from the specific pros/cons (commented below), which I=20 have added some to, my architectural instinct is that the 'visible' approach is the better solution at least initially.=20 There are three reasons: 1) We already have 'invisible' NAT approaches for existing protocols (TCP, UDP etc.) That's all very nice and reasonable given the fact that NATs happened after these protocols were specified. But a huge amount of subsequent effort has gone=20 into methods to make these NATs visible (STUN, TURN and so=20 on). In the long term, I don't think that continually trying=20 to hide NATs from (new) protocols is desirable. 2) Some NAT implementations are very good and some are not so good; also, many end up in embedded firmware that is very=20 rarely updated (i.e. bug-fixed). From that point of view, we need to ensure that there is a NAT approach available with the fewest possible subtleties and the least requirements=20 for updates as GIST and NSLPs evolve. In other words, this consideration tilts the balance towards putting complexity in the GIST node rather than the NAT. 3) There is an (I think) attractive aspect of the GIST design that all the interaction with the infrastructure lying between the GIST nodes takes place in an integrated way, during the 3-way handshake (in fact, in the first 2 messages), both in initial setup and also refresh. The 'invisible' approach=20 complicates this, because interactions with routing and NATs take place during the handshake, and further interactions but only with NATs take place afterwards also. It becomes more of a headache to keep these consistent if routing or NAT configuration is changing. (This probably doesn't matter for the path-coupled MRM in basic scenarios, since if the NAT=20 configuration changes all the flows will fail anyway. But for other MRMs or scenarios with distributed NATs the situation is much less clear to me.) More comments below, r. > -----Original Message----- > From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On=20 > Behalf Of Pashalidis, Andreas > Sent: 12 August 2005 15:48 > To: nsis@ietf.org > Subject: [NSIS] NAT traversal at the GIST Layer: which=20 > approach to take? >=20 >=20 > Dear WG, >=20 > As some of you may remember, in the last meeting a question=20 > arose about > which approach(es) to use for NAT traversal at the GIST layer. > The purpose of this e-mail is for the WG to obtain "rough consensus" > about answering this question, so that the appropriate text can > be put into the next version of the "NAT traversal for GIST"=20 > draft (the > current version is available at > http://www.ietf.org/internet-drafts/draft-pashalidis-nsis-gimp > s-nattrave > rsal-00.txt) >=20 > =3D=3D=3D=3D >=20 > The two approaches concern GIST-aware NATs (GaNATS) only;=20 > (i.e. they do > not apply to "NSIS-unaware" NATs). I will now briefly outline the two > approaches. >=20 > 1) The GaNAT includes an additional "NAT Traversal" payload into the > GIST header of the GIST QUERY, RESPONSE and > CONFIRM messages. The GIST peers either side of the NAT use the > information in this payload in order to map subsequent > signalling messages to the data flows they refer to.=20 >=20 > 2) The GaNAT replaces GIST header fields in a way consistent with the > translation of data traffic, as necessary. The GaNAT > does this for D-mode as well as for C-mode messages throughout the > duration of the signalling session. >=20 > Note that the first approach is more closely aligned with what is > outlined in section 7.3 of the current GIMPS/GIST draft. > I will now list potential advantages and disadvantages of=20 > each approach. > Please feel free to add or delete items from/to these lists. >=20 > Potential advantages of the first approach include the following. >=20 > *) As the GaNAT has to inspect only certain D-mode GIMPS messages, the > processing overhead imposed on it is minimal. > *) The amount of per-signalling session state that the GaNAT has to > maintain is less compared to the second approach. > *) The approach works in the presence of cryptographically protected > signalling traffic. >=20 > Potential disadvantages of the first approach include the following. >=20 > *) Non-NAT GIST nodes must be NAT-aware, i.e. all GIST nodes need to > implement the mechanism that follows this approach. True. (I believe the delta in functionality/load to be relatively minor, however.) > *) Internal network details may be revealed to untrusted parts of the > network. This is because the original GIST header > fields remain in the message that leaves the GaNAT. True. This is intrinsically unavoidable if one uses peer-peer security=20 protection. Also, I am not clear how strongly people care about this level of hiding; if they do, I would have thought that they would=20 also want signalling application level control at the site boundary anyway (which may or may not be at the NAT itself). > *) At some point the GaNAT installs a NAT binding for the signalling > traffic. From that point onwards, the GaNAT treats > signalling traffic like any other type of traffic. This may be an > opportunity for an intruder to inject non-signalling > traffic into the internal network in scenarios where the=20 > GaNAT also acts > as a firewall. I don't see the point here. If you can inject non-signalling traffic, why not inject signalling traffic as well? In reality, if you care about traffic injection you should be using messaging assocation security anyway. > *)The testing of implementations (e.g. via manual packet analysis) in > complex environments may be non-trivial as the correspondence between=20 > signalling and data traffic is only visible in the packets that carry > the initial GIST QUERY/RESPONSE/CONFIRM messages. Like Christian I don't really see the issue here. In either approach, to understand the C-mode traffic, you have to follow the entire C-mode data stream and also understand what D-mode exchanges relate to it.=20 >=20 > Potential advantages of the second approach include the following. >=20 > *) GaNATs remain transparent to other GIST nodes. As a result, non-NAT > GIST nodes do not need to implement any mechanisms > apart from the basic GIST specification. > *) As a result of the above, cascades of such GaNATs are also=20 > handled in > a straightforward manner. This is important (and needs to be verified that the 'visible' approach has the same property, which takes a bit more work.) > *) Testing by packet analysis may be easier as the IP header=20 > in the data > flow in consistent with the MRI in the GIST > header of signalling messages throughout the network. I'm not sure what this means? > *) In contrast to the first approach, the GaNAT verifies that all > signalling traffic actually carries a GIST header after > the transport layer header. This advantage should be contrasted to the > third disadvantage of the first approach. The malicious person can always add a malicious GIST header if=20 they want ... >=20 > Potential disadvantages of the second approach include the following. >=20 > *) The approach does not work in the presence of cryptographically > protected signalling traffic. This is because > the replacement of GIST header fields by the GaNAT causes=20 > cryptographic > checks to fail at the receiving GIST peer.=20 > *) The GaNAT has to process all (as opposed to only a small subset of) > GIST headers of signalling messages.=20 > *) The amount of per signalling session state that the GaNAT maintains > is larger compared to the first approach. > *) The GaNAT may be exposed to service denial attacks to a=20 > higher degree > compared to the first approach. There are a couple of extra disadvantages to be considered here. Firstly, the GaNAT has to preserve the transport layer communications properties provided by C-mode between the two peers, including the operation of - flow control (imposed by one peer on another) - congestion control - reliability - and do so in the case of error conditions (connection resets) and packet re-ordering/loss - all the time reconstructing the data stream to do the in-stream manipulation This can be done in the restricted set of deployment conditions for the use of TCP in GIST; however, no-one should be under any impression that it is at all trivial. It's comparable to the work that needs to be done on the FTP control channel (and I've enough bad experience of the decreased usability of FTP compared to e.g. HTTP behind NATs, especially under extreme conditions.) Secondly, the question of GIST extensions has to be considered. In the 'visible' case, the GIST peers know exactly which objects have been translated by the NAT and which have not; if a new object is added to GIST, which the GIST nodes understand, they can make intelligent decisions about how to handle it when it has been carried through a NAT (since they know what a NAT has done to it). [If they don't understand it, the question is moot anyway.] OTOH, in the 'invisible' approach, a GIST node has no idea whether all the objects have been consistently processed, since it doesn't even know they have been=20 processed in the first place. This is a serious problem with any NAT approach for an extensible protocol. >=20 > Both approaches are adopted in the current draft. That is, a GaNAT > implements the mechanisms that implement both approaches. > It can then adopt the correct behaviour, based on whether or not > cryptographic protection is required for the signalling > traffic between two GIST peers. If such protection is not=20 > required, the > GaNAT adopts the mechanisms that follow the > first approach; if it is, it follows the mechanisms implementing the > second approach. The GaNAT can tell whether or not > cryptographic protection is required from the stack proposals that are > exchanged in the GIST QUERY and RESPONSE messages; > inclusion of IPsec or TLS proposals amount to cryptographic protection > being required.=20 >=20 > For those that may want some more information in order to contribute > their view on this matter (but do not necessarily want > to read the current draft), a more detailed explanation of how new > signalling session are handled by the NAT can be found > in the "trailer" of this email. >=20 > =3D=3D=3D=3D=3D > =20 > Question to the WG: It remains unclear whether or not it is=20 > desirable to > specify both the above approaches=20 > (for example, because there may be scenarios the requirements of which > are better met by one or the other). What does the WG think. >=20 > (a) Both approaches should be mandantory to implement. > (b) One approach only should be taken (which one?) > (c) One approach should be mandantory to implement (which=20 > one?) and one > should be optional (which one?) > (d) Another approach is better (please describe the approach) >=20 > =3D=3D=3D=3D=3D=3D >=20 > Many thanks for your time and response! >=20 > START OF TRAILER >=20 > The following three paragraphs clarify how the GaNAT handles new > signalling sessions and how the selection of the "correct"=20 > behaviour is > supposed to work. >=20 > Regardless of which approach is taken, after a GIST response passes > through the GaNAT, the GaNAT should expect a > messaging association to be set up between the two involved=20 > GIST peers. > For this to happen, the GaNAT has to allow > traffic to traverse it. From a security perspective, the GaNAT should > allow the minimum necessary traffic types > to traverse. Additionally, the amount of per signalling session state > that is allocated at a GaNAT should > be minimised for reasons of efficiency and resistance to=20 > service denial > attacks. For these reasons, it makes sense > for the GaNAT to be able to predict with certainty which of the GIST > responder's stack proposal will be used by > the initiator for the establishement of a messaging association. This > can be accomplished by having the GaNAT=20 > modify the stack configuration object in the GIST response as=20 > it passes > though it such that the initiator is forced to use > a particular stack proposal and, if applicable, a particular transport > layer destination port.=20 > =20 > The reason why it is preferable for the GaNAT to modify only the stack > configuration data object (as opposed to the > stack proposal object) is that the GIST responder expects its original > stack proposal to be included in the GIST > CONFIRM message. The initiator would not be able to echo that=20 > object as > it would not have seen it and, if signalling=20 > messages are cryptographically protected, then the GaNAT=20 > cannot replace > the stack proposal in the GIST CONFIRM message=20 > with the one the responder expect, without causing=20 > cryptographic checks > to fail at the responder. Thus, the approach taken > in this document is for the GaNAT to render invalid all but one stack > configuration data objects in the GIST RESPONSE > message. A stack configuration object is rendered invalid by=20 > setting the > port number to zero.=20 >=20 > A question arises due to the fact that the stack proposal carried by a > GIST RESPONSE may include multiple messaging=20 > associations of which some provide > cryptographic protection for signalling traffic and some do not. Which > behaviour should the GaNAT assume in this case? In > other words, which stack configuration objects should the GaNAT render > invalid in this case? The GaNAT SHOULD render > invalid all stack configuration objects except the first that=20 > refers to > a stack proposal that offers cryptographic > protection.=20 >=20 > END OF TRAILER >=20 > Andreas and Hannes >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Sat Aug 20 22:45:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6fpl-00068I-Kd; Sat, 20 Aug 2005 22:45:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6fpj-000684-WD for nsis@megatron.ietf.org; Sat, 20 Aug 2005 22:45:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20046 for ; Sat, 20 Aug 2005 22:45:13 -0400 (EDT) Received: from mail120.messagelabs.com ([216.82.255.211]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1E6gPv-0004b3-Qw for nsis@ietf.org; Sat, 20 Aug 2005 23:22:45 -0400 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-14.tower-120.messagelabs.com!1124592295!5719033!1 X-StarScan-Version: 5.4.15; banners=-,-,- X-Originating-IP: [192.128.133.132] Received: (qmail 26449 invoked from network); 21 Aug 2005 02:44:55 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (192.128.133.132) by server-14.tower-120.messagelabs.com with SMTP; 21 Aug 2005 02:44:55 -0000 Received: from kcclust06evs1.ugd.att.com (135.38.164.89) by attrh3i.attrh.att.com (7.2.052) id 42E3BC2B00D50B99; Sat, 20 Aug 2005 22:44:54 -0400 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] QSPEC extensibility and re-use of multiple instances ofdefined parameters Date: Sat, 20 Aug 2005 21:44:11 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA09FA9225@KCCLUST06EVS1.ugd.att.com> Thread-Topic: [NSIS] QSPEC extensibility and re-use of multiple instances ofdefined parameters Thread-Index: AcWd3C0rfXniEI+ZScaG5v9vZ62C3AFJR4nwAL4ZztA= From: "Ash, Gerald R \(Jerry\), ALABS" To: "Kappler, Cornelia" , "Tseno Tsenov" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: quoted-printable Cc: "Ash, Gerald R \(Jerry\), ALABS" 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: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi Cornelia, > Hi Tseno - and John and Jerry,=20 > > so there doesnt seem to be much concrete use for this > additional kind of extensibility. Therefore my suggestion > is to not support it. I agree, and support John's view that QSPEC functionality not be so extended unless there is a clear need. Thanks, Regards, Jerry _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Sun Aug 21 15:57:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6vwF-0001v1-Rx; Sun, 21 Aug 2005 15:57:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6vwC-0001ug-A4 for nsis@megatron.ietf.org; Sun, 21 Aug 2005 15:57:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16207 for ; Sun, 21 Aug 2005 15:56:58 -0400 (EDT) Received: from mclmx2.mail.saic.com ([149.8.64.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E6wWc-0007SE-IL for nsis@ietf.org; Sun, 21 Aug 2005 16:34:39 -0400 Received: from [149.8.64.21] by mclmx2.mail.saic.com; Sun, 21 Aug 2005 15:56:36 -0400 Received: from mclmx2.mail.saic.com ([149.8.64.32]) by mcl-its-ieg01.mail.saic.com (SMSSMTP 4.0.5.66) with SMTP id M2005082115563620959 ; Sun, 21 Aug 2005 15:56:36 -0400 Received: from [149.8.64.21] by mclmx2.mail.saic.com with ESMTP; Sun, 21 Aug 2005 15:56:36 -0400 Received: from bh-exchange02.saic-abingdon.com ([10.42.81.226]) by bh-exchangefe.saic-abingdon.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 21 Aug 2005 15:58:55 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [NSIS] QSPEC extensibility and re-use of multiple instancesofdefined parameters Date: Sun, 21 Aug 2005 15:58:51 -0400 Message-Id: <2FE23D25B7292B489A217D1965CDA866726455@bh-exchange02.saic-abingdon.com> Thread-Topic: [NSIS] QSPEC extensibility and re-use of multiple instancesofdefined parameters Thread-Index: AcWd3C0rfXniEI+ZScaG5v9vZ62C3AFJR4nwAL4ZztAAI3IfIw== From: "Roy, Radhika \(AEAD\)" To: "Ash, Gerald R \(Jerry\), ALABS" , "Kappler, Cornelia" , "Tseno Tsenov" , X-OriginalArrivalTime: 21 Aug 2005 19:58:55.0809 (UTC) FILETIME=[C30DDB10:01C5A68A] X-Spam-Score: 0.6 (/) X-Scan-Signature: 43317e64100dd4d87214c51822b582d1 Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0750724736==" Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. --===============0750724736== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5A68A.C08AA8DC" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5A68A.C08AA8DC Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Tseno and all: =20 We all support John's view as we described before as explained before as = follows: =20 1.=09 Present QSPEC draft needs to delete those QOS model-specific specific = parts of draft as John L. has also admitted that it will create problems = if domains are NOT constructed carefully. 2.=09 Tseno has suggested to generalize the extensions related QOS models for = making draft consistent as the draft itself is NOT specific for = extensions of any specific QOS models. Jerry suggested to use multiple = instances to take care of this problem. John L. has gone further in = explaining why Jerry's suggestions for multiple instances of the same = parameter is NOT acceptable. 3.=09 The present QSPEC draft, for example, has extended the QSPEC for Y1541 = which itself is incomplete. Because the another draft = http://www.ietf.org/internet-drafts/draft-ietf-nsis-y1541-qosm-00.txt- = shows many more QSPEC extensions specific to Y1541 QOS model is needed = to support the Y1541 QOS model. So, this Y1541-QOSM draft is the right = place for dealing with all QSPEC extensions-specific to Y1541 QOS model. = This draft (y1541-qosm) must also explain how this Y1541 QOS = model-specific "DOMAIN" needs to created without contradicting in = "values" of end-to-end QOS parameters used in the templates as expressed = by applications. So, the QSPEC draft is the generalized QOS templates that can be used by = NSIS QOS signaling messages, and MUST delete all technically = inconsistent QOS model-specific (e.g., Y1541) extensions. Best regards, Radhika ________________________________ From: nsis-bounces@ietf.org on behalf of Ash, Gerald R (Jerry), ALABS Sent: Sat 8/20/2005 10:44 PM To: Kappler, Cornelia; Tseno Tsenov; nsis@ietf.org Cc: Ash, Gerald R (Jerry), ALABS Subject: RE: [NSIS] QSPEC extensibility and re-use of multiple = instancesofdefined parameters Hi Cornelia, > Hi Tseno - and John and Jerry, > > so there doesnt seem to be much concrete use for this > additional kind of extensibility. Therefore my suggestion > is to not support it. I agree, and support John's view that QSPEC functionality not be so extended unless there is a clear need. Thanks, Regards, Jerry _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis ------_=_NextPart_001_01C5A68A.C08AA8DC Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A= =0A= =0A= RE: [NSIS] QSPEC extensibility and re-use of multiple = instancesofdefined parameters=0A= =0A= =0A=
Tseno and = all:
=0A=
 
=0A=
We all support John's view as = we described =0A= before as explained before as follows:
=0A=
 
=0A=
    =0A=
  1. =0A=
    =0A=
    Present QSPEC draft = needs to =0A= delete those QOS model-specific specific parts of draft as John L. has = also =0A= admitted that it will create problems if domains are NOT constructed =0A= carefully.
    2. =0A=
  2. =0A=
    =0A=
    Tseno has suggested to = generalize =0A= the extensions related QOS models for making draft consistent as the = draft =0A= itself is NOT specific for extensions of any specific QOS models. = Jerry =0A= suggested to use multiple instances to take care of this problem. John = L. has =0A= gone further in explaining why Jerry’s suggestions for multiple = instances of =0A= the same parameter is NOT = acceptable.
    3. =0A=
  3. =0A=
    =0A=
    The present QSPEC draft, for = example, has =0A= extended the QSPEC for Y1541 which itself is incomplete. Because the = another =0A= draft  http://www.ietf.org/internet-drafts/draft-ietf-nsis-y1541-qosm-0= 0.txt- shows many more QSPEC extensions specific to = Y1541 QOS =0A= model is needed to support the Y1541 QOS model. So, this Y1541-QOSM =0A= draft is the right place for dealing with all QSPEC = extensions-specific =0A= to Y1541 QOS model. This draft (y1541-qosm) must also explain how this =0A= Y1541 QOS model-specific "DOMAIN" needs to created without = contradicting =0A= in "values" of end-to-end QOS parameters used in the templates as = expressed by =0A= applications.
=0A=

=0A=

So, the QSPEC draft is the =0A= generalized QOS templates that can be used by NSIS QOS signaling = messages, and =0A= MUST delete all technically inconsistent QOS model-specific (e.g., = Y1541) =0A= extensions.

=0A=
Best regards,
=0A=
Radhika
=0A=
=0A=
=0A=
=0A=
From: = nsis-bounces@ietf.org on =0A= behalf of Ash, Gerald R (Jerry), ALABS
Sent: Sat 8/20/2005 = 10:44 =0A= PM
To: Kappler, Cornelia; Tseno Tsenov; = nsis@ietf.org
Cc: =0A= Ash, Gerald R (Jerry), ALABS
Subject: RE: [NSIS] QSPEC = extensibility =0A= and re-use of multiple instancesofdefined parameters

=0A=
=0A=

Hi Cornelia,

> Hi Tseno - and John and =0A= Jerry,
>
> so there doesnt seem to be much concrete use for =0A= this
> additional kind of extensibility. Therefore my = suggestion
> =0A= is to not support it.

I agree, and support John's view that QSPEC =0A= functionality not be so
extended unless there is a clear =0A= need.

Thanks,
Regards,
Jerry

________________________= _______________________
nsis =0A= mailing list
nsis@ietf.org
https://www1.ietf.or= g/mailman/listinfo/nsis

=0A= =0A= =0A= ------_=_NextPart_001_01C5A68A.C08AA8DC-- --===============0750724736== 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 --===============0750724736==-- From nsis-bounces@ietf.org Tue Aug 23 09:35:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7Yvq-0006jg-MK; Tue, 23 Aug 2005 09:35:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7Yvp-0006ht-6S for nsis@megatron.ietf.org; Tue, 23 Aug 2005 09:35:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03314 for ; Tue, 23 Aug 2005 09:35:11 -0400 (EDT) Received: from mail.piranho.net ([80.190.200.220]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1E7Yvv-0004g2-KW for nsis@ietf.org; Tue, 23 Aug 2005 09:35:21 -0400 Received: (qmail 28682 invoked from network); 23 Aug 2005 13:34:56 -0000 Received: from localhost (HELO mail.piranho.net) (127.0.0.1) by 0 with SMTP; 23 Aug 2005 13:34:56 -0000 Received: from 192.35.17.24 (SquirrelMail authenticated user zedsoy) by mail.piranho.net with HTTP; Tue, 23 Aug 2005 15:34:56 +0200 (CEST) Message-ID: <50740.192.35.17.24.1124804096.squirrel@mail.piranho.net> Date: Tue, 23 Aug 2005 15:34:56 +0200 (CEST) From: "Henning Peters" To: nsis@ietf.org User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal X-Spam-Score: 0.8 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 8bit Subject: [NSIS] How to handle unknown MRMs 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: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hello WG, hello Robert, today we discussed the new loose-end MRM and asked ourselves how GIST shall behave in general when it is about to handle an MRM that might be specified in a future RFC and is yet unknown to a GIST implementation that relies on current RFCs. We didn't find a part in the spec that clearly defines how an implementation shall handle unknown MRMs. Our view is to treat those MRMs with the same behavior as if the NSLP is unknown, that means: relaying without modification of the message or without setup up of any state. Otherwise future MRMs might get blocked and can't be deployed in a proper way if an old implementation is on the path. Is this assumption correct? Christian Dickmann & Henning Peters _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Aug 25 08:45:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8H6w-00047b-Bo; Thu, 25 Aug 2005 08:45:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8H6t-00045v-FY for nsis@megatron.ietf.org; Thu, 25 Aug 2005 08:45:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15730 for ; Thu, 25 Aug 2005 08:45:34 -0400 (EDT) Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8H7J-0001xk-TE for nsis@ietf.org; Thu, 25 Aug 2005 08:46:08 -0400 Received: from rsys005a.comm.ad.roke.co.uk ([193.118.193.85]) by rsys001x.roke.co.uk (8.12.8/8.12.8) with ESMTP id j7PCiw7g024827; Thu, 25 Aug 2005 13:44:58 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] How to handle unknown MRMs Date: Thu, 25 Aug 2005 13:44:58 +0100 Message-ID: Thread-Topic: [NSIS] How to handle unknown MRMs Thread-Index: AcWn59MEdsttJBr2Re+zxPCBh/O5bgBe3PvA From: "Hancock, Robert" To: "Henning Peters" , X-MailScanner-rsys001x: Found to be clean X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Content-Transfer-Encoding: quoted-printable 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: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi Henning, this is a good question. i think there are several components=20 to the right answer (what follows is basically me thinking aloud, but the short answer is that your analysis is correct). 1. GIST was always designed (using the same techniques as RSVP, in fact), to work OK in regions where there were no GIST nodes at all. Query messages can always be forwarded at the IP layer provided the destination IP address can be forwarded to. It's not as good as doing a proper analysis of the MRM and deciding exactly what to do with the message, but it's better than nothing (and MRM designers should be prepared to cope with this scenario). 2. If a Query message actually arrives at a node which will become a GIST peers (i.e. it has the right NSLP which wants to take part in the signalling session and so on), then in some senses the receiving GIST node doesn't *need* to understand the MRM at all. It just needs to be able to use it as a table index and pass it up to the NSLP. (Actually this is a slightly extreme view, and I wouldn't expect a GIST implementation to be able to receive unknown MRMs. But there is an asymmetry between the level of support required in the sender and the receiver.) 3. Fundamentally, I think it is necessary for NSLPs to fix which MRM they use. (In practice this should not be an issue, but it probably needs to be written down.) Then the only case where a node doesn't understand an MRM is where is doesn't support the NSLP either, in which case forwarding the message as though one were totally NSIS-unaware is the right thing to do; if the message cannot be forwarded (e.g. because it's reached the destination in the encapsulation) then we already have an error message for that circumstance. cheers, robert h. ps. recorded at=20 http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue66 > -----Original Message----- > From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On=20 > Behalf Of Henning Peters > Sent: 23 August 2005 14:35 > To: nsis@ietf.org > Subject: [NSIS] How to handle unknown MRMs >=20 >=20 > Hello WG, hello Robert, >=20 > today we discussed the new loose-end MRM and asked ourselves how GIST > shall behave in general when it is about to handle an MRM=20 > that might be > specified in a future RFC and is yet unknown to a GIST=20 > implementation that > relies on current RFCs. We didn't find a part in the spec that clearly > defines how an implementation shall handle unknown MRMs. >=20 > Our view is to treat those MRMs with the same behavior as if=20 > the NSLP is > unknown, that means: relaying without modification of the message or > without setup up of any state. Otherwise future MRMs might=20 > get blocked and > can't be deployed in a proper way if an old implementation is=20 > on the path. >=20 > Is this assumption correct? >=20 > Christian Dickmann & Henning Peters >=20 >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Aug 26 08:21:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8dDA-0002MQ-Gk; Fri, 26 Aug 2005 08:21:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8dD9-0002ML-M8 for nsis@megatron.ietf.org; Fri, 26 Aug 2005 08:21:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14909 for ; Fri, 26 Aug 2005 08:21:30 -0400 (EDT) Received: from difra-computer.de ([81.169.157.103] helo=www.difra-computer.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8dDr-0004FH-Bj for nsis@ietf.org; Fri, 26 Aug 2005 08:22:16 -0400 Received: from win2003.dickmann2003.home (p548A74EF.dip.t-dialin.net [84.138.116.239]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by www.difra-computer.de (Postfix) with ESMTP id 79A883E402B for ; Fri, 26 Aug 2005 14:15:41 +0200 (CEST) Received: from christian ([192.168.0.2]) by win2003.dickmann2003.home with Microsoft SMTPSVC(6.0.3790.211); Fri, 26 Aug 2005 14:13:58 +0200 From: "Christian Dickmann" To: Date: Fri, 26 Aug 2005 14:13:57 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcWqN6IlW8JOQfVUSrWyuTyfE11b3g== Message-ID: X-OriginalArrivalTime: 26 Aug 2005 12:13:58.0349 (UTC) FILETIME=[A2F007D0:01C5AA37] X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit Subject: [NSIS] GIMPS/GIST: Ordering of objects 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: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi Robert, hi WG, at the Interop we talked about the ordering of objects. The current draft specifies, that the ordering is fixed. The common feeling was, that there is no need for it to be fixed. I just want to comment on this topic again. When I wanted to implement the LooseEnd-ByPass, I came to the conclusion, that it should be mandatory to have the MRI as the first object. When bypass should take place I do not want to parse the complete message to get the MRM, instead, I want to simply step into the message and read the MRM field at the fixed position. So NSLP Data (we agreed here) and MRI (I do not remember if we agreed here) should be at fixed positions (end/front respectively). If we agree on those two, the specification should really make the complete ordering fixed in my opinion. But the statement about the ordering should be moved IMHO. Currently it is the last sentence in the initial text on TLVs (chapter 5.2.2 TLV Objects "The ABNF given above fixes the order of objects within a message."). The ABNF itself is given in chapter 5.1. I think the note should be moved to the beginning of chapter 5.1, as it is the possition where the note applies. It in not so much about the TLV objects, but about the messages and so to my mind, chapter 5.1 (named GIMPS Messages) is the right place to put the note. Christian Dickmann _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Aug 26 10:30:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8fE1-0008Nv-IJ; Fri, 26 Aug 2005 10:30:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8fDz-0008Nl-CK for nsis@megatron.ietf.org; Fri, 26 Aug 2005 10:30:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23737 for ; Fri, 26 Aug 2005 10:30:29 -0400 (EDT) Received: from difra-computer.de ([81.169.157.103] helo=www.difra-computer.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8fEi-00009a-0T for nsis@ietf.org; Fri, 26 Aug 2005 10:31:17 -0400 Received: from win2003.dickmann2003.home (p548A74EF.dip.t-dialin.net [84.138.116.239]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by www.difra-computer.de (Postfix) with ESMTP id 254903E402B for ; Fri, 26 Aug 2005 16:24:41 +0200 (CEST) Received: from christian ([192.168.0.2]) by win2003.dickmann2003.home with Microsoft SMTPSVC(6.0.3790.211); Fri, 26 Aug 2005 16:26:21 +0200 From: "Christian Dickmann" To: "'Hancock, Robert'" , Subject: RE: [NSIS] How to handle unknown MRMs Date: Fri, 26 Aug 2005 16:26:20 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcWn59MEdsttJBr2Re+zxPCBh/O5bgBe3PvAADkIX9A= In-Reply-To: Message-ID: X-OriginalArrivalTime: 26 Aug 2005 14:26:21.0631 (UTC) FILETIME=[2180ACF0:01C5AA4A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit 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: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi Robert, > 2. If a Query message actually arrives at a node which will become > a GIST peers (i.e. it has the right NSLP which wants to take part > in the signalling session and so on), then in some senses the > receiving GIST node doesn't *need* to understand the MRM at all. > It just needs to be able to use it as a table index and pass it > up to the NSLP. (Actually this is a slightly extreme view, and > I wouldn't expect a GIST implementation to be able to receive > unknown MRMs. But there is an asymmetry between the level of support > required in the sender and the receiver.) This is really an extreme view, but certainly it is somehow right. The problem is the 3-way handshake. The first problem would be the D-Flag in the Response. If you do not consider the MRI in the GIST layer, then you can not send a valid Response. So the 3-way handshake won't be completed and so the NSLP might never be triggered. Even if the 3-way handshake works, we get new problems. Lets say, that GIST established a MRS using an MRM that it does not understand. The NSLP payload is passed to an NSLP that understands the MRM (that is already strange). The NSLP wants to forward the message downstream and so uses the API to send the message. As you said, sending is a different issue. Sending means, that you can read the MRI to find the destination IP address. The message is stuck and to make everything worse, we already got a MRS with the upstream peer. I think that in practice, a GIST node not supporting a MRM should not try to participate in a signaling session using that MRM. In addition, every NSLP should state which MRMs it supports. So the GIST node should only consider Queries with a MRM supported by the GIST implementation _and_ the NSLP (implementation, but specification as well). Did I miss something? Christian _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Sat Aug 27 05:25:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8wvw-0000hi-7j; Sat, 27 Aug 2005 05:25:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8wvu-0000gv-Hh for nsis@megatron.ietf.org; Sat, 27 Aug 2005 05:25:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04679 for ; Sat, 27 Aug 2005 05:24:59 -0400 (EDT) Received: from bay103-f22.bay103.hotmail.com ([65.54.174.32] helo=hotmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8wwn-0002Sc-Hx for nsis@ietf.org; Sat, 27 Aug 2005 05:25:58 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 27 Aug 2005 02:24:51 -0700 Message-ID: Received: from 65.54.174.206 by by103fd.bay103.hotmail.msn.com with HTTP; Sat, 27 Aug 2005 09:24:50 GMT X-Originating-IP: [192.35.17.15] X-Originating-Email: [hannestschofenig@hotmail.com] X-Sender: hannestschofenig@hotmail.com In-Reply-To: From: "Hannes Tschofenig" To: nsis@ietf.org Date: Sat, 27 Aug 2005 11:24:50 +0200 Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed X-OriginalArrivalTime: 27 Aug 2005 09:24:51.0145 (UTC) FILETIME=[2D255390:01C5AAE9] X-Spam-Score: 0.8 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Subject: [NSIS] ietf#63 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: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org hi all, please take a look at the meeting minutes: http://www.ietf-nsis.org/nsis/IETF63/nsis-meeting-minutes.txt if you think that something is missing or wrong please send me a mail. ciao hannes _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Sat Aug 27 05:35:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8x6L-0003H2-Ea; Sat, 27 Aug 2005 05:35:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8x6J-0003Gx-Iv for nsis@megatron.ietf.org; Sat, 27 Aug 2005 05:35:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05016 for ; Sat, 27 Aug 2005 05:35:44 -0400 (EDT) Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8x79-0002jw-B2 for nsis@ietf.org; Sat, 27 Aug 2005 05:36:44 -0400 Received: from rsys005a.comm.ad.roke.co.uk ([193.118.193.85]) by rsys001x.roke.co.uk (8.12.8/8.12.8) with ESMTP id j7R9ZF7g014433; Sat, 27 Aug 2005 10:35:15 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Received: from ac78840 (orion.roke.co.uk [193.118.192.66]) by rsys002a.roke.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id RBBWC1B3; Sat, 27 Aug 2005 10:38:27 +0100 MIME-Version: 1.0 Content-class: urn:content-classes:message Subject: RE: [NSIS] ietf#63 nsis meeting minutes Date: Sat, 27 Aug 2005 10:35:21 +0100 Message-ID: <015401c5aaea$a51679f0$0202a8c0@comm.ad.roke.co.uk> Thread-Topic: [NSIS] ietf#63 nsis meeting minutes Thread-Index: AcWq6xPX3sjVswl3TISPlbLoFUvFuA== From: "Hancock, Robert" To: "Hannes Tschofenig" , X-MailScanner-rsys001x: Found to be clean X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.8 (/) X-Scan-Signature: 827a2a57ca7ab0837847220f447e8d56 Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0064862239==" Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. --===============0064862239== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5AAEB.136EEB80" Content-class: urn:content-classes:message This is a multi-part message in MIME format. ------_=_NextPart_001_01C5AAEB.136EEB80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable hi, on the implementation front, it might be nice to add pointers to the mails announcing the available implementations. (for outsiders, the nsis-imp archive is pretty hard to find.) they are coimbra: = http://www.ietf.org/mail-archive/web/nsis-imp/current/msg00056.html goettingen: http://www.ietf.org/mail-archive/web/nsis-imp/current/msg00051.html robert h. PS should there be a reference to the implementors list on the charter page? > -----Original Message----- > From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On=20 > Behalf Of Hannes Tschofenig > Sent: 27 August 2005 10:25 > To: nsis@ietf.org > Subject: [NSIS] ietf#63 nsis meeting minutes >=20 >=20 > hi all, >=20 > please take a look at the meeting minutes: > http://www.ietf-nsis.org/nsis/IETF63/nsis-meeting-minutes.txt >=20 > if you think that something is missing or wrong please send me a mail. >=20 > ciao > hannes >=20 >=20 >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 ------_=_NextPart_001_01C5AAEB.136EEB80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [NSIS] ietf#63 nsis meeting minutes

hi,

on the implementation front, it might be nice to add = pointers
to the mails announcing the available = implementations. (for outsiders,
the nsis-imp archive is pretty hard to find.) they = are
coimbra: http://www.ietf.org/mail-archive/web/nsis-imp/current/msg00056.html
goettingen:
http://www.ietf.org/mail-archive/web/nsis-imp/current/msg00051.html

robert h.

PS should there be a reference to the implementors = list on the charter
page?

> -----Original Message-----
> From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] = On
> Behalf Of Hannes Tschofenig
> Sent: 27 August 2005 10:25
> To: nsis@ietf.org
> Subject: [NSIS] ietf#63 nsis meeting = minutes
>
>
> hi all,
>
> please take a look at the meeting = minutes:
> ht= tp://www.ietf-nsis.org/nsis/IETF63/nsis-meeting-minutes.txt
>
> if you think that something is missing or wrong = please send me a mail.
>
> ciao
> hannes
>
>
>
> = _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.or= g/mailman/listinfo/nsis
>

------_=_NextPart_001_01C5AAEB.136EEB80-- --===============0064862239== 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 --===============0064862239==-- From nsis-bounces@ietf.org Sat Aug 27 09:07:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E90Or-0001Du-Ij; Sat, 27 Aug 2005 09:07:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E90Oo-0001Dp-DL for nsis@megatron.ietf.org; Sat, 27 Aug 2005 09:07:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12448 for ; Sat, 27 Aug 2005 09:07:04 -0400 (EDT) Received: from bay103-f8.bay103.hotmail.com ([65.54.174.18] helo=hotmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E90Pj-0008Lf-E3 for nsis@ietf.org; Sat, 27 Aug 2005 09:08:04 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 27 Aug 2005 06:06:55 -0700 Message-ID: Received: from 65.54.174.206 by by103fd.bay103.hotmail.msn.com with HTTP; Sat, 27 Aug 2005 13:06:55 GMT X-Originating-IP: [192.35.17.15] X-Originating-Email: [hannestschofenig@hotmail.com] X-Sender: hannestschofenig@hotmail.com In-Reply-To: <015401c5aaea$a51679f0$0202a8c0@comm.ad.roke.co.uk> From: "Hannes Tschofenig" To: robert.hancock@roke.co.uk, nsis@ietf.org Subject: RE: [NSIS] ietf#63 nsis meeting minutes Date: Sat, 27 Aug 2005 15:06:55 +0200 Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed X-OriginalArrivalTime: 27 Aug 2005 13:06:55.0836 (UTC) FILETIME=[3347D1C0:01C5AB08] X-Spam-Score: 0.8 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 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: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org hi robert i added these links to the meeting minutes and to the weblog (http://www.ietf-nsis.org) ciao hannes >From: "Hancock, Robert" >To: "Hannes Tschofenig" , >Subject: RE: [NSIS] ietf#63 nsis meeting minutes >Date: Sat, 27 Aug 2005 10:35:21 +0100 > >hi, > >on the implementation front, it might be nice to add pointers >to the mails announcing the available implementations. (for outsiders, >the nsis-imp archive is pretty hard to find.) they are >coimbra: >http://www.ietf.org/mail-archive/web/nsis-imp/current/msg00056.html >goettingen: >http://www.ietf.org/mail-archive/web/nsis-imp/current/msg00051.html > >robert h. > >PS should there be a reference to the implementors list on the charter >page? > > > -----Original Message----- > > From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On > > Behalf Of Hannes Tschofenig > > Sent: 27 August 2005 10:25 > > To: nsis@ietf.org > > Subject: [NSIS] ietf#63 nsis meeting minutes > > > > > > hi all, > > > > please take a look at the meeting minutes: > > http://www.ietf-nsis.org/nsis/IETF63/nsis-meeting-minutes.txt > > > > if you think that something is missing or wrong please send me a mail. > > > > ciao > > hannes > > > > > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Sun Aug 28 02:16:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9GSg-0002eX-8A; Sun, 28 Aug 2005 02:16:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9GSd-0002eP-Nu for nsis@megatron.ietf.org; Sun, 28 Aug 2005 02:16:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00451 for ; Sun, 28 Aug 2005 02:16:04 -0400 (EDT) From: john.loughney@nokia.com Received: from mgw-ext01.nokia.com ([131.228.20.93]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E9GTf-0005zl-FX for nsis@ietf.org; Sun, 28 Aug 2005 02:17:12 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext01.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j7S6Fvkg028444; Sun, 28 Aug 2005 09:16:00 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 28 Aug 2005 09:15:59 +0300 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 28 Aug 2005 09:16:00 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] ietf#63 nsis meeting minutes Date: Sun, 28 Aug 2005 09:15:58 +0300 Message-ID: <1AA39B75171A7144A73216AED1D7478DBB3407@esebe100.NOE.Nokia.com> Thread-Topic: [NSIS] ietf#63 nsis meeting minutes Thread-Index: AcWq6xPX3sjVswl3TISPlbLoFUvFuAArJJ4w To: , , X-OriginalArrivalTime: 28 Aug 2005 06:16:00.0096 (UTC) FILETIME=[F5BA3600:01C5AB97] X-Spam-Score: 0.3 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: quoted-printable 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: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Posting it in the meeting minutes & Hannes' page would be OK, but one of the benefits of not having it plastered all over web is that we get less spam. Just by way of stats, NSIS mailman filters traps about 30 spams a day, the nsis-imp traps about 1 a month ... ________________________________ From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On Behalf Of ext Hancock, Robert Sent: 27 August, 2005 12:35 To: Hannes Tschofenig; nsis@ietf.org Subject: RE: [NSIS] ietf#63 nsis meeting minutes =09 =09 hi,=20 on the implementation front, it might be nice to add pointers=20 to the mails announcing the available implementations. (for outsiders,=20 the nsis-imp archive is pretty hard to find.) they are=20 coimbra: http://www.ietf.org/mail-archive/web/nsis-imp/current/msg00056.html=20 goettingen:=20 =09 http://www.ietf.org/mail-archive/web/nsis-imp/current/msg00051.html=20 robert h.=20 PS should there be a reference to the implementors list on the charter=20 page?=20 > -----Original Message-----=20 > From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On=20 > Behalf Of Hannes Tschofenig=20 > Sent: 27 August 2005 10:25=20 > To: nsis@ietf.org=20 > Subject: [NSIS] ietf#63 nsis meeting minutes=20 >=20 >=20 > hi all,=20 >=20 > please take a look at the meeting minutes:=20 > http://www.ietf-nsis.org/nsis/IETF63/nsis-meeting-minutes.txt=20 >=20 > if you think that something is missing or wrong please send me a mail.=20 >=20 > ciao=20 > hannes=20 >=20 >=20 >=20 > _______________________________________________=20 > nsis mailing list=20 > nsis@ietf.org=20 > https://www1.ietf.org/mailman/listinfo/nsis=20 >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Sun Aug 28 18:50:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9VzK-0006mm-Qi; Sun, 28 Aug 2005 18:50:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9VzJ-0006mh-1c for nsis@megatron.ietf.org; Sun, 28 Aug 2005 18:50:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16594 for ; Sun, 28 Aug 2005 18:50:50 -0400 (EDT) Received: from mail-in-09.arcor-online.net ([151.189.21.49]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E9W0V-00017G-Rk for nsis@ietf.org; Sun, 28 Aug 2005 18:52:09 -0400 Received: from mail-in-08-z2.arcor-online.net (mail-in-08-z2.arcor-online.net [151.189.8.20]) by mail-in-09.arcor-online.net (Postfix) with ESMTP id A73A3677BE for ; Mon, 29 Aug 2005 00:50:41 +0200 (CEST) Received: from mail-in-03.arcor-online.net (mail-in-03.arcor-online.net [151.189.21.43]) by mail-in-08-z2.arcor-online.net (Postfix) with ESMTP id 998AD48E1 for ; Mon, 29 Aug 2005 00:50:41 +0200 (CEST) Received: from Tseno (dsl-084-057-003-140.arcor-ip.net [84.57.3.140]) by mail-in-03.arcor-online.net (Postfix) with SMTP id 0378553FFB for ; Mon, 29 Aug 2005 00:50:37 +0200 (CEST) Message-ID: <00f101c5ac22$80d81ec0$0c00a8c0@Tseno> From: "Tseno Tsenov" To: Date: Mon, 29 Aug 2005 00:47:39 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1506 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit Subject: [NSIS] New version of the QoS NSLP state machine draft X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi all, We have updated the QoS NSLP state machine draft. You can find the new version at: http://www.tschofenig.priv.at/drafts/draft-fu-nsis-qos-nslp-statemachine-02.txt http://www.tschofenig.priv.at/drafts/draft-fu-nsis-qos-nslp-statemachine-02.pdf The state machine is based on QoS NSLP draft v-07. We have compiled a .pdf version of the draft that includes the state machine's diagrams. This should improve the readability of the document. Open issues: Some of the open issues listed in the draft were already pointed in the mailing list, i.e.: 1. Section 5.4.3./the last paragraph/ of QoS NSLP draft states: " On receipt of a RESPONSE message containing an RSN object, the QNE MUST compare the RSN to that of the appropriate signaling session. If the match succeeds then the ERROR_SPEC MUST be processed. The RESPONSE message MUST NOT be forwarded further along the path whether or not the match succeeds. " This statement makes it unclear how to signal to the QNI an unsuccessful reservation with RESERVE message that does not include RII object and therefore the RESPONSE message should include only RSN. 2. Section 5.4.1 of QoS NSLP draft states: " RESERVE messages MUST only be sent towards the QNR " We think that the text in Section 3.2.10 "Rerouting" implies that RESERVE message might be sent in both directions. Refinement or clarifications of this section should be helpful. Any comments are more than welcome. Greetings, Tseno _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Sun Aug 28 21:56:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9YtF-0008Be-Km; Sun, 28 Aug 2005 21:56:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9YtD-0008BO-HS for nsis@megatron.ietf.org; Sun, 28 Aug 2005 21:56:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23495 for ; Sun, 28 Aug 2005 21:56:45 -0400 (EDT) Received: from jalapeno.cc.columbia.edu ([128.59.29.5] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E9YuR-0005dp-VJ for nsis@ietf.org; Sun, 28 Aug 2005 21:58:05 -0400 Received: from ccs (dhcp-65-162.ee.columbia.edu [128.59.65.162]) (user=qs2005 mech=LOGIN bits=0) by jalapeno.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j7T1uMkK025831 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sun, 28 Aug 2005 21:56:22 -0400 (EDT) From: "Charles Shen" To: , , , Date: Sun, 28 Aug 2005 21:54:52 -0400 Organization: Columbia University Message-ID: <001101c5ac3c$a5791bc0$a2413b80@ccs> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: quoted-printable Cc: nsis@ietf.org Subject: [NSIS] A question on QoS NSLP RESERVE behavior 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: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi=20 In the last paragraph on page 47 of qos-nslp-07.txt, it is said "A QNE = that receives a RESERVE with the REPLACE flag set to zero but with the same = SII will update the flow ID and indicate REPLACE=3D0 to the RMF".=20 Could you please elaborate a bit what this "update the flow ID" means? Addition or replacement or ...? Will the same update be performed if the = SII is different and REPLACE=3D0 is set? Thanks. Best regards, Charles=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Sun Aug 28 21:56:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9YtG-0008C3-1a; Sun, 28 Aug 2005 21:56:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9YtD-0008BP-JG for nsis@megatron.ietf.org; Sun, 28 Aug 2005 21:56:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23494 for ; Sun, 28 Aug 2005 21:56:45 -0400 (EDT) Received: from jalapeno.cc.columbia.edu ([128.59.29.5] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E9YuR-0005ds-VF for nsis@ietf.org; Sun, 28 Aug 2005 21:58:05 -0400 Received: from ccs (dhcp-65-162.ee.columbia.edu [128.59.65.162]) (user=qs2005 mech=LOGIN bits=0) by jalapeno.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j7T1u2Uo025824 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sun, 28 Aug 2005 21:56:11 -0400 (EDT) From: "Charles Shen" To: , , , Date: Sun, 28 Aug 2005 21:54:32 -0400 Organization: Columbia University Message-ID: <001001c5ac3c$a1aa1260$a2413b80@ccs> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: quoted-printable Cc: nsis@ietf.org Subject: [NSIS] A question on QoS NSLP RESERVE behavior 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: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi=20 In the last paragraph on page 47 of qos-nslp-07.txt, it is said "A QNE = that receives a RESERVE with the REPLACE flag set to zero but with the same = SII will update the flow ID and indicate REPLACE=3D0 to the RMF".=20 Could you please elaborate a bit what this "update the flow ID" means? Addition or replacement or ...? Will the same update be performed if the = SII is different and REPLACE=3D0 is set? Thanks. Best regards, Charles=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Aug 30 12:24:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EA8ug-0000tb-Bx; Tue, 30 Aug 2005 12:24:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EA8ue-0000tW-OP for nsis@megatron.ietf.org; Tue, 30 Aug 2005 12:24:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21718 for ; Tue, 30 Aug 2005 12:24:37 -0400 (EDT) Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EA8w9-0005eU-BA for nsis@ietf.org; Tue, 30 Aug 2005 12:26:18 -0400 Received: from rsys005a.comm.ad.roke.co.uk ([193.118.193.85]) by rsys001x.roke.co.uk (8.12.8/8.12.8) with ESMTP id j7UGO47g002020; Tue, 30 Aug 2005 17:24:04 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] How to handle unknown MRMs Date: Tue, 30 Aug 2005 17:24:04 +0100 Message-ID: Thread-Topic: [NSIS] How to handle unknown MRMs Thread-Index: AcWn59MEdsttJBr2Re+zxPCBh/O5bgBe3PvAADkIX9AAzci+IA== From: "Hancock, Robert" To: "Christian Dickmann" , X-MailScanner-rsys001x: Found to be clean X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: quoted-printable 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: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org hi christian, i think we're in agreement. the key point is that NSLPs=20 specifications will define the set of valid MRMs to use, in which case any GIST node hosting an NSLP can also be=20 required to understand the MRMs of that NSLP. (Probably something about this needs to go in the extensibility draft.) GIST nodes which don't understand an MRM should be able to bypass the message without processing the MRI=20 object in it. the only subtlety is the case where a message arrives at a GIST node where is *cannot* be bypassed, which would only be the case if the GIST node was at the IP destination address of the Query packet. But in that case, the error response is sent based on the NLI object, and there is no need to=20 create any routing state or understand the MRI at all. (You would probably want to include the MRI in the error message, however.) robert h. > -----Original Message----- > From: Christian Dickmann [mailto:mail@christian-dickmann.de]=20 > Sent: 26 August 2005 15:26 > To: Hancock, Robert; nsis@ietf.org > Subject: RE: [NSIS] How to handle unknown MRMs >=20 >=20 > Hi Robert, >=20 > > 2. If a Query message actually arrives at a node which will become > > a GIST peers (i.e. it has the right NSLP which wants to take part > > in the signalling session and so on), then in some senses the > > receiving GIST node doesn't *need* to understand the MRM at all. > > It just needs to be able to use it as a table index and pass it > > up to the NSLP. (Actually this is a slightly extreme view, and > > I wouldn't expect a GIST implementation to be able to receive > > unknown MRMs. But there is an asymmetry between the level of support > > required in the sender and the receiver.) >=20 > This is really an extreme view, but certainly it is somehow right. > The problem is the 3-way handshake. The first problem would be the > D-Flag in the Response. If you do not consider the MRI in the GIST > layer, then you can not send a valid Response. So the 3-way handshake > won't be completed and so the NSLP might never be triggered.=20 > Even if the 3-way handshake works, we get new problems. Lets say, that > GIST established a MRS using an MRM that it does not understand. > The NSLP payload is passed to an NSLP that understands the=20 > MRM (that is > already strange). The NSLP wants to forward the message downstream=20 > and so uses the API to send the message. As you said, sending is a > different issue. Sending means, that you can read the MRI to find the > destination IP address. The message is stuck and to make=20 > everything worse, > we already got a MRS with the upstream peer. >=20 > I think that in practice, a GIST node not supporting a MRM=20 > should not try > to participate in a signaling session using that MRM. In=20 > addition, every > NSLP should state which MRMs it supports. So the GIST node=20 > should only=20 > consider Queries with a MRM supported by the GIST=20 > implementation _and_ the=20 > NSLP (implementation, but specification as well).=20 >=20 >=20 > Did I miss something? >=20 > Christian >=20 >=20 >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Aug 30 12:34:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EA94b-0002D0-GX; Tue, 30 Aug 2005 12:34:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EA94a-0002Cq-D3 for nsis@megatron.ietf.org; Tue, 30 Aug 2005 12:34:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22182 for ; Tue, 30 Aug 2005 12:34:53 -0400 (EDT) Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EA969-0005vZ-FN for nsis@ietf.org; Tue, 30 Aug 2005 12:36:34 -0400 Received: from rsys005a.comm.ad.roke.co.uk ([193.118.193.85]) by rsys001x.roke.co.uk (8.12.8/8.12.8) with ESMTP id j7UGYd7g004340; Tue, 30 Aug 2005 17:34:39 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] GIMPS/GIST: Ordering of objects Date: Tue, 30 Aug 2005 17:34:38 +0100 Message-ID: Thread-Topic: [NSIS] GIMPS/GIST: Ordering of objects Thread-Index: AcWqN6IlW8JOQfVUSrWyuTyfE11b3gDSIwdA From: "Hancock, Robert" To: "Christian Dickmann" , X-MailScanner-rsys001x: Found to be clean X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: quoted-printable 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: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org Hi Christian, I'm personally happy with the idea of fixed ordering (maybe more precisely, allowing receivers to assume that the order is fixed). And the ABNF already matches your recommendation to have the MRI first (although I don't recall us analysing the question very much when we decided that).=20 I agree that a better place to say this would be at the start of 5.1 and I've added this as an editorial issue, http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue67 Maybe when it is a bit more prominent there will also be some more technical argument on the subject as well... Cheers, Robert H. > -----Original Message----- > From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On=20 > Behalf Of Christian Dickmann > Sent: 26 August 2005 13:14 > To: nsis@ietf.org > Subject: [NSIS] GIMPS/GIST: Ordering of objects >=20 >=20 > Hi Robert, hi WG, >=20 > at the Interop we talked about the ordering of objects. The=20 > current draft specifies, that the ordering is fixed. The=20 > common feeling was, that there is no need for it to be fixed.=20 > I just want to comment on this topic again. When I wanted to=20 > implement the LooseEnd-ByPass, I=20 > came to the conclusion, that it should be mandatory to have=20 > the MRI as the first object. When=20 > bypass should take place I do not want to parse the complete=20 > message to get the MRM, instead, I want to simply step into=20 > the message and read the MRM field at the fixed position.=20 >=20 > So NSLP Data (we agreed here) and MRI (I do not remember if=20 > we agreed here) should be at fixed positions (end/front=20 > respectively). If we agree on those two, the specification=20 > should really make the complete ordering fixed in my opinion.=20 > But the statement about the ordering should be moved IMHO.=20 > Currently it is the last sentence in the initial text on TLVs=20 > (chapter 5.2.2 TLV Objects "The ABNF given above fixes the=20 > order of objects within a message."). The ABNF itself is given in=20 > chapter 5.1. I think the note should be moved to the=20 > beginning of chapter 5.1, as it is the possition where the=20 > note applies. It in not so much about the TLV objects, but=20 > about the messages and so=20 > to my mind, chapter 5.1 (named GIMPS Messages) is the right=20 > place to put the note. >=20 > Christian Dickmann >=20 >=20 >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Aug 30 19:45:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAFnZ-000220-Ml; Tue, 30 Aug 2005 19:45:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAFnY-00021v-HI for nsis@megatron.ietf.org; Tue, 30 Aug 2005 19:45:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18303 for ; Tue, 30 Aug 2005 19:45:44 -0400 (EDT) Received: from mail121.messagelabs.com ([216.82.241.195]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EAFp7-0001mQ-P3 for nsis@ietf.org; Tue, 30 Aug 2005 19:47:30 -0400 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-8.tower-121.messagelabs.com!1125445519!4954532!2 X-StarScan-Version: 5.4.15; banners=-,-,- X-Originating-IP: [192.128.133.132] Received: (qmail 28641 invoked from network); 30 Aug 2005 23:45:34 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (192.128.133.132) by server-8.tower-121.messagelabs.com with SMTP; 30 Aug 2005 23:45:34 -0000 Received: from kcclust06evs1.ugd.att.com (135.38.164.89) by attrh3i.attrh.att.com (7.2.052) id 4311E0B5000EB010 for nsis@ietf.org; Tue, 30 Aug 2005 19:45:34 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 30 Aug 2005 18:45:33 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA09FA92C5@KCCLUST06EVS1.ugd.att.com> Thread-Topic: [Ieprep] Proposed Revised Charter Thread-Index: AcWtuImURPd9qiqLTrSgKNbEATeKcgAAsTug From: "Ash, Gerald R \(Jerry\), ALABS" To: X-Spam-Score: 0.8 (/) X-Scan-Signature: 48472a944c87678fcfe8db15ffecdfff Content-Transfer-Encoding: quoted-printable Cc: "Ash, Gerald R \(Jerry\), ALABS" Subject: [NSIS] RE: [Ieprep] Proposed Revised Charter 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: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org FYI, note references below to possible NSIS requirements coming out of the IEPREP working group. I had earlier pointed IEPREP to some of the NSIS work relevant to the proposed IEPREP charter http://www1.ietf.org/mail-archive/web/ieprep/current/msg02350.html. Thanks, Jerry -----Original Message----- From: ieprep-bounces@ietf.org [mailto:ieprep-bounces@ietf.org] On Behalf Of King, Kimberly S. Sent: Tuesday, August 30, 2005 7:13 PM To: 'ieprep@ietf.org' Cc: 'sob@harvard.edu'; 'jon.peterson@neustar.biz' Subject: [Ieprep] Proposed Revised Charter Below is an updated proposed charter for WG review. --- Internet Emergency Preparedness (ieprep) Charter =20 Description of Working Group: =20 Effective telecommunications capabilities are imperative to facilitate =20 immediate recovery operations for serious disaster events including =20 natural disasters (e.g., hurricanes, floods, earthquakes) and those =20 created by man (e.g., terrorist attacks, combat situations or wartime =20 events). In addition, related capabilities should be usable in normal =20 command and control operations of military services, which often have =20 timeliness requirements even in peacetime.=20 Disasters can happen any time, any place, unexpectedly. Quick response =20 for recovery operations requires immediate access to any public =20 telecommunications capabilities at hand. These capabilities include: =20 conventional telephone, cellular phones, and Internet access via online terminals, IP telephones, and wireless PDAs. The commercial =20 telecommunications infrastructure is rapidly evolving to Internet-based technology. Therefore, the Internet community needs to consider how it =20 can best support emergency management and recovery operations.=20 The IEPREP WG will address proactive measures to congestion and recovery from various outages using three perspectives:=20 1. A commercial (i.e., or public) telecommunications infrastructure=20 2. A governmental/military or enterprise telecommunications =20 infrastructure that retains sole administration of its own network =20 resources=20 3. A governmental/military telecommunications infrastructure that =20 combines private resources and leverages public infrastructure. This =20 scenario may be subject to local policies, laws, and regulations. =20 Potential disasters for governmental/military infrastructures can =20 extend beyond what might be experienced by the commercial/public sector and can be anticipated to some degree.=20 Proactive mechanisms to address would-be outages are required for each =20 of these cases. =20 Now that the initial documents describe the broad problem space and its salient characteristics have been competed, new efforts will focus on =20 specific requirements and solutions such as those pertaining to the =20 governmental/military sector. For example, a document exists in the =20 Transport Area working group of interest to IEPREP that could satisfy a governmental framework/BCP is draft-ietf-tsvwg-mlpp-that-works-XX. This document will progress to completion in that WG, yet may be the basis of more work in this IEPREP WG. Some additional efforts on the =20 governmental/military track within IEPREP could focus on this TSVWG =20 document, analyze gaps, and provide input where needed. =20 The following are four specific examples that can satisfy the interests of governmental/military (and potentially, =20 commercial/public/enterprise) emergency communications: =20 1. Conveying information about the priority of specific flows (or =20 sessions) that originate in a VoIP environment. This could include a =20 requirements effort to describe extensions to NSIS or RSVP. =20 Requirements for NSIS would be forwarded to the NSIS working group. =20 Requirements for RSVP could be forwarded to tsvwg or worked on in =20 IEPREP. =20 2. Nested VPNs require special considerations for routing and QoS if =20 nodes in the path that make these decisions generally have limited =20 information. =20 3. Some countries require civil networks to preempt sessions under state circumstances, and preemption is considered an absolute requirement in governmental networks in most countries. Unless implementation of these requirements can be objectively shown to threaten network health (via =20 simulation or in operations), then the requirement needs to be =20 considered by IEPREP and specific solutions must be developed. =20 4. Considering robustness of non-real-time applications with =20 preferential treatments, as voice will not be the only application used by IEPREP. =20 In the IETF, considerations for treatment and security of emergency =20 communications stretch across a number of Areas and Working Groups, =20 notably including the various voice/video signaling working groups, =20 instant messaging, and the open Transport Area for path coupled =20 signaling and various operational groups. IEPREP will cooperate closely with these groups and with those outside of the IETF such as various =20 ITU-T study groups. =20 If there is an existing group that can extend a protocol or mechanism, =20 IEPREP will generate only a requirements document for those groups to =20 evaluate. =20 If there is not an existing group that can extend a protocol or =20 mechanism, IEPREP will prepare requirements and discuss the extension =20 of that protocol/mechanism or protocols/mechanisms within IEPREP.=20 =20 Goals and Milestones: =20 Done Submit initial I-D of Requirements =20 Done Submit initial I-D of Framework =20 Done Submit initial I-D of Recommendations BCP =20 Done Submit Requirements I-D to IESG for publication as an =20 Informational RFC =20 Done Submit Framework I-D to IESG for publication as an Informational =20 RFC =20 Oct 05 Submit an initial I-D of Emergency Threats Analysis of =20 Government/Military Networks =20 Dec 05 Submit an initial I-D of Differences between GETS and MLPP =20 Networks =20 Feb 06 Submit an initial I-D of Requirements of Government/Military =20 Networks =20 Mar 06 Submit an initial I-D of Considerations for potential solutions of Government/Military Networks =20 Apr 06 Submit an initial I-D of Mechanisms to be used by =20 Government/Military Networks =20 Oct 05 Submit final I-D of Emergency Threats Analysis of =20 Government/Military Networks to IESG as Informational RFC=20 =20 Feb 06 Submit final I-D of Requirements of Government/Military Networks to IESG as Informational RFC =20 Apr 06 Submit final I-D of Mechanisms to be used by Government/Military Networks to IESG as BCP RFC =20 Dec 06 Submit Recommendations I-D for commercial telecommunications =20 infrastructure to IESG for publication as a BCP =20 The working group will discuss re-chartering if additional efforts are agreed upon by the WG (for example, work items related to protocols =20 outside existing WGs). =20 =20 _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis