From adrian@olddog.co.uk Tue Apr 3 12:53:44 2012 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45AA711E8131 for ; Tue, 3 Apr 2012 12:53:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AH1hmAzKrAua for ; Tue, 3 Apr 2012 12:53:43 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by ietfa.amsl.com (Postfix) with ESMTP id 5001111E8120 for ; Tue, 3 Apr 2012 12:53:43 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id q33Jrg6T031422; Tue, 3 Apr 2012 20:53:42 +0100 Received: from 950129200 (AGrenoble-551-1-16-202.w92-133.abo.wanadoo.fr [92.133.247.202]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id q33JrJuY031207 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 3 Apr 2012 20:53:35 +0100 From: "Adrian Farrel" To: , Date: Tue, 3 Apr 2012 20:53:20 +0100 Message-ID: <005001cd11d3$77852ac0$668f8040$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac0R00SVA9YAKzzdS32BNClY82vJHQ== Content-Language: en-gb Cc: pim@ietf.org Subject: [pim] AD Review draft-ietf-pim-ecmp X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 19:53:44 -0000 Hi, I have done my usual AD review of your draft in response to the publication request from the working group. The purpose of the review is to clean up issues that I think might show up in IETF last call, Directorate reviews, or during IESG evaluation. By catching the issues at this stage we can save the effort of multiple reviewers, and achieve a smoother passage through the publication process. All of my comments can be discussed. As it stands, I think a new revision would help address these point so I will move the I-D into "New Revision Required" state, and when I see an update I will advance the document to IETF last call. Please be sure to run idnits on the new revision and fix all of the warnings. Thanks, Adrian --- It took me some time to determine that you are only talking about parallel links between adjacent routers and not talking about the more generic, network view of ECMP. In fact, I was so confused, I had to ask for clarification on the PIM list. In this context, is it really helpful to say ECMP? Wouldn't "parallel, equal cost links" be a better term? It would also tie in with other terminology relating to link bundles (such as in TE) while avoiding confusion with the wider concept of ECMP. While I would prefer that the document replaced "ECMP" with "parallel links" throughout, I understand that this is a lot of effort and you might not have the stamina to make the change. If you can't/won't do that, could you please add a clarification to the Abstract and early in the Introduction to say "In this document, the term ECMP is used to apply to parallel, single-hop, equal cost links between a pair of adjacent nodes." --- Please update Yiqun's email address to yiqunc@microsoft.com and his coordinates to Microsoft. --- Please expand RPF in the Abstract and on first use in the Introduction. --- The RFC Editor usually requires that the first section is the Introduction, so best to move Section 1 to 2.3 and renumber. --- The concept of an ECMP bundle is introduced in Section 3, and seems to be central to the document. That means that the text in Section 2 is missing this concept. Do you think you should move the definition of an ECMP bundle to Section 2 so that Section 2.1 can refer to it? --- In Section 3.2 An upstream router may choose not to send ECMP Redirects if it becomes aware that some of the downstream routers do not support the message... You need to say how it might "become aware". A pointer to 3.5 is probably enough. I think "may" is "MAY" --- In Section 3.3 When a downstream router receives an ECMP Redirect, and detects that the desired RPF path from its upstream router's point of view is different from its current one, it should choose to prune from the current path and join the new path. Is that "SHOULD"? --- Section 3.3 If an upstream router receives an ECMP Redirect from another upstream router, it SHOULD NOT change its forwarding behavior even if the ECMP Redirect makes it a less preferred RPF neighbor on the receiving interface. Too many "upstreams" to make this easy to parse. Is the second upstream router upstream of the first upstream router? Or just upstream of the downstream router? Maybe you are missing some pictures in this document! --- Section 3.4 In such an event, the following actions are recommended. Is that "RECOMMENDED"? --- Section 3.4 s/down stream/downstream/ (twice) Either s/re-select a new/re-select a/ Or s/re-select a new/select a new/ --- Section 3.5 If a PIM router detects that any of its neighbor does not support this Hello option, it MUST not send ECMP Redirects, however, it SHOULD still process any ECMP Redirects received. s/neighbor/neighbors/ s/MUST not/MUST NOT/ s/send ECMP Redirects/send ECMP Redirects to that neighbor/ What would a legacy node do with an ECMP Redirect that it received? You should be able to answer this with a reference to an existing RFC. --- It would help IANA get their actions right if you could use TBD1 and TBD2 instead of TBD twice. You can then also use those flags in Section 4. --- 3.6.2 I am missing a definition of how a timestamp is encoded in the Metric field. Assuming the idea is that the router that has been forwarding out of its interface for longer will be preferred (by having a smaller timestamp value), it would be important that everyone has the same understanding of what a timestamp looks like. --- Section 4 Could you help IANA by naming the registries as they are named on the IANA pages? From adrian@olddog.co.uk Tue Apr 3 13:38:19 2012 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B14A511E8205 for ; Tue, 3 Apr 2012 13:38:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y+cvtNPSD+3T for ; Tue, 3 Apr 2012 13:38:18 -0700 (PDT) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) by ietfa.amsl.com (Postfix) with ESMTP id 5F4AD11E820C for ; Tue, 3 Apr 2012 13:38:18 -0700 (PDT) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id q33KcE1U018416; Tue, 3 Apr 2012 21:38:14 +0100 Received: from 950129200 (AGrenoble-551-1-16-202.w92-133.abo.wanadoo.fr [92.133.247.202]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id q33KbwDA018323 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 3 Apr 2012 21:38:12 +0100 From: "Adrian Farrel" To: , "Yiqun Cai" Date: Tue, 3 Apr 2012 21:38:00 +0100 Message-ID: <005101cd11d9$b1c44da0$154ce8e0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac0R2VKxh4+5Xo/xQGG8Wxk3SqBiiQ== Content-Language: en-gb Cc: pim@ietf.org Subject: [pim] AD review of draft-ietf-pim-pop-count X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 20:38:19 -0000 Hi, Sorry I sat on this I-D a while doing my review. The review is my usual pass over the document to iron out nits that I think might show up in IETF last call, Directorate reviews, or during IESG evaluation. By catching the issues at this stage we can save the effort of multiple reviewers, and achieve a smoother passage through the publication process. All of my comments can be discussed. As it stands, I think a new revision would help address these point so I will move the I-D into "New Revision Required" state, and when I see an update I will advance the document to IETF last call. Please be sure that the new revision passes idnits. Thanks, Adrian --- Please update Yiqun's email address to yiqunc@microsoft.com and his coordinates to Microsoft. --- The RFC Editor likes the document to begin with an Introduction, so you could move Section 1 into 2.1 and renumber. --- I think that the RFC Editor likes all figures to be captioned and given a number (e.g. Figure 1 : A Sample Foobar). Further, they like all figures to be explicitly referenced form the text. That sounds a bore to do, but if you have the energy it might be worth it. --- Can you s/this draft/this document/ throughout since, on publication, this will not be a draft any more. --- We will get push-back from the IESG to "describe the experiment". I think this can be handled relatively easily in the Introduction with some text such as: This is a new proposal for an extension to PIM, and it is not completely understood what impact collecting information using PIM would have on the operation of PIM. Many PIM features (including the core protocol) were first introduced as Experimental RFCs, and it seems appropriate to advance this work as Experimental. Reports of implementation and deployment across whole distribution trees or within sub-trees (see Section 7) will enable an assessment of the desirability and stability of this feature. The PIM working group will then consider whether to move this work to the Standards Track. I am only showing example text here. I am not attached to the content, but I am trying to cover the bases in a way that the IESG is likely to request. Please feel free to use other text if it works better for you. --- I think you need to expand "oif-list" on first use. --- Section 3 If a PIM router supports this draft, it must send the Pop- Count-Supported TLV. I think this might be better written as: A PIM router indicates that it supports this document by sending the Pop-Count-Supported TLV in a PIM Hello message. --- Section 3 The format of the TLV is defined to be: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OptionType | OptionLength | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OptionValue | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ OptionType = 29, OptionLength = 4, there is no OptionValue semantics defined at this time but will be included for expandability and be defined in future revisions of this draft. The format will look like: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 29 | 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Unallocated Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Unallocated Flags: for now should be sent as 0 and ignored on receipt. I am ambivalent about defining the flags field. Does PIM require that an options TLV is always the same length? If so, you are doing the right thing, but if not, you could equally come back later and define that, if the length is non-zero, the first four bytes are flags. But this is Experimental, so I don't object. Mainly I am curious :-) But anyway, I don't think you need the TLV format twice, and you need to allow IANA to make the allocation (although you can suggest a value in the IANA section). So you could rewrite as: The format follows the format of all Hello Option TLVs [RFC4601]: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OptionType = TBD1 | OptionLength = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Unallocated Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Unallocated Flags: Unused flags SHOULD be sent as 0 and ignored on receipt. This document defines no flags. Then, in Section 8... OLD A new PIM Hello Option type, 29, has been assigned. See [HELLO] for details. NEW IANA is requested to define a new PIM Hello Option type in the registry at [HELLO]. Pop-Count Support TBD1 A value of 29 is suggested. END --- Section 4 Suggest s/Pop-Count attribute/Pop-Count Join Attribute/ s/to process PIM Join Attribute/to process a PIM Join Attribute/ --- Section 4 Again, to leave this to IANA... OLD Attr Type: 2. NEW Attr Type: TBD2 END And then, in Section 8 OLD A new PIM Join Attribute type needs to be assigned. 2 is proposed in this draft. NEW IANA is requested to allocate a new PIM Join Attribute type. Pop-Count Join Attribute TBD2 A value of 2 is suggested. --- Section 4 Unallocated Flags: The flags which are currently not defined. If a new flag is defined and sent by a new implementation, an old implementation should preserve the bit settings. This means that if a bit was set in a PIM Join message from any of the downstream routers, then it MUST also be set in any PIM Join sent upstream. Am I being too pedantic? Presumably clear bits MUST also be kept clear. How about: This means that a router MUST preserve the settings of all Unallocated Flags in PIM Join messages received from downstream routers in any PIM Join sent upstream. --- Section 4 P flag: This flag remains set if all downstream routers support this specification. That is, they are PIM pop-count capable. This allows one to tell if the entire sub-tree is completely accounting capable. I'm not clear about this. Is the assumption that a router will clear this flag if it knows that a downstream router is not PIM pop-count capable? (I presume that the downstream router would not clear the flag because it doesn't know about this I-D.) Can you clarify by saying who has the responsibility to clear the flag? --- Section 4.2 has some ugly XML bleedthrough
X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ADE221F8452; Fri, 23 Mar 2012 08:25:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.156 X-Spam-Level: X-Spam-Status: No, score=0.156 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D06ae19hIq9N; Fri, 23 Mar 2012 08:25:02 -0700 (PDT) Received: from mx3.haw-public.haw-hamburg.de (mx3.haw-public.haw-hamburg.de [141.22.6.2]) by ietfa.amsl.com (Postfix) with ESMTP id 2EF9B21F8453; Fri, 23 Mar 2012 08:25:01 -0700 (PDT) Received: from dehawshub02.mailcluster.haw-hamburg.de ([141.22.200.52]) by mail3.is.haw-hamburg.de with ESMTP/TLS/RC4-MD5; 23 Mar 2012 16:24:59 +0100 Received: from dehawscas03.mailcluster.haw-hamburg.de (141.22.200.83) by DEHAWSHUB02.mailcluster.haw-hamburg.de (141.22.200.52) with Microsoft SMTP Server (TLS) id 8.1.358.0; Fri, 23 Mar 2012 16:24:59 +0100 Received: from mail-gx0-f172.google.com (141.22.200.35) by haw-mailer.haw-hamburg.de (141.22.200.80) with Microsoft SMTP Server (TLS) id 8.1.358.0; Fri, 23 Mar 2012 16:24:59 +0100 Received: by ggmi1 with SMTP id i1so3162953ggm.31 for ; Fri, 23 Mar 2012 08:24:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.30.3 with SMTP id o3mr15210633oeh.9.1332516297358; Fri, 23 Mar 2012 08:24:57 -0700 (PDT) Received: by 10.182.186.10 with HTTP; Fri, 23 Mar 2012 08:24:57 -0700 (PDT) Date: Fri, 23 Mar 2012 16:24:57 +0100 Message-ID: From: =?ISO-8859-1?Q?Sebastian_W=F6lke?= To: , , , Content-Type: multipart/alternative; boundary="e89a8ff1c60c8fbe3504bbeaa0d9" X-Mailman-Approved-At: Tue, 03 Apr 2012 14:31:15 -0700 Subject: [pim] Multicast Proxy Release X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Sebastian.Woelke@haw-hamburg.de List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 15:25:06 -0000 --e89a8ff1c60c8fbe3504bbeaa0d9 Content-Type: text/plain; charset="ISO-8859-1" Hi all, I want to announce our IGMP/MLD proxy implementation named mcproxy. It is implemented in C++ and conforms to RFC 4605. Mcproxy runs on Linux with Kernel version > 2.6.36. Its core features are: - support of IGMPv2/MLDv1; IGMPv3/MLDv2 support coming soon - multiple proxy instances per host: needed for PMIPv6 (RFC6224) - dynamic configuration: add/del downstream interfaces at runtime - high performance and throughput: operates on Linux Kernel tables The latest beta version and further documentation of the mcproxy prototype are available at http://mcproxy.realmv6.org/ Any questions and feedback are very welcome. Regards, Sebastian --e89a8ff1c60c8fbe3504bbeaa0d9 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
Hi all,

I want to announce our IGM= P/MLD proxy implementation named mcproxy. It is implemented in C++ and=A0co= nforms to RFC 4605. Mcproxy=A0runs on Linux with Kernel version > 2.6.36= .=A0

Its core features are:

=A0 =A0= - support of IGMPv2/MLDv1; IGMPv3/MLDv2 support coming soon
=A0 = =A0 - multiple proxy instances per host: needed for=A0PMIPv6 (RFC6224)
=A0 =A0 - dynamic configuration: add/del downstream interfaces at runtime
=A0 =A0 - high performance and throughput: operates on Linux Kerne= l tables

The latest beta version and further docum= entation of the mcproxy prototype are available at=A0http://m= cproxy.realmv6.org/

Any questions and feedback are very welcome.
=
Regards,
=A0 Sebastian

