From rtg-dir-bounces@ietf.org Mon Sep 04 06:04:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKBJT-0001Id-Jn; Mon, 04 Sep 2006 06:04:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKBJR-0001IY-PW for rtg-dir@ietf.org; Mon, 04 Sep 2006 06:04:17 -0400 Received: from [80.86.78.228] (helo=smtp.testbed.se) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GKBJQ-0001aR-6R for rtg-dir@ietf.org; Mon, 04 Sep 2006 06:04:17 -0400 Received: from gw.imc.kth.se ([193.10.152.67] helo=[172.16.2.189]) by fw.testbed.se with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.43) id 1GKBJI-0002FK-DF; Mon, 04 Sep 2006 12:04:12 +0200 Message-ID: <44FBF987.2010809@pi.se> Date: Mon, 04 Sep 2006 12:01:43 +0200 From: Loa Andersson Organization: Acreo AB User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: ospf@ietf.org, isis-wg@ietf.org, rtg-dir@ietf.org X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -1.4 (-) X-Spam-Report: -1.4 ALL_TRUSTED Passed through trusted hosts only via SMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: George Swallow Subject: [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 All, the MPLS working group want to notify the ospf and is-s working groups, as well as the routing directorate that we are currently doing a wg last call on draft-ietf-mpls-number-0-bw-te-lsps-02.txt. Loa and George -------- Original Message -------- Subject: [mpls] WG Last Call on draft-ietf-mpls-number-0-bw-te-lsps-02.txt Date: Fri, 01 Sep 2006 10:08:10 +0200 From: Loa Andersson Organization: Acreo AB To: mpls@ietf.org Working Group, this initiates a two week working group last call on draft-ietf-mpls-number-0-bw-te-lsps-02.txt The wg last call ends on September 17. Please send comments to the working group mailing list and/or the working group chairs. /Loa and George -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.se _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.se From rtg-dir-bounces@ietf.org Mon Sep 11 07:02:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMjYP-00026R-Ce; Mon, 11 Sep 2006 07:02:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMjYN-00026B-Q7 for rtg-dir@ietf.org; Mon, 11 Sep 2006 07:02:15 -0400 Received: from alnrmhc14.comcast.net ([204.127.225.94] helo=alnrmhc11.comcast.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GMjYN-0007jP-Db for rtg-dir@ietf.org; Mon, 11 Sep 2006 07:02:15 -0400 Received: from frogbits.attlabs.att.com (c-24-6-155-213.hsd1.ca.comcast.net[24.6.155.213]) by comcast.net (alnrmhc14) with ESMTP id <20060911110204b14001ni92e>; Mon, 11 Sep 2006 11:02:14 +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 k8BB1NXA086966 for ; Mon, 11 Sep 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 k8BB1N3P086965 for rtg-dir@ietf.org; Mon, 11 Sep 2006 04:01:23 -0700 (PDT) (envelope-from fenner) Date: Mon, 11 Sep 2006 04:01:23 -0700 (PDT) Message-Id: <200609111101.k8BB1N3P086965@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: c2e58d9873012c90703822e287241385 Subject: IESG agenda for 2006-09-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-09-14). Updated 2:2:39 EDT, September 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 GIST: General Internet Signaling Transport (Proposed Standard) - 1 of 7 draft-ietf-nsis-ntlp-11.txt [Open Web Ballot] Note: WG Shepherd: John Loughney (john.loughney@nokia.com) Token: Magnus Westerlund Connecting IPv6 Islands over IPv4 MPLS using RTG IPv6 Provider Edge Routers (6PE) (Proposed Standard) - 2 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 Registration Event Package Extension for RAI Session Initiation Protocol (SIP) Globally Routable User Agent URIs (GRUU) (Proposed Standard) - 3 of 7 draft-ietf-sipping-gruu-reg-event-06.txt [Open Web Ballot] Token: Jon Peterson SEC The Kerberos V5 ("GSSAPI") SASL mechanism (Proposed Standard) - 4 of 7 draft-ietf-sasl-gssapi-08.txt [Open Web Ballot] Token: Sam Hartman APP SIEVE Email Filtering: Spamtest and Virustest Extensions (Proposed Standard) - 5 of 7 draft-ietf-sieve-spamtestbis-05.txt Token: Lisa Dusseault GEN Aug 22 RFC 3978 Update to recognize the IETF Trust (BCP) - 6 of 7 draft-ietf-ipr-ietf-trust-update-03.txt [Open Web Ballot] Token: Brian Carpenter Forward Error Correction Grouping Semantics in RAI Session Description Protocol (Proposed Standard) - 7 of 7 draft-ietf-mmusic-fec-grouping-05.txt [Open Web Ballot] Note: PROTO shepherd is Colin Token: Cullen Jennings 2.1.2 Returning Item Area Date RAI The ENUM Dip Indicator parameter for the "tel" URI (Proposed Standard) - 1 of 1 draft-ietf-iptel-tel-enumdi-05.txt [Open Web Ballot] Note: Proto Shepherd: Jonathan Rosenberg Token: Cullen Jennings 2.2 Individual Submissions 2.2.1 New Item Area Date GEN vCard Extensions for Instant Messaging (IM) (Proposed Standard) - 1 of 3 draft-jennings-impp-vcard-07.txt Token: Lisa Dusseault SEC Integrity Transform Carrying Roll-over Counter (Proposed Standard) - 2 of 3 draft-lehtovirta-srtp-rcc-05.txt [Open Web Ballot] Note: PROTO Shepherd: Lakshminath Dondeti Token: Russ Housley GEN Procedures for protocol extensions and variations (BCP) - 3 of 3 draft-carpenter-protocol-extensions-02.txt [Open Web Ballot] Token: Ross Callon 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 INT Mobile IPv4 Regional Registration (Experimental) - 1 of 5 draft-ietf-mip4-reg-tunnel-03.txt [Open Web Ballot] Token: Jari Arkko RAI ENUM Validation Architecture (Informational) - 2 of 5 draft-ietf-enum-validation-arch-04.txt [Open Web Ballot] Token: Jon Peterson Framework and Requirements for Layer 1 RTG Virtual Private Networks (Informational) - 3 of 5 draft-ietf-l1vpn-framework-04.txt [Open Web Ballot] Token: Ross Callon SEC Using OpenPGP keys for TLS authentication (Experimental) - 4 of 5 draft-ietf-tls-openpgp-keys-11.txt [Open Web Ballot] Token: Russ Housley SEC Desired Enhancements to GSSAPI Version 3 Naming (Informational) - 5 of 5 draft-ietf-kitten-gss-naming-05.txt [Open Web Ballot] Token: Russ Housley 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 Jan 11 The RC4-HMAC Kerberos Encryption Types Used by Microsoft Windows (Informational) - 1 of 5 draft-jaganathan-rc4-hmac-03.txt [Open Web Ballot] Note: The expert has reviewed the draft and sent comments to the author. I believe a revised ID is required to address these comments. Token: Sam Hartman INT IPv6 Router Advertisement Option for DNS Configuration (Experimental) - 2 of 5 draft-jeong-dnsop-ipv6-dns-discovery-09.txt [Open Web Ballot] Token: Mark Townsley INT The Protected One-Time Password Protocol (EAP-POTP) (Informational) - 3 of 5 draft-nystrom-eap-potp-06.txt [Open Web Ballot] Token: Jari Arkko An IPv6 Prefix for Overlay Routable INT Cryptographic Hash Identifiers (ORCHID) (Experimental) - 4 of 5 draft-laganier-ipv6-khi-05.txt [Open Web Ballot] Token: Jari Arkko SEC OMA BCAST MIKEY General Extension Payload Specification (Informational) - 5 of 5 draft-dondeti-msec-mikey-genext-oma-02.txt [Open Web Ballot] Token: Russ Housley 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 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 Sep 7 Mobility for IPv6 (mip6) - 1 of 1 Token: Jari 4.2.2 Proposed for Approval NONE 5. IAB News We Can Use 6. Management Issues 6.1 Review EDU charter (Brian Carpenter) 7. Working Group News From rtg-dir-bounces@ietf.org Mon Sep 11 10:42:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMmzv-000507-I6; Mon, 11 Sep 2006 10:42:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMmzt-0004xV-PX; Mon, 11 Sep 2006 10:42:53 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GMmzs-0006qe-BN; Mon, 11 Sep 2006 10:42:53 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-1.cisco.com with ESMTP; 11 Sep 2006 07:42:51 -0700 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-8.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k8BEgpIv017997; Mon, 11 Sep 2006 07:42:51 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k8BEgpw7014258; Mon, 11 Sep 2006 07:42:51 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 11 Sep 2006 07:42:51 -0700 Received: from [127.0.0.1] ([171.68.225.134]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 Sep 2006 07:42:50 -0700 User-Agent: Microsoft-Entourage/11.2.5.060620 Date: Mon, 11 Sep 2006 09:42:48 -0500 From: David Ward To: Loa Andersson , , , , David Ward Message-ID: Thread-Topic: [Fwd: [mpls] WG Last Call on draft-ietf-mpls-number-0-bw-te-lsps-02.txt] Thread-Index: AcbVsIzPy1DsLEGjEduLFQAKlcR7kg== In-Reply-To: <44FBF987.2010809@pi.se> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 11 Sep 2006 14:42:50.0807 (UTC) FILETIME=[8E7BB470:01C6D5B0] DKIM-Signature: a=rsa-sha1; q=dns; l=1018; t=1157985771; x=1158849771; c=relaxed/relaxed; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dward@cisco.com; z=From:David=20Ward=20 |Subject:Re=3A=20[Fwd=3A=20[mpls]=20WG=20Last=20Call=20on=0A=20draft-ietf-mpls-nu mber-0-bw-te-lsps-02.txt]; X=v=3Dcisco.com=3B=20h=3DAy4P/bIijwCk4Su6Z7kuKSDqq7s=3D; b=uMp+rnYtVCOLZo55wYqno80+cqlFQYU7+5BBvkv5ytwT43yNiE2xLzDw3Yevw9nEKt97Co10 KjU9eouABVh3fHOoXlo72K1UOKrMcslwFlEKwOLbyHt6cg8pjTAFLSIT; Authentication-Results: sj-dkim-8.cisco.com; header.From=dward@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: George Swallow Subject: 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 Do you want our WG to review? Co-Last Call (as we have for other WG that affect our protocol)? Do you have a desired date for end of last call from the IGPs? Thanks -DWard On 9/4/06 5:01 AM, "Loa Andersson" wrote: > All, > > the MPLS working group want to notify the ospf and is-s > working groups, as well as the routing directorate that > we are currently doing a wg last call on > draft-ietf-mpls-number-0-bw-te-lsps-02.txt. > > Loa and George > > > -------- Original Message -------- > Subject: [mpls] WG Last Call on draft-ietf-mpls-number-0-bw-te-lsps-02.txt > Date: Fri, 01 Sep 2006 10:08:10 +0200 > From: Loa Andersson > Organization: Acreo AB > To: mpls@ietf.org > > Working Group, > > this initiates a two week working group last call on > draft-ietf-mpls-number-0-bw-te-lsps-02.txt > > The wg last call ends on September 17. > > Please send comments to the working group mailing list and/or > the working group chairs. > > /Loa and George From rtg-dir-bounces@ietf.org Thu Sep 14 11:20:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNt14-0004iZ-JT; Thu, 14 Sep 2006 11:20:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNt0f-0004Ow-Gl for rtg-dir@ietf.org; Thu, 14 Sep 2006 11:20:13 -0400 Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNstR-0006yt-2o for rtg-dir@ietf.org; Thu, 14 Sep 2006 11:12:46 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id k8EFCi1Z068129; Thu, 14 Sep 2006 08:12:44 -0700 (PDT) (envelope-from rcallon@juniper.net) Received: from rcallon-lt1.juniper.net ([172.23.1.61]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id k8EFChg78045; Thu, 14 Sep 2006 08:12:43 -0700 (PDT) (envelope-from rcallon@juniper.net) Message-Id: <5.0.0.25.2.20060914110925.037c5240@zircon.juniper.net> X-Sender: rcallon@zircon.juniper.net X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Thu, 14 Sep 2006 11:12:37 -0400 To: rtg-dir@ietf.org From: Ross Callon Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: rcallon@juniper.net, fenner@research.att.com Subject: Review of draft-ietf-nsis-ntlp-11 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 Has anyone reviewed, or is anyone willing to review for the routing directorate: "GIST: General Internet Signaling Transport" draft-ietf-nsis-ntlp-11.txt? This was originally on the agenda for today's IESG telechat. I have put a DEFER on it, which gives us two weeks to review it. In general I don't like to DEFER a document for more than two weeks unless there is a *very* good reason. Thanks, Ross From rtg-dir-bounces@ietf.org Sat Sep 16 16:00:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOgLM-0005IC-E9; Sat, 16 Sep 2006 16:00:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOgLL-0005I7-38 for rtg-dir@ietf.org; Sat, 16 Sep 2006 16:00:51 -0400 Received: from mail1.noc.data.net.uk ([80.68.34.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GOfRi-0002Ee-8V for rtg-dir@ietf.org; Sat, 16 Sep 2006 15:03:25 -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 1GOfRr-0002zb-00 for rtg-dir@ietf.org; Sat, 16 Sep 2006 20:03:31 +0100 Received: from your029b8cecfe ([217.158.132.63] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 16 Sep 2006 20:03:06 +0100 Message-ID: <093e01c6d9c2$b3868c20$0a23fea9@your029b8cecfe> From: "Adrian Farrel" To: , "Ross Callon" References: <5.0.0.25.2.20060914110925.037c5240@zircon.juniper.net> Date: Sat, 16 Sep 2006 20:01:57 +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: 16 Sep 2006 19:03:08.0767 (UTC) FILETIME=[BF9406F0:01C6D9C2] X-Spam-Score: 0.1 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: rcallon@juniper.net, fenner@research.att.com Subject: Re: Review of draft-ietf-nsis-ntlp-11 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 I guess the new recruit should be the first to volunteer. This is a truly enormous draft :-( I have time to look at it toward the end of the week. If a response by the end of 9/22 is OK, then I'll have a go. A ----- Original Message ----- From: "Ross Callon" To: rtg-dir@ietf.org Cc: ; Sent: Thursday, September 14, 2006 4:12 PM Subject: Review of draft-ietf-nsis-ntlp-11 > Has anyone reviewed, or is anyone willing to review for the > routing directorate: "GIST: General Internet Signaling Transport" > draft-ietf-nsis-ntlp-11.txt? > > This was originally on the agenda for today's IESG telechat. I > have put a DEFER on it, which gives us two weeks to review > it. In general I don't like to DEFER a document for more than > two weeks unless there is a *very* good reason. > > Thanks, Ross > > > > > From rtg-dir-bounces@ietf.org Fri Sep 22 10:20:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQlsq-0001Yw-2B; Fri, 22 Sep 2006 10:20:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQlso-0001YZ-Ia for rtg-dir@ietf.org; Fri, 22 Sep 2006 10:20:02 -0400 Received: from mail2.noc.data.net.uk ([80.68.34.49]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQlsn-0006Wb-Pa for rtg-dir@ietf.org; Fri, 22 Sep 2006 10:20:02 -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 1GQlsZ-0004a2-00 for rtg-dir@ietf.org; Fri, 22 Sep 2006 15:19:48 +0100 Received: from your029b8cecfe ([217.158.132.175] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 22 Sep 2006 15:19:47 +0100 Message-ID: <10f301c6de52$19336140$0a23fea9@your029b8cecfe> From: "Adrian Farrel" To: Date: Fri, 22 Sep 2006 15:18:56 +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: 8bit 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: 22 Sep 2006 14:19:47.0731 (UTC) FILETIME=[28A64E30:01C6DE52] X-Spam-Score: 0.1 (/) X-Scan-Signature: 83867a50fd8f547996ccdaf89af24437 Subject: Fw: Routing Directorate comments on draft-ietf-ccamp-automesh-01 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 Trying with the right address! ----- Original Message ----- From: "Adrian Farrel" To: Sent: Thursday, September 21, 2006 5:05 PM Subject: Fw: Routing Directorate comments on draft-ietf-ccamp-automesh-01 > Hi, > > I can't recall who originated which comments. I think they came from > Dimitri, Acee, and me. > > I will copy the Directorate on my response to JP. Perhaps anyone who has > any further issues could follow-up direct? > > Thanks, > Adrian > ----- Original Message ----- > From: "JP Vasseur" > To: "Adrian Farrel" > Cc: ; "Ross Callon" > Sent: Thursday, September 21, 2006 1:32 PM > Subject: Re: Routing Directorate comments on draft-ietf-ccamp-automesh-01 > > > Hi Adrian, > > On Sep 2, 2006, at 9:25 AM, Adrian Farrel wrote: > >> Hi, >> >> We held an additional last call for this draft in the IGP working >> groups and received some further comments that JP has just >> addressed in a new revision. >> >> We have also received some comments from a review in the Routing >> Directorate that I am précising below. JP, authors: please look >> through these and let us know your proposals for dealing with them. >> > > Sure, in line. > >> Thanks, >> Adrian >> >> === >> >> 1) The Tail-end name field facilitates LSP identification. Is this >> a new form of LSP identification? >> If it is not new, then there should be a reference to RFC3209 and a >> statement of which RFC3209 fields are mapped to this IGP field. >> If it is not new then there is a significant concern that a new >> identification is being introduced when it is not needed. > > As indicated in the document the string refers to a "Tail-end" name, > not an TE LSP name: thus it does not replace the session name of the > SESSION-ATTRIBUTE object defined in RFC3209. > >> >> 2) 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 (although this might be constrained by OSPF's limit >> of a TLV size to 2^16 bytes. >> The document (and the authors) state that scaling of these >> extensions is not an issue because only a small number of mesh >> groups are likely to be in existence in a network, and any one >> router is unlikely to participate in more than a very few. >> There are two concerns: >> a) Whenever we say that something in the Internet is limited, >> history usually proves us wrong. > > And that's undoubtedly a good news :-) > >> Indeed, there is already a >> proposal (draft-leroux-mpls-p2mp-te-autoleaf-01.txt) that uses a >> similar mechanism for a problem that would have far more groups. > > Two comments: > - Mesh groups are used to set up TE LSP meshes. If we consider let > say 10 meshes comprising 100 routers each, that gives us 99,000 TE > LSPs. One can easily see that the number of meshes is unlikely to > explode in a foreseeable future. If it turns out to be the case, > we'll have other scalability issues to fix before any potential with > the IGP. > - More importantly, the dynamics of joining a TE mesh is such that > IGP updates are used to advertise to TE mesh group membership change > (join or prune), which are indeed expected to be very unfrequent. > >> b) The I-D does not itself impose any reasonable limits on the >> number of groups with the potential for a single router (by >> misconfiguration, design, or malice) advertising a very large >> number of groups. >> Thus, it appears that the scaling concerns are not properly >> addressed in this I-D. >> > > Not sure to see the point here. If indeed, a large number of TE MESH > GROUPs were advertised, this would not impact the other LSRs since > they would not create any new TE LSPs trying to join the new TE-MESH- > GROUP. In term of amount of flooded information, this should not be a > concern either (handled by routing). We clarified this in the > security section. > >> 3) 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") ? >> >> AF>> My comment on this is that the definition of the TLVs seems >> unclear. >> AF>> From figure 2, it appears that some additional information can be >> AF>> present in the TLV after the fields listed, and (reading >> between the >> AF>> lines) it would appear that this additional information is a >> series of >> AF>> repeats of the set of fields to define multiple mesh groups. >> AF>> This could usefully be clarified considerably. >> > > You're absolutely right. The figures have been modified: > > (example show below): > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | mesh-group-number 1 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Tail-end IPv4 address 1 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Name length | Tail-end name 1 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > // / > / > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | mesh-group-number n | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Tail-end IPv4 address n | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Name length | Tail-end name n | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure 2 - OSPF TE-MESH-GROUP TLV format (IPv4 Address) > > >> AF>> >> AF>> But it is now unclear to me whether a single router can be a >> member >> AF>> of IPv4 an IPv6 mesh groups. It would seem that these cannot be >> AF>> mixed within a single TLV, and multiple TLVs (one IPv4 and one >> AF>> IPv6) are prohibited. > > OK the text requires some clarification. What is prohibited is to > have two IPv4 sub-TLV or two IPv6 sub-TLV but one of each is > permitted. New proposed text to clarify: > > The TE-MESH-GROUP TLV is OPTIONAL and at most one IPv4 instance and > one IPv6 instance MUST appear in a OSPF Router Information LSA or > ISIS Router Capability TLV. If the OSPF TE-MESH-GROUP TLV (IPv4 or > IPv6) occurs more than once within the OSPF Router Information LSA, > only the first instance is processed, subsequent TLV(s) will be > silently ignored. Similarly, If the ISIS TE-MESH-GROUP sub-TLV (IPv4 > or IPv6) occurs more than once within the ISIS Router capability TLV, > only the first instance is processed, subsequent TLV(s) will be > silently ignored. > >> >> 4) Small terminology issue in section 5.1 it says: "Note that both >> operations can be performed in the context of a single refresh." >> This is not a refresh. It is a trigger/update. A better term for >> OSPF would be "LSA origination". >> > > OK fixed (I used the term "Update"), thanks. > >> 5) Please state the applicability to OSPF v2 and or v3. Note that >> the Router_Cap document covers both v2 and v3 > > Indeed, Thanks for the comments. The OSPFv3 aspects have been > incorporated. Here is the new text: > > The TE-MESH-GROUP TLV is advertised within an OSPF Router > Information > opaque LSA (opaque type of 4, opaque ID of 0) for OSPFv2 ([RFC2328]) > and within a new LSA (Router Information LSA) for OSPFv3 > ([RFC2740]). > > ... > > As defined in [RFC2370] for OSPVv2 and in [RFC2740] for OSPFv3, the > flooding scope of the Router Information LSA is determined by the > LSA > Opaque type for OSPFv2 and the values of the S1/S2 bits for OSPFv3. > > For OSPFv2 Router Information opaque LSA: > > - Link-local scope: type 9; > > - Area-local scope: type 10; > > - Routing-domain scope: type 11. In this case, the flooding > scope is > equivalent to the Type 5 LSA flooding scope. > > For OSPFv3 Router Information LSA: > > - Link-local scope: OSPFV3 Router Information LSA with the S1 and S2 > bits cleared; > > - Area-local scope: OSPFV3 Router Information LSA with the S1 bit > set > and the S2 bit cleared; > > - Routing-domain scope: OSPFv3 Router Information LSA with S1 bit > cleared and the S2 bit set. > > A router may generate multiple OSPF Router Information LSAs with > different flooding scopes. The TE-MESH-GROUP TLV may be advertised > within an Area-local or Routing-domain scope Router Information LSA > depending on the MPLS TE mesh group profile: > > - If the MPLS TE mesh-group is contained within a single area (all > the LSRs of the mesh-group are contained within a single area), the > TE-MESH-GROUP TLV MUST be generated within an Area-local Router > Information LSA; > > - If the MPLS TE mesh-group spans multiple OSPF areas, the TE mesh- > group TLV MUST be generated within a Routing-domain scope router > information LSA. > >> >> 6) The term "fairly static" at the end of section 5.1 is >> meaningless without some relative context. >> Presumably this relates to the number times an LSR joins or leaves >> a mesh group over time. >> Is it intended to be relative to the IGP refresh period? >> Please clarify in an objective rather than a subjective way. >> > > Right, this requires clarification. Here is the new text: Moreover, > TE mesh-group membership should not change frequently: each time an > LSR joins or leaves a new TE mesh-group. > > I guess that this is sufficiently explicit: it is a well-known fact > that LSRs are infrequently added or removed to a TE mesh. > >> 7) The security section (section 8) is inadequate and will >> undoubtedly be rejected by the security ADs. At the very least, the >> I-D needs a paragraph (i.e. more than one or two lines) explaining >> why there are no new security considerations. But what would be the >> impact of adding false mesh groups to a TLV? Is there anything >> (dangerous) that can be learned about the network by inspecting >> mesh group TLVs? >> > > The following section has been added: > > No new security issues are raised in this document. Any new > security > issues raised by the procedures in this document depend upon the > opportunity for LSAs/LSPs to be snooped, the ease/difficulty of > which > has not been altered. Security considerations are covered in > [RFC2328] and [RFC2740] for the base OSPF protocol and in [RFC1194] > for IS-IS. As the LSPs may now contain additional information > regarding router capabilities, this new information would also > become > available. Note that intentional or unintentional advertisement of > "fake" TE Mesh Groups by an LSR A does not have any impact on other > LSRs since an LSR B would only try to signal a TE LSP torward that > advertizing LSR A to join the advertized TE Mesh TE Group if and > only > if such TE Mesh Group is also locally configured on LSR B. > > + new references added. > > > Does that address the comments ? > > Thanks. > > JP. From rtg-dir-bounces@ietf.org Fri Sep 22 10:20:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQlt4-0001eN-60; Fri, 22 Sep 2006 10:20:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQlt0-0001cp-P5 for rtg-dir@ietf.org; Fri, 22 Sep 2006 10:20:14 -0400 Received: from mail2.noc.data.net.uk ([80.68.34.49]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQlt0-0006kj-2O for rtg-dir@ietf.org; Fri, 22 Sep 2006 10:20:14 -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 1GQlsw-0004eL-00 for rtg-dir@ietf.org; Fri, 22 Sep 2006 15:20:10 +0100 Received: from your029b8cecfe ([217.158.132.175] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 22 Sep 2006 15:20:07 +0100 Message-ID: <110101c6de52$30f0a680$0a23fea9@your029b8cecfe> From: "Adrian Farrel" To: Date: Fri, 22 Sep 2006 15:19:21 +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: 22 Sep 2006 14:20:08.0538 (UTC) FILETIME=[350D33A0:01C6DE52] X-Spam-Score: 0.1 (/) X-Scan-Signature: f0b5a4216bfa030ed8a6f68d1833f8ae Subject: Fw: Routing Directorate comments on draft-ietf-ccamp-automesh-01 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 Also this one. ----- Original Message ----- From: "Adrian Farrel" To: "JP Vasseur" Cc: ; "Ross Callon" ; Sent: Thursday, September 21, 2006 5:48 PM Subject: Re: Routing Directorate comments on draft-ietf-ccamp-automesh-01 > Hi JP, > > Thanks for addressing the comments. I have forwarded these to the Routing > Directorate and copied them on this email to let them respond if they > want. But here are my comments: > >>> 1) The Tail-end name field facilitates LSP identification. Is this >>> a new form of LSP identification? >>> If it is not new, then there should be a reference to RFC3209 and a >>> statement of which RFC3209 fields are mapped to this IGP field. >>> If it is not new then there is a significant concern that a new >>> identification is being introduced when it is not needed. >> >> As indicated in the document the string refers to a "Tail-end" name, >> not an TE LSP name: thus it does not replace the session name of the >> SESSION-ATTRIBUTE object defined in RFC3209. > > Hmmm, yes it is not an LSP name, but recall that the LSP is identified by > a combination of Session and Sender Template, and that the Session > includes the destination IP address. In Section 3.2 I see: > - A Tail-end name: string used to ease the TE-LSP naming. > and in Section 4.1: > - A Tail-end name: a variable length field used to facilitate the TE > LSP identification. > > These definitions seem to imply that the tail-end name is used as an > identifier for the LSP. The question that will be asked is: How does this > identification of an LSP differ from the conventional identification of > the LSP? Given that you also have: > - A Tail-end address: an IPv4 or IPv6 IP address to be used as a > tail-end TE LSP address by other LSRs belonging to the same mesh- > group > it appears that the tail-name is superfluous information. > > So, perhaps the name is present for diagnostic purposes? Perhaps it is > there to ease OAM? But it does not seem to play any role in the protocol > procedures as it is not explicitly mentioned later in the I-D (e.g. > Section 5). > > How would a node behave if it received a mesh group advertisement that > indicated a tail-end address that did not appear to match its record of > the tail-end name? > >>> 2) 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 (although this might be constrained by >>> OSPF's limit of a TLV size to 2^16 bytes. >>> The document (and the authors) state that scaling of these >>> extensions is not an issue because only a small number of mesh >>> groups are likely to be in existence in a network, and any one >>> router is unlikely to participate in more than a very few. >>> There are two concerns: >>> a) Whenever we say that something in the Internet is limited, >>> history usually proves us wrong. >> >> And that's undoubtedly a good news :-) >> >>> Indeed, there is already a >>> proposal (draft-leroux-mpls-p2mp-te-autoleaf-01.txt) that uses a >>> similar mechanism for a problem that would have far more groups. >> >> Two comments: >>- Mesh groups are used to set up TE LSP meshes. If we consider let >> say 10 meshes comprising 100 routers each, that gives us 99,000 TE >> LSPs. One can easily see that the number of meshes is unlikely to >> explode in a foreseeable future. If it turns out to be the case, >> we'll have other scalability issues to fix before any potential with >> the IGP. > > What about 100 meshes comprising 10 routers each? > I make that only 9,000 TE LSPs. > > So clearly the scaling of MPLS-TE is not directly related to the scaling > of automesh. > > What this comes down to is your statement about how automesh will be used. > I think we can all accept that this is the problem space that you intend > to deploy in, and that is great. But the original point from the Routing > Directorate was that there is nothing in the I-D that imposes this > restriction. So how can we say that the protocol extensions will scale? > >> - More importantly, the dynamics of joining a TE mesh is such that >> IGP updates are used to advertise to TE mesh group membership change >> (join or prune), which are indeed expected to be very unfrequent. > > Again, the concern raised is that the problem space you intend to deploy > in is, indeed, limited in this way. All good. But how can we say whether > the protocol extensions will be used differently in the future? What > controls are there over constructing a mesh where joins and prunes are > frequent? > >>> b) The I-D does not itself impose any reasonable limits on the >>> number of groups with the potential for a single router (by >>> misconfiguration, design, or malice) advertising a very large >>> number of groups. >>> Thus, it appears that the scaling concerns are not properly >>> addressed in this I-D. >> >>Not sure to see the point here. If indeed, a large number of TE MESH >>GROUPs were advertised, this would not impact the other LSRs since >>they would not create any new TE LSPs trying to join the new TE-MESH- >>GROUP. In term of amount of flooded information, this should not be a >>concern either (handled by routing). We clarified this in the >>security section. > > The impact on the other LSRs is exactly flooding question. Covering that > in the security section is fine for the misconfiguration and malice cases. > >>> 3) 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") ? >>> >>> AF>> My comment on this is that the definition of the TLVs seems >>> AF>> unclear. >>> AF>> From figure 2, it appears that some additional information can be >>> AF>> present in the TLV after the fields listed, and (reading >>> AF>> between the lines) it would appear that this additional >>> AF>> information is a series of repeats of the set of fields to >>> AF>> define multiple mesh groups. >>> AF>> This could usefully be clarified considerably. >> >> >> You're absolutely right. The figures have been modified: >> >> (example show below): > > [SNIP] > Looks good to me. > >>> AF>> But it is now unclear to me whether a single router can be a >>> AF>> member of IPv4 an IPv6 mesh groups. It would seem that >>> AF>> these cannot be mixed within a single TLV, and multiple >>> AF>> TLVs (one IPv4 and one IPv6) are prohibited. >> >> OK the text requires some clarification. What is prohibited is to >> have two IPv4 sub-TLV or two IPv6 sub-TLV but one of each is >> permitted. New proposed text to clarify: >> >> The TE-MESH-GROUP TLV is OPTIONAL and at most one IPv4 instance and >> one IPv6 instance MUST appear in a OSPF Router Information LSA or >> ISIS Router Capability TLV. If the OSPF TE-MESH-GROUP TLV (IPv4 or >> IPv6) occurs more than once within the OSPF Router Information LSA, >> only the first instance is processed, subsequent TLV(s) will be >> silently ignored. Similarly, If the ISIS TE-MESH-GROUP sub-TLV (IPv4 >> or IPv6) occurs more than once within the ISIS Router capability TLV, >> only the first instance is processed, subsequent TLV(s) will be >> silently ignored. > > OK. That's fine. > I think you want to make a couple of changes: > - "at most one instance MUST appear" is ambiguous since it will > be confused with "an instance MUST appear". I suggest you > reword as "MUST NOT include more than one of each of" > - "If the OSPF TE-MESH-GROUP TLV (IPv4 or IPv6) occurs > more than once" should really be phrased as "If the either the > IPv4 or IPv6 OSPF TE-MESH-GROUP TLV occurs more > than once". Ditto for the IS-IS sub-TLV. > - Two instances of "will be silently ignored" should read "SHOULD > be silently ignored" > >>> 4) Small terminology issue in section 5.1 it says: "Note that both >>> operations can be performed in the context of a single refresh." >>> This is not a refresh. It is a trigger/update. A better term for >>> OSPF would be "LSA origination". >> >>OK fixed (I used the term "Update"), thanks. > > OK > >>> 5) Please state the applicability to OSPF v2 and or v3. Note that >>> the Router_Cap document covers both v2 and v3 >> >>Indeed, Thanks for the comments. The OSPFv3 aspects have been >>incorporated. Here is the new text: > > [SNIP] > OK > >>> 6) The term "fairly static" at the end of section 5.1 is >>> meaningless without some relative context. >>> Presumably this relates to the number times an LSR joins or leaves >>> a mesh group over time. >>> Is it intended to be relative to the IGP refresh period? >>> Please clarify in an objective rather than a subjective way. >> >> >> Right, this requires clarification. Here is the new text: Moreover, >> TE mesh-group membership should not change frequently: each time an >> LSR joins or leaves a new TE mesh-group. > > I could live with this, personally. We'll see whether we get any more > comments. > I think the nub will be: > 1. whether your "should not" can be "SHOULD NOT" > 2. what does "frequently mean"? > 3. what is there in this I-D to say that an LSR does not join/leave a > TE mesh-group very often? > >> I guess that this is sufficiently explicit: it is a well-known fact >> that LSRs are infrequently added or removed to a TE mesh. > > :-) Very well known. In fact, my mother was commenting on it to me only > the other day ;-) > > Consider the case where PE membership of an automesh is dependent on > whether there are C-nodes subscribed to some service. > > Perhaps this well known fact could be noted in the Introduction to this > I-D which is AFAIK the only IETF document on the subject of automesh. > >>> 7) The security section (section 8) is inadequate and will >>> undoubtedly be rejected by the security ADs. At the very least, the >>> I-D needs a paragraph (i.e. more than one or two lines) explaining >>> why there are no new security considerations. But what would be the >>> impact of adding false mesh groups to a TLV? Is there anything >>> (dangerous) that can be learned about the network by inspecting >>> mesh group TLVs? >> >> The following section has been added: > > [SNIP] > OK. Let's run with that and see how much we get beaten up by the Security > experts. > > Cheers, > Adrian From rtg-dir-bounces@ietf.org Fri Sep 22 10:20:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQltB-0001iQ-UV; Fri, 22 Sep 2006 10:20:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQltB-0001iL-3Y for rtg-dir@ietf.org; Fri, 22 Sep 2006 10:20:25 -0400 Received: from mail1.noc.data.net.uk ([80.68.34.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQltA-0006mP-8I for rtg-dir@ietf.org; Fri, 22 Sep 2006 10:20:25 -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 1GQltL-000535-00 for rtg-dir@ietf.org; Fri, 22 Sep 2006 15:20:35 +0100 Received: from your029b8cecfe ([217.158.132.175] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 22 Sep 2006 15:20:16 +0100 Message-ID: <110201c6de52$31c27570$0a23fea9@your029b8cecfe> From: "Adrian Farrel" To: Date: Fri, 22 Sep 2006 15:19:52 +0100 Organization: Old Dog Consulting MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original 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: 22 Sep 2006 14:20:16.0921 (UTC) FILETIME=[3A0C5890:01C6DE52] X-Spam-Score: 0.1 (/) X-Scan-Signature: 841b5d6ad57042632519d2198f34cc8d Subject: Fw: Routing Directorate comments on draft-ietf-ccamp-automesh-01 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 And JP's response. A ----- Original Message ----- From: "JP Vasseur" To: "Adrian Farrel" Cc: ; "Ross Callon" ; Sent: Friday, September 22, 2006 2:22 PM Subject: Re: Routing Directorate comments on draft-ietf-ccamp-automesh-01 > Hi Adrian, > > On Sep 21, 2006, at 12:48 PM, Adrian Farrel wrote: > >> Hi JP, >> >> Thanks for addressing the comments. I have forwarded these to the >> Routing Directorate and copied them on this email to let them >> respond if they want. > > OK > >> But here are my comments: >> > > in line, > >>>> 1) The Tail-end name field facilitates LSP identification. Is this >>>> a new form of LSP identification? >>>> If it is not new, then there should be a reference to RFC3209 and a >>>> statement of which RFC3209 fields are mapped to this IGP field. >>>> If it is not new then there is a significant concern that a new >>>> identification is being introduced when it is not needed. >>> >>> As indicated in the document the string refers to a "Tail-end" name, >>> not an TE LSP name: thus it does not replace the session name of the >>> SESSION-ATTRIBUTE object defined in RFC3209. >> >> Hmmm, yes it is not an LSP name, but recall that the LSP is >> identified by a combination of Session and Sender Template, and >> that the Session includes the destination IP address. In Section >> 3.2 I see: >> - A Tail-end name: string used to ease the TE-LSP naming. >> and in Section 4.1: >> - A Tail-end name: a variable length field used to facilitate the TE >> LSP identification. > > Ah I see your point now. Just bad wording, it should have read " > The idea is not to use that field for LSP identification per say but > to ease the management, troubleshooting, ... > For example, an implementation could form the session name based on > the strings on these fields. > > A Tail-end name: name of the Tail-end LSR. > > + see below > >> >> These definitions seem to imply that the tail-end name is used as >> an identifier for the LSP. The question that will be asked is: How >> does this identification of an LSP differ from the conventional >> identification of the LSP? Given that you also have: >> - A Tail-end address: an IPv4 or IPv6 IP address to be used as a >> tail-end TE LSP address by other LSRs belonging to the same mesh- >> group >> it appears that the tail-name is superfluous information. >> > > Well having the name definitely helps for management, > troubleshooting, ... > >> So, perhaps the name is present for diagnostic purposes? Perhaps it >> is there to ease OAM? But it does not seem to play any role in the >> protocol procedures as it is not explicitly mentioned later in the >> I-D (e.g. Section 5). >> > > OK let me try to clarify adding the following text then: > > The aim of the Tail-end address field is to provide a way to quickly > identify the tail-end LSR originating the TE-MESH-GROUP and could be > used for various purposes such such troubleshooting, management and > so on. It does not interfere by any mean with the TE LSP attributes > used to identify a TE LSP. > > Does that clarify ? > >> How would a node behave if it received a mesh group advertisement >> that indicated a tail-end address that did not appear to match its >> record of the tail-end name? >> >>>> 2) 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 (although this might be constrained by >>>> OSPF's limit of a TLV size to 2^16 bytes. >>>> The document (and the authors) state that scaling of these >>>> extensions is not an issue because only a small number of mesh >>>> groups are likely to be in existence in a network, and any one >>>> router is unlikely to participate in more than a very few. >>>> There are two concerns: >>>> a) Whenever we say that something in the Internet is limited, >>>> history usually proves us wrong. >>> >>> And that's undoubtedly a good news :-) >>> >>>> Indeed, there is already a >>>> proposal (draft-leroux-mpls-p2mp-te-autoleaf-01.txt) that uses a >>>> similar mechanism for a problem that would have far more groups. >>> >>> Two comments: >>> - Mesh groups are used to set up TE LSP meshes. If we consider let >>> say 10 meshes comprising 100 routers each, that gives us 99,000 TE >>> LSPs. One can easily see that the number of meshes is unlikely to >>> explode in a foreseeable future. If it turns out to be the case, >>> we'll have other scalability issues to fix before any potential with >>> the IGP. >> >> What about 100 meshes comprising 10 routers each? > > Note that would still be very reasonable ;-) > >> I make that only 9,000 TE LSPs. >> >> So clearly the scaling of MPLS-TE is not directly related to the >> scaling of automesh. >> > > Well you see my point ... since these extensions are used to set up > TE LSPs, in the vast majority of the realistic cases you'll end up > with scalability concerns with RSVP before seeing any IGP scalability > issue. > >> What this comes down to is your statement about how automesh will >> be used. I think we can all accept that this is the problem space >> that you intend to deploy in, and that is great. But the original >> point from the Routing Directorate was that there is nothing in the >> I-D that imposes this restriction. So how can we say that the >> protocol extensions will scale? > > And that is true with pretty much every protocol: one could always > come up with a scenario where a bad usage of the protocol or a broken > implementation may be a concern. Anyway, let me try to propose some > text to close on this: > > OLD: > > It is expected that the number of mesh-groups be very limited (to at > most 10 or so). > Moreover, TE mesh-group membership should not change frequently: each > time an LSR joins or leaves a new TE mesh-group. > > NEW: > The aim of the IGP extensions proposed in this document is to ease > the provisioning of TE meshes, the number of which is generally very > limited (10 at most or so), and should stay of this order of > magnitude at least in a foreseeable future. Furthermore, such TE > meshes are not expected to change frequently and thus the TE mesh- > group membership is likely to be very stable (each time an LSR joins > or leaves a new TE mesh-group, which is a not a frequent). An > implementation SHOULD support mechanisms to control the frequency at > which an LSR joins/leaves a particular a TE mesh group. > > Does that address your concern ? > >> >>> - More importantly, the dynamics of joining a TE mesh is such that >>> IGP updates are used to advertise to TE mesh group membership change >>> (join or prune), which are indeed expected to be very unfrequent. >> >> Again, the concern raised is that the problem space you intend to >> deploy in is, indeed, limited in this way. All good. But how can we >> say whether the protocol extensions will be used differently in the >> future? What controls are there over constructing a mesh where >> joins and prunes are frequent? >> >>>> b) The I-D does not itself impose any reasonable limits on the >>>> number of groups with the potential for a single router (by >>>> misconfiguration, design, or malice) advertising a very large >>>> number of groups. >>>> Thus, it appears that the scaling concerns are not properly >>>> addressed in this I-D. >>> >>> Not sure to see the point here. If indeed, a large number of TE MESH >>> GROUPs were advertised, this would not impact the other LSRs since >>> they would not create any new TE LSPs trying to join the new TE-MESH- >>> GROUP. In term of amount of flooded information, this should not be a >>> concern either (handled by routing). We clarified this in the >>> security section. >> >> The impact on the other LSRs is exactly flooding question. Covering >> that in the security section is fine for the misconfiguration and >> malice cases. >> >>>> 3) 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") ? >>>> >>>> AF>> My comment on this is that the definition of the TLVs seems >>>> AF>> unclear. >>>> AF>> From figure 2, it appears that some additional information >>>> can be >>>> AF>> present in the TLV after the fields listed, and (reading >>>> AF>> between the lines) it would appear that this additional >>>> AF>> information is a series of repeats of the set of fields to >>>> AF>> define multiple mesh groups. >>>> AF>> This could usefully be clarified considerably. >>> >>> >>> You're absolutely right. The figures have been modified: >>> >>> (example show below): >> >> [SNIP] >> Looks good to me. >> >>>> AF>> But it is now unclear to me whether a single router can be a >>>> AF>> member of IPv4 an IPv6 mesh groups. It would seem that >>>> AF>> these cannot be mixed within a single TLV, and multiple >>>> AF>> TLVs (one IPv4 and one IPv6) are prohibited. >>> >>> OK the text requires some clarification. What is prohibited is to >>> have two IPv4 sub-TLV or two IPv6 sub-TLV but one of each is >>> permitted. New proposed text to clarify: >>> >>> The TE-MESH-GROUP TLV is OPTIONAL and at most one IPv4 instance and >>> one IPv6 instance MUST appear in a OSPF Router Information LSA or >>> ISIS Router Capability TLV. If the OSPF TE-MESH-GROUP TLV (IPv4 or >>> IPv6) occurs more than once within the OSPF Router Information LSA, >>> only the first instance is processed, subsequent TLV(s) will be >>> silently ignored. Similarly, If the ISIS TE-MESH-GROUP sub-TLV (IPv4 >>> or IPv6) occurs more than once within the ISIS Router capability TLV, >>> only the first instance is processed, subsequent TLV(s) will be >>> silently ignored. >> >> OK. That's fine. >> I think you want to make a couple of changes: >> - "at most one instance MUST appear" is ambiguous since it will >> be confused with "an instance MUST appear". I suggest you >> reword as "MUST NOT include more than one of each of" >> - "If the OSPF TE-MESH-GROUP TLV (IPv4 or IPv6) occurs >> more than once" should really be phrased as "If the either the >> IPv4 or IPv6 OSPF TE-MESH-GROUP TLV occurs more >> than once". Ditto for the IS-IS sub-TLV. >> - Two instances of "will be silently ignored" should read "SHOULD >> be silently ignored" > > Fixed, thanks ! > >> >>>> 4) Small terminology issue in section 5.1 it says: "Note that both >>>> operations can be performed in the context of a single refresh." >>>> This is not a refresh. It is a trigger/update. A better term for >>>> OSPF would be "LSA origination". >>> >>> OK fixed (I used the term "Update"), thanks. >> >> OK >> >>>> 5) Please state the applicability to OSPF v2 and or v3. Note that >>>> the Router_Cap document covers both v2 and v3 >>> >>> Indeed, Thanks for the comments. The OSPFv3 aspects have been >>> incorporated. Here is the new text: >> >> [SNIP] >> OK >> >>>> 6) The term "fairly static" at the end of section 5.1 is >>>> meaningless without some relative context. >>>> Presumably this relates to the number times an LSR joins or leaves >>>> a mesh group over time. >>>> Is it intended to be relative to the IGP refresh period? >>>> Please clarify in an objective rather than a subjective way. >>> >>> >>> Right, this requires clarification. Here is the new text: Moreover, >>> TE mesh-group membership should not change frequently: each time an >>> LSR joins or leaves a new TE mesh-group. >> >> I could live with this, personally. We'll see whether we get any >> more comments. >> I think the nub will be: >> 1. whether your "should not" can be "SHOULD NOT" >> 2. what does "frequently mean"? >> 3. what is there in this I-D to say that an LSR does not join/leave a >> TE mesh-group very often? >> > > Hopefully I clarified with the text above. > >>> I guess that this is sufficiently explicit: it is a well-known fact >>> that LSRs are infrequently added or removed to a TE mesh. >> >> :-) Very well known. In fact, my mother was commenting on it to me >> only the other day ;-) >> > > ah so she should talk to my kids then ... we can work this out ;-))) > >> Consider the case where PE membership of an automesh is dependent >> on whether there are C-nodes subscribed to some service. >> >> Perhaps this well known fact could be noted in the Introduction to >> this I-D which is AFAIK the only IETF document on the subject of >> automesh. > > OK, see the proposed text, and let me know what you think, I do think > that this is sufficient but let me know. > >> >>>> 7) The security section (section 8) is inadequate and will >>>> undoubtedly be rejected by the security ADs. At the very least, the >>>> I-D needs a paragraph (i.e. more than one or two lines) explaining >>>> why there are no new security considerations. But what would be the >>>> impact of adding false mesh groups to a TLV? Is there anything >>>> (dangerous) that can be learned about the network by inspecting >>>> mesh group TLVs? >>> >>> The following section has been added: >> >> [SNIP] >> OK. Let's run with that and see how much we get beaten up by the >> Security experts. > > OK, thanks. > > cheers, > > JP. > >> >> Cheers, >> Adrian > > From rtg-dir-bounces@ietf.org Sat Sep 23 12:10:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRA4r-0000Xx-OX; Sat, 23 Sep 2006 12:10:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRA4q-0000Xo-Et for rtg-dir@ietf.org; Sat, 23 Sep 2006 12:10:04 -0400 Received: from mail2.noc.data.net.uk ([80.68.34.49]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GRA4n-0006FM-6G for rtg-dir@ietf.org; Sat, 23 Sep 2006 12:10: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 1GRA4N-0001R2-00 for rtg-dir@ietf.org; Sat, 23 Sep 2006 17:09:35 +0100 Received: from your029b8cecfe ([217.158.132.58] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 23 Sep 2006 17:09:22 +0100 Message-ID: <11ca01c6df2a$9b5d47c0$0a23fea9@your029b8cecfe> From: "Adrian Farrel" To: "Ross Callon" Date: Sat, 23 Sep 2006 17:08:17 +0100 Organization: Old Dog Consulting MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original 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: 23 Sep 2006 16:09:27.0955 (UTC) FILETIME=[A52E8E30:01C6DF2A] X-Spam-Score: 0.1 (/) X-Scan-Signature: ff8f6fb66123e35ba88156f838266c1a Cc: Routing Area Directorate Subject: Review of draft-ietf-nsis-ntlp-11-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 Ross, Here is my review of draft-ietf-nsis-ntlp-11.txt. Although I have some doubts about the motivation for the work, I have tried to concentrate on technical issues with the protocol and the documentation. The concerns are broken into technical and editorial in the lists below. My review has been very quick which accounts for the relatively small number of comments. Please feel free to share these thoughts with the IESG or the authors. No doubt many of these issues have been discussed by the nsis working group and satisfactory conclusions have already been reached. I don't think there is a need to enter into a debate on the points if that is the case, but I would be happy to clarify any of my comments on request. Cheers, Adrian ========= Technical issues ---- Non-path-coupled signaling - Section 1 para 2 "concentrates mainly on path-coupled signaling". You raised my hopes :-) But I think the document concentrates entirely on path-coupled signaling. We could note that there are only a few places where this is actually enforced. For example, the Query, Response and Confirm could easily be allowed to use an existing MA (possibly set up on demand by a D-mode Query) and so out- of-band signaling would be supported. ---- Section 1.1 - Multicast flows You say: Multicast: GIST does not handle multicast flows. This includes classical IP multicast and any of the small group multicast schemes recently proposed. I think you might say that this is for future investigation rather than say it is not supported. You may find that GIST is perfectly capable of supporting multicast and is rather a useful tool where all replication points are GIST-capable. ---- Section 2 - Definitions The definitions of routing and transport don't appear until section 3.1. Given that these terms have subtle context- specific meanings in nsis, and that readers familiar with the current nature of the Internet may become confused, you might consider moving these into section 2. It would be helpful to define "routing state" in the context of GIST. The definition of "[data] flow" seems to be lacking. "A set of packets" is pretty vague. ---- Section 3.1 - Routing Does routing as described in this document determine how to reach the adjacent GIST peer along the data path? Surely either: - routing (conventional IP routing) determines how packets are forwarded along the data path or - GIST routing as described in this document determines which is the adjacent GIST peer by probing nodes along the data path. ---- Section 3.2 - Connection mode The motivation "fast state setup in the face of packet loss" is suspect. What makes you think that you will be able to set up and maintain a MA more rapidly in the face of message loss than you would be able to squeeze through a single UDP message? ---- Section 3.2 - D-mode encapsulation You say that UDP is the only encapsulation which does not require per-message shared state to be maintained between peers. Raw IP seems to do this job as well. So your point is that UDP is the only encapsulation with other properties that you desire that... ---- Router Alert interception I am concerned about this process as specified. Perhaps my memory of IP is a little rusty? And perhaps I am telling you how to suck eggs, but the current text on this is very scattered and unclear. RFC 2711 defines the Router Alert option for IPv6. The option carries a two byte field that indicates that the datagram includes a message of a particular protocol. The IANA maintains a registry of values for this field, and new NSLPs could certainly be added to this registry. The RFC states that: The router's interest and the actions taken by employing Router Alert MUST be specified in the RFC of the protocol that mandates or allows the use of Router Alert That means that each NSLP specification must describe the processing - i.e. it is out of scope for GIST unless (and this might be sensible) a single new value is defined to indicate that the datagram carries a GIST message. Obviously, if you do this you will need to make a new request in section 9. However, note well that a datagram that is intercepted because of the Router Alert option will be delivered to the component for processing the payload protocol - in this case UDP, and UDP will deliver the GIST message to the destination port on the local host. So you need to be really careful in IPv6: if you register with your local IPv6 stack that you want to receive intercepted Router Alert-flagged datagrams, you need to make sure that the GIST port is enabled or the UDP stack will drop/reject packets. IPv4 is slightly less friendly than IPv6. Although the Router Alert option defined in RFC 2113 also has a two byte field, only one value (zero) is defined and there is no IANA registry of other values. In IPv4, an IP stack decides to intercept a Router Alert-flagged datagram "shall examine packets carrying it more closely (check the IP Protocol field, for example) to determine whether or not further processing is necessary." I think that you would be well- advised to define the precise examination that you are requiring in the case of GIST. Are you asking that all flagged packets are delivered to UDP (as marked by their IP Protocol field) even though it may be that many cannot be delivered - perhaps they are not even GIST messages. Or are you asking that the IP stack checks such flagged datagrams for: - IP protocol = UDP - destination port = GIST default port Bottom line: - You must recall that there will be other users of Router Alert active in the network at the same time as GIST - You must take care that if a datagram is intercepted and delivered to UDP, UDP will know what to do with it. UDP is not a forwarding protocol. - You must define the correct processing for any IPv6 Router Alert options in the "owning specification" or define a new codepoint for GIST. ---- Section 3.4 I think it would be worth discussing somewhere how the upstream node knows when state has been successfully installed at the downstream node if the downstream node requested the use of Confirm. In fact the answer is that it doesn't. It just goes ahead and tries a message and if it doesn't get an error back everything must be OK. This is probably within the spirit of not optimising for error conditions, but you might want to make it a bit clearer. ---- Section 3.5 SIDs The statement about whether NSIS implementations could provide common functionality to generate SIDs is clearly out of scope. I suggest removing it. You need to add a couple of clear statements in this section: - Is the SID maintained end-to-end or does each NSLP that handles the message insert its own SID? - What is the scope of uniqueness of the SID? Is it per node, or is it per NSLP ID? ---- Section 4 Is this section normative? It includes some 2119 language (e.g., 4.3.4) and some text that appears to be definitive (e.g. the bullets in 4.3.2). However, the GIS service interface (section 4.1) is clearly not normative. It would be helpful if the text made clear what is and is not normative. In particular, some text in 4.1 like: This abstract service interface definition in no way constrains implementations, is non-normative, and is only provided as in formation to help understand how GIST might be used. ---- Section 4.1.2 Security This section should discuss where the keys come from and how they are distributed (or ref 8.2). ---- Section 4.2.1 para 1 Says: "The primary key" without reference to any other keys. ---- Section 4.2.1 "All of this information is learned from prior GIST exchanges". Well, once I had read the rest of the document, I understood this! Can you clarify that there are specific GIST exchanges that are used to set up Message Routing State and that those exchanges distribute this information. ---- Section 4.3.1 D-mode Normal encapsulation "Each datagram contains a single message" Didn't I see something about bundling somewhere? ---- Section 4.3.1 Q-mode "usually with an IP router alert option" How so "usually"? ---- Section 4.3.2 para 2 You say that the interaction is with signaling application policy, but I think that the interaction is with the signaling application, itself. The application is responsible for applying policy. That is, GIST does not interact with a policy component at this stage. ---- Section 4.3.2 para 2 (Perhaps a nit) You say that GIST MUST propagate the Query. But consider that the local node may be the destination of the Query. ---- Section 4.3.2 bullets Given how these look to be normative, it might be best to put bullet 3 before bullet 2. Otherwise there is a small security hole because bullet 2 can be used to discover that a given MRI/SID/NSLP-ID combination exists on a target node ---- Section 4.3.3 bullet 2 Worth saying why. "...to preserve fragment ordering" ---- Section 4.3.4 - GIST Hop Count A.4.4.2 shows clearly that an error is generated by a GIST node if it decrements the hop count to zero on receipt. But the definition in A.1 says: GIST hops (8 bits): A hop count for the number of GIST-aware nodes this message can still pass through. This is inconsistent. A message sent with a hop count of 1 will have the count decremented to zero on receipt resulting in an error. So the value 1 did not represent the number of nodes that the message could pass through. In fact, there is no point in sending a message with hop count 1. In 4.3.4 you have 2. The GIST hop count has reached zero. The error "Hop Limit Exceeded" (Appendix A.4.4.2) SHOULD be returned to the sender, which MAY retry with a larger initial hop count if it is clear that a loop has not been formed. It is not explained how a receiver of a "Hop Limit Exceeded" error can tell whether a loop has not been formed. And it is not explained how the initiator of such an error message could know, either. Additionally, the statement (in several places, e.g., 4.3.2) that the GIST hop count prevents looping is not completely accurate. It prevents indefinite looping, but it does not prevent looping per se. ---- Section 4.3.4 point 3 Is there a valid race where this can happen? For example, when a signaling application crashes. Suggest you add "during normal processing", or "this is an error condition", or remove "...this should never happen" as you go on to describe how to handle it anyway. ---- Section 4.4 This section appears to say that an MA cannot exist without some Routing State. Is this the case, and if so why? Surely it would be helpful to prevent MA flap to allow an implementation to retain an MA without Routing State in case a subsequent usage became apparent. Confusingly, section 4.4.2 describes MA "Re-use", but this is meant to describe "multi-use" because the MA is assumed to already be in use. Perhaps you could change the title and text in 4.4.2? Note that a receiver that does not install routing state until it receives a Confirm, may have an MA set up with no associated routing state. And such an MA could be assigned for use for other routing state. ---- Section 4.4.1 page 29 "about the node itself" Which node? ---- Section 4.4.2 Peer-Identity s/uniqueness between peers/uniqueness across the set of all potential peers/ Should you suggest a source of this value since the uniqueness will depend on all implementations selecting a value in the same way. Perhaps you could suggest the use of the Router ID, or some-such. ---- Section 4.4.2 bullet 1 "This will only fail..." This is a subjective measure of failure. What you actually mean is "This will only happen..." But if this can happen (and if it can be done by an on-path attacker) you need to describe how to recover/protect. ---- Section 4.4.2 bullet 2 "These should be rare events..." Not only is "rare" subjective, but I don't see how you can say that hijack attempts should be rare. So the protection against this type of attack seems to be that you allow a new MA to be set up and then let it time out. ---- Section 4.4.3 Soft State Concerns for Routing State You should think carefully about the soft state scalability concerns of RSVP (see RFC 2961). The Routing State maintenance process that you describe here and expand on in Sections 6.2 and 6.3 scale linearly with the number of Routing States. Discussing rate limiting here is interesting: how many Routing States would be needed before rate limiting caused some state not to be refreshed? The text at the end of 4.4.3 about refresh timing is good, but conflicts slightly with paragraph 2 where: The Querying node MUST generate a Query before this timer expires since what you really mean is that the Query node must act to ensure the delivery of a Query before the time expires on the Responder. Given the impact of UDP rate limiting on top of unreliable message delivery, you should probably be stronger in your recommendation of suitable timer values. ---- Section 4.4.3 Leveraging Soft State NSLP for MA keepalive In the event that the NSLP is a soft state protocol or contains keep-alive messages, you may want to consider leveraging those transactions in the setting of the MA-Hold-Time. This would require that a suitable value for the MA-Hold-Time was suggested by the NSLP application. ---- Section 4.4.3 TCP failure detection One use of the MA-Hello may be the converse of what is proposed. As currently stated, the message keeps alive an MA that would otherwise be closed down. But another possibility is that the TCP connection that underlies the MA fails without being reported to the GIST implementation. In this case, the implementation would not become aware of the fact until it next tried to send, or until the hold time expired. Although not fatal, such a state of affairs delays delivery of NSLP messages until the MA can be re-established. Therefore MA-Hello could be used to detect MA failures. But that would place quite a different timescale on the rate of sending. ---- Parallel MAs Not sure that I saw any comment on the correct use of parallel MAs. I assume that the rules are that all messages associated with one flow must be sent on the same MA to avoid message re-ordering. Can you make sure that this is stated somewhere. ---- Section 5.1 Confirm Confirm: A Confirm may be sent in D-mode, or C-mode if a messaging association has been re-used. The implication of this text is that I can send the Confirm and pipeline setting up the MA. But the last para of 5.7.1 says that the Confirm is sent over the MA. The table in 5.5 supports 5.1, not 5.7.1. ---- Section 5.1 MA-Hello A bit obvious, but you may want to recommend (or must) that an MA-Hello sent in response to an MA-Hello that contains R=1 does not itself contain R=1. ---- Section 5.2.2 Helpful to state here whether the presence of a duplicate object is to be ignored or treated as an error. The former would be better for forward extensibility, but either would be acceptable. ---- Section 5.3.3 The final paragraphs describe good techniques for implementations to protect the network. Are there also mechanisms for nodes to protect themselves? Such as rate limiting on the receive side. ---- Section 5.6 How will we handle an error introduced by a GIST forwarding node? Will the error be reported to the forwarding node or to the originator? If the latter, is this: - helpful - a security weakness ---- Section 6.1 and Section 8.4 A DoS attack can come from any node in the network. Such a node can send a Q-mode Query message as though it was forwarding it at the GIST level. The result, from any GIST capable node that intercepts it, may be a D-mode Response direct to the (spoofed) Query node. The Query node will handle the Response (according to Rule 2) by sending a "No Routing State" error message. Please consider whether a Responder node should be recommended to keep track of such events and rate limit processing of new Query messages under such circumstances. ---- Section 6.2 Can I receive er_NoRSM in Awaiting Refresh state? I think so because my sent Query refresh may have been lost, the peer may have timed out the state, and I may have sent Data. ---- Section 6.2 to_Inactive_QNode is not possible in Awaiting Response state because the timer is not running. ---- Section 6.2 What about the receipt of other errors? Especially fatal errors. ---- Section 6.2 Rule 3 This action needs to check to see if Confirm was requested. Should not send a Confirm if one was never requested. What if the er_NoRSM is sent in response to the Confirm? This is opening a tight loop! (Such could arise if the peer has 'lost' the Routing State. Also, if you have sent several (say 100) Data messages immediately after a lost Confirm, you will receive 100 er_NoRSM messages and (according to this state machine) you will send 100 new Confirm messages. This is not just a mater of implementation optimisation because you are impacting the network and the adjacent nodes. Further, this state machine is presented as normative so variations from it will be tested by certification labs. ---- Section 6.3 Rule 1 Say "set R=1" ---- Section 6.3 Rule 5 Say "set R=0" ---- Section 6.3 Can I change my mind about whether I want a Confirm while I am waiting for one? For example, in Awaiting Confirm state I may receive a new Query. Must I also set the R flag on the Response or can I clear the flag and move to Established state? Similarly, during the refresh processing (since the MA is now set up and I no longer need to see the Confirm) can I clear the R flag on refresh Responses? I think the state machine allows this. But once I am in Awaiting Refresh state, can I change my mind and send R=0 on my next Response? ---- Section 6.3 I can receive a Confirm in Established state ---- Section 6.3 to_Expire_RNode is not possible in Awaiting Confirm state because the timer is not running. ---- Section 6.4 Probably need to support tg_RawData in Connected state :-) ---- Section 6.4 er_MAFailure is not possible in Awaiting Connection state. ---- Section 6.4 Rule 8 Should there be some feedback to the Message State machines or can we rely on them to fail to find an MA next time they try? What about potentially lost messages? ---- Section 7.1.1 "On the assumption" Can you include the reference, please. [26]? ---- Section 7.1.4 As demonstrated by Figure 9 and the text in 7.1.1, rapid local repair may not be such a good idea. It will cause the GIST state to thrash around and new MAs to be set up for no purpose because the new flow path is actually an entirely different route from the head-end. Thus, in the figure, any action taken immediately by (say) D1 is a waste of time because the new flow actually does not touch D1. Shouldn't you let the flow routing protocol (IGP?) converge first and let the NSLP drive the repair through its retransmissions/refreshes/explicit messages? ---- Section 9 The use of reserved blocks within the codepoint registries appears non-standard. The word "Reserved" does not appear in RFC 2434. I would suggest the use of "IETF consensus" with an additional note saying that the block is reserved for future expansion. If you do not do this, IANA will not know under what circumstances to open up the block for allocation. ---- Section 9 - Object Types etc. There is a note (using RFC 2119 language, which is not appropriate in the IANA section) about what must be defined if a new object type (etc.) is defined. You need to say where those definitions are expected to be lodged. It reads like you are asking IANA to keep the definitions in the registries. ---- Section 9 - Error classes IANA will find it helpful if you make clearer that the 2-byte error code is split into an error class and an error code. You are asking them to keep a registry of the 1-byte error code as listed in A.4.4 and to track the error class as a parameter of that registry. As currently presented, IANA might reasonably assume that the error codes 0x0101 and 0x0201 are different error values ---- Section 11.1 draft-loughney-nsis-ext-02.txt seems to have expired. Do you really want this RFC to be gated on the development of a personal I-D? If material in that I-D is normative to GIST (and it appears that that is the case) you should consider moving that material into the main GIST specification. ---- Section 11.2 A reference to draft-ietf-nsis-ntlp-statemachine-02.txt would be a good idea. ---- Section A.2.1 The extensibility flags are very sensible. But the definition of 10 is not clear. If the message is to be delivered to an NSLP application, how are objects of this type handled? Note that I think the processing described in this section is normative to the protocol and should appear in the body of the document. ---- Section A.3.1.1 - Flow Label You define a "may only be set" for the F flag without describing how to handle the Flow label (presumably ignore) if the F flag is set. ---- Section A.3.1.1 - S flag You say that the S flag can only be set if P=1. How to process the SPI if P=0? ---- Section A.3.1.1 - A/B flags You say that these flags can only be set if P=1. How to process the ports if P=0? ---- Section A.3.3 - Routing state validity time Did you consider allowing zero for "always valid"? ---- Section A.3.4 Need to say what happens in Prof-Count = 0 The current text says: "If there are no profiles (i.e. all bytes are null)," Should this say "if there are no protocol layers in a profile"? The description of the padding is fine, but I presume a receiver MUST ignore all bytes beyond the length indicated by the layer count field. ---- Section A.3.5 Can MPO-Count be zero? Should say so for clarity. Did you consider allowing zero for "hold open indefinitely" Did you consider that different hold times might be applicable to different MAs according to the protocols in use? ---- Section A.3.8 - List of translated objects Please say that the elements of this list are the object type values defined for use in section A.2. Please indicate whether the A, B and reserved flags are relevant. ---- Section A.3.9 Please state padding rules. ---- Section A.4.1 I suspect it is the intention that the Additional Information objects are encoded as sub-objects (i.e. as TLVs) since otherwise, parsing the data is impossible and future extensibility is compromised. But where is the list of object type values, and shouldn't IANA manage them? ---- Section A.4.3 Do you want to distinguish between protocol errors (i.e. messages received at the wrong time) and message formatting errors? ---- Section A.4.7 I should have thought that the class of this error is a Permanent-Failure. Or do you plan that a Response will also be sent even though the NSLP ID cannot be matched? If no response, then according to Figure 7, the receiver state machine is stuck. If the error class is Informational then according to figure 6, the sender state machine is stuck. ---- Section A.4.9 - Error sub-code 2: Missing Object How will you identify which object was missing? ========= Editorial issues ---- Abstract s/universal/common/ ---- Section 2 - Session Identifier The word "long" is a bit too subjective for inclusion in a protocol spec. Can you find a better term? ---- Section 3 There is various 2119 notation in this section. I think the section is not a normative protocol definition so all uses should go to lower case. But if I am wrong, then the many lower case uses need to be changed. ---- Section 3.2 - Connection mode s/objects/messages/ ---- Section 3.3 page 13 3rd para These updates may be done in separate documents as is the case for the base GIST specification, as described in Section 7.2.2. s/base/NAT traversal/ s/7.2.2./7.2.2 and [40]./ ---- Section 3.3 page 13 4th para s/enforce/allow/ ---- Section 3.4 The Data message is used purely to encapsulate signaling application data. Not to deliver it? :-) ---- Section 3.7 point 3 s/towards/to/ ---- Section 3.7 point 8 There is a reference to step 6.B, but step 6 has no such labeling. ---- Section 4, para 1 Delete "in the first place" ---- Section 4.1.1, para 2 Delete "directly" ---- Section 4.1.2 para 1 s/security related/security-related/ ---- Section 4.3.4 s/MUST never/MUST NOT/ ---- Section 4.4.1 Missing reference in empty square brackets "[]" ---- Section 4.4.2 bullet 1 "appropriate" should be replaced with something more specific. ---- Section 4.4.3 bullet 2, para 2 s/retain/create/ ---- Section 5.2.1 It might be nice to order the fields described here in the same order as they appear in the message. See A.1 ---- Section 5.2.2 GIST-Error-Data s/determine/report/ ---- Section 5.8.1.2 s/vital/essential/ ---- Section 6.3 Rule 2 and 8 s/piggybacked/NSLP/ ---- Section 9 - MA Protocol IDs You say "upper layer protocol", but I think "transport protocol" would be more appropriate. ---- Section 11.2 I think [26] and [27] might usefully be normative. ---- Section A.2.1 s/containing and/containing an/ ---- Section A.3.1.1 - P flag s/IP Protocol/Protocol field/ ---- Section A.3.1.2 - D flag Need to back-reference A.3.1.1 for the definition ---- Section A.3.3 Odd ordering to the field descriptions. ---- Section A.4.10 para 1 s/packet/message/ ---- Section D. Suggest adding an RFC Editor note to have this appendix deleted before publication as an RFC. From rtg-dir-bounces@ietf.org Sat Sep 23 18:37:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRG7e-0004zD-GA; Sat, 23 Sep 2006 18:37:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRG7c-0004z8-RD for rtg-dir@ietf.org; Sat, 23 Sep 2006 18:37:20 -0400 Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GRG7b-0004Np-Qx for rtg-dir@ietf.org; Sat, 23 Sep 2006 18:37:20 -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 k8NMbK5P010057; Sun, 24 Sep 2006 00:37:20 +0200 In-Reply-To: <110201c6de52$31c27570$0a23fea9@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: Sun, 24 Sep 2006 00:37:13 +0200 X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 09/24/2006 00:37:18, Serialize complete at 09/24/2006 00:37:18 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: 06d29b9b22258f4f07fe89b4d4a05a86 Cc: rtg-dir@ietf.org Subject: Re: Fw: Routing Directorate comments on draft-ietf-ccamp-automesh-01 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 - much thanks for the feedback - two specific points o) "> Well you see my point ... since these extensions are used to set up > TE LSPs, in the vast majority of the realistic cases you'll end up > with scalability concerns with RSVP before seeing any IGP scalability > issue." actually, . if the number of LSRs is high in a given mesh then signaling scaling issue takes precedence over the routing scaling . if the number of meshes is high then the routing scaling issues takes precedence over the signaling scaling . in case of combination we're in also combining issues authors seems to see a real limitation in the former since de facto signaling is limited i would then argue that there are induced scaling concerns wrt to signaling and nothing is provided in this document to rate limit the number of LSRs per mesh group (hence i just hope that LSRs won't be installed by a default mesh group) the issue is that at the end if there is a need to limit the number of mesh group members an explicit list should be provided o) concerning the "tail-end name" ... reasoning is that it simplifies the actual operations and manaement ... so now on we're going to name resources such as to facilitate network operations ? why is this specific to automesh ? ... for me we're opening the pandora box i would like first to understand why a name is more easily managed by a system that any other id (or their combination) ? thanks, - dimitri. "Adrian Farrel" 22/09/2006 16:19 Please respond to Adrian Farrel To: cc: Subject: Fw: Routing Directorate comments on draft-ietf-ccamp-automesh-01 And JP's response. A ----- Original Message ----- From: "JP Vasseur" To: "Adrian Farrel" Cc: ; "Ross Callon" ; Sent: Friday, September 22, 2006 2:22 PM Subject: Re: Routing Directorate comments on draft-ietf-ccamp-automesh-01 > Hi Adrian, > > On Sep 21, 2006, at 12:48 PM, Adrian Farrel wrote: > >> Hi JP, >> >> Thanks for addressing the comments. I have forwarded these to the >> Routing Directorate and copied them on this email to let them >> respond if they want. > > OK > >> But here are my comments: >> > > in line, > >>>> 1) The Tail-end name field facilitates LSP identification. Is this >>>> a new form of LSP identification? >>>> If it is not new, then there should be a reference to RFC3209 and a >>>> statement of which RFC3209 fields are mapped to this IGP field. >>>> If it is not new then there is a significant concern that a new >>>> identification is being introduced when it is not needed. >>> >>> As indicated in the document the string refers to a "Tail-end" name, >>> not an TE LSP name: thus it does not replace the session name of the >>> SESSION-ATTRIBUTE object defined in RFC3209. >> >> Hmmm, yes it is not an LSP name, but recall that the LSP is >> identified by a combination of Session and Sender Template, and >> that the Session includes the destination IP address. In Section >> 3.2 I see: >> - A Tail-end name: string used to ease the TE-LSP naming. >> and in Section 4.1: >> - A Tail-end name: a variable length field used to facilitate the TE >> LSP identification. > > Ah I see your point now. Just bad wording, it should have read " > The idea is not to use that field for LSP identification per say but > to ease the management, troubleshooting, ... > For example, an implementation could form the session name based on > the strings on these fields. > > A Tail-end name: name of the Tail-end LSR. > > + see below > >> >> These definitions seem to imply that the tail-end name is used as >> an identifier for the LSP. The question that will be asked is: How >> does this identification of an LSP differ from the conventional >> identification of the LSP? Given that you also have: >> - A Tail-end address: an IPv4 or IPv6 IP address to be used as a >> tail-end TE LSP address by other LSRs belonging to the same mesh- >> group >> it appears that the tail-name is superfluous information. >> > > Well having the name definitely helps for management, > troubleshooting, ... > >> So, perhaps the name is present for diagnostic purposes? Perhaps it >> is there to ease OAM? But it does not seem to play any role in the >> protocol procedures as it is not explicitly mentioned later in the >> I-D (e.g. Section 5). >> > > OK let me try to clarify adding the following text then: > > The aim of the Tail-end address field is to provide a way to quickly > identify the tail-end LSR originating the TE-MESH-GROUP and could be > used for various purposes such such troubleshooting, management and > so on. It does not interfere by any mean with the TE LSP attributes > used to identify a TE LSP. > > Does that clarify ? > >> How would a node behave if it received a mesh group advertisement >> that indicated a tail-end address that did not appear to match its >> record of the tail-end name? >> >>>> 2) 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 (although this might be constrained by >>>> OSPF's limit of a TLV size to 2^16 bytes. >>>> The document (and the authors) state that scaling of these >>>> extensions is not an issue because only a small number of mesh >>>> groups are likely to be in existence in a network, and any one >>>> router is unlikely to participate in more than a very few. >>>> There are two concerns: >>>> a) Whenever we say that something in the Internet is limited, >>>> history usually proves us wrong. >>> >>> And that's undoubtedly a good news :-) >>> >>>> Indeed, there is already a >>>> proposal (draft-leroux-mpls-p2mp-te-autoleaf-01.txt) that uses a >>>> similar mechanism for a problem that would have far more groups. >>> >>> Two comments: >>> - Mesh groups are used to set up TE LSP meshes. If we consider let >>> say 10 meshes comprising 100 routers each, that gives us 99,000 TE >>> LSPs. One can easily see that the number of meshes is unlikely to >>> explode in a foreseeable future. If it turns out to be the case, >>> we'll have other scalability issues to fix before any potential with >>> the IGP. >> >> What about 100 meshes comprising 10 routers each? > > Note that would still be very reasonable ;-) > >> I make that only 9,000 TE LSPs. >> >> So clearly the scaling of MPLS-TE is not directly related to the >> scaling of automesh. >> > > Well you see my point ... since these extensions are used to set up > TE LSPs, in the vast majority of the realistic cases you'll end up > with scalability concerns with RSVP before seeing any IGP scalability > issue. > >> What this comes down to is your statement about how automesh will >> be used. I think we can all accept that this is the problem space >> that you intend to deploy in, and that is great. But the original >> point from the Routing Directorate was that there is nothing in the >> I-D that imposes this restriction. So how can we say that the >> protocol extensions will scale? > > And that is true with pretty much every protocol: one could always > come up with a scenario where a bad usage of the protocol or a broken > implementation may be a concern. Anyway, let me try to propose some > text to close on this: > > OLD: > > It is expected that the number of mesh-groups be very limited (to at > most 10 or so). > Moreover, TE mesh-group membership should not change frequently: each > time an LSR joins or leaves a new TE mesh-group. > > NEW: > The aim of the IGP extensions proposed in this document is to ease > the provisioning of TE meshes, the number of which is generally very > limited (10 at most or so), and should stay of this order of > magnitude at least in a foreseeable future. Furthermore, such TE > meshes are not expected to change frequently and thus the TE mesh- > group membership is likely to be very stable (each time an LSR joins > or leaves a new TE mesh-group, which is a not a frequent). An > implementation SHOULD support mechanisms to control the frequency at > which an LSR joins/leaves a particular a TE mesh group. > > Does that address your concern ? > >> >>> - More importantly, the dynamics of joining a TE mesh is such that >>> IGP updates are used to advertise to TE mesh group membership change >>> (join or prune), which are indeed expected to be very unfrequent. >> >> Again, the concern raised is that the problem space you intend to >> deploy in is, indeed, limited in this way. All good. But how can we >> say whether the protocol extensions will be used differently in the >> future? What controls are there over constructing a mesh where >> joins and prunes are frequent? >> >>>> b) The I-D does not itself impose any reasonable limits on the >>>> number of groups with the potential for a single router (by >>>> misconfiguration, design, or malice) advertising a very large >>>> number of groups. >>>> Thus, it appears that the scaling concerns are not properly >>>> addressed in this I-D. >>> >>> Not sure to see the point here. If indeed, a large number of TE MESH >>> GROUPs were advertised, this would not impact the other LSRs since >>> they would not create any new TE LSPs trying to join the new TE-MESH- >>> GROUP. In term of amount of flooded information, this should not be a >>> concern either (handled by routing). We clarified this in the >>> security section. >> >> The impact on the other LSRs is exactly flooding question. Covering >> that in the security section is fine for the misconfiguration and >> malice cases. >> >>>> 3) 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") ? >>>> >>>> AF>> My comment on this is that the definition of the TLVs seems >>>> AF>> unclear. >>>> AF>> From figure 2, it appears that some additional information >>>> can be >>>> AF>> present in the TLV after the fields listed, and (reading >>>> AF>> between the lines) it would appear that this additional >>>> AF>> information is a series of repeats of the set of fields to >>>> AF>> define multiple mesh groups. >>>> AF>> This could usefully be clarified considerably. >>> >>> >>> You're absolutely right. The figures have been modified: >>> >>> (example show below): >> >> [SNIP] >> Looks good to me. >> >>>> AF>> But it is now unclear to me whether a single router can be a >>>> AF>> member of IPv4 an IPv6 mesh groups. It would seem that >>>> AF>> these cannot be mixed within a single TLV, and multiple >>>> AF>> TLVs (one IPv4 and one IPv6) are prohibited. >>> >>> OK the text requires some clarification. What is prohibited is to >>> have two IPv4 sub-TLV or two IPv6 sub-TLV but one of each is >>> permitted. New proposed text to clarify: >>> >>> The TE-MESH-GROUP TLV is OPTIONAL and at most one IPv4 instance and >>> one IPv6 instance MUST appear in a OSPF Router Information LSA or >>> ISIS Router Capability TLV. If the OSPF TE-MESH-GROUP TLV (IPv4 or >>> IPv6) occurs more than once within the OSPF Router Information LSA, >>> only the first instance is processed, subsequent TLV(s) will be >>> silently ignored. Similarly, If the ISIS TE-MESH-GROUP sub-TLV (IPv4 >>> or IPv6) occurs more than once within the ISIS Router capability TLV, >>> only the first instance is processed, subsequent TLV(s) will be >>> silently ignored. >> >> OK. That's fine. >> I think you want to make a couple of changes: >> - "at most one instance MUST appear" is ambiguous since it will >> be confused with "an instance MUST appear". I suggest you >> reword as "MUST NOT include more than one of each of" >> - "If the OSPF TE-MESH-GROUP TLV (IPv4 or IPv6) occurs >> more than once" should really be phrased as "If the either the >> IPv4 or IPv6 OSPF TE-MESH-GROUP TLV occurs more >> than once". Ditto for the IS-IS sub-TLV. >> - Two instances of "will be silently ignored" should read "SHOULD >> be silently ignored" > > Fixed, thanks ! > >> >>>> 4) Small terminology issue in section 5.1 it says: "Note that both >>>> operations can be performed in the context of a single refresh." >>>> This is not a refresh. It is a trigger/update. A better term for >>>> OSPF would be "LSA origination". >>> >>> OK fixed (I used the term "Update"), thanks. >> >> OK >> >>>> 5) Please state the applicability to OSPF v2 and or v3. Note that >>>> the Router_Cap document covers both v2 and v3 >>> >>> Indeed, Thanks for the comments. The OSPFv3 aspects have been >>> incorporated. Here is the new text: >> >> [SNIP] >> OK >> >>>> 6) The term "fairly static" at the end of section 5.1 is >>>> meaningless without some relative context. >>>> Presumably this relates to the number times an LSR joins or leaves >>>> a mesh group over time. >>>> Is it intended to be relative to the IGP refresh period? >>>> Please clarify in an objective rather than a subjective way. >>> >>> >>> Right, this requires clarification. Here is the new text: Moreover, >>> TE mesh-group membership should not change frequently: each time an >>> LSR joins or leaves a new TE mesh-group. >> >> I could live with this, personally. We'll see whether we get any >> more comments. >> I think the nub will be: >> 1. whether your "should not" can be "SHOULD NOT" >> 2. what does "frequently mean"? >> 3. what is there in this I-D to say that an LSR does not join/leave a >> TE mesh-group very often? >> > > Hopefully I clarified with the text above. > >>> I guess that this is sufficiently explicit: it is a well-known fact >>> that LSRs are infrequently added or removed to a TE mesh. >> >> :-) Very well known. In fact, my mother was commenting on it to me >> only the other day ;-) >> > > ah so she should talk to my kids then ... we can work this out ;-))) > >> Consider the case where PE membership of an automesh is dependent >> on whether there are C-nodes subscribed to some service. >> >> Perhaps this well known fact could be noted in the Introduction to >> this I-D which is AFAIK the only IETF document on the subject of >> automesh. > > OK, see the proposed text, and let me know what you think, I do think > that this is sufficient but let me know. > >> >>>> 7) The security section (section 8) is inadequate and will >>>> undoubtedly be rejected by the security ADs. At the very least, the >>>> I-D needs a paragraph (i.e. more than one or two lines) explaining >>>> why there are no new security considerations. But what would be the >>>> impact of adding false mesh groups to a TLV? Is there anything >>>> (dangerous) that can be learned about the network by inspecting >>>> mesh group TLVs? >>> >>> The following section has been added: >> >> [SNIP] >> OK. Let's run with that and see how much we get beaten up by the >> Security experts. > > OK, thanks. > > cheers, > > JP. > >> >> Cheers, >> Adrian > > From rtg-dir-bounces@ietf.org Sat Sep 23 22:42:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRJwK-0001Jt-QF; Sat, 23 Sep 2006 22:41:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRJwJ-0001Jo-NB for rtg-dir@ietf.org; Sat, 23 Sep 2006 22:41:55 -0400 Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GRJwI-0007Hm-Hr for rtg-dir@ietf.org; Sat, 23 Sep 2006 22:41:55 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id k8O2fn1Z090747; Sat, 23 Sep 2006 19:41:49 -0700 (PDT) (envelope-from rcallon@juniper.net) Received: from rcallon-lt1.juniper.net ([172.23.1.155]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id k8O2flg87641; Sat, 23 Sep 2006 19:41:47 -0700 (PDT) (envelope-from rcallon@juniper.net) Message-Id: <5.0.0.25.2.20060923223414.039b77c0@zircon.juniper.net> X-Sender: rcallon@zircon.juniper.net X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Sat, 23 Sep 2006 22:37:39 -0400 To: "Adrian Farrel" From: Ross Callon In-Reply-To: <11ca01c6df2a$9b5d47c0$0a23fea9@your029b8cecfe> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 86a4d7ebdc337882c86d755b1c60a122 Cc: Routing Area Directorate Subject: Re: Review of draft-ietf-nsis-ntlp-11-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 Adrian; Thanks for the very careful detailed comments (although I suppose that per page of spec there aren't really all *that* many comments). I have entered these in the ID tracker (as part of the "DISCUSS" vote that I was about to enter even before seeing these comments). I will be on vacation and probably largely out of email contact for the next week, but of course you might hear from the authors before I get back. Thanks, Ross At 05:08 PM 9/23/2006 +0100, Adrian Farrel wrote: >Hi Ross, > >Here is my review of draft-ietf-nsis-ntlp-11.txt. > >Although I have some doubts about the motivation for the >work, I have tried to concentrate on technical issues with >the protocol and the documentation. The concerns are >broken into technical and editorial in the lists below. > >My review has been very quick which accounts for the >relatively small number of comments. > >Please feel free to share these thoughts with the IESG or >the authors. > >No doubt many of these issues have been discussed by the >nsis working group and satisfactory conclusions have >already been reached. I don't think there is a need to >enter into a debate on the points if that is the case, >but I would be happy to clarify any of my comments on >request. > >Cheers, >Adrian > >========= >Technical issues > > >---- >Non-path-coupled signaling - Section 1 para 2 >"concentrates mainly on path-coupled signaling". You raised >my hopes :-) But I think the document concentrates entirely >on path-coupled signaling. >We could note that there are only a few places where this >is actually enforced. For example, the Query, Response and >Confirm could easily be allowed to use an existing MA >(possibly set up on demand by a D-mode Query) and so out- >of-band signaling would be supported. >---- >Section 1.1 - Multicast flows >You say: > Multicast: GIST does not handle multicast flows. > This includes classical IP multicast and any of the > small group multicast schemes recently proposed. >I think you might say that this is for future investigation >rather than say it is not supported. You may find that GIST >is perfectly capable of supporting multicast and is rather >a useful tool where all replication points are >GIST-capable. >---- >Section 2 - Definitions >The definitions of routing and transport don't appear until >section 3.1. Given that these terms have subtle context- >specific meanings in nsis, and that readers familiar with >the current nature of the Internet may become confused, you >might consider moving these into section 2. > >It would be helpful to define "routing state" in the >context of GIST. > >The definition of "[data] flow" seems to be lacking. "A set >of packets" is pretty vague. >---- >Section 3.1 - Routing >Does routing as described in this document determine how to >reach the adjacent GIST peer along the data path? >Surely either: >- routing (conventional IP routing) determines how packets > are forwarded along the data path >or >- GIST routing as described in this document determines > which is the adjacent GIST peer by probing nodes along > the data path. >---- >Section 3.2 - Connection mode >The motivation "fast state setup in the face of packet >loss" is suspect. What makes you think that you will be >able to set up and maintain a MA more rapidly in the >face of message loss than you would be able to squeeze >through a single UDP message? >---- >Section 3.2 - D-mode encapsulation >You say that UDP is the only encapsulation which does not >require per-message shared state to be maintained between >peers. Raw IP seems to do this job as well. So your point >is that UDP is the only encapsulation with other properties >that you desire that... >---- >Router Alert interception >I am concerned about this process as specified. >Perhaps my memory of IP is a little rusty? >And perhaps I am telling you how to suck eggs, but the >current text on this is very scattered and unclear. > >RFC 2711 defines the Router Alert option for IPv6. >The option carries a two byte field that indicates that the >datagram includes a message of a particular protocol. The >IANA maintains a registry of values for this field, and >new NSLPs could certainly be added to this registry. >The RFC states that: > The router's interest and the actions taken by employing > Router Alert MUST be specified in the RFC of the > protocol that mandates or allows the use of Router Alert >That means that each NSLP specification must describe the >processing - i.e. it is out of scope for GIST unless (and >this might be sensible) a single new value is defined to >indicate that the datagram carries a GIST message. >Obviously, if you do this you will need to make a new >request in section 9. > >However, note well that a datagram that is intercepted >because of the Router Alert option will be delivered to the >component for processing the payload protocol - in this >case UDP, and UDP will deliver the GIST message to the >destination port on the local host. So you need to be >really careful in IPv6: if you register with your local >IPv6 stack that you want to receive intercepted Router >Alert-flagged datagrams, you need to make sure that the >GIST port is enabled or the UDP stack will drop/reject >packets. > >IPv4 is slightly less friendly than IPv6. Although the >Router Alert option defined in RFC 2113 also has a two byte >field, only one value (zero) is defined and there is no >IANA registry of other values. In IPv4, an IP stack decides >to intercept a Router Alert-flagged datagram "shall examine >packets carrying it more closely (check the IP Protocol >field, for example) to determine whether or not further >processing is necessary." I think that you would be well- >advised to define the precise examination that you are >requiring in the case of GIST. Are you asking that all >flagged packets are delivered to UDP (as marked by their >IP Protocol field) even though it may be that many cannot >be delivered - perhaps they are not even GIST messages. Or >are you asking that the IP stack checks such flagged >datagrams for: >- IP protocol = UDP >- destination port = GIST default port > >Bottom line: >- You must recall that there will be other users of > Router Alert active in the network at the same time as > GIST >- You must take care that if a datagram is intercepted > and delivered to UDP, UDP will know what to do with it. > UDP is not a forwarding protocol. >- You must define the correct processing for any IPv6 > Router Alert options in the "owning specification" or > define a new codepoint for GIST. >---- >Section 3.4 >I think it would be worth discussing somewhere how the >upstream node knows when state has been successfully >installed at the downstream node if the downstream node >requested the use of Confirm. >In fact the answer is that it doesn't. It just goes ahead >and tries a message and if it doesn't get an error back >everything must be OK. >This is probably within the spirit of not optimising for >error conditions, but you might want to make it a bit >clearer. >---- >Section 3.5 SIDs >The statement about whether NSIS implementations could >provide common functionality to generate SIDs is clearly >out of scope. I suggest removing it. >You need to add a couple of clear statements in this >section: >- Is the SID maintained end-to-end or does each NSLP > that handles the message insert its own SID? >- What is the scope of uniqueness of the SID? Is it per > node, or is it per NSLP ID? >---- >Section 4 >Is this section normative? It includes some 2119 language >(e.g., 4.3.4) and some text that appears to be definitive >(e.g. the bullets in 4.3.2). However, the GIS service >interface (section 4.1) is clearly not normative. >It would be helpful if the text made clear what is and is >not normative. In particular, some text in 4.1 like: > This abstract service interface definition in no way > constrains implementations, is non-normative, and is > only provided as in formation to help understand how > GIST might be used. >---- >Section 4.1.2 Security >This section should discuss where the keys come from and >how they are distributed (or ref 8.2). >---- >Section 4.2.1 para 1 >Says: "The primary key" without reference to any other >keys. >---- >Section 4.2.1 >"All of this information is learned from prior GIST >exchanges". Well, once I had read the rest of the document, >I understood this! >Can you clarify that there are specific GIST exchanges that >are used to set up Message Routing State and that those >exchanges distribute this information. >---- >Section 4.3.1 D-mode Normal encapsulation >"Each datagram contains a single message" >Didn't I see something about bundling somewhere? >---- >Section 4.3.1 Q-mode >"usually with an IP router alert option" >How so "usually"? >---- >Section 4.3.2 para 2 >You say that the interaction is with signaling application >policy, but I think that the interaction is with the >signaling application, itself. The application is >responsible for applying policy. That is, GIST does not >interact with a policy component at this stage. >---- >Section 4.3.2 para 2 >(Perhaps a nit) >You say that GIST MUST propagate the Query. But consider >that the local node may be the destination of the Query. >---- >Section 4.3.2 bullets >Given how these look to be normative, it might be best to >put bullet 3 before bullet 2. Otherwise there is a small >security hole because bullet 2 can be used to discover that >a given MRI/SID/NSLP-ID combination exists on a target node >---- >Section 4.3.3 bullet 2 >Worth saying why. >"...to preserve fragment ordering" >---- >Section 4.3.4 - GIST Hop Count >A.4.4.2 shows clearly that an error is generated by a GIST >node if it decrements the hop count to zero on receipt. But >the definition in A.1 says: > GIST hops (8 bits): A hop count for the number of > GIST-aware nodes this message can still pass through. >This is inconsistent. A message sent with a hop count of 1 >will have the count decremented to zero on receipt >resulting in an error. So the value 1 did not represent the >number of nodes that the message could pass through. >In fact, there is no point in sending a message with hop >count 1. > >In 4.3.4 you have > 2. The GIST hop count has reached zero. The error > "Hop Limit Exceeded" (Appendix A.4.4.2) SHOULD be > returned to the sender, which MAY retry with a > larger initial hop count if it is clear that a > loop has not been formed. >It is not explained how a receiver of a "Hop Limit >Exceeded" error can tell whether a loop has not been >formed. And it is not explained how the initiator of >such an error message could know, either. > >Additionally, the statement (in several places, e.g., >4.3.2) that the GIST hop count prevents looping is not >completely accurate. It prevents indefinite looping, but >it does not prevent looping per se. >---- >Section 4.3.4 point 3 >Is there a valid race where this can happen? For example, >when a signaling application crashes. >Suggest you add "during normal processing", or "this is an >error condition", or remove "...this should never happen" >as you go on to describe how to handle it anyway. >---- >Section 4.4 >This section appears to say that an MA cannot exist without >some Routing State. Is this the case, and if so why? >Surely it would be helpful to prevent MA flap to allow an >implementation to retain an MA without Routing State in >case a subsequent usage became apparent. >Confusingly, section 4.4.2 describes MA "Re-use", but this >is meant to describe "multi-use" because the MA is assumed >to already be in use. Perhaps you could change the title >and text in 4.4.2? >Note that a receiver that does not install routing state >until it receives a Confirm, may have an MA set up with no >associated routing state. And such an MA could be assigned >for use for other routing state. >---- >Section 4.4.1 page 29 >"about the node itself" >Which node? >---- >Section 4.4.2 Peer-Identity >s/uniqueness between peers/uniqueness across the set of >all potential peers/ > >Should you suggest a source of this value since the >uniqueness will depend on all implementations selecting >a value in the same way. Perhaps you could suggest the >use of the Router ID, or some-such. >---- >Section 4.4.2 bullet 1 >"This will only fail..." >This is a subjective measure of failure. >What you actually mean is "This will only happen..." >But if this can happen (and if it can be done by an on-path >attacker) you need to describe how to recover/protect. >---- >Section 4.4.2 bullet 2 >"These should be rare events..." >Not only is "rare" subjective, but I don't see how you can >say that hijack attempts should be rare. So the protection >against this type of attack seems to be that you allow a >new MA to be set up and then let it time out. >---- >Section 4.4.3 Soft State Concerns for Routing State > >You should think carefully about the soft state scalability >concerns of RSVP (see RFC 2961). The Routing State >maintenance process that you describe here and expand on in >Sections 6.2 and 6.3 scale linearly with the number of >Routing States. Discussing rate limiting here is >interesting: how many Routing States would be needed before >rate limiting caused some state not to be refreshed? > >The text at the end of 4.4.3 about refresh timing is good, >but conflicts slightly with paragraph 2 where: > The Querying node MUST generate a Query before this > timer expires >since what you really mean is that the Query node must act >to ensure the delivery of a Query before the time expires >on the Responder. > >Given the impact of UDP rate limiting on top of unreliable >message delivery, you should probably be stronger in your >recommendation of suitable timer values. >---- >Section 4.4.3 Leveraging Soft State NSLP for MA keepalive >In the event that the NSLP is a soft state protocol or >contains keep-alive messages, you may want to consider >leveraging those transactions in the setting of the >MA-Hold-Time. This would require that a suitable value for >the MA-Hold-Time was suggested by the NSLP application. >---- >Section 4.4.3 TCP failure detection >One use of the MA-Hello may be the converse of what is >proposed. As currently stated, the message keeps alive an >MA that would otherwise be closed down. But another >possibility is that the TCP connection that underlies the >MA fails without being reported to the GIST implementation. >In this case, the implementation would not become aware of >the fact until it next tried to send, or until the hold >time expired. >Although not fatal, such a state of affairs delays delivery >of NSLP messages until the MA can be re-established. >Therefore MA-Hello could be used to detect MA failures. But >that would place quite a different timescale on the rate of >sending. >---- >Parallel MAs >Not sure that I saw any comment on the correct use of >parallel MAs. I assume that the rules are that all messages >associated with one flow must be sent on the same MA to >avoid message re-ordering. >Can you make sure that this is stated somewhere. >---- >Section 5.1 Confirm > Confirm: A Confirm may be sent in D-mode, or C-mode if a > messaging association has been re-used. >The implication of this text is that I can send the Confirm >and pipeline setting up the MA. >But the last para of 5.7.1 says that the Confirm is sent >over the MA. >The table in 5.5 supports 5.1, not 5.7.1. >---- >Section 5.1 MA-Hello >A bit obvious, but you may want to recommend (or must) that >an MA-Hello sent in response to an MA-Hello that contains >R=1 does not itself contain R=1. >---- >Section 5.2.2 >Helpful to state here whether the presence of a duplicate >object is to be ignored or treated as an error. >The former would be better for forward extensibility, but >either would be acceptable. >---- >Section 5.3.3 >The final paragraphs describe good techniques for >implementations to protect the network. Are there also >mechanisms for nodes to protect themselves? Such as rate >limiting on the receive side. >---- >Section 5.6 >How will we handle an error introduced by a GIST forwarding >node? Will the error be reported to the forwarding node or >to the originator? If the latter, is this: >- helpful >- a security weakness >---- >Section 6.1 and Section 8.4 >A DoS attack can come from any node in the network. >Such a node can send a Q-mode Query message as though it >was forwarding it at the GIST level. The result, from any >GIST capable node that intercepts it, may be a D-mode >Response direct to the (spoofed) Query node. The Query >node will handle the Response (according to Rule 2) by >sending a "No Routing State" error message. >Please consider whether a Responder node should be >recommended to keep track of such events and rate limit >processing of new Query messages under such circumstances. >---- >Section 6.2 >Can I receive er_NoRSM in Awaiting Refresh state? >I think so because my sent Query refresh may have been >lost, the peer may have timed out the state, and I may >have sent Data. >---- >Section 6.2 >to_Inactive_QNode is not possible in Awaiting Response >state because the timer is not running. >---- >Section 6.2 >What about the receipt of other errors? Especially fatal >errors. >---- >Section 6.2 Rule 3 >This action needs to check to see if Confirm was requested. >Should not send a Confirm if one was never requested. > >What if the er_NoRSM is sent in response to the Confirm? >This is opening a tight loop! (Such could arise if the >peer has 'lost' the Routing State. > >Also, if you have sent several (say 100) Data messages >immediately after a lost Confirm, you will receive 100 >er_NoRSM messages and (according to this state machine) >you will send 100 new Confirm messages. > >This is not just a mater of implementation optimisation >because you are impacting the network and the adjacent >nodes. Further, this state machine is presented as >normative so variations from it will be tested by >certification labs. >---- >Section 6.3 Rule 1 >Say "set R=1" >---- >Section 6.3 Rule 5 >Say "set R=0" >---- >Section 6.3 >Can I change my mind about whether I want a Confirm >while I am waiting for one? >For example, in Awaiting Confirm state I may receive a >new Query. Must I also set the R flag on the Response >or can I clear the flag and move to Established state? > >Similarly, during the refresh processing (since the MA >is now set up and I no longer need to see the Confirm) >can I clear the R flag on refresh Responses? I think the >state machine allows this. But once I am in Awaiting >Refresh state, can I change my mind and send R=0 on my next >Response? >---- >Section 6.3 >I can receive a Confirm in Established state >---- >Section 6.3 >to_Expire_RNode is not possible in Awaiting Confirm >state because the timer is not running. >---- >Section 6.4 >Probably need to support tg_RawData in Connected state :-) >---- >Section 6.4 >er_MAFailure is not possible in Awaiting Connection state. >---- >Section 6.4 Rule 8 >Should there be some feedback to the Message State machines >or can we rely on them to fail to find an MA next time they >try? >What about potentially lost messages? >---- >Section 7.1.1 >"On the assumption" >Can you include the reference, please. [26]? >---- >Section 7.1.4 >As demonstrated by Figure 9 and the text in 7.1.1, rapid >local repair may not be such a good idea. It will cause the >GIST state to thrash around and new MAs to be set up for no >purpose because the new flow path is actually an entirely >different route from the head-end. >Thus, in the figure, any action taken immediately by (say) >D1 is a waste of time because the new flow actually does >not touch D1. >Shouldn't you let the flow routing protocol (IGP?) converge >first and let the NSLP drive the repair through its >retransmissions/refreshes/explicit messages? >---- >Section 9 >The use of reserved blocks within the codepoint registries >appears non-standard. The word "Reserved" does not appear >in RFC 2434. >I would suggest the use of "IETF consensus" with an >additional note saying that the block is reserved for >future expansion. If you do not do this, IANA will not know >under what circumstances to open up the block for >allocation. >---- >Section 9 - Object Types etc. >There is a note (using RFC 2119 language, which is not >appropriate in the IANA section) about what must be defined >if a new object type (etc.) is defined. You need to say >where those definitions are expected to be lodged. It reads >like you are asking IANA to keep the definitions in the >registries. >---- >Section 9 - Error classes >IANA will find it helpful if you make clearer that the >2-byte error code is split into an error class and an error >code. You are asking them to keep a registry of the 1-byte >error code as listed in A.4.4 and to track the error class >as a parameter of that registry. >As currently presented, IANA might reasonably assume that >the error codes 0x0101 and 0x0201 are different error >values >---- >Section 11.1 >draft-loughney-nsis-ext-02.txt seems to have expired. >Do you really want this RFC to be gated on the development >of a personal I-D? >If material in that I-D is normative to GIST (and it >appears that that is the case) you should consider moving >that material into the main GIST specification. >---- >Section 11.2 >A reference to draft-ietf-nsis-ntlp-statemachine-02.txt >would be a good idea. >---- >Section A.2.1 >The extensibility flags are very sensible. But the >definition of 10 is not clear. If the message is to be >delivered to an NSLP application, how are objects of this >type handled? >Note that I think the processing described in this section >is normative to the protocol and should appear in the body >of the document. >---- >Section A.3.1.1 - Flow Label >You define a "may only be set" for the F flag without >describing how to handle the Flow label (presumably ignore) >if the F flag is set. >---- >Section A.3.1.1 - S flag >You say that the S flag can only be set if P=1. How to >process the SPI if P=0? >---- >Section A.3.1.1 - A/B flags >You say that these flags can only be set if P=1. How to >process the ports if P=0? >---- >Section A.3.3 - Routing state validity time >Did you consider allowing zero for "always valid"? >---- >Section A.3.4 >Need to say what happens in Prof-Count = 0 >The current text says: > "If there are no profiles (i.e. all bytes are null)," >Should this say "if there are no protocol layers in a >profile"? >The description of the padding is fine, but I presume a >receiver MUST ignore all bytes beyond the length indicated >by the layer count field. >---- >Section A.3.5 >Can MPO-Count be zero? Should say so for clarity. >Did you consider allowing zero for "hold open indefinitely" >Did you consider that different hold times might be >applicable to different MAs according to the protocols in >use? >---- >Section A.3.8 - List of translated objects >Please say that the elements of this list are the object >type values defined for use in section A.2. >Please indicate whether the A, B and reserved flags are >relevant. >---- >Section A.3.9 >Please state padding rules. >---- >Section A.4.1 >I suspect it is the intention that the Additional >Information objects are encoded as sub-objects (i.e. as >TLVs) since otherwise, parsing the data is impossible >and future extensibility is compromised. >But where is the list of object type values, and shouldn't >IANA manage them? >---- >Section A.4.3 >Do you want to distinguish between protocol errors (i.e. >messages received at the wrong time) and message >formatting errors? >---- >Section A.4.7 >I should have thought that the class of this error is >a Permanent-Failure. Or do you plan that a Response will >also be sent even though the NSLP ID cannot be matched? >If no response, then according to Figure 7, the receiver >state machine is stuck. If the error class is Informational >then according to figure 6, the sender state machine is >stuck. >---- >Section A.4.9 - Error sub-code 2: Missing Object >How will you identify which object was missing? > > > >========= >Editorial issues > >---- >Abstract >s/universal/common/ >---- >Section 2 - Session Identifier >The word "long" is a bit too subjective for inclusion in a >protocol spec. Can you find a better term? >---- >Section 3 >There is various 2119 notation in this section. I think the >section is not a normative protocol definition so all uses >should go to lower case. But if I am wrong, then the many >lower case uses need to be changed. >---- >Section 3.2 - Connection mode >s/objects/messages/ >---- >Section 3.3 page 13 3rd para > These updates may be done in separate documents as is > the case for the base GIST specification, as described > in Section 7.2.2. >s/base/NAT traversal/ >s/7.2.2./7.2.2 and [40]./ >---- >Section 3.3 page 13 4th para >s/enforce/allow/ >---- >Section 3.4 > The Data message is used purely to encapsulate signaling > application data. >Not to deliver it? :-) >---- >Section 3.7 point 3 >s/towards/to/ >---- >Section 3.7 point 8 >There is a reference to step 6.B, but step 6 has no such >labeling. >---- >Section 4, para 1 >Delete "in the first place" >---- >Section 4.1.1, para 2 >Delete "directly" >---- >Section 4.1.2 para 1 >s/security related/security-related/ >---- >Section 4.3.4 >s/MUST never/MUST NOT/ >---- >Section 4.4.1 >Missing reference in empty square brackets "[]" >---- >Section 4.4.2 bullet 1 >"appropriate" should be replaced with something more >specific. >---- >Section 4.4.3 bullet 2, para 2 >s/retain/create/ >---- >Section 5.2.1 >It might be nice to order the fields described here in the >same order as they appear in the message. See A.1 >---- >Section 5.2.2 GIST-Error-Data >s/determine/report/ >---- >Section 5.8.1.2 >s/vital/essential/ >---- >Section 6.3 Rule 2 and 8 >s/piggybacked/NSLP/ >---- >Section 9 - MA Protocol IDs >You say "upper layer protocol", but I think "transport >protocol" would be more appropriate. >---- >Section 11.2 >I think [26] and [27] might usefully be normative. >---- >Section A.2.1 >s/containing and/containing an/ >---- >Section A.3.1.1 - P flag >s/IP Protocol/Protocol field/ >---- Section A.3.1.2 - D flag >Need to back-reference A.3.1.1 for the definition >---- >Section A.3.3 >Odd ordering to the field descriptions. >---- >Section A.4.10 para 1 >s/packet/message/ >---- >Section D. >Suggest adding an RFC Editor note to have this appendix >deleted before publication as an RFC. From rtg-dir-bounces@ietf.org Mon Sep 25 07:02:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRoDx-0001qK-V9; Mon, 25 Sep 2006 07:02:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRoDw-0001qF-Ls for rtg-dir@ietf.org; Mon, 25 Sep 2006 07:02:08 -0400 Received: from rwcrmhc13.comcast.net ([216.148.227.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GRoDv-0008Mq-86 for rtg-dir@ietf.org; Mon, 25 Sep 2006 07:02:08 -0400 Received: from frogbits.attlabs.att.com (c-24-6-155-213.hsd1.ca.comcast.net[24.6.155.213]) by comcast.net (rwcrmhc13) with ESMTP id <20060925110206m1300m1d01e>; Mon, 25 Sep 2006 11:02:06 +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 k8PB1O2K078959 for ; Mon, 25 Sep 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 k8PB1Oqm078958 for rtg-dir@ietf.org; Mon, 25 Sep 2006 04:01:24 -0700 (PDT) (envelope-from fenner) Date: Mon, 25 Sep 2006 04:01:24 -0700 (PDT) Message-Id: <200609251101.k8PB1Oqm078958@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: 140baa79ca42e6b0e2b4504291346186 Subject: IESG agenda for 2006-09-28 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-09-28). Updated 18:2:21 EDT, September 22, 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 GIST: General Internet Signaling Transport (Proposed Standard) - 1 of 5 draft-ietf-nsis-ntlp-11.txt [Open Web Ballot] Note: WG Shepherd: John Loughney (john.loughney@nokia.com) Token: Magnus Westerlund OPS Operation of Anycast Services (BCP) - 2 of 5 draft-ietf-grow-anycast-04.txt [Open Web Ballot] Note: PROTO Shepherd: Geoff Huston Token: David Kessens TSV Aggregation of RSVP Reservations over MPLS TE/ DS-TE Tunnels (Proposed Standard) - 3 of 5 draft-ietf-tsvwg-rsvp-dste-05.txt [Open Web Ballot] Note: Gen-ART Reviewer: Sharon Chisholm (schishol@nortel.com) Token: Magnus Westerlund RTP Payload Format and File Storage Format for RAI the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) Audio Codecs (Proposed Standard) - 4 of 5 draft-ietf-avt-rtp-amr-bis-06.txt [Open Web Ballot] Note: Colin Perkins is PROTO Shepherd Token: Cullen Jennings SEC Oct 31 Secure Shell Public-Key Subsystem (Proposed Standard) - 5 of 5 draft-ietf-secsh-publickey-subsystem-07.txt [Open Web Ballot] Note: Requested comments be fixed by October 31 Token: Sam Hartman 2.1.2 Returning Item NONE 2.2 Individual Submissions 2.2.1 New Item Area Date SEC OCSP Extensions to IKEv2 (Proposed Standard) - 1 of 2 draft-myers-ikev2-ocsp-04.txt [Open Web Ballot] Token: Russ Housley Simple Network Management Protocol (SNMP) OPS over IEEE 802 Networks (Proposed Standard) - 2 of 2 draft-schoenw-snmp-ether-01.txt [Open Web Ballot] Note: version 02 was submitted by the document editor on 9/21 and should be used in the IESG discussion Token: Dan Romascanu 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 and Requirements for Layer 1 RTG Virtual Private Networks (Informational) - 1 of 3 draft-ietf-l1vpn-framework-04.txt [Open Web Ballot] Token: Ross Callon OPS Operational Security Current Practices (Informational) - 2 of 3 draft-ietf-opsec-current-practices-07.txt [Open Web Ballot] Note: Ross Callon is the proto shepherd Token: David Kessens INT Softwire Problem Statement (Informational) - 3 of 3 draft-ietf-softwire-problem-statement-02.txt Note: Exiting Last Call on 9/28 Token: Mark Townsley 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 OPS Administration of the IANA Special Purpose Address Block (Informational) - 1 of 2 draft-huston-ipv6-iana-specials-01.txt [Open Web Ballot] Token: Dan Romascanu SEC OMA BCAST MIKEY General Extension Payload Specification (Informational) - 2 of 2 draft-dondeti-msec-mikey-genext-oma-02.txt [Open Web Ballot] Token: Russ Housley 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 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 OPS Sep 19 ADSL MIB (adslmib) - 1 of 1 Token: Dan 4.2.2 Proposed for Approval Area Date INT Sep 7 Mobility for IPv6 (mip6) - 1 of 1 Token: Jari 5. IAB News We Can Use 6. Management Issues 6.1 Response to ITU-T SG-13 Liaison Statement (Lars Eggert) 7. Working Group News