From rtg-dir-bounces@ietf.org Fri Dec 01 07:33:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gq7Zi-00085T-0O; Fri, 01 Dec 2006 07:33:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gq7Zg-00085B-UM; Fri, 01 Dec 2006 07:33:04 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gq7Zf-0006Ts-Jn; Fri, 01 Dec 2006 07:33:04 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by sj-iport-5.cisco.com with ESMTP; 01 Dec 2006 04:33:01 -0800 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id kB1CX0d5006428; Fri, 1 Dec 2006 07:33:00 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kB1CX0YJ020969; Fri, 1 Dec 2006 07:33:00 -0500 (EST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Dec 2006 07:33:00 -0500 Received: from [10.86.104.179] ([10.86.104.179]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Dec 2006 07:32:59 -0500 In-Reply-To: <200612010243.kB12hPqt062617@workhorse.brookfield.occnc.com> References: <200612010243.kB12hPqt062617@workhorse.brookfield.occnc.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <285A9D7C-8A64-46CE-89CF-0C26B98F995E@cisco.com> Content-Transfer-Encoding: 7bit From: JP Vasseur Date: Fri, 1 Dec 2006 07:32:57 -0500 To: curtis@occnc.com X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 01 Dec 2006 12:32:59.0772 (UTC) FILETIME=[D61FDBC0:01C71544] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1975; t=1164976380; x=1165840380; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[OSPF]=20Re=3A=20[Fwd=3A=20[mpls]=20WG=20Last=20Call= 20on=20draft-ietf-mpls-number-0-bw-te-lsps-02.txt]=20 |Sender:=20 |To:=20curtis@occnc.com; bh=Aih36499HOqTosU68vGgaifJmeykdrE2zf+LpD6bJwA=; b=Dv50bfzdt5V0lMNb/IfV4mQLV5IURuJCiA9pc5nKDPteqInPVIw14kzknlpqktU0AvoXGYRr o44VcMHzVDoYMsf3mFDuvpmmVa4hgeJ1KlA1nrRsp2Dd4ZzHdTaiVceC; Authentication-Results: rtp-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: George Swallow , rtg-dir@ietf.org, isis-wg@ietf.org, ospf@ietf.org, David Ward , Loa Andersson , Acee Lindem Subject: Re: [OSPF] Re: [Fwd: [mpls] WG Last Call on draft-ietf-mpls-number-0-bw-te-lsps-02.txt] X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rtg-dir-bounces@ietf.org On Nov 30, 2006, at 9:43 PM, Curtis Villamizar wrote: > > In message <133D69D4-43D7-46D0-88E5-80FD8CB25CCF@cisco.com> > JP Vasseur writes: >> >> Hi Curtis, >> >> On Nov 30, 2006, at 8:48 PM, Curtis Villamizar wrote: >> >>> >>> In message <4354A088-B93C-457F-93FD-55B8EB4A861A@cisco.com> >>> JP Vasseur writes: >>>> >>>> Other attributes such as affinity should be used to not allows 0-bw >>>> TE LSP to traverse a specific link. This TLV is only used to report >>>> the number of such TE LSPs traversing the link. >>>> >>>> Thanks. >>>> >>>> JP. >>> >>> >>> The provider already has the necessary tools that can be used to >>> accomplish this. If a general purpose tool (attributes and >>> affinities) is available which accomplishes something a special >>> purpose tool to accomplish the same thing is not needed. >>> >>> Such a tool would only be useful if the administration of the MPLS >>> midpoint (where the attribute is set) had no control over the >>> administration of the MPLS ingress or a border that is doing route >>> computation (where the affinity is set). I don't see any >>> anticipated >>> real world deployment that would benefit from this. If you do, then >>> please explain the deployment scenario. >>> >> >> not sure to see your point here ... I was mentioning that the aim of >> this TLV was not to avoid some links. >> Looks like you're saying the same thing. >> >> JP. >> >>> Curtis > > > My point was regarding a mention in that conversation that the value > of zero might mean no zero-BW LSPs have been set up or none are > allowed. Looks like I cut the wrong paragraph out of the > conversation. > > The existing link attributes and affinity are sufficient to indicate > the condition that no zero-BW LSPs are allowed if the administration > of that network decides to use an attribute for that purpose. > > I'm agreeing with you. great, thanks. Cheers. JP. > > Curtis From rtg-dir-bounces@ietf.org Fri Dec 01 08:44:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gq8h9-00048W-O7; Fri, 01 Dec 2006 08:44:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpxKo-0005qE-HL; Thu, 30 Nov 2006 20:37:02 -0500 Received: from [69.37.59.173] (helo=workhorse.brookfield.occnc.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpxKn-0005O6-5w; Thu, 30 Nov 2006 20:37:02 -0500 Received: from workhorse.brookfield.occnc.com (localhost [127.0.0.1]) by workhorse.brookfield.occnc.com (8.13.4/8.13.4) with ESMTP id kB11m8o2061362; Thu, 30 Nov 2006 20:48:08 -0500 (EST) (envelope-from curtis@workhorse.brookfield.occnc.com) Message-Id: <200612010148.kB11m8o2061362@workhorse.brookfield.occnc.com> To: JP Vasseur In-reply-to: Your message of "Thu, 30 Nov 2006 14:29:49 EST." <4354A088-B93C-457F-93FD-55B8EB4A861A@cisco.com> Date: Thu, 30 Nov 2006 20:48:08 -0500 From: Curtis Villamizar X-Spam-Score: 0.1 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 X-Mailman-Approved-At: Fri, 01 Dec 2006 08:44:50 -0500 Cc: George Swallow , rtg-dir@ietf.org, isis-wg@ietf.org, ospf@ietf.org, David Ward , Loa Andersson , Acee Lindem Subject: Re: [OSPF] Re: [Fwd: [mpls] WG Last Call on draft-ietf-mpls-number-0-bw-te-lsps-02.txt] X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: curtis@occnc.com List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rtg-dir-bounces@ietf.org In message <4354A088-B93C-457F-93FD-55B8EB4A861A@cisco.com> JP Vasseur writes: > > Other attributes such as affinity should be used to not allows 0-bw > TE LSP to traverse a specific link. This TLV is only used to report > the number of such TE LSPs traversing the link. > > Thanks. > > JP. The provider already has the necessary tools that can be used to accomplish this. If a general purpose tool (attributes and affinities) is available which accomplishes something a special purpose tool to accomplish the same thing is not needed. Such a tool would only be useful if the administration of the MPLS midpoint (where the attribute is set) had no control over the administration of the MPLS ingress or a border that is doing route computation (where the affinity is set). I don't see any anticipated real world deployment that would benefit from this. If you do, then please explain the deployment scenario. Curtis From rtg-dir-bounces@ietf.org Fri Dec 01 08:44:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gq8h9-00048u-Qj; Fri, 01 Dec 2006 08:44:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gpy8w-0000tO-U9; Thu, 30 Nov 2006 21:28:50 -0500 Received: from [69.37.59.173] (helo=workhorse.brookfield.occnc.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gpy8v-0006Vi-Hc; Thu, 30 Nov 2006 21:28:50 -0500 Received: from workhorse.brookfield.occnc.com (localhost [127.0.0.1]) by workhorse.brookfield.occnc.com (8.13.4/8.13.4) with ESMTP id kB12hPqt062617; Thu, 30 Nov 2006 21:43:25 -0500 (EST) (envelope-from curtis@workhorse.brookfield.occnc.com) Message-Id: <200612010243.kB12hPqt062617@workhorse.brookfield.occnc.com> To: JP Vasseur In-reply-to: Your message of "Thu, 30 Nov 2006 20:53:21 EST." <133D69D4-43D7-46D0-88E5-80FD8CB25CCF@cisco.com> Date: Thu, 30 Nov 2006 21:43:25 -0500 From: Curtis Villamizar X-Spam-Score: 0.1 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 X-Mailman-Approved-At: Fri, 01 Dec 2006 08:44:50 -0500 Cc: George Swallow , rtg-dir@ietf.org, isis-wg@ietf.org, curtis@occnc.com, ospf@ietf.org, David Ward , Loa Andersson , Acee Lindem Subject: Re: [OSPF] Re: [Fwd: [mpls] WG Last Call on draft-ietf-mpls-number-0-bw-te-lsps-02.txt] X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: curtis@occnc.com List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rtg-dir-bounces@ietf.org In message <133D69D4-43D7-46D0-88E5-80FD8CB25CCF@cisco.com> JP Vasseur writes: > > Hi Curtis, > > On Nov 30, 2006, at 8:48 PM, Curtis Villamizar wrote: > > > > > In message <4354A088-B93C-457F-93FD-55B8EB4A861A@cisco.com> > > JP Vasseur writes: > >> > >> Other attributes such as affinity should be used to not allows 0-bw > >> TE LSP to traverse a specific link. This TLV is only used to report > >> the number of such TE LSPs traversing the link. > >> > >> Thanks. > >> > >> JP. > > > > > > The provider already has the necessary tools that can be used to > > accomplish this. If a general purpose tool (attributes and > > affinities) is available which accomplishes something a special > > purpose tool to accomplish the same thing is not needed. > > > > Such a tool would only be useful if the administration of the MPLS > > midpoint (where the attribute is set) had no control over the > > administration of the MPLS ingress or a border that is doing route > > computation (where the affinity is set). I don't see any anticipated > > real world deployment that would benefit from this. If you do, then > > please explain the deployment scenario. > > > > not sure to see your point here ... I was mentioning that the aim of > this TLV was not to avoid some links. > Looks like you're saying the same thing. > > JP. > > > Curtis My point was regarding a mention in that conversation that the value of zero might mean no zero-BW LSPs have been set up or none are allowed. Looks like I cut the wrong paragraph out of the conversation. The existing link attributes and affinity are sufficient to indicate the condition that no zero-BW LSPs are allowed if the administration of that network decides to use an attribute for that purpose. I'm agreeing with you. Curtis From rtg-dir-bounces@ietf.org Thu Dec 07 21:07:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsV9W-0007PB-PG; Thu, 07 Dec 2006 21:07:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsV9V-0007Oz-Ej; Thu, 07 Dec 2006 21:07:53 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsV9T-0001q2-3c; Thu, 07 Dec 2006 21:07:53 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by sj-iport-4.cisco.com with ESMTP; 07 Dec 2006 18:07:50 -0800 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id kB827nk7021536; Thu, 7 Dec 2006 21:07:49 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id kB827nDM006145; Thu, 7 Dec 2006 21:07:49 -0500 (EST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Dec 2006 21:07:49 -0500 Received: from [10.86.104.179] ([10.86.104.179]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Dec 2006 21:07:48 -0500 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: JP Vasseur Date: Thu, 7 Dec 2006 21:07:45 -0500 To: "Les Ginsberg \(ginsberg\)" X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 08 Dec 2006 02:07:48.0911 (UTC) FILETIME=[A8CCF3F0:01C71A6D] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2020; t=1165543669; x=1166407669; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Isis-wg]=20Re=3A=20[Fwd=3A=20[mpls]=20WG=20Last=20Ca ll=20ondraft-ietf-mpls-number-0-bw-te-lsps-02.txt] |Sender:=20 |To:=20=22Les=20Ginsberg=20\(ginsberg\)=22=20; bh=alNIcAXgWvky8DXrSZ/XnEA9JObFfBTAb4obJgqrKhY=; b=Tc4IMt3l2yV7M8LKz/hAlhHpxvsc/q7qRNlKVx49tEE+69ca4uOLPQXQ7YzpRVfi9F+Aix3U oxmSRjSZTkP6bnJUTquFOmxOMxRugA/tssgAuyP1adqAdaGU5GSxbqK2; Authentication-Results: rtp-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: "George Swallow \(swallow\)" , rtg-dir@ietf.org, Loa Andersson , isis-wg@ietf.org, ospf@ietf.org Subject: Re: [Isis-wg] Re: [Fwd: [mpls] WG Last Call ondraft-ietf-mpls-number-0-bw-te-lsps-02.txt] X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rtg-dir-bounces@ietf.org Hi Les, Your comments definitely make sense, thanks. I'll respin a new revision very soon, this time the last one. Thanks. JP. On Dec 7, 2006, at 8:46 PM, Les Ginsberg ((ginsberg)) wrote: > JP - > > Sorry for the very belated comments - but I do have two minor, but > still > important, concerns regarding IS-IS. > > Both are in Section 3.1. > > 1)You have specified a 32 bit value for the number of unconstrained TE > LSPs. I would prefer that this be a 16 bit value. This still provides > ample range and given the 255 octet limit for a TLV, it is > worthwhile to > be prudent in our use of encoding space. And, unlike OSPF, there is no > benefit in IS-IS to attempts to align fields on a natural boundary. > Whether you want to change OSPF encoding to match is not required > and is > left up to you and OSPF folks to decide. > > So > Length (1 octet): 4 > > becomes > > Length (1 octet): 2 > > And > > Value (4 octets): number of unconstrained TE LSP(s) signalled > across > the link. > > Becomes > > Value (2 octets): number of unconstrained TE LSP(s) signalled > across > the link. > > 2)Remove the following sentence from the first paragraph of Section > 3.1: > > "If a second instance of the Number of > 0-bandwidth TE LSP(s) sub-TLV is present, the receiving system MUST > only process the first instance of the sub-TLV." > > In cases where a TLV may move from one LSP fragment to another (for > example because of the addition of information which exceeds the > carrying capacity of the original LSP fragment) a router may have > multiple copies of the same TLV as a transient condition. It is > impossible to know which of the copies is newer and therefore > impossible > to deterministically decide which is the first instance of a > subTLV. So > it is better to leave the behavior in this case as undefined. > > Thanx - and once again my apologies for the very late review. > > Les > From rtg-dir-bounces@ietf.org Fri Dec 08 10:25:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gshb0-0001CM-NT; Fri, 08 Dec 2006 10:25:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsUp2-0007eO-4R; Thu, 07 Dec 2006 20:46:44 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsUp0-0005Iy-QB; Thu, 07 Dec 2006 20:46:44 -0500 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-4.cisco.com with ESMTP; 07 Dec 2006 17:46:42 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id kB81kfe2028012; Thu, 7 Dec 2006 17:46:41 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id kB81kbWC010601; Thu, 7 Dec 2006 17:46:41 -0800 (PST) Received: from xmb-sjc-222.amer.cisco.com ([128.107.191.106]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Dec 2006 17:46:37 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 7 Dec 2006 17:46:37 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isis-wg] Re: [Fwd: [mpls] WG Last Call ondraft-ietf-mpls-number-0-bw-te-lsps-02.txt] Thread-Index: AccT81/XiICnmTiZSr2qcnqjTzVEswGdWjrw From: "Les Ginsberg \(ginsberg\)" To: "Jean Philippe Vasseur \(jvasseur\)" X-OriginalArrivalTime: 08 Dec 2006 01:46:37.0952 (UTC) FILETIME=[B3400000:01C71A6A] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1688; t=1165542401; x=1166406401; c=relaxed/simple; s=sjdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ginsberg@cisco.com; z=From:=20=22Les=20Ginsberg=20\(ginsberg\)=22=20 |Subject:=20RE=3A=20[Isis-wg]=20Re=3A=20[Fwd=3A=20[mpls]=20WG=20Last=20Ca ll=20ondraft-ietf-mpls-number-0-bw-te-lsps-02.txt] |Sender:=20; bh=W/PRbQFPcFLZ2kxfShOF2DUv6RkYA4yIKeRCCE6JaZU=; b=CvoBQgsWUWq4PbhmNSfKgsuzTB+QpN6yJ7LX2poPG7XW8P8HQhNEnIWEU/+6n5qI+65tjrR+ 9N1mluNKO1Xg9hJkSRW++wcWtiU4rXWSna2XhWWI2+CQO5V2yVWEySaY; Authentication-Results: sj-dkim-1; header.From=ginsberg@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 X-Mailman-Approved-At: Fri, 08 Dec 2006 10:25:04 -0500 Cc: "George Swallow \(swallow\)" , rtg-dir@ietf.org, Loa Andersson , isis-wg@ietf.org, ospf@ietf.org Subject: RE: [Isis-wg] Re: [Fwd: [mpls] WG Last Call ondraft-ietf-mpls-number-0-bw-te-lsps-02.txt] X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rtg-dir-bounces@ietf.org JP - Sorry for the very belated comments - but I do have two minor, but still important, concerns regarding IS-IS. Both are in Section 3.1. 1)You have specified a 32 bit value for the number of unconstrained TE LSPs. I would prefer that this be a 16 bit value. This still provides ample range and given the 255 octet limit for a TLV, it is worthwhile to be prudent in our use of encoding space. And, unlike OSPF, there is no benefit in IS-IS to attempts to align fields on a natural boundary. Whether you want to change OSPF encoding to match is not required and is left up to you and OSPF folks to decide. So Length (1 octet): 4 becomes Length (1 octet): 2 And Value (4 octets): number of unconstrained TE LSP(s) signalled across the link. Becomes Value (2 octets): number of unconstrained TE LSP(s) signalled across the link. 2)Remove the following sentence from the first paragraph of Section 3.1: "If a second instance of the Number of 0-bandwidth TE LSP(s) sub-TLV is present, the receiving system MUST only process the first instance of the sub-TLV." In cases where a TLV may move from one LSP fragment to another (for example because of the addition of information which exceeds the carrying capacity of the original LSP fragment) a router may have multiple copies of the same TLV as a transient condition. It is impossible to know which of the copies is newer and therefore impossible to deterministically decide which is the first instance of a subTLV. So it is better to leave the behavior in this case as undefined. Thanx - and once again my apologies for the very late review. Les From rtg-dir-bounces@ietf.org Mon Dec 11 07:04:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gtjsu-00004v-SZ; Mon, 11 Dec 2006 07:03:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gtjst-0008UL-LP for rtg-dir@ietf.org; Mon, 11 Dec 2006 07:03:51 -0500 Received: from sccrmhc13.comcast.net ([204.127.200.83]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gtjss-0004Xb-A5 for rtg-dir@ietf.org; Mon, 11 Dec 2006 07:03:51 -0500 Received: from frogbits.attlabs.att.com (c-67-188-114-134.hsd1.ca.comcast.net[67.188.114.134]) by comcast.net (sccrmhc13) with ESMTP id <20061211120339013008sufce>; Mon, 11 Dec 2006 12:03:49 +0000 Received: from frogbits.attlabs.att.com (localhost [127.0.0.1]) by frogbits.attlabs.att.com (8.13.4/8.13.4) with ESMTP id kBBC01lX074358 for ; Mon, 11 Dec 2006 04:00:01 -0800 (PST) (envelope-from fenner@frogbits.attlabs.att.com) Received: (from fenner@localhost) by frogbits.attlabs.att.com (8.13.4/8.13.4/Submit) id kBBC01Zq074357 for rtg-dir@ietf.org; Mon, 11 Dec 2006 04:00:01 -0800 (PST) (envelope-from fenner) Date: Mon, 11 Dec 2006 04:00:01 -0800 (PST) Message-Id: <200612111200.kBBC01Zq074357@frogbits.attlabs.att.com> From: fenner@research.att.com (Bill Fenner) To: rtg-dir@ietf.org (Routing Area Directorate) X-Spam-Score: 0.1 (/) X-Scan-Signature: 03fb21b15d5177c512a4caa19876f30a Subject: IESG agenda for 2006-12-14 telechat. X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rtg-dir-bounces@ietf.org IESG Agenda Good approximation of what will be included in the Agenda of next Telechat (2006-12-14). Updated 2:2:38 EDT, December 11, 2006 ----------------------------------------------------------------------- 1. Administrivia 1.1 Roll Call 1.2 Bash the Agenda 1.3 Approval of the Minutes of the past telechat 1.4 List of Remaining Action Items from Last Telechat 1.5 Review of Projects 2. Protocol Actions Reviews should focus on these questions: "Is this document a reasonable basis on which to build the salient part of the Internet infrastructure? If not, what changes would make it so?" 2.1 WG Submissions 2.1.1 New Item Area Date TSV TCP Extended Statistics MIB (Proposed Standard) - 1 of 9 draft-ietf-tsvwg-tcp-mib-extension-13.txt [Open Web Ballot] Note: PROTO Document Shepherd: James Polk MIB Doctors: Dan Romascanu, Bert Wijnen Token: Lars Eggert RTG Multi-Topology (MT) Routing in OSPF (Proposed Standard) - 2 of 9 draft-ietf-ospf-mt-07.txt [Open Web Ballot] Note: The PROTO shepherd is Acee Lindem Token: Bill Fenner RTG Exclude Routes - Extension to RSVP-TE (Proposed Standard) - 3 of 9 draft-ietf-ccamp-rsvp-te-exclude-route-06.txt [Open Web Ballot] Token: Ross Callon Security Preconditions for Session RAI Description Protocol (SDP) Media Streams (Proposed Standard) - 4 of 9 draft-ietf-mmusic-securityprecondition-03.txt [Open Web Ballot] Token: Jon Peterson Declarative Public Extension Key for iSCSI TSV Node Architecture (Proposed Standard) - 5 of 9 draft-ietf-ips-iscsi-nodearch-key-03.txt [Open Web Ballot] Note: Document Shepherd: David Black (Black_David@emc.com) Token: Lars Eggert TSV Padding Chunk and Parameter for SCTP (Proposed Standard) - 6 of 9 draft-ietf-tsvwg-sctp-padding-02.txt [Open Web Ballot] Note: PROTO Document Shepherd: James Polk Token: Lars Eggert SEC DomainKeys Identified Mail (DKIM) Signatures (Proposed Standard) - 7 of 9 draft-ietf-dkim-base-07.txt [Open Web Ballot] Token: Russ Housley RTG Extensions to RSVP-TE for Point-to-Multipoint TE LSPs (Proposed Standard) - 8 of 9 draft-ietf-mpls-rsvp-te-p2mp-06.txt [Open Web Ballot] Token: Ross Callon TSV The RObust Header Compression (ROHC) Framework (Proposed Standard) - 9 of 9 draft-ietf-rohc-rfc3095bis-framework-04.txt [Open Web Ballot] Token: Magnus Westerlund 2.1.2 Returning Item Area Date OPS RADIUS Delegated-IPv6-Prefix Attribute (Proposed Standard) - 1 of 1 draft-ietf-radext-delegated-prefix-05.txt [Open Web Ballot] Note: PROTO Shepherd: Bernard Aboba Back on the agenda to check whether Mark's concerns have been addressed. Token: David Kessens 2.2 Individual Submissions 2.2.1 New Item Area Date Change Process for Multiprotocol Label RTG Oct 12 Switching (MPLS) and Generalized MPLS (GMPLS) Protocols and Procedures (BCP) - 1 of 1 draft-andersson-rtg-gmpls-change-07.txt [Open Web Ballot] Note: Brian shepherds on behalf of the Routing ADs Token: Brian Carpenter 2.2.2 Returning Item NONE 3. Document Actions 3.1 WG Submissions Reviews should focus on these questions: "Is this document a reasonable contribution to the area of Internet engineering which it covers? If not, what changes would make it so?" 3.1.1 New Item Area Date TCP Friendly Rate Control (TFRC): the TSV Small-Packet (SP) Variant (Experimental) - 1 of 4 draft-ietf-dccp-tfrc-voip-07.txt [Open Web Ballot] Note: PROTO Document Shepherd: Gorry Fairhurst Token: Lars Eggert Requirements for Accounting, Authentication OPS and Authorization in Well Managed IP Multicasting Services (Informational) - 2 of 4 draft-ietf-mboned-maccnt-req-04.txt [Open Web Ballot] Note: Marshall Eubanks is the Document Shepherd Token: David Kessens Hash and Stuffing: Overlooked Factors in OPS Network Device Benchmarking (Informational) - 3 of 4 draft-ietf-bmwg-hash-stuffing-07.txt [Open Web Ballot] Note: Al Morton is the Document Shepherd Token: David Kessens OPS Using IPsec to Secure IPv6-in-IPv4 Tunnels (Informational) - 4 of 4 draft-ietf-v6ops-ipsec-tunnels-04.txt [Open Web Ballot] Note: Fred Baker is the document shepherd Token: David Kessens 3.1.2 Returning Item NONE 3.2 Individual Submissions Via AD Reviews should focus on these questions: "Is this document a reasonable contribution to the area of Internet engineering which it covers? If not, what changes would make it so?" 3.2.1 New Item Area Date TSV IPv4 Fragmentation Considered Very Harmful (Informational) - 1 of 1 draft-heffner-frag-harmful-03.txt [Open Web Ballot] Token: Lars Eggert 3.2.2 Returning Item Area Date An IPv6 Prefix for Overlay Routable INT Cryptographic Hash Identifiers (ORCHID) (Experimental) - 1 of 1 draft-laganier-ipv6-khi-05.txt [Open Web Ballot] Note: Back on the agenda to review input from 2nd LC and decide next steps. Token: Jari Arkko 3.3 Individual Submissions Via RFC Editor The IESG will use RFC 3932 responses: 1) The IESG has not found any conflict between this document and IETF work; 2) The IESG thinks that this work is related to IETF work done in WG , but this does not prevent publishing; 3) The IESG thinks that publication is harmful to work in WG and recommends not publishing at this time; 4) The IESG thinks that this document violates the IETF procedures for and should therefore not be published without IETF review and IESG approval; 5) The IESG thinks that this document extends an IETF protocol in a way that requires IETF review and should therefore not be published without IETF review and IESG approval. Other matters may be recorded in comments to be passed on to the RFC Editor as community review of the document. 3.3.1 New Item NONE 3.3.2 Returning Item NONE 4. Working Group Actions 4.1 WG Creation 4.1.1 Proposed for IETF Review NONE 4.1.2 Proposed for Approval NONE 4.2 WG Rechartering 4.2.1 Under evaluation for IETF Review Area Date INT Nov 26 Mobility for IPv4 (mip4) - 1 of 1 Token: Jari 4.2.2 Proposed for Approval Area Date RAI Oct 19 Internet Emergency Preparedness (ieprep) - 1 of 1 Token: Jon 5. IAB News We Can Use 6. Management Issues 6.1 First two IONs ready for public comment (Brian Carpenter) 7. Working Group News