<= /div> --e89a8ff1c60c8fbe3504bbeaa0d9-- From hou@cisco.com Wed Apr 4 11:55:15 2012 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2049111E80B0 for ; Wed, 4 Apr 2012 11:55:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.532 X-Spam-Level: X-Spam-Status: No, score=-8.532 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V4hJoJrYsGa5 for ; Wed, 4 Apr 2012 11:55:13 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id AFD0A11E80B7 for ; Wed, 4 Apr 2012 11:55:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=hou@cisco.com; l=9379; q=dns/txt; s=iport; t=1333565713; x=1334775313; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=K8M7LFYVQavgvbNicWSZ8o+KdSxzdTl/WlhN3cDUPqU=; b=cuK/ynnz+SK3lE4igxB9hJvUxzJm++W0mA/AOVyGUCA7R/WIi036xKJ/ fyjcJZ1S5r5AQZTsS64Vxzyc9JE4sE4O39LHNTYdG34MgdFM/O3MV3Bby 1sHOxYEOCea0hGIdM/Q8q/Lm+WLFtGQYBMlG4ZVSPVlar464JCgKQZCtC g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: An0QAOSYfE+rRDoG/2dsb2JhbABFtxkDgQoCgQeCCQEBAQMBAQEBDwEnAgExBgUFDQEIbTABAQQBDQUihW+BcwQBC5tNnlkEiw5AhQYEiFiNC45HJ4FCgweBNQc X-IronPort-AV: E=Sophos;i="4.75,370,1330905600"; d="scan'208";a="36495133" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 04 Apr 2012 18:55:12 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q34ItCx3026941; Wed, 4 Apr 2012 18:55:12 GMT Received: from xmb-sjc-231.amer.cisco.com ([128.107.191.73]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 4 Apr 2012 11:55:12 -0700 Received: from 128.107.163.65 ([128.107.163.65]) by xmb-sjc-231.amer.cisco.com ([128.107.191.73]) with Microsoft Exchange Server HTTP-DAV ; Wed, 4 Apr 2012 18:55:11 +0000 User-Agent: Microsoft-Entourage/12.26.0.100708 Date: Wed, 04 Apr 2012 11:55:16 -0700 From: Heidi Ou To: , , Yiqun Cai Message-ID: Thread-Topic: [pim] AD review of draft-ietf-pim-pop-count Thread-Index: Ac0R2VKxh4+5Xo/xQGG8Wxk3SqBiiQAuyZrh In-Reply-To: <005101cd11d9$b1c44da0$154ce8e0$@olddog.co.uk> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 04 Apr 2012 18:55:12.0613 (UTC) FILETIME=[7717F150:01CD1294] Cc: pim@ietf.org Subject: Re: [pim] AD review of draft-ietf-pim-pop-count X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 18:55:15 -0000 Adrian, Thanks for your review. We will address your comments in a new version. - Heidi On 4/3/12 1:38 PM, "Adrian Farrel" wrote: > Hi, > > Sorry I sat on this I-D a while doing my review. The review is my > usual pass over the document to iron out nits that I think might > show up in IETF last call, Directorate reviews, or during IESG > evaluation. By catching the issues at this stage we can save the > effort of multiple reviewers, and achieve a smoother passage > through the publication process. > > All of my comments can be discussed. > > As it stands, I think a new revision would help address these point > so I will move the I-D into "New Revision Required" state, and when > I see an update I will advance the document to IETF last call. Please > be sure that the new revision passes idnits. > > Thanks, > Adrian > > --- > > Please update Yiqun's email address to yiqunc@microsoft.com and his > coordinates to Microsoft. > > --- > > The RFC Editor likes the document to begin with an Introduction, so > you could move Section 1 into 2.1 and renumber. > > --- > > I think that the RFC Editor likes all figures to be captioned and given > a number (e.g. Figure 1 : A Sample Foobar). Further, they like all > figures to be explicitly referenced form the text. > > That sounds a bore to do, but if you have the energy it might be worth > it. > > --- > > Can you s/this draft/this document/ throughout since, on publication, > this will not be a draft any more. > > --- > > We will get push-back from the IESG to "describe the experiment". > > I think this can be handled relatively easily in the Introduction with > some text such as: > > This is a new proposal for an extension to PIM, and it is not > completely understood what impact collecting information using PIM > would have on the operation of PIM. Many PIM features (including the > core protocol) were first introduced as Experimental RFCs, and it > seems appropriate to advance this work as Experimental. Reports of > implementation and deployment across whole distribution trees or > within sub-trees (see Section 7) will enable an assessment of the > desirability and stability of this feature. The PIM working group > will then consider whether to move this work to the Standards Track. > > I am only showing example text here. I am not attached to the content, > but I am trying to cover the bases in a way that the IESG is likely to > request. Please feel free to use other text if it works better for you. > > --- > > I think you need to expand "oif-list" on first use. > > --- > > Section 3 > > If a PIM router supports this draft, it must send the Pop- > Count-Supported TLV. > > I think this might be better written as: > > A PIM router indicates that it supports this document by sending the > Pop-Count-Supported TLV in a PIM Hello message. > > --- > > Section 3 > > The format of the TLV is defined to be: > > > 0 1 2 3 > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | OptionType | OptionLength | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | OptionValue | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > OptionType = 29, OptionLength = 4, there is no OptionValue semantics > defined at this time but will be included for expandability and be > defined in future revisions of this draft. The format will look > like: > > > 0 1 2 3 > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 29 | 4 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Unallocated Flags | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Unallocated Flags: for now should be sent as 0 and ignored on > receipt. > > > I am ambivalent about defining the flags field. Does PIM require that > an options TLV is always the same length? If so, you are doing the > right thing, but if not, you could equally come back later and define > that, if the length is non-zero, the first four bytes are flags. But > this is Experimental, so I don't object. Mainly I am curious :-) > > But anyway, I don't think you need the TLV format twice, and you need > to allow IANA to make the allocation (although you can suggest a > value in the IANA section). So you could rewrite as: > > The format follows the format of all Hello Option TLVs [RFC4601]: > > 0 1 2 3 > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | OptionType = TBD1 | OptionLength = 4 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Unallocated Flags | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Unallocated Flags: Unused flags SHOULD be sent as 0 and ignored on > receipt. This document defines no flags. > > Then, in Section 8... > > OLD > A new PIM Hello Option type, 29, has been assigned. See [HELLO] for > details. > NEW > IANA is requested to define a new PIM Hello Option type in the > registry at [HELLO]. > > Pop-Count Support TBD1 > > A value of 29 is suggested. > END > > > --- > > Section 4 > > Suggest > > s/Pop-Count attribute/Pop-Count Join Attribute/ > s/to process PIM Join Attribute/to process a PIM Join Attribute/ > > --- > > Section 4 > > Again, to leave this to IANA... > > OLD > Attr Type: 2. > NEW > Attr Type: TBD2 > END > > And then, in Section 8 > > OLD > A new PIM Join Attribute type needs to be assigned. 2 is proposed in > this draft. > NEW > IANA is requested to allocate a new PIM Join Attribute type. > > Pop-Count Join Attribute TBD2 > > A value of 2 is suggested. > > --- > > Section 4 > > Unallocated Flags: The flags which are currently not defined. > If a new flag is defined and sent by a new implementation, an > old implementation should preserve the bit settings. This > means that if a bit was set in a PIM Join message from any of > the downstream routers, then it MUST also be set in any PIM > Join sent upstream. > > Am I being too pedantic? Presumably clear bits MUST also be kept clear. > How about: > This means that a router MUST preserve the settings of all Unallocated > Flags in PIM Join messages received from downstream routers in any PIM > Join sent upstream. > > --- > > Section 4 > > P flag: This flag remains set if all downstream routers support > this specification. That is, they are PIM pop-count capable. > This allows one to tell if the entire sub-tree is completely > accounting capable. > > I'm not clear about this. Is the assumption that a router will clear > this flag if it knows that a downstream router is not PIM pop-count > capable? (I presume that the downstream router would not clear the > flag because it doesn't know about this I-D.) Can you clarify by saying > who has the responsibility to clear the flag? > > --- > > Section 4.2 has some ugly XML bleedthrough > >
> > > --- > > Section 5 has some lower case 2119-type words. Can you check to see > whether you mean upper case. > > --- > > Section 6 is good. It might be nice to note at the top that the section is > non-normative. > > However, the final paragraph (with its recommendation and use of "should > not") seems to be important enough to promote to Section 5 and to use > 2119 language. > > --- > > Section 9 > > I wonder... > > Does collecting this information put any additional burden on the > routers and the network? If so, might it be something that a router > should rate limit to prevent DoS? > > Does access to the information provide assistance to an attacker or > even just violate an operator's confidentiality? If so, there should > be a warning against sniffing attackers if the information is considered > sensitive (I presume encrypting it is not possible). > > Now, you may say "so what?" but I think we should make a habit of > raising flags so that operators are aware and thoughtful. > > _______________________________________________ > pim mailing list > pim@ietf.org > https://www.ietf.org/mailman/listinfo/pim From hou@cisco.com Wed Apr 4 12:29:25 2012 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D66C11E80C4 for ; Wed, 4 Apr 2012 12:29:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.532 X-Spam-Level: X-Spam-Status: No, score=-8.532 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eQhKZ2bwv+fb for ; Wed, 4 Apr 2012 12:29:24 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 1ABAC11E80BE for ; Wed, 4 Apr 2012 12:29:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=hou@cisco.com; l=5429; q=dns/txt; s=iport; t=1333567764; x=1334777364; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=etzZfturxuidmCiY4F6FbkZ5yUm3ONVH9xTj4MLzTa4=; b=O683mjjwgFEc8YLRLb/G3bJ2OeOPFI2qvMKi07SujXtofKxGRygqb/DP Dqpwu4zud+OprPubOSbP7V+TMPlBEhgBCZCMXKnAdPWgHDA+mBTqQ/jBD k5N11AgbFdekrop9ny6YLut0U8nmwWeVgR4Sx9mVdQg0poDOvDMbIQL0W s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApYQANeffE+rRDoG/2dsb2JhbABFtxoDgQoCgQeCCQEBAQMBAQEBDwEnAgExBgUFDQEIbTABAQQBDQUih2IEAQubM55bBItRhH4EiFiNC45HJ4FCgweBNAcB X-IronPort-AV: E=Sophos;i="4.75,370,1330905600"; d="scan'208";a="36500530" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 04 Apr 2012 19:29:23 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q34JTNA4026049; Wed, 4 Apr 2012 19:29:23 GMT Received: from xmb-sjc-231.amer.cisco.com ([128.107.191.73]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 4 Apr 2012 12:29:23 -0700 Received: from 128.107.163.65 ([128.107.163.65]) by xmb-sjc-231.amer.cisco.com ([128.107.191.73]) with Microsoft Exchange Server HTTP-DAV ; Wed, 4 Apr 2012 19:29:22 +0000 User-Agent: Microsoft-Entourage/12.26.0.100708 Date: Wed, 04 Apr 2012 12:29:27 -0700 From: Heidi Ou To: , , Message-ID: Thread-Topic: [pim] AD Review draft-ietf-pim-ecmp Thread-Index: Ac0R00SVA9YAKzzdS32BNClY82vJHQAxfsGJ In-Reply-To: <005001cd11d3$77852ac0$668f8040$@olddog.co.uk> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 04 Apr 2012 19:29:23.0242 (UTC) FILETIME=[3D5D18A0:01CD1299] Cc: pim@ietf.org Subject: Re: [pim] AD Review draft-ietf-pim-ecmp X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 19:29:25 -0000 Hi Adrian, We will generate a new version to address your comments. BTW: my previous reply on "Re:[pim] AD review of draft-ietf-pim-pop-count" was a mistake. thanks - Heidi On 4/3/12 12:53 PM, "Adrian Farrel" wrote: > Hi, > > I have done my usual AD review of your draft in response to the > publication request from the working group. The purpose of the > review is to clean up issues that I think might show up in IETF > last call, Directorate reviews, or during IESG evaluation. By > catching the issues at this stage we can save the effort of multiple > reviewers, and achieve a smoother passage through the publication > process. > > All of my comments can be discussed. > > As it stands, I think a new revision would help address these point > so I will move the I-D into "New Revision Required" state, and when > I see an update I will advance the document to IETF last call. Please > be sure to run idnits on the new revision and fix all of the warnings. > > Thanks, > Adrian > > --- > > It took me some time to determine that you are only talking about > parallel links between adjacent routers and not talking about the > more generic, network view of ECMP. In fact, I was so confused, I > had to ask for clarification on the PIM list. > > In this context, is it really helpful to say ECMP? Wouldn't > "parallel, equal cost links" be a better term? It would also tie in > with other terminology relating to link bundles (such as in TE) while > avoiding confusion with the wider concept of ECMP. > > While I would prefer that the document replaced "ECMP" with "parallel > links" throughout, I understand that this is a lot of effort and you > might not have the stamina to make the change. If you can't/won't do > that, could you please add a clarification to the Abstract and early > in the Introduction to say "In this document, the term ECMP is used to > apply to parallel, single-hop, equal cost links between a pair of > adjacent nodes." > > --- > > Please update Yiqun's email address to yiqunc@microsoft.com and his > coordinates to Microsoft. > > --- > > Please expand RPF in the Abstract and on first use in the Introduction. > > --- > > The RFC Editor usually requires that the first section is the > Introduction, so best to move Section 1 to 2.3 and renumber. > > --- > > The concept of an ECMP bundle is introduced in Section 3, and seems to > be central to the document. That means that the text in Section 2 is > missing this concept. Do you think you should move the definition of > an ECMP bundle to Section 2 so that Section 2.1 can refer to it? > > --- > > In Section 3.2 > > An upstream router may choose not to send ECMP Redirects if it > becomes aware that some of the downstream routers do not support the > message... > > You need to say how it might "become aware". A pointer to 3.5 is > probably enough. > > I think "may" is "MAY" > > --- > > In Section 3.3 > > When a downstream router receives an ECMP Redirect, and detects that > the desired RPF path from its upstream router's point of view is > different from its current one, it should choose to prune from the > current path and join the new path. > > Is that "SHOULD"? > > --- > > Section 3.3 > > If an upstream router receives an ECMP Redirect from another upstream > router, it SHOULD NOT change its forwarding behavior even if the ECMP > Redirect makes it a less preferred RPF neighbor on the receiving > interface. > > Too many "upstreams" to make this easy to parse. Is the second upstream > router upstream of the first upstream router? Or just upstream of the > downstream router? > > Maybe you are missing some pictures in this document! > > --- > > Section 3.4 > > In such an event, the following actions are > recommended. > > Is that "RECOMMENDED"? > > --- > > Section 3.4 > > s/down stream/downstream/ (twice) > > Either > s/re-select a new/re-select a/ > Or > s/re-select a new/select a new/ > > --- > > Section 3.5 > > If a PIM router detects > that any of its neighbor does not support this Hello option, it MUST > not send ECMP Redirects, however, it SHOULD still process any ECMP > Redirects received. > > s/neighbor/neighbors/ > s/MUST not/MUST NOT/ > s/send ECMP Redirects/send ECMP Redirects to that neighbor/ > > What would a legacy node do with an ECMP Redirect that it received? > You should be able to answer this with a reference to an existing RFC. > > --- > > It would help IANA get their actions right if you could use TBD1 and > TBD2 instead of TBD twice. You can then also use those flags in > Section 4. > > --- > > 3.6.2 > > I am missing a definition of how a timestamp is encoded in the Metric > field. Assuming the idea is that the router that has been forwarding > out of its interface for longer will be preferred (by having a smaller > timestamp value), it would be important that everyone has the same > understanding of what a timestamp looks like. > > --- > > Section 4 > > Could you help IANA by naming the registries as they are named on > the IANA pages? > > _______________________________________________ > pim mailing list > pim@ietf.org > https://www.ietf.org/mailman/listinfo/pim From Tina.Tsou.Zouting@huawei.com Thu Apr 5 13:45:15 2012 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D687121F8655 for ; Thu, 5 Apr 2012 13:45:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bomFh66aAQWE for ; Thu, 5 Apr 2012 13:45:15 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 61B0921F8653 for ; Thu, 5 Apr 2012 13:45:15 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AER61956; Thu, 05 Apr 2012 16:45:15 -0400 (EDT) Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 5 Apr 2012 13:45:00 -0700 Received: from SZXEML418-HUB.china.huawei.com (10.82.67.157) by dfweml406-hub.china.huawei.com (10.193.5.131) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 5 Apr 2012 13:44:58 -0700 Received: from SZXEML526-MBX.china.huawei.com ([169.254.2.214]) by szxeml418-hub.china.huawei.com ([10.82.67.157]) with mapi id 14.01.0323.003; Fri, 6 Apr 2012 04:44:54 +0800 From: Tina TSOU To: "pim@ietf.org" Thread-Topic: Comment on draft-lts-pim-hello-mtu? Thread-Index: Ac0TbPRReFB8+MLJQ6Wly2HsnKucXQ== Date: Thu, 5 Apr 2012 20:44:54 +0000 Message-ID: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.193.34.143] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [pim] Comment on draft-lts-pim-hello-mtu? X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 20:45:15 -0000 Dear all, May the author of draft-lts-pim-hello-mtu ask people to read the draft and = provide comments? http://datatracker.ietf.org/doc/draft-lts-pim-hello-mtu/ Thank you in advance. Best Regards, Tina TSOU From stig@venaas.com Mon Apr 9 10:49:26 2012 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFC6221F879A for ; Mon, 9 Apr 2012 10:49:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YycZPH1Nw6QX for ; Mon, 9 Apr 2012 10:49:26 -0700 (PDT) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by ietfa.amsl.com (Postfix) with ESMTP id 63AD821F8796 for ; Mon, 9 Apr 2012 10:49:26 -0700 (PDT) Received: from [10.33.12.93] (128-107-239-233.cisco.com [128.107.239.233]) by ufisa.uninett.no (Postfix) with ESMTPSA id 3D5428031 for ; Mon, 9 Apr 2012 19:49:24 +0200 (CEST) Message-ID: <4F832108.4080208@venaas.com> Date: Mon, 09 Apr 2012 10:48:56 -0700 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: "pim@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [pim] Minutes from pim at IETF 83 in Paris X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 17:49:27 -0000 The minutes are now available at http://www.ietf.org/proceedings/83/minutes/minutes-83-pim.txt Kurt Windisch did a great job with these minutes, but let Mike and me know if you have any corrections. Stig From stig@venaas.com Mon Apr 9 10:58:47 2012 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE07821F87D0 for ; Mon, 9 Apr 2012 10:58:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WZRkHEq2dwat for ; Mon, 9 Apr 2012 10:58:47 -0700 (PDT) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by ietfa.amsl.com (Postfix) with ESMTP id A9F9B21F87CF for ; Mon, 9 Apr 2012 10:58:46 -0700 (PDT) Received: from [10.33.12.93] (128-107-239-233.cisco.com [128.107.239.233]) by ufisa.uninett.no (Postfix) with ESMTPSA id B36178031; Mon, 9 Apr 2012 19:58:44 +0200 (CEST) Message-ID: <4F832352.1000804@venaas.com> Date: Mon, 09 Apr 2012 10:58:42 -0700 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: adrian@olddog.co.uk References: <005101cd11d9$b1c44da0$154ce8e0$@olddog.co.uk> In-Reply-To: <005101cd11d9$b1c44da0$154ce8e0$@olddog.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-ietf-pim-pop-count@tools.ietf.org, pim@ietf.org Subject: Re: [pim] AD review of draft-ietf-pim-pop-count X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 17:58:48 -0000 On 4/3/2012 1:38 PM, Adrian Farrel wrote: > Hi, > > Sorry I sat on this I-D a while doing my review. The review is my > usual pass over the document to iron out nits that I think might > show up in IETF last call, Directorate reviews, or during IESG > evaluation. By catching the issues at this stage we can save the > effort of multiple reviewers, and achieve a smoother passage > through the publication process. > > All of my comments can be discussed. Thanks for the detailed review. Your comments look good. I will start working on an update. Stig > > As it stands, I think a new revision would help address these point > so I will move the I-D into "New Revision Required" state, and when > I see an update I will advance the document to IETF last call. Please > be sure that the new revision passes idnits. > > Thanks, > Adrian > > --- > > Please update Yiqun's email address to yiqunc@microsoft.com and his > coordinates to Microsoft. > > --- > > The RFC Editor likes the document to begin with an Introduction, so > you could move Section 1 into 2.1 and renumber. > > --- > > I think that the RFC Editor likes all figures to be captioned and given > a number (e.g. Figure 1 : A Sample Foobar). Further, they like all > figures to be explicitly referenced form the text. > > That sounds a bore to do, but if you have the energy it might be worth > it. > > --- > > Can you s/this draft/this document/ throughout since, on publication, > this will not be a draft any more. > > --- > > We will get push-back from the IESG to "describe the experiment". > > I think this can be handled relatively easily in the Introduction with > some text such as: > > This is a new proposal for an extension to PIM, and it is not > completely understood what impact collecting information using PIM > would have on the operation of PIM. Many PIM features (including the > core protocol) were first introduced as Experimental RFCs, and it > seems appropriate to advance this work as Experimental. Reports of > implementation and deployment across whole distribution trees or > within sub-trees (see Section 7) will enable an assessment of the > desirability and stability of this feature. The PIM working group > will then consider whether to move this work to the Standards Track. > > I am only showing example text here. I am not attached to the content, > but I am trying to cover the bases in a way that the IESG is likely to > request. Please feel free to use other text if it works better for you. > > --- > > I think you need to expand "oif-list" on first use. > > --- > > Section 3 > > If a PIM router supports this draft, it must send the Pop- > Count-Supported TLV. > > I think this might be better written as: > > A PIM router indicates that it supports this document by sending the > Pop-Count-Supported TLV in a PIM Hello message. > > --- > > Section 3 > > The format of the TLV is defined to be: > > > 0 1 2 3 > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | OptionType | OptionLength | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | OptionValue | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > OptionType = 29, OptionLength = 4, there is no OptionValue semantics > defined at this time but will be included for expandability and be > defined in future revisions of this draft. The format will look > like: > > > 0 1 2 3 > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 29 | 4 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Unallocated Flags | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Unallocated Flags: for now should be sent as 0 and ignored on > receipt. > > > I am ambivalent about defining the flags field. Does PIM require that > an options TLV is always the same length? If so, you are doing the > right thing, but if not, you could equally come back later and define > that, if the length is non-zero, the first four bytes are flags. But > this is Experimental, so I don't object. Mainly I am curious :-) > > But anyway, I don't think you need the TLV format twice, and you need > to allow IANA to make the allocation (although you can suggest a > value in the IANA section). So you could rewrite as: > > The format follows the format of all Hello Option TLVs [RFC4601]: > > 0 1 2 3 > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | OptionType = TBD1 | OptionLength = 4 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Unallocated Flags | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Unallocated Flags: Unused flags SHOULD be sent as 0 and ignored on > receipt. This document defines no flags. > > Then, in Section 8... > > OLD > A new PIM Hello Option type, 29, has been assigned. See [HELLO] for > details. > NEW > IANA is requested to define a new PIM Hello Option type in the > registry at [HELLO]. > > Pop-Count Support TBD1 > > A value of 29 is suggested. > END > > > --- > > Section 4 > > Suggest > > s/Pop-Count attribute/Pop-Count Join Attribute/ > s/to process PIM Join Attribute/to process a PIM Join Attribute/ > > --- > > Section 4 > > Again, to leave this to IANA... > > OLD > Attr Type: 2. > NEW > Attr Type: TBD2 > END > > And then, in Section 8 > > OLD > A new PIM Join Attribute type needs to be assigned. 2 is proposed in > this draft. > NEW > IANA is requested to allocate a new PIM Join Attribute type. > > Pop-Count Join Attribute TBD2 > > A value of 2 is suggested. > > --- > > Section 4 > > Unallocated Flags: The flags which are currently not defined. > If a new flag is defined and sent by a new implementation, an > old implementation should preserve the bit settings. This > means that if a bit was set in a PIM Join message from any of > the downstream routers, then it MUST also be set in any PIM > Join sent upstream. > > Am I being too pedantic? Presumably clear bits MUST also be kept clear. > How about: > This means that a router MUST preserve the settings of all Unallocated > Flags in PIM Join messages received from downstream routers in any PIM > Join sent upstream. > > --- > > Section 4 > > P flag: This flag remains set if all downstream routers support > this specification. That is, they are PIM pop-count capable. > This allows one to tell if the entire sub-tree is completely > accounting capable. > > I'm not clear about this. Is the assumption that a router will clear > this flag if it knows that a downstream router is not PIM pop-count > capable? (I presume that the downstream router would not clear the > flag because it doesn't know about this I-D.) Can you clarify by saying > who has the responsibility to clear the flag? > > --- > > Section 4.2 has some ugly XML bleedthrough > >
> > > --- > > Section 5 has some lower case 2119-type words. Can you check to see > whether you mean upper case. > > --- > > Section 6 is good. It might be nice to note at the top that the section is > non-normative. > > However, the final paragraph (with its recommendation and use of "should > not") seems to be important enough to promote to Section 5 and to use > 2119 language. > > --- > > Section 9 > > I wonder... > > Does collecting this information put any additional burden on the > routers and the network? If so, might it be something that a router > should rate limit to prevent DoS? > > Does access to the information provide assistance to an attacker or > even just violate an operator's confidentiality? If so, there should > be a warning against sniffing attackers if the information is considered > sensitive (I presume encrypting it is not possible). > > Now, you may say "so what?" but I think we should make a habit of > raising flags so that operators are aware and thoughtful. > > _______________________________________________ > pim mailing list > pim@ietf.org > https://www.ietf.org/mailman/listinfo/pim From stig@venaas.com Mon Apr 9 11:01:44 2012 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F08621F8667 for ; Mon, 9 Apr 2012 11:01:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mItyJoeDLbdh for ; Mon, 9 Apr 2012 11:01:43 -0700 (PDT) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by ietfa.amsl.com (Postfix) with ESMTP id 53CBD21F8666 for ; Mon, 9 Apr 2012 11:01:43 -0700 (PDT) Received: from [10.33.12.93] (128-107-239-234.cisco.com [128.107.239.234]) by ufisa.uninett.no (Postfix) with ESMTPSA id 054E68031; Mon, 9 Apr 2012 20:01:41 +0200 (CEST) Message-ID: <4F832403.3060607@venaas.com> Date: Mon, 09 Apr 2012 11:01:39 -0700 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Tina TSOU References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "pim@ietf.org" Subject: Re: [pim] Comment on draft-lts-pim-hello-mtu? X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 18:01:44 -0000 On 4/5/2012 1:44 PM, Tina TSOU wrote: > Dear all, > May the author of draft-lts-pim-hello-mtu ask people to read the draft and provide comments? > > http://datatracker.ietf.org/doc/draft-lts-pim-hello-mtu/ > > Thank you in advance. See the minutes I just posted if you like. My main comment is that MTU is important for other protocols too, and also for traffic/data, so I'm wondering if it would be better to do it with some more general protocol. Maybe BFD or in the IGP? For IPv6 one could perhaps use RAs? Stig > > > Best Regards, > Tina TSOU > > > _______________________________________________ > pim mailing list > pim@ietf.org > https://www.ietf.org/mailman/listinfo/pim From gjshep@gmail.com Mon Apr 9 11:08:21 2012 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A34821F875E for ; Mon, 9 Apr 2012 11:08:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7r4TTIR2pPCd for ; Mon, 9 Apr 2012 11:08:20 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2890E21F8764 for ; Mon, 9 Apr 2012 11:08:19 -0700 (PDT) Received: by bkuw5 with SMTP id w5so3822204bku.31 for ; Mon, 09 Apr 2012 11:08:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=LCpZvxdRDiet4iVLIb99d1bL714qjuOTvTITm5WD90U=; b=RamKPJTzSPJq92eOSwCnEONEk2hn8LW0L+YL3t3qqd+2epMHMZnreNMSsnUusJae4P /a4gUxzQ6JuAGjEZPkqHCv/ORNTAfCiOZ9a0J4chOsx0WGsryNFi3giNkHnu2vvrbrnV f5Ct5dgyCBoiX+K1q4HQZLdOMUu6IKk+MOnLUFiIq4Yo8qx6NJRXigBPxVUXClsFA8qw wfnKdZNj1qzOHrBnBtH3lpl23aWbw9q4h55J1hclei3UlaKPQK+G22hU3+ZWvBQMXtEf K9IORGgYWqO0ckjaRlMG2ZhJV/L5/hZiqY3p0wbcSY52le46HLQOzVWPLoj+06omlww4 H1Iw== MIME-Version: 1.0 Received: by 10.204.156.79 with SMTP id v15mr3455002bkw.37.1333994897942; Mon, 09 Apr 2012 11:08:17 -0700 (PDT) Received: by 10.204.99.67 with HTTP; Mon, 9 Apr 2012 11:08:17 -0700 (PDT) In-Reply-To: <4F832352.1000804@venaas.com> References: <005101cd11d9$b1c44da0$154ce8e0$@olddog.co.uk> <4F832352.1000804@venaas.com> Date: Mon, 9 Apr 2012 11:08:17 -0700 Message-ID: From: Greg Shepherd To: Stig Venaas Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: draft-ietf-pim-pop-count@tools.ietf.org, pim@ietf.org Subject: Re: [pim] AD review of draft-ietf-pim-pop-count X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: gjshep@gmail.com List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 18:08:21 -0000 Thanks Stig! -G On Mon, Apr 9, 2012 at 10:58 AM, Stig Venaas wrote: > On 4/3/2012 1:38 PM, Adrian Farrel wrote: >> >> Hi, >> >> Sorry I sat on this I-D a while doing my review. The review is my >> usual pass over the document to iron out nits that I think might >> show up in IETF last call, Directorate reviews, or during IESG >> evaluation. By catching the issues at this stage we can save the >> effort of multiple reviewers, and achieve a smoother passage >> through the publication process. >> >> All of my comments can be discussed. > > > Thanks for the detailed review. Your comments look good. I will start > working on an update. > > Stig > > >> >> As it stands, I think a new revision would help address these point >> so I will move the I-D into "New Revision Required" state, and when >> I see an update I will advance the document to IETF last call. Please >> be sure that the new revision passes idnits. >> >> Thanks, >> Adrian >> >> --- >> >> Please update Yiqun's email address to yiqunc@microsoft.com and his >> coordinates to Microsoft. >> >> --- >> >> The RFC Editor likes the document to begin with an Introduction, so >> you could move Section 1 into 2.1 and renumber. >> >> --- >> >> I think that the RFC Editor likes all figures to be captioned and given >> a number (e.g. Figure 1 : A Sample Foobar). Further, they like all >> figures to be explicitly referenced form the text. >> >> That sounds a bore to do, but if you have the energy it might be worth >> it. >> >> --- >> >> Can you s/this draft/this document/ throughout since, on publication, >> this will not be a draft any more. >> >> --- >> >> We will get push-back from the IESG to "describe the experiment". >> >> I think this can be handled relatively easily in the Introduction with >> some text such as: >> >> =A0 =A0This is a new proposal for an extension to PIM, and it is not >> =A0 =A0completely understood what impact collecting information using PI= M >> =A0 =A0would have on the operation of PIM. Many PIM features (including = the >> =A0 =A0core protocol) were first introduced as Experimental RFCs, and it >> =A0 =A0seems appropriate to advance this work as Experimental. Reports o= f >> =A0 =A0implementation and deployment across whole distribution trees or >> =A0 =A0within sub-trees (see Section 7) will enable an assessment of the >> =A0 =A0desirability and stability of this feature. The PIM working group >> =A0 =A0will then consider whether to move this work to the Standards Tra= ck. >> >> I am only showing example text here. I am not attached to the content, >> but I am trying to cover the bases in a way that the IESG is likely to >> request. Please feel free to use other text if it works better for you. >> >> --- >> >> I think you need to expand "oif-list" on first use. >> >> --- >> >> Section 3 >> >> =A0 =A0If a PIM router supports this draft, it must send the Pop- >> =A0 =A0Count-Supported TLV. >> >> I think this might be better written as: >> >> =A0 =A0A PIM router indicates that it supports this document by sending = the >> =A0 =A0Pop-Count-Supported TLV in a PIM Hello message. >> >> --- >> >> Section 3 >> >> =A0 =A0The format of the TLV is defined to be: >> >> >> =A0 =A0 =A0 =A00 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 1 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 2 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 3 >> =A0 =A0 =A0 =A00 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 >> =A0 =A0 =A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+ >> =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0OptionType =A0 =A0 =A0 =A0 =A0 | =A0 = =A0 =A0 =A0 OptionLength =A0 =A0 =A0 =A0 =A0| >> =A0 =A0 =A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+ >> =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0OptionV= alue =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| >> =A0 =A0 =A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+ >> >> =A0 =A0OptionType =3D 29, OptionLength =3D 4, there is no OptionValue se= mantics >> =A0 =A0defined at this time but will be included for expandability and b= e >> =A0 =A0defined in future revisions of this draft. =A0The format will loo= k >> =A0 =A0like: >> >> >> =A0 =A0 =A0 =A00 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 1 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 2 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 3 >> =A0 =A0 =A0 =A00 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 >> =A0 =A0 =A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+ >> =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 29 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= | =A0 =A0 =A0 =A0 =A0 =A0 =A04 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| >> =A0 =A0 =A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+ >> =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Unallocated Fla= gs =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| >> =A0 =A0 =A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+ >> >> =A0 =A0Unallocated Flags: =A0 for now should be sent as 0 and ignored on >> =A0 =A0 =A0 receipt. >> >> >> I am ambivalent about defining the flags field. Does PIM require that >> an options TLV is always the same length? If so, you are doing the >> right thing, but if not, you could equally come back later and define >> that, if the length is non-zero, the first four bytes are flags. But >> this is Experimental, so I don't object. Mainly I am curious :-) >> >> But anyway, I don't think you need the TLV format twice, and you need >> to allow IANA to make the allocation (although you can suggest a >> value in the IANA section). So you could rewrite as: >> >> =A0 =A0The format follows the format of all Hello Option TLVs [RFC4601]: >> >> =A0 =A0 =A0 =A00 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 1 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 2 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 3 >> =A0 =A0 =A0 =A00 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 >> =A0 =A0 =A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+ >> =A0 =A0 =A0 | =A0 =A0 OptionType =3D TBD1 =A0 =A0 =A0 =A0 | =A0 =A0 =A0O= ptionLength =3D 4 =A0 =A0 =A0 =A0 | >> =A0 =A0 =A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+ >> =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Unallocated Fla= gs =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| >> =A0 =A0 =A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+ >> >> =A0 =A0Unallocated Flags: =A0 Unused flags SHOULD be sent as 0 and ignor= ed on >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 receipt. This document d= efines no flags. >> >> Then, in Section 8... >> >> OLD >> =A0 =A0A new PIM Hello Option type, 29, has been assigned. =A0See [HELLO= ] for >> =A0 =A0details. >> NEW >> =A0 =A0IANA is requested to define a new PIM Hello Option type in the >> =A0 =A0registry at [HELLO]. >> >> =A0 =A0 =A0 Pop-Count Support =A0 TBD1 >> >> =A0 =A0A value of 29 is suggested. >> END >> >> >> --- >> >> Section 4 >> >> Suggest >> >> s/Pop-Count attribute/Pop-Count Join Attribute/ >> s/to process PIM Join Attribute/to process a PIM Join Attribute/ >> >> --- >> >> Section 4 >> >> Again, to leave this to IANA... >> >> OLD >> =A0 =A0Attr Type: =A0 2. >> NEW >> =A0 =A0Attr Type: =A0 TBD2 >> END >> >> And then, in Section 8 >> >> OLD >> =A0 =A0A new PIM Join Attribute type needs to be assigned. 2 is proposed= in >> =A0 =A0this draft. >> NEW >> =A0 =A0IANA is requested to allocate a new PIM Join Attribute type. >> >> =A0 =A0 =A0 Pop-Count Join Attribute =A0 TBD2 >> >> =A0 =A0A value of 2 is suggested. >> >> --- >> >> Section 4 >> >> =A0 =A0 =A0 Unallocated Flags: =A0 The flags which are currently not def= ined. >> =A0 =A0 =A0 =A0 =A0If a new flag is defined and sent by a new implementa= tion, an >> =A0 =A0 =A0 =A0 =A0old implementation should preserve the bit settings. = =A0This >> =A0 =A0 =A0 =A0 =A0means that if a bit was set in a PIM Join message fro= m any of >> =A0 =A0 =A0 =A0 =A0the downstream routers, then it MUST also be set in a= ny PIM >> =A0 =A0 =A0 =A0 =A0Join sent upstream. >> >> Am I being too pedantic? Presumably clear bits MUST also be kept clear. >> How about: >> This means that a router MUST preserve the settings of all Unallocated >> Flags in PIM Join messages received from downstream routers in any PIM >> Join sent upstream. >> >> --- >> >> Section 4 >> >> =A0 =A0 =A0 P flag: =A0 This flag remains set if all downstream routers = support >> =A0 =A0 =A0 =A0 =A0this specification. =A0That is, they are PIM pop-coun= t capable. >> =A0 =A0 =A0 =A0 =A0This allows one to tell if the entire sub-tree is com= pletely >> =A0 =A0 =A0 =A0 =A0accounting capable. >> >> I'm not clear about this. Is the assumption that a router will clear >> this flag if it knows that a downstream router is not PIM pop-count >> capable? (I presume that the downstream router would not clear the >> flag because it doesn't know about this I-D.) Can you clarify by saying >> who has the responsibility to clear the flag? >> >> --- >> >> Section 4.2 has some ugly XML bleedthrough >> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> >> --- >> >> Section 5 has some lower case 2119-type words. Can you check to see >> whether you mean upper case. >> >> --- >> >> Section 6 is good. It might be nice to note at the top that the section = is >> non-normative. >> >> However, the final paragraph (with its recommendation and use of "should >> not") seems to be important enough to promote to Section 5 and to use >> 2119 language. >> >> --- >> >> Section 9 >> >> I wonder... >> >> Does collecting this information put any additional burden on the >> routers and the network? If so, might it be something that a router >> should rate limit to prevent DoS? >> >> Does access to the information provide assistance to an attacker or >> even just violate an operator's confidentiality? If so, there should >> be a warning against sniffing attackers if the information is considered >> sensitive (I presume encrypting it is not possible). >> >> Now, you may say "so what?" but I think we should make a habit of >> raising flags so that operators are aware and thoughtful. >> >> _______________________________________________ >> pim mailing list >> pim@ietf.org >> https://www.ietf.org/mailman/listinfo/pim > > From Tina.Tsou.Zouting@huawei.com Mon Apr 9 11:19:26 2012 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB0E421F87CC for ; Mon, 9 Apr 2012 11:19:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K5ZnIrlU03ec for ; Mon, 9 Apr 2012 11:19:26 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 07D4221F8768 for ; Mon, 9 Apr 2012 11:19:25 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AFB75858; Mon, 09 Apr 2012 14:19:24 -0400 (EDT) Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 9 Apr 2012 11:17:18 -0700 Received: from SZXEML409-HUB.china.huawei.com (10.82.67.136) by dfweml407-hub.china.huawei.com (10.193.5.132) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 9 Apr 2012 11:17:20 -0700 Received: from SZXEML526-MBX.china.huawei.com ([169.254.2.22]) by szxeml409-hub.china.huawei.com ([10.82.67.136]) with mapi id 14.01.0323.003; Tue, 10 Apr 2012 02:17:11 +0800 From: Tina TSOU To: Stig Venaas Thread-Topic: [pim] Comment on draft-lts-pim-hello-mtu? Thread-Index: Ac0TbPRReFB8+MLJQ6Wly2HsnKucXQCys0+AABFKQ0A= Date: Mon, 9 Apr 2012 18:17:11 +0000 Message-ID: References: <4F832403.3060607@venaas.com> In-Reply-To: <4F832403.3060607@venaas.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.246.19] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "pim@ietf.org" Subject: Re: [pim] Comment on draft-lts-pim-hello-mtu? X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 18:19:27 -0000 Tina > -----Original Message----- > From: Stig Venaas [mailto:stig@venaas.com] > Sent: Monday, April 09, 2012 11:02 AM > To: Tina TSOU > Cc: pim@ietf.org > Subject: Re: [pim] Comment on draft-lts-pim-hello-mtu? >=20 > On 4/5/2012 1:44 PM, Tina TSOU wrote: > > Dear all, > > May the author of draft-lts-pim-hello-mtu ask people to read the > draft and provide comments? > > > > http://datatracker.ietf.org/doc/draft-lts-pim-hello-mtu/ > > > > Thank you in advance. >=20 > See the minutes I just posted if you like. >=20 > My main comment is that MTU is important for other protocols too, and > also for traffic/data, so I'm wondering if it would be better to do it > with some more general protocol. Maybe BFD or in the IGP? Which WG does IGP belong to? > For IPv6 one could perhaps use RAs? >=20 > Stig >=20 > > > > > > Best Regards, > > Tina TSOU > > > > > > _______________________________________________ > > pim mailing list > > pim@ietf.org > > https://www.ietf.org/mailman/listinfo/pim From helen.liu@huawei.com Tue Apr 10 04:09:00 2012 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26AD821F8731; Tue, 10 Apr 2012 04:09:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id omCGx+M3DyYX; Tue, 10 Apr 2012 04:08:59 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 43D3121F872F; Tue, 10 Apr 2012 04:08:59 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AFC29919; Tue, 10 Apr 2012 07:08:59 -0400 (EDT) Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 10 Apr 2012 04:06:42 -0700 Received: from SZXEML423-HUB.china.huawei.com (10.82.67.162) by dfweml405-hub.china.huawei.com (10.193.5.102) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 10 Apr 2012 04:06:41 -0700 Received: from SZXEML501-MBS.china.huawei.com ([169.254.5.163]) by szxeml423-hub.china.huawei.com ([10.82.67.162]) with mapi id 14.01.0323.003; Tue, 10 Apr 2012 19:06:30 +0800 From: Liuhui To: Stig Venaas , Tina TSOU Thread-Topic: [pim] Comment on draft-lts-pim-hello-mtu? Thread-Index: Ac0TbPRReFB8+MLJQ6Wly2HsnKucXQCys0+AADOfugA= Date: Tue, 10 Apr 2012 11:06:30 +0000 Message-ID: <0521328FA8CCCE4089CA3C9261A28DD9374E43D0@SZXEML501-MBS.china.huawei.com> References: <4F832403.3060607@venaas.com> In-Reply-To: <4F832403.3060607@venaas.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.108.4.72] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "rtg-bfd@ietf.org" , "pim@ietf.org" Subject: Re: [pim] Comment on draft-lts-pim-hello-mtu? X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 11:09:00 -0000 Hi Stig, Thanks for the comments. I also introduce the points in minutes below for d= iscussion. Thanks, Liu Hui > -----Original Message----- > From: pim-bounces@ietf.org [mailto:pim-bounces@ietf.org] On Behalf Of > Stig Venaas > Sent: Tuesday, April 10, 2012 2:02 AM > To: Tina TSOU > Cc: pim@ietf.org > Subject: Re: [pim] Comment on draft-lts-pim-hello-mtu? >=20 > On 4/5/2012 1:44 PM, Tina TSOU wrote: > > Dear all, > > May the author of draft-lts-pim-hello-mtu ask people to read the draft > and provide comments? > > > > http://datatracker.ietf.org/doc/draft-lts-pim-hello-mtu/ > > > > Thank you in advance. >=20 > See the minutes I just posted if you like. "Stig: Useful if there are msiconfigurations or asymmetric MTUs for routers= on a link. But not just a PIM problem." [LH] Agree. E.g. OSPF also has MTU option carried in its Database Descripti= on packet.=20 =20 "Bill: If you are using MTU for control packets you may be able to send goo= d control packets but if the data packets are still too big, this could be = a bad thing. We need to make sure that this isn't a bad thing and explain i= t" [LH] Accepted. Could we explain it in this way: the control and data plane = are run independently. The control plane makes sure that forwarding paths a= re setup even though there exists asymmetric MTUs. Even though some data pa= ckets exceeding MTU limitation of some point of paths cannot be processed p= roperly, other packets in scope will be normally forwarded and delivered. A= nd it's up to first-hop or head- end to determine the length of a data pack= et, with other measures such as PMTU. "Dino: Population count helps because you can drop the packets at the first= hop router." [LH]Pop count is a PMTU-like method, which should deal with data packet. >=20 > My main comment is that MTU is important for other protocols too, [LH] It's important for protocol between its adjacent peers when they have = to exchange volumes of data, such as PIM Join with large amounts of group s= tates, and OSPF Database Description carrying all link-states during initia= lization. > and also for traffic/data,=20 [LH] I suppose PMTU-like methods are more applicable for traffic/data, whil= e for PIM and OSPF the key issue is between two adjacent hops where message= s often having to be segmented. They are for different purpose and should u= se different measures > so I'm wondering if it would be better > to do it with some more general protocol. Maybe BFD or in the IGP? > For IPv6 one could perhaps use RAs? [LH] Good points. Please see my considerations: For per-hop MTU here there are two steps implied, i.e., how PIM acquire= s its peer MTU info, and how it uses it. The first step has the possibility= to be generalized, and the second is somewhat protocol specific Then does this 'generalization' mean BFD or IGP or RA? As PIM is protoc= ol independent, we cannot assume it always run with IGP. So IGP might be no= t a good option for generalization.=20 RA has already had MTU option there, but it's for use for the nodes not= the routers. Even if the router takes the role of a node, there are no exp= licit peer and one common MTU is taken for all nodes in RA case, which is d= ifferent from the PIM one. And RA is applicable to only IPv6 network. BFD is more general. Should it be extended as here to cover most protoc= ols? It is not impossible, but the precondition is every protocol expects t= he same information from the common structure maintained by BFD. It deserve= s it if the number of protocols having this control message segmenting requ= irement is not small. PIM extension is proposed because there is no common structure availabl= e right now, and promoted by resolving the current network issues. It can b= e applied to both IPv4 and IPv6 networks, and doesn't mind whether IGP or B= FD is running or not.=20 >=20 > Stig >=20 > > > > > > Best Regards, > > Tina TSOU > > > > > > _______________________________________________ > > pim mailing list > > pim@ietf.org > > https://www.ietf.org/mailman/listinfo/pim >=20 > _______________________________________________ > pim mailing list > pim@ietf.org > https://www.ietf.org/mailman/listinfo/pim From internet-drafts@ietf.org Tue Apr 10 08:01:29 2012 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 384A111E80F4; Tue, 10 Apr 2012 08:01:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.558 X-Spam-Level: X-Spam-Status: No, score=-102.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7do1pZHuVwdQ; Tue, 10 Apr 2012 08:01:28 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF70F11E80F0; Tue, 10 Apr 2012 08:01:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120410150128.27393.5864.idtracker@ietfa.amsl.com> Date: Tue, 10 Apr 2012 08:01:28 -0700 Cc: pim@ietf.org Subject: [pim] I-D Action: draft-ietf-pim-explicit-tracking-01.txt X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 15:01:29 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Protocol Independent Multicast Workin= g Group of the IETF. Title : IGMP/MLD-Based Explicit Membership Tracking Function for= Multicast Routers Author(s) : Hitoshi Asaeda Nicolai Leymann Filename : draft-ietf-pim-explicit-tracking-01.txt Pages : 10 Date : 2012-04-10 This document describes the IGMP/MLD-based explicit membership tracking function for multicast routers. The explicit tracking function is useful for accounting and contributes to saving network resource and fast leaves (i.e. shortened leave latency). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pim-explicit-tracking-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-pim-explicit-tracking-01.txt From stig@venaas.com Tue Apr 10 11:32:22 2012 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C285E11E810C for ; Tue, 10 Apr 2012 11:32:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tllcmQF7iWtH for ; Tue, 10 Apr 2012 11:32:21 -0700 (PDT) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by ietfa.amsl.com (Postfix) with ESMTP id 29D8711E8139 for ; Tue, 10 Apr 2012 11:32:21 -0700 (PDT) Received: from [10.33.12.93] (128-107-239-233.cisco.com [128.107.239.233]) by ufisa.uninett.no (Postfix) with ESMTPSA id D31B3802C; Tue, 10 Apr 2012 20:32:18 +0200 (CEST) Message-ID: <4F847CAB.70402@venaas.com> Date: Tue, 10 Apr 2012 11:32:11 -0700 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: adrian@olddog.co.uk References: <005101cd11d9$b1c44da0$154ce8e0$@olddog.co.uk> <4F832352.1000804@venaas.com> In-Reply-To: <4F832352.1000804@venaas.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-ietf-pim-pop-count@tools.ietf.org, pim@ietf.org Subject: Re: [pim] AD review of draft-ietf-pim-pop-count X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 18:32:22 -0000 Hi I've been editing the document and hopefully resolved most of your concerns. Please see my comments below. Unless you see any obvious issues based on my comments, I can go ahead and submit a new version. Note that these changes are fairly big, I made a few additional ones, so I feel we also need to give the WG some time to review them. And of course also for you and the other authors to review them. Thanks a lot, I think this improved the document significantly. I also found some issues myself that I tried to take care of. On 4/9/2012 10:58 AM, Stig Venaas wrote: > On 4/3/2012 1:38 PM, Adrian Farrel wrote: >> Hi, >> >> Sorry I sat on this I-D a while doing my review. The review is my >> usual pass over the document to iron out nits that I think might >> show up in IETF last call, Directorate reviews, or during IESG >> evaluation. By catching the issues at this stage we can save the >> effort of multiple reviewers, and achieve a smoother passage >> through the publication process. >> >> All of my comments can be discussed. > > Thanks for the detailed review. Your comments look good. I will start > working on an update. > > Stig > >> >> As it stands, I think a new revision would help address these point >> so I will move the I-D into "New Revision Required" state, and when >> I see an update I will advance the document to IETF last call. Please >> be sure that the new revision passes idnits. >> >> Thanks, >> Adrian >> >> --- >> >> Please update Yiqun's email address to yiqunc@microsoft.com and his >> coordinates to Microsoft. Done >> --- >> >> The RFC Editor likes the document to begin with an Introduction, so >> you could move Section 1 into 2.1 and renumber. Done >> --- >> >> I think that the RFC Editor likes all figures to be captioned and given >> a number (e.g. Figure 1 : A Sample Foobar). Further, they like all >> figures to be explicitly referenced form the text. >> >> That sounds a bore to do, but if you have the energy it might be worth >> it. Sorry, I didn't have the energy. I don't really think it is needed. And it can be done later if it really seems to be needed. >> --- >> >> Can you s/this draft/this document/ throughout since, on publication, >> this will not be a draft any more. Done >> --- >> >> We will get push-back from the IESG to "describe the experiment". >> >> I think this can be handled relatively easily in the Introduction with >> some text such as: >> >> This is a new proposal for an extension to PIM, and it is not >> completely understood what impact collecting information using PIM >> would have on the operation of PIM. Many PIM features (including the >> core protocol) were first introduced as Experimental RFCs, and it >> seems appropriate to advance this work as Experimental. Reports of >> implementation and deployment across whole distribution trees or >> within sub-trees (see Section 7) will enable an assessment of the >> desirability and stability of this feature. The PIM working group >> will then consider whether to move this work to the Standards Track. >> >> I am only showing example text here. I am not attached to the content, >> but I am trying to cover the bases in a way that the IESG is likely to >> request. Please feel free to use other text if it works better for you. I pretty much used your text here, and acknowledged you. >> --- >> >> I think you need to expand "oif-list" on first use. Done >> --- >> >> Section 3 >> >> If a PIM router supports this draft, it must send the Pop- >> Count-Supported TLV. >> >> I think this might be better written as: >> >> A PIM router indicates that it supports this document by sending the >> Pop-Count-Supported TLV in a PIM Hello message. Yes. I'm also calling it option instead of TLV as that is the terminology usually used in the docs. >> --- >> >> Section 3 >> >> The format of the TLV is defined to be: >> >> >> 0 1 2 3 >> 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 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | OptionType | OptionLength | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | OptionValue | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> OptionType = 29, OptionLength = 4, there is no OptionValue semantics >> defined at this time but will be included for expandability and be >> defined in future revisions of this draft. The format will look >> like: >> >> >> 0 1 2 3 >> 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 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | 29 | 4 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Unallocated Flags | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> Unallocated Flags: for now should be sent as 0 and ignored on >> receipt. >> >> >> I am ambivalent about defining the flags field. Does PIM require that >> an options TLV is always the same length? If so, you are doing the >> right thing, but if not, you could equally come back later and define >> that, if the length is non-zero, the first four bytes are flags. But >> this is Experimental, so I don't object. Mainly I am curious :-) I've added some text where I define it without the options, but also say that implementations MUST accept an Hello with non-zero length and ignore the contents. This way we should be able to add flags later if needed. >> But anyway, I don't think you need the TLV format twice, and you need >> to allow IANA to make the allocation (although you can suggest a >> value in the IANA section). So you could rewrite as: >> >> The format follows the format of all Hello Option TLVs [RFC4601]: >> >> 0 1 2 3 >> 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 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | OptionType = TBD1 | OptionLength = 4 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Unallocated Flags | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> Unallocated Flags: Unused flags SHOULD be sent as 0 and ignored on >> receipt. This document defines no flags. >> >> Then, in Section 8... >> >> OLD >> A new PIM Hello Option type, 29, has been assigned. See [HELLO] for >> details. >> NEW >> IANA is requested to define a new PIM Hello Option type in the >> registry at [HELLO]. >> >> Pop-Count Support TBD1 >> >> A value of 29 is suggested. I did something like this. But note that 29 has already been temporarily assigned for this purpose. I'm noting that in the new text. >> END >> >> >> --- >> >> Section 4 >> >> Suggest >> >> s/Pop-Count attribute/Pop-Count Join Attribute/ >> s/to process PIM Join Attribute/to process a PIM Join Attribute/ Done >> --- >> >> Section 4 >> >> Again, to leave this to IANA... >> >> OLD >> Attr Type: 2. >> NEW >> Attr Type: TBD2 >> END Done >> And then, in Section 8 >> >> OLD >> A new PIM Join Attribute type needs to be assigned. 2 is proposed in >> this draft. >> NEW >> IANA is requested to allocate a new PIM Join Attribute type. >> >> Pop-Count Join Attribute TBD2 >> >> A value of 2 is suggested. Done >> --- >> >> Section 4 >> >> Unallocated Flags: The flags which are currently not defined. >> If a new flag is defined and sent by a new implementation, an >> old implementation should preserve the bit settings. This >> means that if a bit was set in a PIM Join message from any of >> the downstream routers, then it MUST also be set in any PIM >> Join sent upstream. >> >> Am I being too pedantic? Presumably clear bits MUST also be kept clear. >> How about: >> This means that a router MUST preserve the settings of all Unallocated >> Flags in PIM Join messages received from downstream routers in any PIM >> Join sent upstream. You're absolutely right. Done. >> --- >> >> Section 4 >> >> P flag: This flag remains set if all downstream routers support >> this specification. That is, they are PIM pop-count capable. >> This allows one to tell if the entire sub-tree is completely >> accounting capable. >> >> I'm not clear about this. Is the assumption that a router will clear >> this flag if it knows that a downstream router is not PIM pop-count >> capable? (I presume that the downstream router would not clear the >> flag because it doesn't know about this I-D.) Can you clarify by saying >> who has the responsibility to clear the flag? Tried to make this clearer. >> --- >> >> Section 4.2 has some ugly XML bleedthrough >> >>
>> >> > --- >> >> Section 5 has some lower case 2119-type words. Can you check to see >> whether you mean upper case. Done. Some changes. >> --- >> >> Section 6 is good. It might be nice to note at the top that the >> section is >> non-normative. Done >> However, the final paragraph (with its recommendation and use of "should >> not") seems to be important enough to promote to Section 5 and to use >> 2119 language. Done >> --- >> >> Section 9 >> >> I wonder... >> >> Does collecting this information put any additional burden on the >> routers and the network? If so, might it be something that a router >> should rate limit to prevent DoS? >> >> Does access to the information provide assistance to an attacker or >> even just violate an operator's confidentiality? If so, there should >> be a warning against sniffing attackers if the information is considered >> sensitive (I presume encrypting it is not possible). >> >> Now, you may say "so what?" but I think we should make a habit of >> raising flags so that operators are aware and thoughtful. I rewrote the security considerations, trying to discuss this. Stig >> _______________________________________________ >> pim mailing list >> pim@ietf.org >> https://www.ietf.org/mailman/listinfo/pim > > _______________________________________________ > pim mailing list > pim@ietf.org > https://www.ietf.org/mailman/listinfo/pim From adrian@olddog.co.uk Tue Apr 10 14:25:00 2012 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A349511E809D for ; Tue, 10 Apr 2012 14:24:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CnFI5Pi8hb0w for ; Tue, 10 Apr 2012 14:24:55 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id D45DF11E810C for ; Tue, 10 Apr 2012 14:24:51 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id q3ALOokQ031299; Tue, 10 Apr 2012 22:24:50 +0100 Received: from 950129200 (AGrenoble-551-1-43-107.w92-157.abo.wanadoo.fr [92.157.202.107]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id q3ALOmjv031285 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 10 Apr 2012 22:24:49 +0100 From: "Adrian Farrel" To: "'Stig Venaas'" References: <005101cd11d9$b1c44da0$154ce8e0$@olddog.co.uk> <4F832352.1000804@venaas.com> <4F847CAB.70402@venaas.com> In-Reply-To: <4F847CAB.70402@venaas.com> Date: Tue, 10 Apr 2012 22:24:49 +0100 Message-ID: <112401cd1760$5d8c56b0$18a50410$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEu7qDKVajglam8QL67CUF5vgxGHwHgyUwlAcsefiGXs4PygA== Content-Language: en-gb Cc: draft-ietf-pim-pop-count@tools.ietf.org, pim@ietf.org Subject: Re: [pim] AD review of draft-ietf-pim-pop-count X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 21:25:01 -0000 Excellent job, Stig, thanks. I'd be OK with this, but you are right that the WG should have a quick look to make sure they are happy. Probably best to post it and let Mike run it from there. Cheers, Adrian > -----Original Message----- > From: Stig Venaas [mailto:stig@venaas.com] > Sent: 10 April 2012 19:32 > To: adrian@olddog.co.uk > Cc: draft-ietf-pim-pop-count@tools.ietf.org; pim@ietf.org; Yiqun Cai > Subject: Re: [pim] AD review of draft-ietf-pim-pop-count > > Hi > > I've been editing the document and hopefully resolved most of your > concerns. Please see my comments below. > > Unless you see any obvious issues based on my comments, I can > go ahead and submit a new version. > > Note that these changes are fairly big, I made a few additional ones, > so I feel we also need to give the WG some time to review them. And > of course also for you and the other authors to review them. > > Thanks a lot, I think this improved the document significantly. I > also found some issues myself that I tried to take care of. > > On 4/9/2012 10:58 AM, Stig Venaas wrote: > > On 4/3/2012 1:38 PM, Adrian Farrel wrote: > >> Hi, > >> > >> Sorry I sat on this I-D a while doing my review. The review is my > >> usual pass over the document to iron out nits that I think might > >> show up in IETF last call, Directorate reviews, or during IESG > >> evaluation. By catching the issues at this stage we can save the > >> effort of multiple reviewers, and achieve a smoother passage > >> through the publication process. > >> > >> All of my comments can be discussed. > > > > Thanks for the detailed review. Your comments look good. I will start > > working on an update. > > > > Stig > > > >> > >> As it stands, I think a new revision would help address these point > >> so I will move the I-D into "New Revision Required" state, and when > >> I see an update I will advance the document to IETF last call. Please > >> be sure that the new revision passes idnits. > >> > >> Thanks, > >> Adrian > >> > >> --- > >> > >> Please update Yiqun's email address to yiqunc@microsoft.com and his > >> coordinates to Microsoft. > > Done > > >> --- > >> > >> The RFC Editor likes the document to begin with an Introduction, so > >> you could move Section 1 into 2.1 and renumber. > > Done > > >> --- > >> > >> I think that the RFC Editor likes all figures to be captioned and given > >> a number (e.g. Figure 1 : A Sample Foobar). Further, they like all > >> figures to be explicitly referenced form the text. > >> > >> That sounds a bore to do, but if you have the energy it might be worth > >> it. > > Sorry, I didn't have the energy. I don't really think it is needed. And > it can be done later if it really seems to be needed. > > >> --- > >> > >> Can you s/this draft/this document/ throughout since, on publication, > >> this will not be a draft any more. > > Done > > >> --- > >> > >> We will get push-back from the IESG to "describe the experiment". > >> > >> I think this can be handled relatively easily in the Introduction with > >> some text such as: > >> > >> This is a new proposal for an extension to PIM, and it is not > >> completely understood what impact collecting information using PIM > >> would have on the operation of PIM. Many PIM features (including the > >> core protocol) were first introduced as Experimental RFCs, and it > >> seems appropriate to advance this work as Experimental. Reports of > >> implementation and deployment across whole distribution trees or > >> within sub-trees (see Section 7) will enable an assessment of the > >> desirability and stability of this feature. The PIM working group > >> will then consider whether to move this work to the Standards Track. > >> > >> I am only showing example text here. I am not attached to the content, > >> but I am trying to cover the bases in a way that the IESG is likely to > >> request. Please feel free to use other text if it works better for you. > > I pretty much used your text here, and acknowledged you. > > >> --- > >> > >> I think you need to expand "oif-list" on first use. > > Done > > >> --- > >> > >> Section 3 > >> > >> If a PIM router supports this draft, it must send the Pop- > >> Count-Supported TLV. > >> > >> I think this might be better written as: > >> > >> A PIM router indicates that it supports this document by sending the > >> Pop-Count-Supported TLV in a PIM Hello message. > > Yes. I'm also calling it option instead of TLV as that is the > terminology usually used in the docs. > > >> --- > >> > >> Section 3 > >> > >> The format of the TLV is defined to be: > >> > >> > >> 0 1 2 3 > >> 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 > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> | OptionType | OptionLength | > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> | OptionValue | > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> > >> OptionType = 29, OptionLength = 4, there is no OptionValue semantics > >> defined at this time but will be included for expandability and be > >> defined in future revisions of this draft. The format will look > >> like: > >> > >> > >> 0 1 2 3 > >> 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 > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> | 29 | 4 | > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> | Unallocated Flags | > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> > >> Unallocated Flags: for now should be sent as 0 and ignored on > >> receipt. > >> > >> > >> I am ambivalent about defining the flags field. Does PIM require that > >> an options TLV is always the same length? If so, you are doing the > >> right thing, but if not, you could equally come back later and define > >> that, if the length is non-zero, the first four bytes are flags. But > >> this is Experimental, so I don't object. Mainly I am curious :-) > > I've added some text where I define it without the options, but also say > that implementations MUST accept an Hello with non-zero length and > ignore the contents. This way we should be able to add flags later if > needed. > > >> But anyway, I don't think you need the TLV format twice, and you need > >> to allow IANA to make the allocation (although you can suggest a > >> value in the IANA section). So you could rewrite as: > >> > >> The format follows the format of all Hello Option TLVs [RFC4601]: > >> > >> 0 1 2 3 > >> 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 > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> | OptionType = TBD1 | OptionLength = 4 | > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> | Unallocated Flags | > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> > >> Unallocated Flags: Unused flags SHOULD be sent as 0 and ignored on > >> receipt. This document defines no flags. > >> > >> Then, in Section 8... > >> > >> OLD > >> A new PIM Hello Option type, 29, has been assigned. See [HELLO] for > >> details. > >> NEW > >> IANA is requested to define a new PIM Hello Option type in the > >> registry at [HELLO]. > >> > >> Pop-Count Support TBD1 > >> > >> A value of 29 is suggested. > > I did something like this. But note that 29 has already been > temporarily assigned for this purpose. I'm noting that in the > new text. > > >> END > >> > >> > >> --- > >> > >> Section 4 > >> > >> Suggest > >> > >> s/Pop-Count attribute/Pop-Count Join Attribute/ > >> s/to process PIM Join Attribute/to process a PIM Join Attribute/ > > Done > > >> --- > >> > >> Section 4 > >> > >> Again, to leave this to IANA... > >> > >> OLD > >> Attr Type: 2. > >> NEW > >> Attr Type: TBD2 > >> END > > Done > > >> And then, in Section 8 > >> > >> OLD > >> A new PIM Join Attribute type needs to be assigned. 2 is proposed in > >> this draft. > >> NEW > >> IANA is requested to allocate a new PIM Join Attribute type. > >> > >> Pop-Count Join Attribute TBD2 > >> > >> A value of 2 is suggested. > > Done > > >> --- > >> > >> Section 4 > >> > >> Unallocated Flags: The flags which are currently not defined. > >> If a new flag is defined and sent by a new implementation, an > >> old implementation should preserve the bit settings. This > >> means that if a bit was set in a PIM Join message from any of > >> the downstream routers, then it MUST also be set in any PIM > >> Join sent upstream. > >> > >> Am I being too pedantic? Presumably clear bits MUST also be kept clear. > >> How about: > >> This means that a router MUST preserve the settings of all Unallocated > >> Flags in PIM Join messages received from downstream routers in any PIM > >> Join sent upstream. > > You're absolutely right. Done. > > >> --- > >> > >> Section 4 > >> > >> P flag: This flag remains set if all downstream routers support > >> this specification. That is, they are PIM pop-count capable. > >> This allows one to tell if the entire sub-tree is completely > >> accounting capable. > >> > >> I'm not clear about this. Is the assumption that a router will clear > >> this flag if it knows that a downstream router is not PIM pop-count > >> capable? (I presume that the downstream router would not clear the > >> flag because it doesn't know about this I-D.) Can you clarify by saying > >> who has the responsibility to clear the flag? > > Tried to make this clearer. > >> --- > >> > >> Section 4.2 has some ugly XML bleedthrough > >> > >>
> >> > >> > Done > > >> --- > >> > >> Section 5 has some lower case 2119-type words. Can you check to see > >> whether you mean upper case. > > Done. Some changes. > > >> --- > >> > >> Section 6 is good. It might be nice to note at the top that the > >> section is > >> non-normative. > > Done > > >> However, the final paragraph (with its recommendation and use of "should > >> not") seems to be important enough to promote to Section 5 and to use > >> 2119 language. > > Done > > >> --- > >> > >> Section 9 > >> > >> I wonder... > >> > >> Does collecting this information put any additional burden on the > >> routers and the network? If so, might it be something that a router > >> should rate limit to prevent DoS? > >> > >> Does access to the information provide assistance to an attacker or > >> even just violate an operator's confidentiality? If so, there should > >> be a warning against sniffing attackers if the information is considered > >> sensitive (I presume encrypting it is not possible). > >> > >> Now, you may say "so what?" but I think we should make a habit of > >> raising flags so that operators are aware and thoughtful. > > I rewrote the security considerations, trying to discuss this. > > Stig > > >> _______________________________________________ > >> pim mailing list > >> pim@ietf.org > >> https://www.ietf.org/mailman/listinfo/pim > > > > _______________________________________________ > > pim mailing list > > pim@ietf.org > > https://www.ietf.org/mailman/listinfo/pim From internet-drafts@ietf.org Tue Apr 10 15:06:09 2012 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B398A11E8139; Tue, 10 Apr 2012 15:06:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.542 X-Spam-Level: X-Spam-Status: No, score=-102.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g77FcWyC0hxr; Tue, 10 Apr 2012 15:06:08 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64AD721F85A2; Tue, 10 Apr 2012 15:06:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120410220608.4713.61963.idtracker@ietfa.amsl.com> Date: Tue, 10 Apr 2012 15:06:08 -0700 Cc: pim@ietf.org Subject: [pim] I-D Action: draft-ietf-pim-pop-count-06.txt X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 22:06:10 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Protocol Independent Multicast Workin= g Group of the IETF. Title : Population Count Extensions to PIM Author(s) : Dino Farinacci Greg Shepherd Stig Venaas Yiqun Cai Filename : draft-ietf-pim-pop-count-06.txt Pages : 20 Date : 2012-04-10 This specification defines a method for providing multicast distribution-tree accounting data. Simple extensions to the PIM protocol allow a rough approximation of tree-based data in a scalable fashion. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pim-pop-count-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-pim-pop-count-06.txt From stig@venaas.com Tue Apr 10 15:13:58 2012 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09EDB11E80DF for ; Tue, 10 Apr 2012 15:13:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 243fuEF8js96 for ; Tue, 10 Apr 2012 15:13:56 -0700 (PDT) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by ietfa.amsl.com (Postfix) with ESMTP id 7EEB611E80D2 for ; Tue, 10 Apr 2012 15:13:56 -0700 (PDT) Received: from [10.33.12.93] (128-107-239-233.cisco.com [128.107.239.233]) by ufisa.uninett.no (Postfix) with ESMTPSA id 962C4802C; Wed, 11 Apr 2012 00:13:54 +0200 (CEST) Message-ID: <4F84B09F.1020704@venaas.com> Date: Tue, 10 Apr 2012 15:13:51 -0700 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: adrian@olddog.co.uk References: <005101cd11d9$b1c44da0$154ce8e0$@olddog.co.uk> <4F832352.1000804@venaas.com> <4F847CAB.70402@venaas.com> <112401cd1760$5d8c56b0$18a50410$@olddog.co.uk> In-Reply-To: <112401cd1760$5d8c56b0$18a50410$@olddog.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-ietf-pim-pop-count@tools.ietf.org, pim@ietf.org Subject: Re: [pim] AD review of draft-ietf-pim-pop-count X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 22:13:58 -0000 On 4/10/2012 2:24 PM, Adrian Farrel wrote: > Excellent job, Stig, thanks. > > I'd be OK with this, but you are right that the WG should have a quick look to > make sure they are happy. > > Probably best to post it and let Mike run it from there. Based on Adrian's comments I've made several changes to the pop-count draft. I also found some other issues I've tried to resolve. Apart from changing wording, whether to use 2119 keywords etc., the only real protocol change IMO, is that the hello option no longer contains an option value with reserved bits. Instead I've added language that if a value is present, the hello option must be processes as if there is no value present. The new version is at http://www.ietf.org/internet-drafts/draft-ietf-pim-pop-count-06.txt and a diff is available at http://tools.ietf.org/rfcdiff?url2=draft-ietf-pim-pop-count-06 Adrian, please check if this resolves your issues. I hope other authors and people in the WG can help review this to make sure the changes are fine. I leave to Mike to ensure that the document is appropriately reviewed by the WG. Stig > > Cheers, > Adrian > >> -----Original Message----- >> From: Stig Venaas [mailto:stig@venaas.com] >> Sent: 10 April 2012 19:32 >> To: adrian@olddog.co.uk >> Cc: draft-ietf-pim-pop-count@tools.ietf.org; pim@ietf.org; Yiqun Cai >> Subject: Re: [pim] AD review of draft-ietf-pim-pop-count >> >> Hi >> >> I've been editing the document and hopefully resolved most of your >> concerns. Please see my comments below. >> >> Unless you see any obvious issues based on my comments, I can >> go ahead and submit a new version. >> >> Note that these changes are fairly big, I made a few additional ones, >> so I feel we also need to give the WG some time to review them. And >> of course also for you and the other authors to review them. >> >> Thanks a lot, I think this improved the document significantly. I >> also found some issues myself that I tried to take care of. >> >> On 4/9/2012 10:58 AM, Stig Venaas wrote: >>> On 4/3/2012 1:38 PM, Adrian Farrel wrote: >>>> Hi, >>>> >>>> Sorry I sat on this I-D a while doing my review. The review is my >>>> usual pass over the document to iron out nits that I think might >>>> show up in IETF last call, Directorate reviews, or during IESG >>>> evaluation. By catching the issues at this stage we can save the >>>> effort of multiple reviewers, and achieve a smoother passage >>>> through the publication process. >>>> >>>> All of my comments can be discussed. >>> >>> Thanks for the detailed review. Your comments look good. I will start >>> working on an update. >>> >>> Stig >>> >>>> >>>> As it stands, I think a new revision would help address these point >>>> so I will move the I-D into "New Revision Required" state, and when >>>> I see an update I will advance the document to IETF last call. Please >>>> be sure that the new revision passes idnits. >>>> >>>> Thanks, >>>> Adrian >>>> >>>> --- >>>> >>>> Please update Yiqun's email address to yiqunc@microsoft.com and his >>>> coordinates to Microsoft. >> >> Done >> >>>> --- >>>> >>>> The RFC Editor likes the document to begin with an Introduction, so >>>> you could move Section 1 into 2.1 and renumber. >> >> Done >> >>>> --- >>>> >>>> I think that the RFC Editor likes all figures to be captioned and given >>>> a number (e.g. Figure 1 : A Sample Foobar). Further, they like all >>>> figures to be explicitly referenced form the text. >>>> >>>> That sounds a bore to do, but if you have the energy it might be worth >>>> it. >> >> Sorry, I didn't have the energy. I don't really think it is needed. And >> it can be done later if it really seems to be needed. >> >>>> --- >>>> >>>> Can you s/this draft/this document/ throughout since, on publication, >>>> this will not be a draft any more. >> >> Done >> >>>> --- >>>> >>>> We will get push-back from the IESG to "describe the experiment". >>>> >>>> I think this can be handled relatively easily in the Introduction with >>>> some text such as: >>>> >>>> This is a new proposal for an extension to PIM, and it is not >>>> completely understood what impact collecting information using PIM >>>> would have on the operation of PIM. Many PIM features (including the >>>> core protocol) were first introduced as Experimental RFCs, and it >>>> seems appropriate to advance this work as Experimental. Reports of >>>> implementation and deployment across whole distribution trees or >>>> within sub-trees (see Section 7) will enable an assessment of the >>>> desirability and stability of this feature. The PIM working group >>>> will then consider whether to move this work to the Standards Track. >>>> >>>> I am only showing example text here. I am not attached to the content, >>>> but I am trying to cover the bases in a way that the IESG is likely to >>>> request. Please feel free to use other text if it works better for you. >> >> I pretty much used your text here, and acknowledged you. >> >>>> --- >>>> >>>> I think you need to expand "oif-list" on first use. >> >> Done >> >>>> --- >>>> >>>> Section 3 >>>> >>>> If a PIM router supports this draft, it must send the Pop- >>>> Count-Supported TLV. >>>> >>>> I think this might be better written as: >>>> >>>> A PIM router indicates that it supports this document by sending the >>>> Pop-Count-Supported TLV in a PIM Hello message. >> >> Yes. I'm also calling it option instead of TLV as that is the >> terminology usually used in the docs. >> >>>> --- >>>> >>>> Section 3 >>>> >>>> The format of the TLV is defined to be: >>>> >>>> >>>> 0 1 2 3 >>>> 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 >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> | OptionType | OptionLength | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> | OptionValue | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> >>>> OptionType = 29, OptionLength = 4, there is no OptionValue semantics >>>> defined at this time but will be included for expandability and be >>>> defined in future revisions of this draft. The format will look >>>> like: >>>> >>>> >>>> 0 1 2 3 >>>> 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 >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> | 29 | 4 | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> | Unallocated Flags | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> >>>> Unallocated Flags: for now should be sent as 0 and ignored on >>>> receipt. >>>> >>>> >>>> I am ambivalent about defining the flags field. Does PIM require that >>>> an options TLV is always the same length? If so, you are doing the >>>> right thing, but if not, you could equally come back later and define >>>> that, if the length is non-zero, the first four bytes are flags. But >>>> this is Experimental, so I don't object. Mainly I am curious :-) >> >> I've added some text where I define it without the options, but also say >> that implementations MUST accept an Hello with non-zero length and >> ignore the contents. This way we should be able to add flags later if >> needed. >> >>>> But anyway, I don't think you need the TLV format twice, and you need >>>> to allow IANA to make the allocation (although you can suggest a >>>> value in the IANA section). So you could rewrite as: >>>> >>>> The format follows the format of all Hello Option TLVs [RFC4601]: >>>> >>>> 0 1 2 3 >>>> 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 >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> | OptionType = TBD1 | OptionLength = 4 | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> | Unallocated Flags | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> >>>> Unallocated Flags: Unused flags SHOULD be sent as 0 and ignored on >>>> receipt. This document defines no flags. >>>> >>>> Then, in Section 8... >>>> >>>> OLD >>>> A new PIM Hello Option type, 29, has been assigned. See [HELLO] for >>>> details. >>>> NEW >>>> IANA is requested to define a new PIM Hello Option type in the >>>> registry at [HELLO]. >>>> >>>> Pop-Count Support TBD1 >>>> >>>> A value of 29 is suggested. >> >> I did something like this. But note that 29 has already been >> temporarily assigned for this purpose. I'm noting that in the >> new text. >> >>>> END >>>> >>>> >>>> --- >>>> >>>> Section 4 >>>> >>>> Suggest >>>> >>>> s/Pop-Count attribute/Pop-Count Join Attribute/ >>>> s/to process PIM Join Attribute/to process a PIM Join Attribute/ >> >> Done >> >>>> --- >>>> >>>> Section 4 >>>> >>>> Again, to leave this to IANA... >>>> >>>> OLD >>>> Attr Type: 2. >>>> NEW >>>> Attr Type: TBD2 >>>> END >> >> Done >> >>>> And then, in Section 8 >>>> >>>> OLD >>>> A new PIM Join Attribute type needs to be assigned. 2 is proposed in >>>> this draft. >>>> NEW >>>> IANA is requested to allocate a new PIM Join Attribute type. >>>> >>>> Pop-Count Join Attribute TBD2 >>>> >>>> A value of 2 is suggested. >> >> Done >> >>>> --- >>>> >>>> Section 4 >>>> >>>> Unallocated Flags: The flags which are currently not defined. >>>> If a new flag is defined and sent by a new implementation, an >>>> old implementation should preserve the bit settings. This >>>> means that if a bit was set in a PIM Join message from any of >>>> the downstream routers, then it MUST also be set in any PIM >>>> Join sent upstream. >>>> >>>> Am I being too pedantic? Presumably clear bits MUST also be kept clear. >>>> How about: >>>> This means that a router MUST preserve the settings of all Unallocated >>>> Flags in PIM Join messages received from downstream routers in any PIM >>>> Join sent upstream. >> >> You're absolutely right. Done. >> >>>> --- >>>> >>>> Section 4 >>>> >>>> P flag: This flag remains set if all downstream routers support >>>> this specification. That is, they are PIM pop-count capable. >>>> This allows one to tell if the entire sub-tree is completely >>>> accounting capable. >>>> >>>> I'm not clear about this. Is the assumption that a router will clear >>>> this flag if it knows that a downstream router is not PIM pop-count >>>> capable? (I presume that the downstream router would not clear the >>>> flag because it doesn't know about this I-D.) Can you clarify by saying >>>> who has the responsibility to clear the flag? >> >> Tried to make this clearer. >>>> --- >>>> >>>> Section 4.2 has some ugly XML bleedthrough >>>> >>>>
>>>> >>>> > >> Done >> >>>> --- >>>> >>>> Section 5 has some lower case 2119-type words. Can you check to see >>>> whether you mean upper case. >> >> Done. Some changes. >> >>>> --- >>>> >>>> Section 6 is good. It might be nice to note at the top that the >>>> section is >>>> non-normative. >> >> Done >> >>>> However, the final paragraph (with its recommendation and use of "should >>>> not") seems to be important enough to promote to Section 5 and to use >>>> 2119 language. >> >> Done >> >>>> --- >>>> >>>> Section 9 >>>> >>>> I wonder... >>>> >>>> Does collecting this information put any additional burden on the >>>> routers and the network? If so, might it be something that a router >>>> should rate limit to prevent DoS? >>>> >>>> Does access to the information provide assistance to an attacker or >>>> even just violate an operator's confidentiality? If so, there should >>>> be a warning against sniffing attackers if the information is considered >>>> sensitive (I presume encrypting it is not possible). >>>> >>>> Now, you may say "so what?" but I think we should make a habit of >>>> raising flags so that operators are aware and thoughtful. >> >> I rewrote the security considerations, trying to discuss this. >> >> Stig >> >>>> _______________________________________________ >>>> pim mailing list >>>> pim@ietf.org >>>> https://www.ietf.org/mailman/listinfo/pim >>> >>> _______________________________________________ >>> pim mailing list >>> pim@ietf.org >>> https://www.ietf.org/mailman/listinfo/pim From simon.perreault@viagenie.ca Wed Apr 11 11:03:43 2012 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FFB211E8094; Wed, 11 Apr 2012 11:03:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.57 X-Spam-Level: X-Spam-Status: No, score=-2.57 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fp0MIPmU+6AQ; Wed, 11 Apr 2012 11:03:43 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id CB88A11E808D; Wed, 11 Apr 2012 11:03:42 -0700 (PDT) Received: from ringo.viagenie.ca (unknown [IPv6:2620:0:230:c000:c44f:f235:37d9:77c2]) by jazz.viagenie.ca (Postfix) with ESMTPSA id CEBE44009E; Wed, 11 Apr 2012 14:03:41 -0400 (EDT) Message-ID: <4F85C77D.70104@viagenie.ca> Date: Wed, 11 Apr 2012 14:03:41 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1 MIME-Version: 1.0 To: pim@ietf.org References: <20120411175856.27333.99878.idtracker@ietfa.amsl.com> In-Reply-To: <20120411175856.27333.99878.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20120411175856.27333.99878.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: MBONED WG Subject: [pim] Fwd: New Version Notification for draft-perreault-mboned-igmp-mld-translation-01.txt X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 18:03:43 -0000 Hi, We have updated the IGMP/MLD translation draft based on the feedback we received in Paris. We tried to make it clearer that this is a logical function that can be implemented in various concrete ways. We also emphasize that the translation is stateless and that, as a consequence, we don't handle arbitrary IPv6 addresses. Please send comments to the PIM WG mailing list. Thanks, Simon -------- Original Message -------- Subject: New Version Notification for draft-perreault-mboned-igmp-mld-translation-01.txt Date: Wed, 11 Apr 2012 10:58:56 -0700 From: internet-drafts@ietf.org To: simon.perreault@viagenie.ca CC: tina.tsou.zouting@huawei.com A new version of I-D, draft-perreault-mboned-igmp-mld-translation-01.txt has been successfully submitted by Simon Perreault and posted to the IETF repository. Filename: draft-perreault-mboned-igmp-mld-translation Revision: 01 Title: Internet Group Management Protocol (IGMP) / Multicast Listener Discovery (MLD)-Based Multicast Translation ("IGMP/MLD Translation") Creation date: 2012-04-10 WG ID: Individual Submission Number of pages: 16 Abstract: This document describes translation between IGMP and MLD. This allows single-stack multicast nodes to participate in multicast groups from a different address family. Both sending and receiving is supported by this translation mechanism. Both any-source and source-specific multicast (ASM and SSM) are supported as well. The IETF Secretariat From chiranjeevi.ramana.rao@ericsson.com Mon Apr 16 23:32:11 2012 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A842411E80AE; Mon, 16 Apr 2012 23:32:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6dqJhnSuOX2W; Mon, 16 Apr 2012 23:32:07 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id E814511E80A5; Mon, 16 Apr 2012 23:32:06 -0700 (PDT) X-AuditID: c1b4fb2d-b7b76ae0000063d8-ed-4f8d0e658cb2 Authentication-Results: mailgw1.ericsson.se x-tls.subject="/CN=esessmw0256"; auth=fail (cipher=AES128-SHA) Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client CN "esessmw0256", Issuer "esessmw0256" (not verified)) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id E2.EB.25560.56E0D8F4; Tue, 17 Apr 2012 08:32:05 +0200 (CEST) Received: from ESESSCMS0359.eemea.ericsson.se ([169.254.1.88]) by esessmw0256.eemea.ericsson.se ([153.88.115.96]) with mapi; Tue, 17 Apr 2012 08:32:05 +0200 From: Chiranjeevi Ramana Rao To: Liuhui , Stig Venaas , Tina TSOU Date: Tue, 17 Apr 2012 08:32:05 +0200 Thread-Topic: [pim] Comment on draft-lts-pim-hello-mtu? Thread-Index: Ac0TbPRReFB8+MLJQ6Wly2HsnKucXQCys0+AADOfugABVx0+cA== Message-ID: <660B7A61018B0247A5427EA250EACE67261054A6F6@ESESSCMS0359.eemea.ericsson.se> References: <4F832403.3060607@venaas.com> <0521328FA8CCCE4089CA3C9261A28DD9374E43D0@SZXEML501-MBS.china.huawei.com> In-Reply-To: <0521328FA8CCCE4089CA3C9261A28DD9374E43D0@SZXEML501-MBS.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "rtg-bfd@ietf.org" , "pim@ietf.org" Subject: Re: [pim] Comment on draft-lts-pim-hello-mtu? X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 06:32:11 -0000 Hello=20 I second Stig on this, MTU problem mentioned here is general problem. Thi= s draft is proposing solution for PIM. IGMPv3 also will have same problem r= ight? It is not good idea to solve MTU problem per protocol. It will be nice, i= f a general solution is found for this problem. Thanks Chiranjeevi =20 -----Original Message----- From: pim-bounces@ietf.org [mailto:pim-bounces@ietf.org] On Behalf Of Liuhu= i Sent: Tuesday, April 10, 2012 4:37 PM To: Stig Venaas; Tina TSOU Cc: rtg-bfd@ietf.org; pim@ietf.org Subject: Re: [pim] Comment on draft-lts-pim-hello-mtu? Hi Stig, Thanks for the comments. I also introduce the points in minutes below for d= iscussion. Thanks, Liu Hui > -----Original Message----- > From: pim-bounces@ietf.org [mailto:pim-bounces@ietf.org] On Behalf Of=20 > Stig Venaas > Sent: Tuesday, April 10, 2012 2:02 AM > To: Tina TSOU > Cc: pim@ietf.org > Subject: Re: [pim] Comment on draft-lts-pim-hello-mtu? >=20 > On 4/5/2012 1:44 PM, Tina TSOU wrote: > > Dear all, > > May the author of draft-lts-pim-hello-mtu ask people to read the=20 > > draft > and provide comments? > > > > http://datatracker.ietf.org/doc/draft-lts-pim-hello-mtu/ > > > > Thank you in advance. >=20 > See the minutes I just posted if you like. "Stig: Useful if there are msiconfigurations or asymmetric MTUs for routers= on a link. But not just a PIM problem." [LH] Agree. E.g. OSPF also has MTU option carried in its Database Descripti= on packet.=20 =20 "Bill: If you are using MTU for control packets you may be able to send goo= d control packets but if the data packets are still too big, this could be = a bad thing. We need to make sure that this isn't a bad thing and explain i= t" [LH] Accepted. Could we explain it in this way: the control and data plane = are run independently. The control plane makes sure that forwarding paths a= re setup even though there exists asymmetric MTUs. Even though some data pa= ckets exceeding MTU limitation of some point of paths cannot be processed p= roperly, other packets in scope will be normally forwarded and delivered. A= nd it's up to first-hop or head- end to determine the length of a data pack= et, with other measures such as PMTU. "Dino: Population count helps because you can drop the packets at the first= hop router." [LH]Pop count is a PMTU-like method, which should deal with data packet. >=20 > My main comment is that MTU is important for other protocols too, [LH] It's important for protocol between its adjacent peers when they have = to exchange volumes of data, such as PIM Join with large amounts of group s= tates, and OSPF Database Description carrying all link-states during initia= lization. > and also for traffic/data, [LH] I suppose PMTU-like methods are more applicable for traffic/data, whil= e for PIM and OSPF the key issue is between two adjacent hops where message= s often having to be segmented. They are for different purpose and should u= se different measures > so I'm wondering if it would be better > to do it with some more general protocol. Maybe BFD or in the IGP? > For IPv6 one could perhaps use RAs? [LH] Good points. Please see my considerations: For per-hop MTU here there are two steps implied, i.e., how PIM acquire= s its peer MTU info, and how it uses it. The first step has the possibility= to be generalized, and the second is somewhat protocol specific Then does this 'generalization' mean BFD or IGP or RA? As PIM is protoc= ol independent, we cannot assume it always run with IGP. So IGP might be no= t a good option for generalization.=20 RA has already had MTU option there, but it's for use for the nodes not= the routers. Even if the router takes the role of a node, there are no exp= licit peer and one common MTU is taken for all nodes in RA case, which is d= ifferent from the PIM one. And RA is applicable to only IPv6 network. BFD is more general. Should it be extended as here to cover most protoc= ols? It is not impossible, but the precondition is every protocol expects t= he same information from the common structure maintained by BFD. It deserve= s it if the number of protocols having this control message segmenting requ= irement is not small. PIM extension is proposed because there is no common structure availabl= e right now, and promoted by resolving the current network issues. It can b= e applied to both IPv4 and IPv6 networks, and doesn't mind whether IGP or B= FD is running or not.=20 >=20 > Stig >=20 > > > > > > Best Regards, > > Tina TSOU > > > > > > _______________________________________________ > > pim mailing list > > pim@ietf.org > > https://www.ietf.org/mailman/listinfo/pim >=20 > _______________________________________________ > pim mailing list > pim@ietf.org > https://www.ietf.org/mailman/listinfo/pim _______________________________________________ pim mailing list pim@ietf.org https://www.ietf.org/mailman/listinfo/pim From helen.liu@huawei.com Tue Apr 17 03:05:44 2012 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92A2121F8608; Tue, 17 Apr 2012 03:05:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 43r2crd-+1fD; Tue, 17 Apr 2012 03:05:40 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 2DA8021F85CF; Tue, 17 Apr 2012 03:05:40 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AFH17739; Tue, 17 Apr 2012 06:05:36 -0400 (EDT) Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 17 Apr 2012 03:03:25 -0700 Received: from SZXEML408-HUB.china.huawei.com (10.82.67.95) by dfweml408-hub.china.huawei.com (10.193.5.134) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 17 Apr 2012 03:03:27 -0700 Received: from SZXEML501-MBS.china.huawei.com ([169.254.5.163]) by szxeml408-hub.china.huawei.com ([10.82.67.95]) with mapi id 14.01.0323.003; Tue, 17 Apr 2012 18:03:14 +0800 From: Liuhui To: Chiranjeevi Ramana Rao , Stig Venaas , Tina TSOU Thread-Topic: [pim] Comment on draft-lts-pim-hello-mtu? Thread-Index: Ac0TbPRReFB8+MLJQ6Wly2HsnKucXQCys0+AADOfugABVx0+cAAFWgrQ Date: Tue, 17 Apr 2012 10:03:14 +0000 Message-ID: <0521328FA8CCCE4089CA3C9261A28DD9374E922B@SZXEML501-MBS.china.huawei.com> References: <4F832403.3060607@venaas.com> <0521328FA8CCCE4089CA3C9261A28DD9374E43D0@SZXEML501-MBS.china.huawei.com> <660B7A61018B0247A5427EA250EACE67261054A6F6@ESESSCMS0359.eemea.ericsson.se> In-Reply-To: <660B7A61018B0247A5427EA250EACE67261054A6F6@ESESSCMS0359.eemea.ericsson.se> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.108.4.67] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "rtg-bfd@ietf.org" , "pim@ietf.org" Subject: Re: [pim] Comment on draft-lts-pim-hello-mtu? X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 10:05:44 -0000 Hi, For IGMPv3, do you mean when it is running between a host and a router? The= n it is quite different from what is resolved by this draft. PIM specific processing also has its benefits, as explained below. General = solution is not impossible, but it's better we collect enough use cases bef= ore we decide to turn to that direction. Thanks, Liu Hui >=20 > Hello > I second Stig on this, MTU problem mentioned here is general problem. > This draft is proposing solution for PIM. IGMPv3 also will have same > problem right? > It is not good idea to solve MTU problem per protocol. It will be nice,= if a > general solution is found for this problem. > Thanks > Chiranjeevi >=20 >=20 > -----Original Message----- > From: pim-bounces@ietf.org [mailto:pim-bounces@ietf.org] On Behalf Of > Liuhui > Sent: Tuesday, April 10, 2012 4:37 PM > To: Stig Venaas; Tina TSOU > Cc: rtg-bfd@ietf.org; pim@ietf.org > Subject: Re: [pim] Comment on draft-lts-pim-hello-mtu? >=20 > Hi Stig, >=20 > Thanks for the comments. I also introduce the points in minutes below for > discussion. >=20 > Thanks, > Liu Hui >=20 > > -----Original Message----- > > From: pim-bounces@ietf.org [mailto:pim-bounces@ietf.org] On Behalf Of > > Stig Venaas > > Sent: Tuesday, April 10, 2012 2:02 AM > > To: Tina TSOU > > Cc: pim@ietf.org > > Subject: Re: [pim] Comment on draft-lts-pim-hello-mtu? > > > > On 4/5/2012 1:44 PM, Tina TSOU wrote: > > > Dear all, > > > May the author of draft-lts-pim-hello-mtu ask people to read the > > > draft > > and provide comments? > > > > > > http://datatracker.ietf.org/doc/draft-lts-pim-hello-mtu/ > > > > > > Thank you in advance. > > >=20 > > See the minutes I just posted if you like. >=20 > "Stig: Useful if there are msiconfigurations or asymmetric MTUs for route= rs > on a link. But not just a PIM problem." > [LH] Agree. E.g. OSPF also has MTU option carried in its Database > Description packet. >=20 > "Bill: If you are using MTU for control packets you may be able to send g= ood > control packets but if the data packets are still too big, this could be = a bad > thing. We need to make sure that this isn't a bad thing and explain it" >=20 > [LH] Accepted. Could we explain it in this way: the control and data plan= e > are run independently. The control plane makes sure that forwarding paths > are setup even though there exists asymmetric MTUs. Even though some > data packets exceeding MTU limitation of some point of paths cannot be > processed properly, other packets in scope will be normally forwarded and > delivered. And it's up to first-hop or head- end to determine the length = of a > data packet, with other measures such as PMTU. >=20 > "Dino: Population count helps because you can drop the packets at the fir= st > hop router." > [LH]Pop count is a PMTU-like method, which should deal with data packet. >=20 > > > > My main comment is that MTU is important for other protocols too, >=20 > [LH] It's important for protocol between its adjacent peers when they hav= e > to exchange volumes of data, such as PIM Join with large amounts of group > states, and OSPF Database Description carrying all link-states during > initialization. >=20 > > and also for traffic/data, > [LH] I suppose PMTU-like methods are more applicable for traffic/data, > while for PIM and OSPF the key issue is between two adjacent hops where > messages often having to be segmented. They are for different purpose and > should use different measures >=20 > > so I'm wondering if it would be better > > to do it with some more general protocol. Maybe BFD or in the IGP? > > For IPv6 one could perhaps use RAs? >=20 > [LH] Good points. Please see my considerations: > For per-hop MTU here there are two steps implied, i.e., how PIM > acquires its peer MTU info, and how it uses it. The first step has the > possibility to be generalized, and the second is somewhat protocol specif= ic > Then does this 'generalization' mean BFD or IGP or RA? As PIM is > protocol independent, we cannot assume it always run with IGP. So IGP > might be not a good option for generalization. > RA has already had MTU option there, but it's for use for the nodes n= ot > the routers. Even if the router takes the role of a node, there are no ex= plicit > peer and one common MTU is taken for all nodes in RA case, which is > different from the PIM one. And RA is applicable to only IPv6 network. > BFD is more general. Should it be extended as here to cover most > protocols? It is not impossible, but the precondition is every protocol > expects the same information from the common structure maintained by > BFD. It deserves it if the number of protocols having this control messag= e > segmenting requirement is not small. > PIM extension is proposed because there is no common structure > available right now, and promoted by resolving the current network issues= . > It can be applied to both IPv4 and IPv6 networks, and doesn't mind whethe= r > IGP or BFD is running or not. >=20 > > > > Stig > > > > > > > > > > > Best Regards, > > > Tina TSOU > > > > > > > > > _______________________________________________ > > > pim mailing list > > > pim@ietf.org > > > https://www.ietf.org/mailman/listinfo/pim > > > > _______________________________________________ > > pim mailing list > > pim@ietf.org > > https://www.ietf.org/mailman/listinfo/pim > _______________________________________________ > pim mailing list > pim@ietf.org > https://www.ietf.org/mailman/listinfo/pim From stig@venaas.com Tue Apr 17 10:43:22 2012 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F30021F8576 for ; Tue, 17 Apr 2012 10:43:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pArnyZL6GoKu for ; Tue, 17 Apr 2012 10:43:17 -0700 (PDT) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by ietfa.amsl.com (Postfix) with ESMTP id E1D4821F855F for ; Tue, 17 Apr 2012 10:43:16 -0700 (PDT) Received: from [10.33.12.93] (128-107-239-233.cisco.com [128.107.239.233]) by ufisa.uninett.no (Postfix) with ESMTPSA id 4C9868000; Tue, 17 Apr 2012 19:43:14 +0200 (CEST) Message-ID: <4F8DABAB.8040802@venaas.com> Date: Tue, 17 Apr 2012 10:43:07 -0700 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: adrian@olddog.co.uk References: <005101cd11d9$b1c44da0$154ce8e0$@olddog.co.uk> <4F832352.1000804@venaas.com> <4F847CAB.70402@venaas.com> <112401cd1760$5d8c56b0$18a50410$@olddog.co.uk> <4F84B09F.1020704@venaas.com> In-Reply-To: <4F84B09F.1020704@venaas.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-ietf-pim-pop-count@tools.ietf.org, pim@ietf.org Subject: Re: [pim] AD review of draft-ietf-pim-pop-count X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 17:43:22 -0000 On 4/10/2012 3:13 PM, Stig Venaas wrote: > On 4/10/2012 2:24 PM, Adrian Farrel wrote: >> Excellent job, Stig, thanks. >> >> I'd be OK with this, but you are right that the WG should have a quick >> look to >> make sure they are happy. >> >> Probably best to post it and let Mike run it from there. Adrian, Mike and rest of WG, hope you can have a look and let everyone know if you have any concerns. Stig > Based on Adrian's comments I've made several changes to the pop-count > draft. I also found some other issues I've tried to resolve. > > Apart from changing wording, whether to use 2119 keywords etc., the only > real protocol change IMO, is that the hello option no longer contains > an option value with reserved bits. Instead I've added language that > if a value is present, the hello option must be processes as if there > is no value present. > > The new version is at > http://www.ietf.org/internet-drafts/draft-ietf-pim-pop-count-06.txt > > and a diff is available at > http://tools.ietf.org/rfcdiff?url2=draft-ietf-pim-pop-count-06 > > Adrian, please check if this resolves your issues. > > I hope other authors and people in the WG can help review this to make > sure the changes are fine. > > I leave to Mike to ensure that the document is appropriately reviewed > by the WG. > > Stig > >> >> Cheers, >> Adrian >> >>> -----Original Message----- >>> From: Stig Venaas [mailto:stig@venaas.com] >>> Sent: 10 April 2012 19:32 >>> To: adrian@olddog.co.uk >>> Cc: draft-ietf-pim-pop-count@tools.ietf.org; pim@ietf.org; Yiqun Cai >>> Subject: Re: [pim] AD review of draft-ietf-pim-pop-count >>> >>> Hi >>> >>> I've been editing the document and hopefully resolved most of your >>> concerns. Please see my comments below. >>> >>> Unless you see any obvious issues based on my comments, I can >>> go ahead and submit a new version. >>> >>> Note that these changes are fairly big, I made a few additional ones, >>> so I feel we also need to give the WG some time to review them. And >>> of course also for you and the other authors to review them. >>> >>> Thanks a lot, I think this improved the document significantly. I >>> also found some issues myself that I tried to take care of. >>> >>> On 4/9/2012 10:58 AM, Stig Venaas wrote: >>>> On 4/3/2012 1:38 PM, Adrian Farrel wrote: >>>>> Hi, >>>>> >>>>> Sorry I sat on this I-D a while doing my review. The review is my >>>>> usual pass over the document to iron out nits that I think might >>>>> show up in IETF last call, Directorate reviews, or during IESG >>>>> evaluation. By catching the issues at this stage we can save the >>>>> effort of multiple reviewers, and achieve a smoother passage >>>>> through the publication process. >>>>> >>>>> All of my comments can be discussed. >>>> >>>> Thanks for the detailed review. Your comments look good. I will start >>>> working on an update. >>>> >>>> Stig >>>> >>>>> >>>>> As it stands, I think a new revision would help address these point >>>>> so I will move the I-D into "New Revision Required" state, and when >>>>> I see an update I will advance the document to IETF last call. Please >>>>> be sure that the new revision passes idnits. >>>>> >>>>> Thanks, >>>>> Adrian >>>>> >>>>> --- >>>>> >>>>> Please update Yiqun's email address to yiqunc@microsoft.com and his >>>>> coordinates to Microsoft. >>> >>> Done >>> >>>>> --- >>>>> >>>>> The RFC Editor likes the document to begin with an Introduction, so >>>>> you could move Section 1 into 2.1 and renumber. >>> >>> Done >>> >>>>> --- >>>>> >>>>> I think that the RFC Editor likes all figures to be captioned and >>>>> given >>>>> a number (e.g. Figure 1 : A Sample Foobar). Further, they like all >>>>> figures to be explicitly referenced form the text. >>>>> >>>>> That sounds a bore to do, but if you have the energy it might be worth >>>>> it. >>> >>> Sorry, I didn't have the energy. I don't really think it is needed. And >>> it can be done later if it really seems to be needed. >>> >>>>> --- >>>>> >>>>> Can you s/this draft/this document/ throughout since, on publication, >>>>> this will not be a draft any more. >>> >>> Done >>> >>>>> --- >>>>> >>>>> We will get push-back from the IESG to "describe the experiment". >>>>> >>>>> I think this can be handled relatively easily in the Introduction with >>>>> some text such as: >>>>> >>>>> This is a new proposal for an extension to PIM, and it is not >>>>> completely understood what impact collecting information using PIM >>>>> would have on the operation of PIM. Many PIM features (including the >>>>> core protocol) were first introduced as Experimental RFCs, and it >>>>> seems appropriate to advance this work as Experimental. Reports of >>>>> implementation and deployment across whole distribution trees or >>>>> within sub-trees (see Section 7) will enable an assessment of the >>>>> desirability and stability of this feature. The PIM working group >>>>> will then consider whether to move this work to the Standards Track. >>>>> >>>>> I am only showing example text here. I am not attached to the content, >>>>> but I am trying to cover the bases in a way that the IESG is likely to >>>>> request. Please feel free to use other text if it works better for >>>>> you. >>> >>> I pretty much used your text here, and acknowledged you. >>> >>>>> --- >>>>> >>>>> I think you need to expand "oif-list" on first use. >>> >>> Done >>> >>>>> --- >>>>> >>>>> Section 3 >>>>> >>>>> If a PIM router supports this draft, it must send the Pop- >>>>> Count-Supported TLV. >>>>> >>>>> I think this might be better written as: >>>>> >>>>> A PIM router indicates that it supports this document by sending the >>>>> Pop-Count-Supported TLV in a PIM Hello message. >>> >>> Yes. I'm also calling it option instead of TLV as that is the >>> terminology usually used in the docs. >>> >>>>> --- >>>>> >>>>> Section 3 >>>>> >>>>> The format of the TLV is defined to be: >>>>> >>>>> >>>>> 0 1 2 3 >>>>> 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 >>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>> | OptionType | OptionLength | >>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>> | OptionValue | >>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>> >>>>> OptionType = 29, OptionLength = 4, there is no OptionValue semantics >>>>> defined at this time but will be included for expandability and be >>>>> defined in future revisions of this draft. The format will look >>>>> like: >>>>> >>>>> >>>>> 0 1 2 3 >>>>> 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 >>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>> | 29 | 4 | >>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>> | Unallocated Flags | >>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>> >>>>> Unallocated Flags: for now should be sent as 0 and ignored on >>>>> receipt. >>>>> >>>>> >>>>> I am ambivalent about defining the flags field. Does PIM require that >>>>> an options TLV is always the same length? If so, you are doing the >>>>> right thing, but if not, you could equally come back later and define >>>>> that, if the length is non-zero, the first four bytes are flags. But >>>>> this is Experimental, so I don't object. Mainly I am curious :-) >>> >>> I've added some text where I define it without the options, but also say >>> that implementations MUST accept an Hello with non-zero length and >>> ignore the contents. This way we should be able to add flags later if >>> needed. >>> >>>>> But anyway, I don't think you need the TLV format twice, and you need >>>>> to allow IANA to make the allocation (although you can suggest a >>>>> value in the IANA section). So you could rewrite as: >>>>> >>>>> The format follows the format of all Hello Option TLVs [RFC4601]: >>>>> >>>>> 0 1 2 3 >>>>> 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 >>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>> | OptionType = TBD1 | OptionLength = 4 | >>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>> | Unallocated Flags | >>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>> >>>>> Unallocated Flags: Unused flags SHOULD be sent as 0 and ignored on >>>>> receipt. This document defines no flags. >>>>> >>>>> Then, in Section 8... >>>>> >>>>> OLD >>>>> A new PIM Hello Option type, 29, has been assigned. See [HELLO] for >>>>> details. >>>>> NEW >>>>> IANA is requested to define a new PIM Hello Option type in the >>>>> registry at [HELLO]. >>>>> >>>>> Pop-Count Support TBD1 >>>>> >>>>> A value of 29 is suggested. >>> >>> I did something like this. But note that 29 has already been >>> temporarily assigned for this purpose. I'm noting that in the >>> new text. >>> >>>>> END >>>>> >>>>> >>>>> --- >>>>> >>>>> Section 4 >>>>> >>>>> Suggest >>>>> >>>>> s/Pop-Count attribute/Pop-Count Join Attribute/ >>>>> s/to process PIM Join Attribute/to process a PIM Join Attribute/ >>> >>> Done >>> >>>>> --- >>>>> >>>>> Section 4 >>>>> >>>>> Again, to leave this to IANA... >>>>> >>>>> OLD >>>>> Attr Type: 2. >>>>> NEW >>>>> Attr Type: TBD2 >>>>> END >>> >>> Done >>> >>>>> And then, in Section 8 >>>>> >>>>> OLD >>>>> A new PIM Join Attribute type needs to be assigned. 2 is proposed in >>>>> this draft. >>>>> NEW >>>>> IANA is requested to allocate a new PIM Join Attribute type. >>>>> >>>>> Pop-Count Join Attribute TBD2 >>>>> >>>>> A value of 2 is suggested. >>> >>> Done >>> >>>>> --- >>>>> >>>>> Section 4 >>>>> >>>>> Unallocated Flags: The flags which are currently not defined. >>>>> If a new flag is defined and sent by a new implementation, an >>>>> old implementation should preserve the bit settings. This >>>>> means that if a bit was set in a PIM Join message from any of >>>>> the downstream routers, then it MUST also be set in any PIM >>>>> Join sent upstream. >>>>> >>>>> Am I being too pedantic? Presumably clear bits MUST also be kept >>>>> clear. >>>>> How about: >>>>> This means that a router MUST preserve the settings of all Unallocated >>>>> Flags in PIM Join messages received from downstream routers in any PIM >>>>> Join sent upstream. >>> >>> You're absolutely right. Done. >>> >>>>> --- >>>>> >>>>> Section 4 >>>>> >>>>> P flag: This flag remains set if all downstream routers support >>>>> this specification. That is, they are PIM pop-count capable. >>>>> This allows one to tell if the entire sub-tree is completely >>>>> accounting capable. >>>>> >>>>> I'm not clear about this. Is the assumption that a router will clear >>>>> this flag if it knows that a downstream router is not PIM pop-count >>>>> capable? (I presume that the downstream router would not clear the >>>>> flag because it doesn't know about this I-D.) Can you clarify by >>>>> saying >>>>> who has the responsibility to clear the flag? >>> >>> Tried to make this clearer. >>>>> --- >>>>> >>>>> Section 4.2 has some ugly XML bleedthrough >>>>> >>>>>
>>>>> >>>>> >> >>> Done >>> >>>>> --- >>>>> >>>>> Section 5 has some lower case 2119-type words. Can you check to see >>>>> whether you mean upper case. >>> >>> Done. Some changes. >>> >>>>> --- >>>>> >>>>> Section 6 is good. It might be nice to note at the top that the >>>>> section is >>>>> non-normative. >>> >>> Done >>> >>>>> However, the final paragraph (with its recommendation and use of >>>>> "should >>>>> not") seems to be important enough to promote to Section 5 and to use >>>>> 2119 language. >>> >>> Done >>> >>>>> --- >>>>> >>>>> Section 9 >>>>> >>>>> I wonder... >>>>> >>>>> Does collecting this information put any additional burden on the >>>>> routers and the network? If so, might it be something that a router >>>>> should rate limit to prevent DoS? >>>>> >>>>> Does access to the information provide assistance to an attacker or >>>>> even just violate an operator's confidentiality? If so, there should >>>>> be a warning against sniffing attackers if the information is >>>>> considered >>>>> sensitive (I presume encrypting it is not possible). >>>>> >>>>> Now, you may say "so what?" but I think we should make a habit of >>>>> raising flags so that operators are aware and thoughtful. >>> >>> I rewrote the security considerations, trying to discuss this. >>> >>> Stig >>> >>>>> _______________________________________________ >>>>> pim mailing list >>>>> pim@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/pim >>>> >>>> _______________________________________________ >>>> pim mailing list >>>> pim@ietf.org >>>> https://www.ietf.org/mailman/listinfo/pim > > _______________________________________________ > pim mailing list > pim@ietf.org > https://www.ietf.org/mailman/listinfo/pim From mmcbride7@gmail.com Mon Apr 23 11:03:57 2012 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08BB221F861D for ; Mon, 23 Apr 2012 11:03:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YA7BN47SKW1f for ; Mon, 23 Apr 2012 11:03:55 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0DF5B21F860B for ; Mon, 23 Apr 2012 11:03:54 -0700 (PDT) Received: by lbgc1 with SMTP id c1so4998646lbg.31 for ; Mon, 23 Apr 2012 11:03:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=5DbtVrdh1R/Gu5aWlK6MTDvNaNGZE+Jy4vHOD+Cbl/o=; b=sjly3qEVdGPbXL5ouzhTEepAhZL/gwpzJHZczIX8TAjeIFnnu7NRRRRRAIWoieJZuj JBlKFYdLgc45KIv3dK/Z+uLZ1QQ1fLis4t3mFQaR2DepevnpBr1QUdpAmJ1R93zw93V4 OAPj4x/9OIfV07KdJ6F1nMG5q4kYhoihUZm66Y73X++zrivE6udw7sr/Uw91PzCrTaEx +OD4dvBAlTnilEI40I7cM5AgZmeTTzmHKrRuel3NTSJnsPdwXvoDoCapUxasR9MHYR70 IjjFezkqnoPijqpdB2W3o3QWZWuYyRCX/70mvM2BDvqmzEhgYb0ygOgJntROnfeOSNrE uUMA== MIME-Version: 1.0 Received: by 10.112.42.134 with SMTP id o6mr8643203lbl.70.1335204230236; Mon, 23 Apr 2012 11:03:50 -0700 (PDT) Received: by 10.152.134.7 with HTTP; Mon, 23 Apr 2012 11:03:50 -0700 (PDT) In-Reply-To: <4F8DABAB.8040802@venaas.com> References: <005101cd11d9$b1c44da0$154ce8e0$@olddog.co.uk> <4F832352.1000804@venaas.com> <4F847CAB.70402@venaas.com> <112401cd1760$5d8c56b0$18a50410$@olddog.co.uk> <4F84B09F.1020704@venaas.com> <4F8DABAB.8040802@venaas.com> Date: Mon, 23 Apr 2012 11:03:50 -0700 Message-ID: From: Mike McBride To: Stig Venaas Content-Type: text/plain; charset=ISO-8859-1 Cc: draft-ietf-pim-pop-count@tools.ietf.org, pim@ietf.org Subject: Re: [pim] AD review of draft-ietf-pim-pop-count X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 18:03:57 -0000 Stig, Thanks for the work. I have no concerns with your changes. Since there have been no comments in the last two weeks I feel we can proceed. Someone on this list will yell if they disagree. mike On Tue, Apr 17, 2012 at 10:43 AM, Stig Venaas wrote: > On 4/10/2012 3:13 PM, Stig Venaas wrote: >> >> On 4/10/2012 2:24 PM, Adrian Farrel wrote: >>> >>> Excellent job, Stig, thanks. >>> >>> I'd be OK with this, but you are right that the WG should have a quick >>> look to >>> make sure they are happy. >>> >>> Probably best to post it and let Mike run it from there. > > > Adrian, Mike and rest of WG, hope you can have a look and let everyone > know if you have any concerns. > > Stig > >> Based on Adrian's comments I've made several changes to the pop-count >> draft. I also found some other issues I've tried to resolve. >> >> Apart from changing wording, whether to use 2119 keywords etc., the only >> real protocol change IMO, is that the hello option no longer contains >> an option value with reserved bits. Instead I've added language that >> if a value is present, the hello option must be processes as if there >> is no value present. >> >> The new version is at >> http://www.ietf.org/internet-drafts/draft-ietf-pim-pop-count-06.txt >> >> and a diff is available at >> http://tools.ietf.org/rfcdiff?url2=draft-ietf-pim-pop-count-06 >> >> Adrian, please check if this resolves your issues. >> >> I hope other authors and people in the WG can help review this to make >> sure the changes are fine. >> >> I leave to Mike to ensure that the document is appropriately reviewed >> by the WG. >> >> Stig >> >>> >>> Cheers, >>> Adrian >>> >>>> -----Original Message----- >>>> From: Stig Venaas [mailto:stig@venaas.com] >>>> Sent: 10 April 2012 19:32 >>>> To: adrian@olddog.co.uk >>>> Cc: draft-ietf-pim-pop-count@tools.ietf.org; pim@ietf.org; Yiqun Cai >>>> Subject: Re: [pim] AD review of draft-ietf-pim-pop-count >>>> >>>> Hi >>>> >>>> I've been editing the document and hopefully resolved most of your >>>> concerns. Please see my comments below. >>>> >>>> Unless you see any obvious issues based on my comments, I can >>>> go ahead and submit a new version. >>>> >>>> Note that these changes are fairly big, I made a few additional ones, >>>> so I feel we also need to give the WG some time to review them. And >>>> of course also for you and the other authors to review them. >>>> >>>> Thanks a lot, I think this improved the document significantly. I >>>> also found some issues myself that I tried to take care of. >>>> >>>> On 4/9/2012 10:58 AM, Stig Venaas wrote: >>>>> >>>>> On 4/3/2012 1:38 PM, Adrian Farrel wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> Sorry I sat on this I-D a while doing my review. The review is my >>>>>> usual pass over the document to iron out nits that I think might >>>>>> show up in IETF last call, Directorate reviews, or during IESG >>>>>> evaluation. By catching the issues at this stage we can save the >>>>>> effort of multiple reviewers, and achieve a smoother passage >>>>>> through the publication process. >>>>>> >>>>>> All of my comments can be discussed. >>>>> >>>>> >>>>> Thanks for the detailed review. Your comments look good. I will start >>>>> working on an update. >>>>> >>>>> Stig >>>>> >>>>>> >>>>>> As it stands, I think a new revision would help address these point >>>>>> so I will move the I-D into "New Revision Required" state, and when >>>>>> I see an update I will advance the document to IETF last call. Please >>>>>> be sure that the new revision passes idnits. >>>>>> >>>>>> Thanks, >>>>>> Adrian >>>>>> >>>>>> --- >>>>>> >>>>>> Please update Yiqun's email address to yiqunc@microsoft.com and his >>>>>> coordinates to Microsoft. >>>> >>>> >>>> Done >>>> >>>>>> --- >>>>>> >>>>>> The RFC Editor likes the document to begin with an Introduction, so >>>>>> you could move Section 1 into 2.1 and renumber. >>>> >>>> >>>> Done >>>> >>>>>> --- >>>>>> >>>>>> I think that the RFC Editor likes all figures to be captioned and >>>>>> given >>>>>> a number (e.g. Figure 1 : A Sample Foobar). Further, they like all >>>>>> figures to be explicitly referenced form the text. >>>>>> >>>>>> That sounds a bore to do, but if you have the energy it might be worth >>>>>> it. >>>> >>>> >>>> Sorry, I didn't have the energy. I don't really think it is needed. And >>>> it can be done later if it really seems to be needed. >>>> >>>>>> --- >>>>>> >>>>>> Can you s/this draft/this document/ throughout since, on publication, >>>>>> this will not be a draft any more. >>>> >>>> >>>> Done >>>> >>>>>> --- >>>>>> >>>>>> We will get push-back from the IESG to "describe the experiment". >>>>>> >>>>>> I think this can be handled relatively easily in the Introduction with >>>>>> some text such as: >>>>>> >>>>>> This is a new proposal for an extension to PIM, and it is not >>>>>> completely understood what impact collecting information using PIM >>>>>> would have on the operation of PIM. Many PIM features (including the >>>>>> core protocol) were first introduced as Experimental RFCs, and it >>>>>> seems appropriate to advance this work as Experimental. Reports of >>>>>> implementation and deployment across whole distribution trees or >>>>>> within sub-trees (see Section 7) will enable an assessment of the >>>>>> desirability and stability of this feature. The PIM working group >>>>>> will then consider whether to move this work to the Standards Track. >>>>>> >>>>>> I am only showing example text here. I am not attached to the content, >>>>>> but I am trying to cover the bases in a way that the IESG is likely to >>>>>> request. Please feel free to use other text if it works better for >>>>>> you. >>>> >>>> >>>> I pretty much used your text here, and acknowledged you. >>>> >>>>>> --- >>>>>> >>>>>> I think you need to expand "oif-list" on first use. >>>> >>>> >>>> Done >>>> >>>>>> --- >>>>>> >>>>>> Section 3 >>>>>> >>>>>> If a PIM router supports this draft, it must send the Pop- >>>>>> Count-Supported TLV. >>>>>> >>>>>> I think this might be better written as: >>>>>> >>>>>> A PIM router indicates that it supports this document by sending the >>>>>> Pop-Count-Supported TLV in a PIM Hello message. >>>> >>>> >>>> Yes. I'm also calling it option instead of TLV as that is the >>>> terminology usually used in the docs. >>>> >>>>>> --- >>>>>> >>>>>> Section 3 >>>>>> >>>>>> The format of the TLV is defined to be: >>>>>> >>>>>> >>>>>> 0 1 2 3 >>>>>> 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 >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>> | OptionType | OptionLength | >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>> | OptionValue | >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>> >>>>>> OptionType = 29, OptionLength = 4, there is no OptionValue semantics >>>>>> defined at this time but will be included for expandability and be >>>>>> defined in future revisions of this draft. The format will look >>>>>> like: >>>>>> >>>>>> >>>>>> 0 1 2 3 >>>>>> 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 >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>> | 29 | 4 | >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>> | Unallocated Flags | >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>> >>>>>> Unallocated Flags: for now should be sent as 0 and ignored on >>>>>> receipt. >>>>>> >>>>>> >>>>>> I am ambivalent about defining the flags field. Does PIM require that >>>>>> an options TLV is always the same length? If so, you are doing the >>>>>> right thing, but if not, you could equally come back later and define >>>>>> that, if the length is non-zero, the first four bytes are flags. But >>>>>> this is Experimental, so I don't object. Mainly I am curious :-) >>>> >>>> >>>> I've added some text where I define it without the options, but also say >>>> that implementations MUST accept an Hello with non-zero length and >>>> ignore the contents. This way we should be able to add flags later if >>>> needed. >>>> >>>>>> But anyway, I don't think you need the TLV format twice, and you need >>>>>> to allow IANA to make the allocation (although you can suggest a >>>>>> value in the IANA section). So you could rewrite as: >>>>>> >>>>>> The format follows the format of all Hello Option TLVs [RFC4601]: >>>>>> >>>>>> 0 1 2 3 >>>>>> 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 >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>> | OptionType = TBD1 | OptionLength = 4 | >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>> | Unallocated Flags | >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>> >>>>>> Unallocated Flags: Unused flags SHOULD be sent as 0 and ignored on >>>>>> receipt. This document defines no flags. >>>>>> >>>>>> Then, in Section 8... >>>>>> >>>>>> OLD >>>>>> A new PIM Hello Option type, 29, has been assigned. See [HELLO] for >>>>>> details. >>>>>> NEW >>>>>> IANA is requested to define a new PIM Hello Option type in the >>>>>> registry at [HELLO]. >>>>>> >>>>>> Pop-Count Support TBD1 >>>>>> >>>>>> A value of 29 is suggested. >>>> >>>> >>>> I did something like this. But note that 29 has already been >>>> temporarily assigned for this purpose. I'm noting that in the >>>> new text. >>>> >>>>>> END >>>>>> >>>>>> >>>>>> --- >>>>>> >>>>>> Section 4 >>>>>> >>>>>> Suggest >>>>>> >>>>>> s/Pop-Count attribute/Pop-Count Join Attribute/ >>>>>> s/to process PIM Join Attribute/to process a PIM Join Attribute/ >>>> >>>> >>>> Done >>>> >>>>>> --- >>>>>> >>>>>> Section 4 >>>>>> >>>>>> Again, to leave this to IANA... >>>>>> >>>>>> OLD >>>>>> Attr Type: 2. >>>>>> NEW >>>>>> Attr Type: TBD2 >>>>>> END >>>> >>>> >>>> Done >>>> >>>>>> And then, in Section 8 >>>>>> >>>>>> OLD >>>>>> A new PIM Join Attribute type needs to be assigned. 2 is proposed in >>>>>> this draft. >>>>>> NEW >>>>>> IANA is requested to allocate a new PIM Join Attribute type. >>>>>> >>>>>> Pop-Count Join Attribute TBD2 >>>>>> >>>>>> A value of 2 is suggested. >>>> >>>> >>>> Done >>>> >>>>>> --- >>>>>> >>>>>> Section 4 >>>>>> >>>>>> Unallocated Flags: The flags which are currently not defined. >>>>>> If a new flag is defined and sent by a new implementation, an >>>>>> old implementation should preserve the bit settings. This >>>>>> means that if a bit was set in a PIM Join message from any of >>>>>> the downstream routers, then it MUST also be set in any PIM >>>>>> Join sent upstream. >>>>>> >>>>>> Am I being too pedantic? Presumably clear bits MUST also be kept >>>>>> clear. >>>>>> How about: >>>>>> This means that a router MUST preserve the settings of all Unallocated >>>>>> Flags in PIM Join messages received from downstream routers in any PIM >>>>>> Join sent upstream. >>>> >>>> >>>> You're absolutely right. Done. >>>> >>>>>> --- >>>>>> >>>>>> Section 4 >>>>>> >>>>>> P flag: This flag remains set if all downstream routers support >>>>>> this specification. That is, they are PIM pop-count capable. >>>>>> This allows one to tell if the entire sub-tree is completely >>>>>> accounting capable. >>>>>> >>>>>> I'm not clear about this. Is the assumption that a router will clear >>>>>> this flag if it knows that a downstream router is not PIM pop-count >>>>>> capable? (I presume that the downstream router would not clear the >>>>>> flag because it doesn't know about this I-D.) Can you clarify by >>>>>> saying >>>>>> who has the responsibility to clear the flag? >>>> >>>> >>>> Tried to make this clearer. >>>>>> >>>>>> --- >>>>>> >>>>>> Section 4.2 has some ugly XML bleedthrough >>>>>> >>>>>>
>>>>>> >>>>>> >>> >>>> >>>> Done >>>> >>>>>> --- >>>>>> >>>>>> Section 5 has some lower case 2119-type words. Can you check to see >>>>>> whether you mean upper case. >>>> >>>> >>>> Done. Some changes. >>>> >>>>>> --- >>>>>> >>>>>> Section 6 is good. It might be nice to note at the top that the >>>>>> section is >>>>>> non-normative. >>>> >>>> >>>> Done >>>> >>>>>> However, the final paragraph (with its recommendation and use of >>>>>> "should >>>>>> not") seems to be important enough to promote to Section 5 and to use >>>>>> 2119 language. >>>> >>>> >>>> Done >>>> >>>>>> --- >>>>>> >>>>>> Section 9 >>>>>> >>>>>> I wonder... >>>>>> >>>>>> Does collecting this information put any additional burden on the >>>>>> routers and the network? If so, might it be something that a router >>>>>> should rate limit to prevent DoS? >>>>>> >>>>>> Does access to the information provide assistance to an attacker or >>>>>> even just violate an operator's confidentiality? If so, there should >>>>>> be a warning against sniffing attackers if the information is >>>>>> considered >>>>>> sensitive (I presume encrypting it is not possible). >>>>>> >>>>>> Now, you may say "so what?" but I think we should make a habit of >>>>>> raising flags so that operators are aware and thoughtful. >>>> >>>> >>>> I rewrote the security considerations, trying to discuss this. >>>> >>>> Stig >>>> >>>>>> _______________________________________________ >>>>>> pim mailing list >>>>>> pim@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/pim >>>>> >>>>> >>>>> _______________________________________________ >>>>> pim mailing list >>>>> pim@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/pim >> >> >> _______________________________________________ >> pim mailing list >> pim@ietf.org >> https://www.ietf.org/mailman/listinfo/pim > > > _______________________________________________ > pim mailing list > pim@ietf.org > https://www.ietf.org/mailman/listinfo/pim From gjshep@gmail.com Mon Apr 23 11:29:13 2012 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C87D921F84B4 for ; Mon, 23 Apr 2012 11:29:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L-Y2RPbO+RmR for ; Mon, 23 Apr 2012 11:29:12 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3043421F84FB for ; Mon, 23 Apr 2012 11:29:12 -0700 (PDT) Received: by bkuw5 with SMTP id w5so10901848bku.31 for ; Mon, 23 Apr 2012 11:29:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=j5ZAjzzgBc+5oJMK1sIPnY2JTyQdeKd6OL9BPD6pMMw=; b=IsvxB9I2pJWF346171MyH7W8cqJ6JTafoXFCPjmPPPPt6DyUmjOktF0/BsInfPLeR+ XgYtTHtsutuAXiR5qfIo4vJXDfNYOZEdh4MGPmbnn+mDazN4qsXZcu7rLpqkZiXTN33w MAiY6TN1kmEz8x2EHQHQ3MjSrjHUNuRqYZrQ5K/RHGz9w0GX5rKYHy7xMmHKblGq66fT dxj2gUmXh0+yQ/MYs6KPpj/0k75iBovOiYDkexh0jE/8ZJvBRZ9j0SXWv5GhdjV/O4+v HZZaDWMJK+nHVjo9nYtueCoVFQvf/Vjazm2sMyjuSqG4CCFYLmT2UuJv9uDQBpFxsw5P G3lg== MIME-Version: 1.0 Received: by 10.205.132.16 with SMTP id hs16mr2519649bkc.115.1335205751100; Mon, 23 Apr 2012 11:29:11 -0700 (PDT) Received: by 10.204.41.205 with HTTP; Mon, 23 Apr 2012 11:29:10 -0700 (PDT) In-Reply-To: References: <005101cd11d9$b1c44da0$154ce8e0$@olddog.co.uk> <4F832352.1000804@venaas.com> <4F847CAB.70402@venaas.com> <112401cd1760$5d8c56b0$18a50410$@olddog.co.uk> <4F84B09F.1020704@venaas.com> <4F8DABAB.8040802@venaas.com> Date: Mon, 23 Apr 2012 11:29:10 -0700 Message-ID: From: Greg Shepherd To: Mike McBride Content-Type: text/plain; charset=ISO-8859-1 Cc: draft-ietf-pim-pop-count@tools.ietf.org, pim@ietf.org Subject: Re: [pim] AD review of draft-ietf-pim-pop-count X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: gjshep@gmail.com List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 18:29:13 -0000 Yes, thank you very much, Stig! Greg On Mon, Apr 23, 2012 at 11:03 AM, Mike McBride wrote: > Stig, > > Thanks for the work. I have no concerns with your changes. Since there > have been no comments in the last two weeks I feel we can proceed. > Someone on this list will yell if they disagree. > > mike > > On Tue, Apr 17, 2012 at 10:43 AM, Stig Venaas wrote: >> On 4/10/2012 3:13 PM, Stig Venaas wrote: >>> >>> On 4/10/2012 2:24 PM, Adrian Farrel wrote: >>>> >>>> Excellent job, Stig, thanks. >>>> >>>> I'd be OK with this, but you are right that the WG should have a quick >>>> look to >>>> make sure they are happy. >>>> >>>> Probably best to post it and let Mike run it from there. >> >> >> Adrian, Mike and rest of WG, hope you can have a look and let everyone >> know if you have any concerns. >> >> Stig >> >>> Based on Adrian's comments I've made several changes to the pop-count >>> draft. I also found some other issues I've tried to resolve. >>> >>> Apart from changing wording, whether to use 2119 keywords etc., the only >>> real protocol change IMO, is that the hello option no longer contains >>> an option value with reserved bits. Instead I've added language that >>> if a value is present, the hello option must be processes as if there >>> is no value present. >>> >>> The new version is at >>> http://www.ietf.org/internet-drafts/draft-ietf-pim-pop-count-06.txt >>> >>> and a diff is available at >>> http://tools.ietf.org/rfcdiff?url2=draft-ietf-pim-pop-count-06 >>> >>> Adrian, please check if this resolves your issues. >>> >>> I hope other authors and people in the WG can help review this to make >>> sure the changes are fine. >>> >>> I leave to Mike to ensure that the document is appropriately reviewed >>> by the WG. >>> >>> Stig >>> >>>> >>>> Cheers, >>>> Adrian >>>> >>>>> -----Original Message----- >>>>> From: Stig Venaas [mailto:stig@venaas.com] >>>>> Sent: 10 April 2012 19:32 >>>>> To: adrian@olddog.co.uk >>>>> Cc: draft-ietf-pim-pop-count@tools.ietf.org; pim@ietf.org; Yiqun Cai >>>>> Subject: Re: [pim] AD review of draft-ietf-pim-pop-count >>>>> >>>>> Hi >>>>> >>>>> I've been editing the document and hopefully resolved most of your >>>>> concerns. Please see my comments below. >>>>> >>>>> Unless you see any obvious issues based on my comments, I can >>>>> go ahead and submit a new version. >>>>> >>>>> Note that these changes are fairly big, I made a few additional ones, >>>>> so I feel we also need to give the WG some time to review them. And >>>>> of course also for you and the other authors to review them. >>>>> >>>>> Thanks a lot, I think this improved the document significantly. I >>>>> also found some issues myself that I tried to take care of. >>>>> >>>>> On 4/9/2012 10:58 AM, Stig Venaas wrote: >>>>>> >>>>>> On 4/3/2012 1:38 PM, Adrian Farrel wrote: >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> Sorry I sat on this I-D a while doing my review. The review is my >>>>>>> usual pass over the document to iron out nits that I think might >>>>>>> show up in IETF last call, Directorate reviews, or during IESG >>>>>>> evaluation. By catching the issues at this stage we can save the >>>>>>> effort of multiple reviewers, and achieve a smoother passage >>>>>>> through the publication process. >>>>>>> >>>>>>> All of my comments can be discussed. >>>>>> >>>>>> >>>>>> Thanks for the detailed review. Your comments look good. I will start >>>>>> working on an update. >>>>>> >>>>>> Stig >>>>>> >>>>>>> >>>>>>> As it stands, I think a new revision would help address these point >>>>>>> so I will move the I-D into "New Revision Required" state, and when >>>>>>> I see an update I will advance the document to IETF last call. Please >>>>>>> be sure that the new revision passes idnits. >>>>>>> >>>>>>> Thanks, >>>>>>> Adrian >>>>>>> >>>>>>> --- >>>>>>> >>>>>>> Please update Yiqun's email address to yiqunc@microsoft.com and his >>>>>>> coordinates to Microsoft. >>>>> >>>>> >>>>> Done >>>>> >>>>>>> --- >>>>>>> >>>>>>> The RFC Editor likes the document to begin with an Introduction, so >>>>>>> you could move Section 1 into 2.1 and renumber. >>>>> >>>>> >>>>> Done >>>>> >>>>>>> --- >>>>>>> >>>>>>> I think that the RFC Editor likes all figures to be captioned and >>>>>>> given >>>>>>> a number (e.g. Figure 1 : A Sample Foobar). Further, they like all >>>>>>> figures to be explicitly referenced form the text. >>>>>>> >>>>>>> That sounds a bore to do, but if you have the energy it might be worth >>>>>>> it. >>>>> >>>>> >>>>> Sorry, I didn't have the energy. I don't really think it is needed. And >>>>> it can be done later if it really seems to be needed. >>>>> >>>>>>> --- >>>>>>> >>>>>>> Can you s/this draft/this document/ throughout since, on publication, >>>>>>> this will not be a draft any more. >>>>> >>>>> >>>>> Done >>>>> >>>>>>> --- >>>>>>> >>>>>>> We will get push-back from the IESG to "describe the experiment". >>>>>>> >>>>>>> I think this can be handled relatively easily in the Introduction with >>>>>>> some text such as: >>>>>>> >>>>>>> This is a new proposal for an extension to PIM, and it is not >>>>>>> completely understood what impact collecting information using PIM >>>>>>> would have on the operation of PIM. Many PIM features (including the >>>>>>> core protocol) were first introduced as Experimental RFCs, and it >>>>>>> seems appropriate to advance this work as Experimental. Reports of >>>>>>> implementation and deployment across whole distribution trees or >>>>>>> within sub-trees (see Section 7) will enable an assessment of the >>>>>>> desirability and stability of this feature. The PIM working group >>>>>>> will then consider whether to move this work to the Standards Track. >>>>>>> >>>>>>> I am only showing example text here. I am not attached to the content, >>>>>>> but I am trying to cover the bases in a way that the IESG is likely to >>>>>>> request. Please feel free to use other text if it works better for >>>>>>> you. >>>>> >>>>> >>>>> I pretty much used your text here, and acknowledged you. >>>>> >>>>>>> --- >>>>>>> >>>>>>> I think you need to expand "oif-list" on first use. >>>>> >>>>> >>>>> Done >>>>> >>>>>>> --- >>>>>>> >>>>>>> Section 3 >>>>>>> >>>>>>> If a PIM router supports this draft, it must send the Pop- >>>>>>> Count-Supported TLV. >>>>>>> >>>>>>> I think this might be better written as: >>>>>>> >>>>>>> A PIM router indicates that it supports this document by sending the >>>>>>> Pop-Count-Supported TLV in a PIM Hello message. >>>>> >>>>> >>>>> Yes. I'm also calling it option instead of TLV as that is the >>>>> terminology usually used in the docs. >>>>> >>>>>>> --- >>>>>>> >>>>>>> Section 3 >>>>>>> >>>>>>> The format of the TLV is defined to be: >>>>>>> >>>>>>> >>>>>>> 0 1 2 3 >>>>>>> 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 >>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>>> | OptionType | OptionLength | >>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>>> | OptionValue | >>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>>> >>>>>>> OptionType = 29, OptionLength = 4, there is no OptionValue semantics >>>>>>> defined at this time but will be included for expandability and be >>>>>>> defined in future revisions of this draft. The format will look >>>>>>> like: >>>>>>> >>>>>>> >>>>>>> 0 1 2 3 >>>>>>> 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 >>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>>> | 29 | 4 | >>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>>> | Unallocated Flags | >>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>>> >>>>>>> Unallocated Flags: for now should be sent as 0 and ignored on >>>>>>> receipt. >>>>>>> >>>>>>> >>>>>>> I am ambivalent about defining the flags field. Does PIM require that >>>>>>> an options TLV is always the same length? If so, you are doing the >>>>>>> right thing, but if not, you could equally come back later and define >>>>>>> that, if the length is non-zero, the first four bytes are flags. But >>>>>>> this is Experimental, so I don't object. Mainly I am curious :-) >>>>> >>>>> >>>>> I've added some text where I define it without the options, but also say >>>>> that implementations MUST accept an Hello with non-zero length and >>>>> ignore the contents. This way we should be able to add flags later if >>>>> needed. >>>>> >>>>>>> But anyway, I don't think you need the TLV format twice, and you need >>>>>>> to allow IANA to make the allocation (although you can suggest a >>>>>>> value in the IANA section). So you could rewrite as: >>>>>>> >>>>>>> The format follows the format of all Hello Option TLVs [RFC4601]: >>>>>>> >>>>>>> 0 1 2 3 >>>>>>> 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 >>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>>> | OptionType = TBD1 | OptionLength = 4 | >>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>>> | Unallocated Flags | >>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>>> >>>>>>> Unallocated Flags: Unused flags SHOULD be sent as 0 and ignored on >>>>>>> receipt. This document defines no flags. >>>>>>> >>>>>>> Then, in Section 8... >>>>>>> >>>>>>> OLD >>>>>>> A new PIM Hello Option type, 29, has been assigned. See [HELLO] for >>>>>>> details. >>>>>>> NEW >>>>>>> IANA is requested to define a new PIM Hello Option type in the >>>>>>> registry at [HELLO]. >>>>>>> >>>>>>> Pop-Count Support TBD1 >>>>>>> >>>>>>> A value of 29 is suggested. >>>>> >>>>> >>>>> I did something like this. But note that 29 has already been >>>>> temporarily assigned for this purpose. I'm noting that in the >>>>> new text. >>>>> >>>>>>> END >>>>>>> >>>>>>> >>>>>>> --- >>>>>>> >>>>>>> Section 4 >>>>>>> >>>>>>> Suggest >>>>>>> >>>>>>> s/Pop-Count attribute/Pop-Count Join Attribute/ >>>>>>> s/to process PIM Join Attribute/to process a PIM Join Attribute/ >>>>> >>>>> >>>>> Done >>>>> >>>>>>> --- >>>>>>> >>>>>>> Section 4 >>>>>>> >>>>>>> Again, to leave this to IANA... >>>>>>> >>>>>>> OLD >>>>>>> Attr Type: 2. >>>>>>> NEW >>>>>>> Attr Type: TBD2 >>>>>>> END >>>>> >>>>> >>>>> Done >>>>> >>>>>>> And then, in Section 8 >>>>>>> >>>>>>> OLD >>>>>>> A new PIM Join Attribute type needs to be assigned. 2 is proposed in >>>>>>> this draft. >>>>>>> NEW >>>>>>> IANA is requested to allocate a new PIM Join Attribute type. >>>>>>> >>>>>>> Pop-Count Join Attribute TBD2 >>>>>>> >>>>>>> A value of 2 is suggested. >>>>> >>>>> >>>>> Done >>>>> >>>>>>> --- >>>>>>> >>>>>>> Section 4 >>>>>>> >>>>>>> Unallocated Flags: The flags which are currently not defined. >>>>>>> If a new flag is defined and sent by a new implementation, an >>>>>>> old implementation should preserve the bit settings. This >>>>>>> means that if a bit was set in a PIM Join message from any of >>>>>>> the downstream routers, then it MUST also be set in any PIM >>>>>>> Join sent upstream. >>>>>>> >>>>>>> Am I being too pedantic? Presumably clear bits MUST also be kept >>>>>>> clear. >>>>>>> How about: >>>>>>> This means that a router MUST preserve the settings of all Unallocated >>>>>>> Flags in PIM Join messages received from downstream routers in any PIM >>>>>>> Join sent upstream. >>>>> >>>>> >>>>> You're absolutely right. Done. >>>>> >>>>>>> --- >>>>>>> >>>>>>> Section 4 >>>>>>> >>>>>>> P flag: This flag remains set if all downstream routers support >>>>>>> this specification. That is, they are PIM pop-count capable. >>>>>>> This allows one to tell if the entire sub-tree is completely >>>>>>> accounting capable. >>>>>>> >>>>>>> I'm not clear about this. Is the assumption that a router will clear >>>>>>> this flag if it knows that a downstream router is not PIM pop-count >>>>>>> capable? (I presume that the downstream router would not clear the >>>>>>> flag because it doesn't know about this I-D.) Can you clarify by >>>>>>> saying >>>>>>> who has the responsibility to clear the flag? >>>>> >>>>> >>>>> Tried to make this clearer. >>>>>>> >>>>>>> --- >>>>>>> >>>>>>> Section 4.2 has some ugly XML bleedthrough >>>>>>> >>>>>>>
>>>>>>> >>>>>>> >>>> >>>>> >>>>> Done >>>>> >>>>>>> --- >>>>>>> >>>>>>> Section 5 has some lower case 2119-type words. Can you check to see >>>>>>> whether you mean upper case. >>>>> >>>>> >>>>> Done. Some changes. >>>>> >>>>>>> --- >>>>>>> >>>>>>> Section 6 is good. It might be nice to note at the top that the >>>>>>> section is >>>>>>> non-normative. >>>>> >>>>> >>>>> Done >>>>> >>>>>>> However, the final paragraph (with its recommendation and use of >>>>>>> "should >>>>>>> not") seems to be important enough to promote to Section 5 and to use >>>>>>> 2119 language. >>>>> >>>>> >>>>> Done >>>>> >>>>>>> --- >>>>>>> >>>>>>> Section 9 >>>>>>> >>>>>>> I wonder... >>>>>>> >>>>>>> Does collecting this information put any additional burden on the >>>>>>> routers and the network? If so, might it be something that a router >>>>>>> should rate limit to prevent DoS? >>>>>>> >>>>>>> Does access to the information provide assistance to an attacker or >>>>>>> even just violate an operator's confidentiality? If so, there should >>>>>>> be a warning against sniffing attackers if the information is >>>>>>> considered >>>>>>> sensitive (I presume encrypting it is not possible). >>>>>>> >>>>>>> Now, you may say "so what?" but I think we should make a habit of >>>>>>> raising flags so that operators are aware and thoughtful. >>>>> >>>>> >>>>> I rewrote the security considerations, trying to discuss this. >>>>> >>>>> Stig >>>>> >>>>>>> _______________________________________________ >>>>>>> pim mailing list >>>>>>> pim@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/pim >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> pim mailing list >>>>>> pim@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/pim >>> >>> >>> _______________________________________________ >>> pim mailing list >>> pim@ietf.org >>> https://www.ietf.org/mailman/listinfo/pim >> >> >> _______________________________________________ >> pim mailing list >> pim@ietf.org >> https://www.ietf.org/mailman/listinfo/pim From adrian@olddog.co.uk Wed Apr 25 14:50:47 2012 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4425221E8037 for ; Wed, 25 Apr 2012 14:50:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.525 X-Spam-Level: X-Spam-Status: No, score=-2.525 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RXe4oumgx4gu for ; Wed, 25 Apr 2012 14:50:46 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id 745FA21E803D for ; Wed, 25 Apr 2012 14:50:45 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id q3PLohgT021109; Wed, 25 Apr 2012 22:50:43 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id q3PLog6j021099 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 25 Apr 2012 22:50:42 +0100 From: "Adrian Farrel" To: "'Mike McBride'" , "'Stig Venaas'" References: <005101cd11d9$b1c44da0$154ce8e0$@olddog.co.uk> <4F832352.1000804@venaas.com> <4F847CAB.70402@venaas.com> <112401cd1760$5d8c56b0$18a50410$@olddog.co.uk> <4F84B09F.1020704@venaas.com> <4F8DABAB.8040802@venaas.com> In-Reply-To: Date: Wed, 25 Apr 2012 22:50:40 +0100 Message-ID: <075801cd232d$758da510$60a8ef30$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEu7qDKVajglam8QL67CUF5vgxGHwHgyUwlAcsefiEBRjd9QgEp/KHsAkEdzhwCNYSYm5eT52Ig Content-Language: en-gb Cc: draft-ietf-pim-pop-count@tools.ietf.org, pim@ietf.org Subject: Re: [pim] AD review of draft-ietf-pim-pop-count X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 21:50:47 -0000 Thanks, I'll take this forward. Adrian > -----Original Message----- > From: Mike McBride [mailto:mmcbride7@gmail.com] > Sent: 23 April 2012 19:04 > To: Stig Venaas > Cc: adrian@olddog.co.uk; draft-ietf-pim-pop-count@tools.ietf.org; pim@ietf.org > Subject: Re: [pim] AD review of draft-ietf-pim-pop-count > > Stig, > > Thanks for the work. I have no concerns with your changes. Since there > have been no comments in the last two weeks I feel we can proceed. > Someone on this list will yell if they disagree. > > mike > > On Tue, Apr 17, 2012 at 10:43 AM, Stig Venaas wrote: > > On 4/10/2012 3:13 PM, Stig Venaas wrote: > >> > >> On 4/10/2012 2:24 PM, Adrian Farrel wrote: > >>> > >>> Excellent job, Stig, thanks. > >>> > >>> I'd be OK with this, but you are right that the WG should have a quick > >>> look to > >>> make sure they are happy. > >>> > >>> Probably best to post it and let Mike run it from there. > > > > > > Adrian, Mike and rest of WG, hope you can have a look and let everyone > > know if you have any concerns. > > > > Stig > > > >> Based on Adrian's comments I've made several changes to the pop-count > >> draft. I also found some other issues I've tried to resolve. > >> > >> Apart from changing wording, whether to use 2119 keywords etc., the only > >> real protocol change IMO, is that the hello option no longer contains > >> an option value with reserved bits. Instead I've added language that > >> if a value is present, the hello option must be processes as if there > >> is no value present. > >> > >> The new version is at > >> http://www.ietf.org/internet-drafts/draft-ietf-pim-pop-count-06.txt > >> > >> and a diff is available at > >> http://tools.ietf.org/rfcdiff?url2=draft-ietf-pim-pop-count-06 > >> > >> Adrian, please check if this resolves your issues. > >> > >> I hope other authors and people in the WG can help review this to make > >> sure the changes are fine. > >> > >> I leave to Mike to ensure that the document is appropriately reviewed > >> by the WG. > >> > >> Stig > >> > >>> > >>> Cheers, > >>> Adrian > >>> > >>>> -----Original Message----- > >>>> From: Stig Venaas [mailto:stig@venaas.com] > >>>> Sent: 10 April 2012 19:32 > >>>> To: adrian@olddog.co.uk > >>>> Cc: draft-ietf-pim-pop-count@tools.ietf.org; pim@ietf.org; Yiqun Cai > >>>> Subject: Re: [pim] AD review of draft-ietf-pim-pop-count > >>>> > >>>> Hi > >>>> > >>>> I've been editing the document and hopefully resolved most of your > >>>> concerns. Please see my comments below. > >>>> > >>>> Unless you see any obvious issues based on my comments, I can > >>>> go ahead and submit a new version. > >>>> > >>>> Note that these changes are fairly big, I made a few additional ones, > >>>> so I feel we also need to give the WG some time to review them. And > >>>> of course also for you and the other authors to review them. > >>>> > >>>> Thanks a lot, I think this improved the document significantly. I > >>>> also found some issues myself that I tried to take care of. > >>>> > >>>> On 4/9/2012 10:58 AM, Stig Venaas wrote: > >>>>> > >>>>> On 4/3/2012 1:38 PM, Adrian Farrel wrote: > >>>>>> > >>>>>> Hi, > >>>>>> > >>>>>> Sorry I sat on this I-D a while doing my review. The review is my > >>>>>> usual pass over the document to iron out nits that I think might > >>>>>> show up in IETF last call, Directorate reviews, or during IESG > >>>>>> evaluation. By catching the issues at this stage we can save the > >>>>>> effort of multiple reviewers, and achieve a smoother passage > >>>>>> through the publication process. > >>>>>> > >>>>>> All of my comments can be discussed. > >>>>> > >>>>> > >>>>> Thanks for the detailed review. Your comments look good. I will start > >>>>> working on an update. > >>>>> > >>>>> Stig > >>>>> > >>>>>> > >>>>>> As it stands, I think a new revision would help address these point > >>>>>> so I will move the I-D into "New Revision Required" state, and when > >>>>>> I see an update I will advance the document to IETF last call. Please > >>>>>> be sure that the new revision passes idnits. > >>>>>> > >>>>>> Thanks, > >>>>>> Adrian > >>>>>> > >>>>>> --- > >>>>>> > >>>>>> Please update Yiqun's email address to yiqunc@microsoft.com and his > >>>>>> coordinates to Microsoft. > >>>> > >>>> > >>>> Done > >>>> > >>>>>> --- > >>>>>> > >>>>>> The RFC Editor likes the document to begin with an Introduction, so > >>>>>> you could move Section 1 into 2.1 and renumber. > >>>> > >>>> > >>>> Done > >>>> > >>>>>> --- > >>>>>> > >>>>>> I think that the RFC Editor likes all figures to be captioned and > >>>>>> given > >>>>>> a number (e.g. Figure 1 : A Sample Foobar). Further, they like all > >>>>>> figures to be explicitly referenced form the text. > >>>>>> > >>>>>> That sounds a bore to do, but if you have the energy it might be worth > >>>>>> it. > >>>> > >>>> > >>>> Sorry, I didn't have the energy. I don't really think it is needed. And > >>>> it can be done later if it really seems to be needed. > >>>> > >>>>>> --- > >>>>>> > >>>>>> Can you s/this draft/this document/ throughout since, on publication, > >>>>>> this will not be a draft any more. > >>>> > >>>> > >>>> Done > >>>> > >>>>>> --- > >>>>>> > >>>>>> We will get push-back from the IESG to "describe the experiment". > >>>>>> > >>>>>> I think this can be handled relatively easily in the Introduction with > >>>>>> some text such as: > >>>>>> > >>>>>> This is a new proposal for an extension to PIM, and it is not > >>>>>> completely understood what impact collecting information using PIM > >>>>>> would have on the operation of PIM. Many PIM features (including the > >>>>>> core protocol) were first introduced as Experimental RFCs, and it > >>>>>> seems appropriate to advance this work as Experimental. Reports of > >>>>>> implementation and deployment across whole distribution trees or > >>>>>> within sub-trees (see Section 7) will enable an assessment of the > >>>>>> desirability and stability of this feature. The PIM working group > >>>>>> will then consider whether to move this work to the Standards Track. > >>>>>> > >>>>>> I am only showing example text here. I am not attached to the content, > >>>>>> but I am trying to cover the bases in a way that the IESG is likely to > >>>>>> request. Please feel free to use other text if it works better for > >>>>>> you. > >>>> > >>>> > >>>> I pretty much used your text here, and acknowledged you. > >>>> > >>>>>> --- > >>>>>> > >>>>>> I think you need to expand "oif-list" on first use. > >>>> > >>>> > >>>> Done > >>>> > >>>>>> --- > >>>>>> > >>>>>> Section 3 > >>>>>> > >>>>>> If a PIM router supports this draft, it must send the Pop- > >>>>>> Count-Supported TLV. > >>>>>> > >>>>>> I think this might be better written as: > >>>>>> > >>>>>> A PIM router indicates that it supports this document by sending the > >>>>>> Pop-Count-Supported TLV in a PIM Hello message. > >>>> > >>>> > >>>> Yes. I'm also calling it option instead of TLV as that is the > >>>> terminology usually used in the docs. > >>>> > >>>>>> --- > >>>>>> > >>>>>> Section 3 > >>>>>> > >>>>>> The format of the TLV is defined to be: > >>>>>> > >>>>>> > >>>>>> 0 1 2 3 > >>>>>> 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 > >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >>>>>> | OptionType | OptionLength | > >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >>>>>> | OptionValue | > >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >>>>>> > >>>>>> OptionType = 29, OptionLength = 4, there is no OptionValue semantics > >>>>>> defined at this time but will be included for expandability and be > >>>>>> defined in future revisions of this draft. The format will look > >>>>>> like: > >>>>>> > >>>>>> > >>>>>> 0 1 2 3 > >>>>>> 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 > >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >>>>>> | 29 | 4 | > >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >>>>>> | Unallocated Flags | > >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >>>>>> > >>>>>> Unallocated Flags: for now should be sent as 0 and ignored on > >>>>>> receipt. > >>>>>> > >>>>>> > >>>>>> I am ambivalent about defining the flags field. Does PIM require that > >>>>>> an options TLV is always the same length? If so, you are doing the > >>>>>> right thing, but if not, you could equally come back later and define > >>>>>> that, if the length is non-zero, the first four bytes are flags. But > >>>>>> this is Experimental, so I don't object. Mainly I am curious :-) > >>>> > >>>> > >>>> I've added some text where I define it without the options, but also say > >>>> that implementations MUST accept an Hello with non-zero length and > >>>> ignore the contents. This way we should be able to add flags later if > >>>> needed. > >>>> > >>>>>> But anyway, I don't think you need the TLV format twice, and you need > >>>>>> to allow IANA to make the allocation (although you can suggest a > >>>>>> value in the IANA section). So you could rewrite as: > >>>>>> > >>>>>> The format follows the format of all Hello Option TLVs [RFC4601]: > >>>>>> > >>>>>> 0 1 2 3 > >>>>>> 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 > >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >>>>>> | OptionType = TBD1 | OptionLength = 4 | > >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >>>>>> | Unallocated Flags | > >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >>>>>> > >>>>>> Unallocated Flags: Unused flags SHOULD be sent as 0 and ignored on > >>>>>> receipt. This document defines no flags. > >>>>>> > >>>>>> Then, in Section 8... > >>>>>> > >>>>>> OLD > >>>>>> A new PIM Hello Option type, 29, has been assigned. See [HELLO] for > >>>>>> details. > >>>>>> NEW > >>>>>> IANA is requested to define a new PIM Hello Option type in the > >>>>>> registry at [HELLO]. > >>>>>> > >>>>>> Pop-Count Support TBD1 > >>>>>> > >>>>>> A value of 29 is suggested. > >>>> > >>>> > >>>> I did something like this. But note that 29 has already been > >>>> temporarily assigned for this purpose. I'm noting that in the > >>>> new text. > >>>> > >>>>>> END > >>>>>> > >>>>>> > >>>>>> --- > >>>>>> > >>>>>> Section 4 > >>>>>> > >>>>>> Suggest > >>>>>> > >>>>>> s/Pop-Count attribute/Pop-Count Join Attribute/ > >>>>>> s/to process PIM Join Attribute/to process a PIM Join Attribute/ > >>>> > >>>> > >>>> Done > >>>> > >>>>>> --- > >>>>>> > >>>>>> Section 4 > >>>>>> > >>>>>> Again, to leave this to IANA... > >>>>>> > >>>>>> OLD > >>>>>> Attr Type: 2. > >>>>>> NEW > >>>>>> Attr Type: TBD2 > >>>>>> END > >>>> > >>>> > >>>> Done > >>>> > >>>>>> And then, in Section 8 > >>>>>> > >>>>>> OLD > >>>>>> A new PIM Join Attribute type needs to be assigned. 2 is proposed in > >>>>>> this draft. > >>>>>> NEW > >>>>>> IANA is requested to allocate a new PIM Join Attribute type. > >>>>>> > >>>>>> Pop-Count Join Attribute TBD2 > >>>>>> > >>>>>> A value of 2 is suggested. > >>>> > >>>> > >>>> Done > >>>> > >>>>>> --- > >>>>>> > >>>>>> Section 4 > >>>>>> > >>>>>> Unallocated Flags: The flags which are currently not defined. > >>>>>> If a new flag is defined and sent by a new implementation, an > >>>>>> old implementation should preserve the bit settings. This > >>>>>> means that if a bit was set in a PIM Join message from any of > >>>>>> the downstream routers, then it MUST also be set in any PIM > >>>>>> Join sent upstream. > >>>>>> > >>>>>> Am I being too pedantic? Presumably clear bits MUST also be kept > >>>>>> clear. > >>>>>> How about: > >>>>>> This means that a router MUST preserve the settings of all Unallocated > >>>>>> Flags in PIM Join messages received from downstream routers in any > PIM > >>>>>> Join sent upstream. > >>>> > >>>> > >>>> You're absolutely right. Done. > >>>> > >>>>>> --- > >>>>>> > >>>>>> Section 4 > >>>>>> > >>>>>> P flag: This flag remains set if all downstream routers support > >>>>>> this specification. That is, they are PIM pop-count capable. > >>>>>> This allows one to tell if the entire sub-tree is completely > >>>>>> accounting capable. > >>>>>> > >>>>>> I'm not clear about this. Is the assumption that a router will clear > >>>>>> this flag if it knows that a downstream router is not PIM pop-count > >>>>>> capable? (I presume that the downstream router would not clear the > >>>>>> flag because it doesn't know about this I-D.) Can you clarify by > >>>>>> saying > >>>>>> who has the responsibility to clear the flag? > >>>> > >>>> > >>>> Tried to make this clearer. > >>>>>> > >>>>>> --- > >>>>>> > >>>>>> Section 4.2 has some ugly XML bleedthrough > >>>>>> > >>>>>>
> >>>>>> > >>>>>> >>>> > >>>> > >>>> Done > >>>> > >>>>>> --- > >>>>>> > >>>>>> Section 5 has some lower case 2119-type words. Can you check to see > >>>>>> whether you mean upper case. > >>>> > >>>> > >>>> Done. Some changes. > >>>> > >>>>>> --- > >>>>>> > >>>>>> Section 6 is good. It might be nice to note at the top that the > >>>>>> section is > >>>>>> non-normative. > >>>> > >>>> > >>>> Done > >>>> > >>>>>> However, the final paragraph (with its recommendation and use of > >>>>>> "should > >>>>>> not") seems to be important enough to promote to Section 5 and to use > >>>>>> 2119 language. > >>>> > >>>> > >>>> Done > >>>> > >>>>>> --- > >>>>>> > >>>>>> Section 9 > >>>>>> > >>>>>> I wonder... > >>>>>> > >>>>>> Does collecting this information put any additional burden on the > >>>>>> routers and the network? If so, might it be something that a router > >>>>>> should rate limit to prevent DoS? > >>>>>> > >>>>>> Does access to the information provide assistance to an attacker or > >>>>>> even just violate an operator's confidentiality? If so, there should > >>>>>> be a warning against sniffing attackers if the information is > >>>>>> considered > >>>>>> sensitive (I presume encrypting it is not possible). > >>>>>> > >>>>>> Now, you may say "so what?" but I think we should make a habit of > >>>>>> raising flags so that operators are aware and thoughtful. > >>>> > >>>> > >>>> I rewrote the security considerations, trying to discuss this. > >>>> > >>>> Stig > >>>> > >>>>>> _______________________________________________ > >>>>>> pim mailing list > >>>>>> pim@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/pim > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> pim mailing list > >>>>> pim@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/pim > >> > >> > >> _______________________________________________ > >> pim mailing list > >> pim@ietf.org > >> https://www.ietf.org/mailman/listinfo/pim > > > > > > _______________________________________________ > > pim mailing list > > pim@ietf.org > > https://www.ietf.org/mailman/listinfo/pim From internet-drafts@ietf.org Thu Apr 26 21:50:48 2012 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C41A21F872E; Thu, 26 Apr 2012 21:50:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.502 X-Spam-Level: X-Spam-Status: No, score=-102.502 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Z5W3eSoLrfd; Thu, 26 Apr 2012 21:50:46 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6487A21F8720; Thu, 26 Apr 2012 21:50:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120427045046.14113.46440.idtracker@ietfa.amsl.com> Date: Thu, 26 Apr 2012 21:50:46 -0700 Cc: pim@ietf.org Subject: [pim] I-D Action: draft-ietf-pim-ecmp-03.txt X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2012 04:50:48 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Protocol Independent Multicast Workin= g Group of the IETF. Title : Protocol Independent Multicast ECMP Redirect Author(s) : Yiqun Cai Liming Wei Heidi Ou Vishal Arya Sunil Jethwani Filename : draft-ietf-pim-ecmp-03.txt Pages : 12 Date : 2012-04-26 A Protocol Independent Multicast (PIM) [RFC4601] router uses the Reverse Path Forwarding (RPF) procedure to select an upstream interface and router to build forwarding state. When there are equal cost multiple paths (ECMP), existing implementations often use hash algorithms to select a path. Such algorithms do not allow the spread of traffic among the ECMPs according to administrative metrics. This usually leads to inefficient or ineffective use of network resources. This document introduces the ECMP Redirect, a mechanism to improve the RPF procedure over ECMPs. It allows ECMP path selection to be based on administratively selected metrics, such as data transmission delays, path preferences and routing metrics. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pim-ecmp-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-pim-ecmp-03.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-pim-ecmp/