From rtg-dir-bounces@ietf.org Tue Aug 08 18:18:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAZuQ-0003uP-4X; Tue, 08 Aug 2006 18:18:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAZuO-0003t3-Tm for rtg-dir@ietf.org; Tue, 08 Aug 2006 18:18:44 -0400 Received: from gateout02.mbox.net ([165.212.64.22]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAZuN-0000x3-JS for rtg-dir@ietf.org; Tue, 08 Aug 2006 18:18:44 -0400 Received: from gateout02.mbox.net (gateout02.mbox.net [165.212.64.22]) by gateout02.mbox.net (Postfix) with ESMTP id 0E06615DC; Tue, 8 Aug 2006 22:18:39 +0000 (GMT) Received: from gateout02.mbox.net [127.0.0.1] by gateout02.mbox.net via mtad (C8.MAIN.3.27X) with ESMTP id 093kHHwsM0062Mo2; Tue, 08 Aug 2006 22:18:38 GMT Received: from gateout02.mbox.net [127.0.0.1] by gateout02.mbox.net via mtad (C8.MAIN.3.27X) with ESMTP id 092kHHwsK0062Mo2; Tue, 08 Aug 2006 22:18:36 GMT X-USANET-Routed: 2 gwsout-vs R:localhost:1825 Received: from GW2.EXCHPROD.USA.NET [165.212.116.254] by gateout02.mbox.net via smtad (C8.MAIN.3.27X); Tue, 08 Aug 2006 22:18:37 GMT X-USANET-Source: 165.212.116.254 IN skh@nexthop.com GW2.EXCHPROD.USA.NET X-USANET-MsgId: XID820kHHwsl8685Xo2 Received: from VS4.EXCHPROD.USA.NET ([10.116.208.141]) by GW2.EXCHPROD.USA.NET with Microsoft SMTPSVC(6.0.3790.1830); Tue, 8 Aug 2006 16:18:36 -0600 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: Tue, 8 Aug 2006 16:18:36 -0600 Message-ID: <6F44D7F6B24A8F4DA0AB46C9BE924F020640A423@VS4.EXCHPROD.USA.NET> In-Reply-To: <5.0.0.25.2.20060726211341.035c62f0@zircon.juniper.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Review of draft-ietf-forces-protocol-08.txt Thread-Index: AcaxGhs4XbG2hPsjQRKVH7Qx9rhbNwKHgVzw From: "Susan Hares" To: "Ross Callon" X-OriginalArrivalTime: 08 Aug 2006 22:18:36.0543 (UTC) FILETIME=[97C460F0:01C6BB38] X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: rtg-dir@ietf.org Subject: RE: Review of draft-ietf-forces-protocol-08.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 Ross: I need to delay this work until August 21 - 26th due to work commitments for the next 2 weeks. It is my vacation week - so I know I can complete the review at that time. Sue -----Original Message----- From: Ross Callon [mailto:rcallon@juniper.net]=20 Sent: Wednesday, July 26, 2006 9:14 PM To: Susan Hares Cc: rtg-dir@ietf.org Subject: RE: Review of draft-ietf-forces-protocol-08.txt At 06:25 AM 7/26/2006 -0600, Susan Hares wrote: >I'll commit to this by 8/11. I've got to clear off old work first. >Will that be soon enough. > >Sue Yes. Thanks. Ross >-----Original Message----- >From: Ross Callon [mailto:rcallon@juniper.net] >Sent: Tuesday, July 25, 2006 11:16 PM >To: Susan Hares; rtg-dir@ietf.org >Subject: RE: Review of draft-ietf-forces-protocol-08.txt > >At 12:21 PM 7/25/2006 -0600, Susan Hares wrote: > >Ross: > > > >I've reviewed this specification for the Forces group. I suspect that > >makes me a "non-valid" reviewer at this time? > > > >Otherwise, I've read it before and can read again. > >I think that your review would be valuable. Given that you have been >keep track of the effort over time, you might have an easier time than >most of us at absorbing the full content of over 100 pages of spec. > >If we can get a second reviewer who is more "neutral" (has not been >involved in the work) then this would be useful also. > >Thanks, Ross > > >-----Original Message----- > >From: Ross Callon [mailto:rcallon@juniper.net] > >Sent: Tuesday, July 25, 2006 2:16 PM > >To: rtg-dir@ietf.org > >Subject: Review of draft-ietf-forces-protocol-08.txt > > > >I am looking for one or two brave people to volunteer to > >review: "ForCES Protocol Specification", > >draft-ietf-forces-protocol-08.txt. > > > >Warning, This is 116 pages long (81 without the appendices), > >so any volunteers will certainly be greatly appreciated! > > > >Thanks, Ross From rtg-dir-bounces@ietf.org Mon Aug 14 07:12:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCaMi-0002Dg-6u; Mon, 14 Aug 2006 07:12:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCaMh-0002Ci-NO for rtg-dir@ietf.org; Mon, 14 Aug 2006 07:12:15 -0400 Received: from alnrmhc13.comcast.net ([206.18.177.53] helo=alnrmhc11.comcast.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GCaCq-0000us-Tw for rtg-dir@ietf.org; Mon, 14 Aug 2006 07:02:07 -0400 Received: from frogbits.attlabs.att.com (c-24-6-155-213.hsd1.ca.comcast.net[24.6.155.213]) by comcast.net (alnrmhc13) with ESMTP id <20060814110204b1300hsvh8e>; Mon, 14 Aug 2006 11:02:04 +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 k7EB1NZt093729 for ; Mon, 14 Aug 2006 04:01:24 -0700 (PDT) (envelope-from fenner@frogbits.attlabs.att.com) Received: (from fenner@localhost) by frogbits.attlabs.att.com (8.13.4/8.13.4/Submit) id k7EB1NWd093728 for rtg-dir@ietf.org; Mon, 14 Aug 2006 04:01:23 -0700 (PDT) (envelope-from fenner) Date: Mon, 14 Aug 2006 04:01:23 -0700 (PDT) Message-Id: <200608141101.k7EB1NWd093728@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: 0e9ebc0cbd700a87c0637ad0e2c91610 Subject: IESG agenda for 2006-08-17 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-08-17). Updated 2:2:29 EDT, August 14, 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 The Session Initiation Protocol (SIP) RAI Conference Bridge Transcoding Model (Proposed Standard) - 1 of 2 draft-ietf-sipping-transc-conf-03.txt [Open Web Ballot] Token: Jon Peterson APP IMAP4 LIST Command Extensions (Proposed Standard) - 2 of 2 draft-ietf-imapext-list-extensions-17.txt [Open Web Ballot] Token: Lisa Dusseault 2.1.2 Returning Item Area Date RTG Graceful Restart Mechanism for BGP (Proposed Standard) - 1 of 1 draft-ietf-idr-restart-13.txt [Open Web Ballot] Token: Bill Fenner 2.2 Individual Submissions 2.2.1 New Item Area Date APP Internet Application Protocol Collation Registry (Proposed Standard) - 1 of 2 draft-newman-i18n-comparator-13.txt [Open Web Ballot] Token: Lisa Dusseault IMAP4 extension to SEARCH command for APP controlling what kind of information is returned (Proposed Standard) - 2 of 2 draft-melnikov-imap-search-ret-03.txt [Open Web Ballot] Token: Ted Hardie 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 Framework for Transcoding with the Session RAI Initiation Protocol (SIP) (Informational) - 1 of 2 draft-ietf-sipping-transc-framework-04.txt [Open Web Ballot] Token: Jon Peterson RTG OAM Requirements for Point-to-Multipoint MPLS Networks (Informational) - 2 of 2 draft-ietf-mpls-p2mp-oam-reqs-01.txt [Open Web Ballot] Token: Ross Callon 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 NONE 3.2.2 Returning Item NONE 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 Area Date GEN LSP Preemption Policies for MPLS Traffic Engineering (Informational) - 1 of 1 draft-deoliveira-diff-te-preemption-05.txt [Open Web Ballot] Token: Ross Callon 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 RAI Aug 10 Session Initiation Protocol (sip) - 1 of 2 Token: Cullen APP Aug 8 Language Tag Registry Update (ltru) - 2 of 2 Token: Ted 4.2.2 Proposed for Approval NONE 5. IAB News We Can Use 6. Management Issues 7. Working Group News From rtg-dir-bounces@ietf.org Mon Aug 28 07:02:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHesd-0003ok-Ml; Mon, 28 Aug 2006 07:02:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHesc-0003oa-B0 for rtg-dir@ietf.org; Mon, 28 Aug 2006 07:02:10 -0400 Received: from alnrmhc13.comcast.net ([204.127.225.93] helo=alnrmhc11.comcast.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GHesa-00005d-Uu for rtg-dir@ietf.org; Mon, 28 Aug 2006 07:02:10 -0400 Received: from frogbits.attlabs.att.com (c-24-6-155-213.hsd1.ca.comcast.net[24.6.155.213]) by comcast.net (alnrmhc13) with ESMTP id <20060828110207b13002vc7he>; Mon, 28 Aug 2006 11:02:08 +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 k7SB1NCw098155 for ; Mon, 28 Aug 2006 04:01:23 -0700 (PDT) (envelope-from fenner@frogbits.attlabs.att.com) Received: (from fenner@localhost) by frogbits.attlabs.att.com (8.13.4/8.13.4/Submit) id k7SB1Nsp098154 for rtg-dir@ietf.org; Mon, 28 Aug 2006 04:01:23 -0700 (PDT) (envelope-from fenner) Date: Mon, 28 Aug 2006 04:01:23 -0700 (PDT) Message-Id: <200608281101.k7SB1Nsp098154@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: b045c2b078f76b9f842d469de8a32de3 Subject: IESG agenda for 2006-08-31 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-08-31). Updated 2:2:38 EDT, August 28, 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 RAI Two-Document ballot: [Open Web Ballot] - 1 of 7 The Message Session Relay Protocol (Proposed Standard) - 1 of 7 draft-ietf-simple-message-sessions-15.txt Relay Extensions for the Message Sessions Relay Protocol (MSRP) (Proposed Standard) draft-ietf-simple-msrp-relays-08.txt Token: Jon Peterson RTG GMPLS - Communication of Alarm Information (Proposed Standard) - 2 of 7 draft-ietf-ccamp-gmpls-alarm-spec-04.txt [Open Web Ballot] Token: Ross Callon RTG Three-Document ballot: [Open Web Ballot] - 3 of 7 Generalized Multiprotocol Label Switching (GMPLS) Label Switching Router (LSR) Management Information Base (Proposed Standard) - 3 of 7 draft-ietf-ccamp-gmpls-lsr-mib-14.txt Definitions of Textual Conventions for Generalized Multiprotocol Label Switching (GMPLS) Management (Proposed Standard) draft-ietf-ccamp-gmpls-tc-mib-10.txt Note: Awaiting update from final MIB review. Generalized Multiprotocol Label Switching (GMPLS) Traffic Engineering Management Information Base (Proposed Standard) draft-ietf-ccamp-gmpls-te-mib-15.txt Note: Awaiting update from final MIB review. Token: Bill Fenner RTG IANA Considerations for OSPF (BCP) - 4 of 7 draft-ietf-ospf-iana-01.txt [Open Web Ballot] Token: Bill Fenner Specifying Alternate Semantics for the TSV Explicit Congestion Notification (ECN) Field (BCP) - 5 of 7 draft-ietf-tsvwg-ecn-alternates-01.txt [Open Web Ballot] Note: PROTO Shepherd: James Polk (jmpolk@cisco.com) Token: Lars Eggert Connecting IPv6 Islands over IPv4 MPLS using RTG IPv6 Provider Edge Routers (6PE) (Proposed Standard) - 6 of 7 draft-ooms-v6ops-bgp-tunnel-06.txt [Open Web Ballot] Note: Despite its filename, this is an *IDR* working group draft. Token: Bill Fenner RAI Two-Document ballot: [Open Web Ballot] - 7 of 7 Media Type Registration of RTP Payload Formats (Proposed Standard) - 7 of 7 draft-ietf-avt-rfc3555bis-04.txt Media Type Registration of Payload Formats in the RTP Profile for Audio and Video Conferences (Proposed Standard) draft-ietf-avt-rfc3555bis-part2-01.txt Token: Cullen Jennings 2.1.2 Returning Item NONE 2.2 Individual Submissions 2.2.1 New Item NONE 2.2.2 Returning Item Area Date APP Calendaring Extensions to WebDAV (CalDAV) (Proposed Standard) - 1 of 2 draft-dusseault-caldav-14.txt [Open Web Ballot] Token: Ted Hardie APP SMTP Submission Service Extension for Future Message Release (Proposed Standard) - 2 of 2 draft-vaudreuil-futuredelivery-04.txt [Open Web Ballot] Note: Last Call ends on June 22, 2006 Token: Ted Hardie 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 INT Goals for Network-based Localized Mobility Management (NETLMM) (Informational) - 1 of 1 draft-ietf-netlmm-nohost-req-04.txt [Open Web Ballot] Token: Jari Arkko 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 SEC EAP Password Authenticated Exchange (Informational) - 1 of 3 draft-clancy-eap-pax-09.txt [Open Web Ballot] Token: Russ Housley RTG RFC 1264 is Obsolete (Informational) - 2 of 3 draft-fenner-obsolete-1264-02.txt [Open Web Ballot] Token: Ross Callon A Uniform Resource Name (URN) Namespace for APP The Near Field Communication Forum (NFC Forum) (Informational) - 3 of 3 draft-abel-nfc-urn-00.txt [Open Web Ballot] Token: Ted Hardie 3.2.2 Returning Item Area Date GEN Apr 11 A Process Experiment in Normative Reference Handling (Experimental) - 1 of 1 draft-klensin-norm-ref-01.txt [Open Web Ballot] Note: RFC 3933 process experiment Token: Brian Carpenter 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 3.3.3 For Action Area Date GEN A Taxonomy and Analysis of Enhancements to Mobile IPv6 Route Optimization (Informational) - 1 of 1 draft-irtf-mobopts-ro-enhancements-08.txt Token: Brian Carpenter 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 NONE 4.2.2 Proposed for Approval Area Date APP Aug 8 Language Tag Registry Update (ltru) - 1 of 1 Token: Ted 5. IAB News We Can Use 6. Management Issues 7. Working Group News From rtg-dir-bounces@ietf.org Tue Aug 29 08:24:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GI2dN-0002Gd-9u; Tue, 29 Aug 2006 08:24:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GI2dL-0002GS-9X for rtg-dir@ietf.org; Tue, 29 Aug 2006 08:23:59 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GI2dH-00029O-Le for rtg-dir@ietf.org; Tue, 29 Aug 2006 08:23:59 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-4.cisco.com with ESMTP; 29 Aug 2006 05:23:46 -0700 X-IronPort-AV: i="4.08,180,1154934000"; d="scan'208"; a="1850896076:sNHT25531105644" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-6.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7TCNk8o022569; Tue, 29 Aug 2006 05:23:46 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k7TCNj6W010254; Tue, 29 Aug 2006 05:23:45 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 29 Aug 2006 05:23:45 -0700 Received: from [10.21.145.148] ([10.21.145.148]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 29 Aug 2006 05:23:44 -0700 Message-ID: <44F3AA49.3010704@cisco.com> Date: Mon, 28 Aug 2006 22:45:29 -0400 From: Acee Lindem User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Dimitri.Papadimitriou@alcatel.be References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Aug 2006 12:23:44.0638 (UTC) FILETIME=[F868A1E0:01C6CB65] DKIM-Signature: a=rsa-sha1; q=dns; l=5676; t=1156854226; x=1157718226; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=acee@cisco.com; z=From:Acee=20Lindem=20 |Subject:Re=3A=20draft-ietf-ccamp-automesh-01.txt; X=v=3Dcisco.com=3B=20h=3DzwYk4LJxT0JkGDKBevId6W19aj4=3D; b=Gsd+WKPL8qaIPMkGb8Zf17VeEtoRYi1mp/0eV8brGGC+2tMzdEMZHDXy18Dk7BV2ZXzXF+mH LX5xOyqBIGLRLOMfi3elFUxBTyjqsdcsMdVLHzNkzpGHwDktaiYrtdIW; Authentication-Results: sj-dkim-6.cisco.com; header.From=acee@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.2 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d Cc: Ross Callon , fenner@research.att.com, rtg-dir@ietf.org Subject: Re: draft-ietf-ccamp-automesh-01.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 Dimitri, Since we recently completed a last call of this document in the OSPF WG and received no additional comments, I decided to take another look. I've also reviewed this document at least twice previously but, judging from section 9, with no "useful" comments ;^). See some comments on your comments inline. Dimitri.Papadimitriou@alcatel.be wrote: > hi ross > > i have a couple points on this doc. > > o) the document does introduce a field to facilitate LSP identification > (name) as part of the routing extension i am concerned by the introduction > of a new LSP identification format / mechanism - if no pointer to RFC 3209 > is provided; > > o) the document mentions that the number of mesh groups is limited but > potentially (depending on encoding) provides for binary encoding for > 2^32-1 groups - how this can be controlled such as to prevent the > resulting behaviour you have described > Actually, the OSPF theoretical limit is much smaller since the new TLV can occur at most once and the length of a single TLV is limited to 2^16 bytes. However, all discussions I've had with the authors indicate that deployments will be limited to a small number of mesh groups (usually 1 and never more than a handful). Is there any reason to doubt this? There are several ways these could have been advertised but now that we've gone this long down this path, I don't think we should change it unless there is a very good reason. > o) the document mentions that "The TE-MESH-GROUP TLV is OPTIONAL and must > at most appear once in a OSPF Router Information LSA or ISIS Router > Capability TLV." but for addition/removal it mentions "conversely, if the > LSR leaves a mesh-group the corresponding entry will be removed from the > TE-MESH-GROUP TLV." what are these "entries" referring to - that there is > a top-level TE-MESH-GROUP TLV with multiple sub-TLVs (but the document > mentions "No sub-TLV is currently defined for the TE-mesh-group TLV") ? > I interpret this to mean that a list of mesh groups is packed in a single TLV. I agree that this should be stated explicitly. To the best of my knowledge, it has been this way from the beginning (although it may have started with a single mesh group). > o) the document mentions that "Note that both operations can be performed > in the context of a single refresh." but this is not a refresh anymore > this becomes a trigger/update > I agree that a better term could be used. I'd prefer "LSA origination". for OSPF. > o) it would be valuable to state exact OSPF applicability since the > Router_Cap document (used by the present doc) covers both v2 and v3 > > o) the term "fairly static" is relative to the OSPF refresh timer ? (i > would ask to refer to periodicity instead) > I interpreted this as referring to the author's view on how often an LSR will be join or leave a mesh group. Thanks, Acee > much thanks, > - dimitri. > > > > > > > Ross Callon > 25/07/2006 18:54 > > To: rtg-dir@ietf.org > cc: rcallon@juniper.net, fenner@research.att.com > Subject: draft-ietf-ccamp-automesh-01.txt > > > I am looking for one or two routing directorate volunteers to > review draft-ietf-ccamp-automesh-01.txt, and/or am looking > for comments on this document. > > To me there seems to be two issues that are worth looking at > (although of course a reviewer may find other things to comment > on). > > One question involves the advisability of piggybacking information > on IGPs. One the one hand in this case the information being > piggybacked is relatively small in volume, and is also quite stable. > Thus the extra load on the IGP seems minimal. On the other hand, > piggybacking on IGPs in general seems to have two issues that > make it more iffy compared to piggybacking on BGP: (i) IGPs have > very tight timing constraints (if a link goes down you want your IGP > to respond quickly, and you also want all routers in an area to update > their routing databases and forwarding tables relatively close to at the > same time to minimize the persistence of microloops); (ii) If the > amount of information grows to the point that it is bothersome, with > BGP the L3VPN framework describes how to partition it into multiple > instances, each of which is only run between those routers which > actually need to know the information being distributed, with IGPs > (OSPF and IS-IS) the same information is flooded to all routers in the > area, including those that don't need it, and it is not obvious to me > how to cleanly partition two instances of an IGP in the same network; > (I have also heard a complaint that IGPs refresh their LSAs periodically, > and thus the piggybacked information also needs to be refreshed -- I > however would expect that refreshes would be rare enough, and > sufficiently spread over time, that this would not be a significant extra > load). > > The other issue that I notice is that the security considerations section > of this document is null ("No new security issues are raised in this > document"). While this may be true (I can't think of any new security > considerations -- if the IGP is compromised then you are in real > trouble with or without this enhancement), if anyone can think of more > to say here this might be a good idea. In fact, it might not be a bad > idea to have a "security considerations with IGPs" document that we > could just refer to (volunteers to write this one?). > > Thanks, Ross > > > > > From rtg-dir-bounces@ietf.org Tue Aug 29 17:43:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIBN5-0004KU-3a; Tue, 29 Aug 2006 17:43:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIBN3-0004ED-Nj for rtg-dir@ietf.org; Tue, 29 Aug 2006 17:43:45 -0400 Received: from mail1.noc.data.net.uk ([80.68.34.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIBN1-0003FG-88 for rtg-dir@ietf.org; Tue, 29 Aug 2006 17:43:45 -0400 Received: from 57-99.dsl.data.net.uk ([80.68.57.99] helo=cortex.aria-networks.com) by mail1.noc.data.net.uk with esmtp (Exim 3.36 #2) id 1GIBN8-0007sj-00 for rtg-dir@ietf.org; Tue, 29 Aug 2006 22:43:50 +0100 Received: from your029b8cecfe ([217.158.132.220] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 29 Aug 2006 22:43:26 +0100 Message-ID: <047701c6cbb4$24e706f0$89849ed9@your029b8cecfe> From: "Adrian Farrel" To: "Acee Lindem" , References: <44F3AA49.3010704@cisco.com> Date: Tue, 29 Aug 2006 22:42:01 +0100 Organization: Old Dog Consulting MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit 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-OriginalArrivalTime: 29 Aug 2006 21:43:27.0102 (UTC) FILETIME=[291DF9E0:01C6CBB4] X-Spam-Score: 0.1 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: Ross Callon , fenner@research.att.com, rtg-dir@ietf.org Subject: Re: draft-ietf-ccamp-automesh-01.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rtg-dir-bounces@ietf.org Hi Acee and Dimitri, Very much appreciate you reviewing this. We did get a couple of comments from IS-IS so we have something to think about. See in line (suitably snipped) > Since we recently completed a last call of this document in the OSPF WG > and received no additional comments, I decided to take another look. > I've also reviewed this document at least twice previously but, judging > from section 9, with no "useful" comments ;^). Oh, is that what the Acknowledgments section is for? >> o) the document mentions that the number of mesh groups is limited but >> potentially (depending on encoding) provides for binary encoding for >> 2^32-1 groups - how this can be controlled such as to prevent the >> resulting behaviour you have described > Actually, the OSPF theoretical limit is much smaller since the new TLV can > occur at most > once and the length of a single TLV is limited to 2^16 bytes. However, all > discussions I've > had with the authors indicate that deployments will be limited to a small > number of mesh > groups (usually 1 and never more than a handful). Is there any reason to > doubt this? Hmmm. 1. Whenever we say something like that, history proves us wrong. 2. There is a proposal to use mesh groups for P2MP membership discovery. Essentially, each P2MP LSP will behave as a mesh group. (Hint: I want to kill that idea!) > There are several ways these could have been advertised but now that we've > gone this > long down this path, I don't think we should change it unless there is a > very good > reason. > >> o) the term "fairly static" is relative to the OSPF refresh timer ? (i >> would ask to refer to periodicity instead) > I interpreted this as referring to the author's view on how often an LSR > will be > join or leave a mesh group. Yeah, that is my take, too. I really don't like these relativistic statements when they are not quantified. It would be best to state it relative to the OSPF refresh timer. For example: "This mechanism SHOULD NOT be used if LSRs join or leave a mesh group more frequently than the OSPF refresh timer." Thoughts? A From rtg-dir-bounces@ietf.org Tue Aug 29 17:46:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIBPK-0004gm-4k; Tue, 29 Aug 2006 17:46:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIBPI-0004gh-G9 for rtg-dir@ietf.org; Tue, 29 Aug 2006 17:46:04 -0400 Received: from mail2.noc.data.net.uk ([80.68.34.49]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIBPG-0003PM-Sp for rtg-dir@ietf.org; Tue, 29 Aug 2006 17:46:04 -0400 Received: from 57-99.dsl.data.net.uk ([80.68.57.99] helo=cortex.aria-networks.com) by mail2.noc.data.net.uk with esmtp (Exim 3.36 #1) id 1GIBPB-0006I0-00 for rtg-dir@ietf.org; Tue, 29 Aug 2006 22:45:57 +0100 Received: from your029b8cecfe ([217.158.132.220] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 29 Aug 2006 22:46:00 +0100 Message-ID: <048601c6cbb4$80929640$89849ed9@your029b8cecfe> From: "Adrian Farrel" To: "Adrian Farrel" , "Acee Lindem" , Date: Tue, 29 Aug 2006 22:45:44 +0100 Organization: Old Dog Consulting MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit 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-OriginalArrivalTime: 29 Aug 2006 21:46:00.0837 (UTC) FILETIME=[84C01350:01C6CBB4] X-Spam-Score: 0.1 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: Ross Callon , fenner@research.att.com, rtg-dir@ietf.org Subject: Re: draft-ietf-ccamp-automesh-01.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rtg-dir-bounces@ietf.org Oh, one other thing: can we get these comments out into the CCAMP WG? They can be anonymised through me or Ross, if you like. A ----- Original Message ----- From: "Adrian Farrel" To: "Acee Lindem" ; Cc: "Ross Callon" ; ; Sent: Tuesday, August 29, 2006 10:42 PM Subject: Re: draft-ietf-ccamp-automesh-01.txt > Hi Acee and Dimitri, > > Very much appreciate you reviewing this. > We did get a couple of comments from IS-IS so we have something to think > about. > > See in line (suitably snipped) > >> Since we recently completed a last call of this document in the OSPF WG >> and received no additional comments, I decided to take another look. >> I've also reviewed this document at least twice previously but, judging >> from section 9, with no "useful" comments ;^). > > Oh, is that what the Acknowledgments section is for? > >>> o) the document mentions that the number of mesh groups is limited but >>> potentially (depending on encoding) provides for binary encoding for >>> 2^32-1 groups - how this can be controlled such as to prevent the >>> resulting behaviour you have described >> Actually, the OSPF theoretical limit is much smaller since the new TLV >> can occur at most >> once and the length of a single TLV is limited to 2^16 bytes. However, >> all discussions I've >> had with the authors indicate that deployments will be limited to a small >> number of mesh >> groups (usually 1 and never more than a handful). Is there any reason to >> doubt this? > > Hmmm. > 1. Whenever we say something like that, history proves us wrong. > 2. There is a proposal to use mesh groups for P2MP membership discovery. > Essentially, each P2MP LSP will behave as a mesh group. > (Hint: I want to kill that idea!) > >> There are several ways these could have been advertised but now that >> we've gone this >> long down this path, I don't think we should change it unless there is a >> very good >> reason. >> >>> o) the term "fairly static" is relative to the OSPF refresh timer ? (i >>> would ask to refer to periodicity instead) >> I interpreted this as referring to the author's view on how often an LSR >> will be >> join or leave a mesh group. > > Yeah, that is my take, too. > I really don't like these relativistic statements when they are not > quantified. > It would be best to state it relative to the OSPF refresh timer. > For example: "This mechanism SHOULD NOT be used if LSRs join or leave a > mesh group more frequently than the OSPF refresh timer." > > Thoughts? > > A From rtg-dir-bounces@ietf.org Wed Aug 30 03:33:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIKZG-0001Mt-Fo; Wed, 30 Aug 2006 03:32:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIKZF-0001Mo-LS for rtg-dir@ietf.org; Wed, 30 Aug 2006 03:32:57 -0400 Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIKZE-0002gh-6g for rtg-dir@ietf.org; Wed, 30 Aug 2006 03:32:57 -0400 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id k7U7Wsxh005754; Wed, 30 Aug 2006 09:32:54 +0200 In-Reply-To: <047701c6cbb4$24e706f0$89849ed9@your029b8cecfe> To: Adrian Farrel MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Dimitri.Papadimitriou@alcatel.be Date: Wed, 30 Aug 2006 09:32:48 +0200 X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 08/30/2006 09:32:52, Serialize complete at 08/30/2006 09:32:52 Content-Type: text/plain; charset="US-ASCII" X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 X-Spam-Score: 0.2 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Cc: fenner@research.att.com, Ross Callon , Acee Lindem , rtg-dir@ietf.org Subject: Re: draft-ietf-ccamp-automesh-01.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 adrian sensible imho - comments can be shared now i would like to see your opinion on "> o) the document does introduce a field to facilitate LSP identification > (name) as part of the routing extension i am concerned by the introduction > of a new LSP identification format / mechanism - if no pointer to RFC 3209 > is provided;" per 3209, we have 3 tuples to identify sessions (+ session name in session attribute) per 3209, we have 5 tuples to identify LSPs so my interpretation from the text that the "tail-end" field is a TE LSP group name - but is that correct ? - ps: subsidiary question - is it suitable to exchange LSP names via routing ? - opinions ? "Adrian Farrel" 29/08/2006 23:42 Please respond to Adrian Farrel To: "Acee Lindem" , Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL cc: Ross Callon , fenner@research.att.com, rtg-dir@ietf.org Subject: Re: draft-ietf-ccamp-automesh-01.txt Hi Acee and Dimitri, Very much appreciate you reviewing this. We did get a couple of comments from IS-IS so we have something to think about. See in line (suitably snipped) > Since we recently completed a last call of this document in the OSPF WG > and received no additional comments, I decided to take another look. > I've also reviewed this document at least twice previously but, judging > from section 9, with no "useful" comments ;^). Oh, is that what the Acknowledgments section is for? >> o) the document mentions that the number of mesh groups is limited but >> potentially (depending on encoding) provides for binary encoding for >> 2^32-1 groups - how this can be controlled such as to prevent the >> resulting behaviour you have described > Actually, the OSPF theoretical limit is much smaller since the new TLV can > occur at most > once and the length of a single TLV is limited to 2^16 bytes. However, all > discussions I've > had with the authors indicate that deployments will be limited to a small > number of mesh > groups (usually 1 and never more than a handful). Is there any reason to > doubt this? Hmmm. 1. Whenever we say something like that, history proves us wrong. 2. There is a proposal to use mesh groups for P2MP membership discovery. Essentially, each P2MP LSP will behave as a mesh group. (Hint: I want to kill that idea!) > There are several ways these could have been advertised but now that we've > gone this > long down this path, I don't think we should change it unless there is a > very good > reason. > >> o) the term "fairly static" is relative to the OSPF refresh timer ? (i >> would ask to refer to periodicity instead) > I interpreted this as referring to the author's view on how often an LSR > will be > join or leave a mesh group. Yeah, that is my take, too. I really don't like these relativistic statements when they are not quantified. It would be best to state it relative to the OSPF refresh timer. For example: "This mechanism SHOULD NOT be used if LSRs join or leave a mesh group more frequently than the OSPF refresh timer." Thoughts? A