Re: [Gen-art] Gen-ART LC review of draft-ietf-pim-group-rp-mapping-07.txt
"Andy Kessler (kessler)" <kessler@cisco.com> Sat, 18 December 2010 05:34 UTC
Return-Path: <kessler@cisco.com>
X-Original-To: gen-art@core3.amsl.com
Delivered-To: gen-art@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09E2A3A69A9 for <gen-art@core3.amsl.com>; Fri, 17 Dec 2010 21:34:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ybSurtSOtKiu for <gen-art@core3.amsl.com>; Fri, 17 Dec 2010 21:34:51 -0800 (PST)
Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id F05C03A6985 for <gen-art@ietf.org>; Fri, 17 Dec 2010 21:34:50 -0800 (PST)
Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EAA7XC02rRN+J/2dsb2JhbACDZJ9uYHOiQopLkFmBIYM1dASEZYk5
X-IronPort-AV: E=Sophos;i="4.60,192,1291593600"; d="scan'208";a="234656580"
Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 18 Dec 2010 05:36:39 +0000
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id oBI5ads3012819; Sat, 18 Dec 2010 05:36:39 GMT
Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 17 Dec 2010 21:36:39 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Date: Fri, 17 Dec 2010 21:36:30 -0800
Message-ID: <65B900A32A86DB4EBF57C0D07F9B2A9E0570028D@xmb-sjc-215.amer.cisco.com>
In-Reply-To: <4D0C1DBA.4000102@gmail.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Gen-ART LC review of draft-ietf-pim-group-rp-mapping-07.txt
Thread-Index: AcueXCjwH6rigS1vSweugYyoLc0iCwAE0K+w
References: <4D0C1DBA.4000102@gmail.com>
From: "Andy Kessler (kessler)" <kessler@cisco.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>, draft-ietf-pim-group-rp-mapping.all@tools.ietf.org, General Area Review Team <gen-art@ietf.org>
X-OriginalArrivalTime: 18 Dec 2010 05:36:39.0356 (UTC) FILETIME=[8B2D5FC0:01CB9E75]
X-Mailman-Approved-At: Sat, 18 Dec 2010 14:11:51 -0800
Cc: Stig Venaas <stig@venaas.com>, Bharat Joshi <bharat_joshi@infosys.com>, "Andy Kessler (kessler)" <kessler@cisco.com>, "Mike McBride (mmcbride)" <mmcbride@cisco.com>
Subject: Re: [Gen-art] Gen-ART LC review of draft-ietf-pim-group-rp-mapping-07.txt
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/gen-art>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 18 Dec 2010 05:34:52 -0000
Hi, Thank you for the review. My comments are below annotated with Andy> Andy I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-pim-group-rp-mapping-07.txt Reviewer: Brian Carpenter Review Date: 2010-12-18 IETF LC End Date: 2010-12-23 IESG Telechat date: Summary: In good shape, a few issues. -------- Major issues: ------------- 3. Existing algorithm ... The algorithm defined in this document updates algorithm defined in PIM-SM ( Section 4.7.1 in [RFC4601]). The new algorithm is backward compatible and will produce the same result only if the Group-to-RP mappings are learned from a single mapping source. A logical implication of the last sentence is that if some of the Group-to-RP mappings are learned from more than one mapping source, the new algorithm might not produce the same result as the existing algorithm. Is that indeed the case, and if so, don't we have a problem until all PIM-SM routers have been updated? Andy> Most vendors today do not officially support deployments with multiple Andy> dynamic routing protocols. They probably have inconsistent results now. Andy> This algorithm will standardize the results for those vendors. It will Andy> be more consistent when all vendors do support the new algorithm. 5. Common use cases o Default static Group-to-RP mappings with dynamically learned entries Many network operators will have a dedicated infrastructure for the standard multicast group range (224/4) and so might be using statically configured Group-to-RP mappings for this range. Please indicate whether this issue also applies to IPv6. Andy> There is no issue with IPv6. IPv4 has some older baggage because Andy> the 224/4 addressing scheme has been around since before there was Andy> SSM and BSR. IPv6 Multicast does not have that history. 6. Proposed algorithm ... 10. From the remaining set of Group-to-RP Mappings we will select the RP with the highest IP address. This will serve as a final tiebreaker. Please define "highest". Does it mean "greatest when considered as an unsigned integer"? Andy> This should be the same method that is used to pick Andy> the highest IP address in many protocols. One I know well is Andy> the way that a designated router is selected in RFC 4601 in Andy> section 4.3.2. The main part of the function says: Andy> a.primary_ip_address > b.primary_ip_address Andy> To me that has always meant you compare the first byte, Andy> then the 2nd, the 3rd and then the 4th. Andy> I don't know where that would be defined. Maybe someone else knows. Andy> It is not defined in RFC 4601. 8. Clarification for MIB Objects When a Group-to-RP mapping entry is created in the pimGroupMappingTable in the PIM-STD MIB[RFC5060], it would be acceptable to have an entry with an RP with address type 'unknown' and a PimMode of Dense Mode or SSM. These entries would represent group ranges for Dense mode or SSM. Also all the entries which are already included in the SSM Range table in the IP Mcast MIB would be copied over to pimGroupMappingTable. They would have a type of configSSM and an RP with address type 'unknown' as described above. Is this section intended to be a normative update of RFC 5060, or is it just commentary? The phrase "it would be acceptable" almost sounds like a normative MAY. Also, shouldn't it be 'unknown(0)' in the context of the MIB? (This applies in three places in the draft.) Andy> At some point we received comments and requests to include all Andy> the group mappings in this table - even for Dense Mode or SSM Andy> which do not have an RP. We are merely stating that it OK to Andy> do that and use the RP address and type (of the RP) of unknown. Nits: ----- 5. Common use cases ... o More use cases By no means, the above list is complete. Please drop a mail to 'authors' if you see any other use case for this. This seems a bit strange to appear in the final RFC; at the least it needs rewriting. Andy> I agree. That was for the draft and should be removed. Should we Andy> just remove the whole section ? Or change the wording to somehow Andy> say there are more use cases that will benefit from this algorithm ? The checker says: == There are 1 instance of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 Andy> We have discussed this before. We need to use the addresses that in the Andy> examples. 239/8 is the Administratively Scoped Block as defined in RFC 5771. Andy> Its the same thing for 239.100.0.0/16 in section 5. We were told to add Andy> the comment that says its an administratively scoped multicast address Andy> range. Using GLOP will not make the same point we are trying to explain.
- [Gen-art] Gen-ART LC review of draft-ietf-pim-gro… Brian E Carpenter
- Re: [Gen-art] Gen-ART LC review of draft-ietf-pim… Brian E Carpenter
- Re: [Gen-art] Gen-ART LC review of draft-ietf-pim… Andy Kessler (kessler)
- Re: [Gen-art] Gen-ART LC review of draft-ietf-pim… Andy Kessler (kessler)
- Re: [Gen-art] Gen-ART LC review of draft-ietf-pim… Brian E Carpenter
- Re: [Gen-art] Gen-ART LC review of draft-ietf-pim… Bharat Joshi
- Re: [Gen-art] Gen-ART LC review of draft-ietf-pim… Adrian Farrel
- Re: [Gen-art] Gen-ART LC review of draft-ietf-pim… Brian E Carpenter
- Re: [Gen-art] Gen-ART LC review of draft-ietf-pim… Bharat Joshi
- Re: [Gen-art] Gen-ART LC review of draft-ietf-pim… Bharat Joshi