Re: [Gen-art] Gen-ART LC review of draft-ietf-pim-group-rp-mapping-07.txt
Bharat Joshi <bharat_joshi@infosys.com> Tue, 28 December 2010 03:11 UTC
Return-Path: <bharat_joshi@infosys.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 189993A6911 for <gen-art@core3.amsl.com>; Mon, 27 Dec 2010 19:11:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.054
X-Spam-Level:
X-Spam-Status: No, score=-6.054 tagged_above=-999 required=5 tests=[AWL=0.545, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 6P2329jnAuPg for <gen-art@core3.amsl.com>; Mon, 27 Dec 2010 19:11:38 -0800 (PST)
Received: from kecgate02.infosys.com (Kecgate02.infosys.com [122.98.14.32]) by core3.amsl.com (Postfix) with ESMTP id 8A4FC3A690E for <gen-art@ietf.org>; Mon, 27 Dec 2010 19:11:37 -0800 (PST)
X-TM-IMSS-Message-ID: <d234569e0019727b@infosys.com>
Received: from blrkechub03.ad.infosys.com ([10.66.236.43]) by infosys.com ([122.98.14.32]) with ESMTP (TREND IMSS SMTP Service 7.1) id d234569e0019727b ; Tue, 28 Dec 2010 08:39:56 +0530
Received: from BLRKECHUB05.ad.infosys.com (10.66.236.45) by blrkechub03.ad.infosys.com (10.66.236.43) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 28 Dec 2010 08:42:51 +0530
Received: from BLRKECMBX02.ad.infosys.com ([10.66.236.22]) by BLRKECHUB05.ad.infosys.com ([10.66.236.45]) with mapi; Tue, 28 Dec 2010 08:42:50 +0530
From: Bharat Joshi <bharat_joshi@infosys.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>, "Adrian.Farrel@huawei.com" <Adrian.Farrel@huawei.com>
Date: Tue, 28 Dec 2010 08:42:09 +0530
Thread-Topic: Gen-ART LC review of draft-ietf-pim-group-rp-mapping-07.txt
Thread-Index: AcumFIU3LFNHe+G+TbOsFAnb3lz8BQAKH5l5
Message-ID: <31D55C4D55BEED48A4459EB64567589A108114958E@BLRKECMBX02.ad.infosys.com>
References: <4D0C1DBA.4000102@gmail.com> <65B900A32A86DB4EBF57C0D07F9B2A9E0570028D@xmb-sjc-215.amer.cisco.com> <4D0D116E.1050605@gmail.com> <65B900A32A86DB4EBF57C0D07F9B2A9E057002DA@xmb-sjc-215.amer.cisco.com> <4D0E5E87.9040302@gmail.com> <31D55C4D55BEED48A4459EB64567589A10819D3069@BLRKECMBX02.ad.infosys.com> <02b101cba36c$d41ac230$7c504690$@huawei.com>, <4D19118A.6050009@gmail.com>
In-Reply-To: <4D19118A.6050009@gmail.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
Cc: 'General, 'Stig Venaas' <stig@venaas.com>, Team' <gen-art@ietf.org>, "'Andy Kessler (kessler)'" <kessler@cisco.com>, "draft-ietf-pim-group-rp-mapping.all@tools.ietf.org" <draft-ietf-pim-group-rp-mapping.all@tools.ietf.org>, "'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: Tue, 28 Dec 2010 03:11:40 -0000
Hi Adrian, I will bring out the new revision after taking care of the comments in a day or so. Regards, Bharat ________________________________________ From: Brian E Carpenter [brian.e.carpenter@gmail.com] Sent: Tuesday, December 28, 2010 3:52 AM To: Adrian.Farrel@huawei.com Cc: Bharat Joshi; 'Andy Kessler (kessler)'; draft-ietf-pim-group-rp-mapping.all@tools.ietf.org; 'General Area Review Team'; 'Stig Venaas'; 'Mike McBride (mmcbride)' Subject: Re: Gen-ART LC review of draft-ietf-pim-group-rp-mapping-07.txt Adrian's text looks fine to me (i.e. unambiguous, without needing RFC 2119 language). Regards Brian Carpenter On 2010-12-25 02:16, Adrian Farrel wrote: > Hi, > > IETF last call completed without further comments. > > Can I suggest > > OLD > 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. > > The advantage of keeping all the ranges in the table would be that > this table will contain all the known multicast group ranges. > NEW > An implementation of this specification can continue to be managed > using the PIM-STD-MIB [RFC5060]. When a Group-to-RP mapping entry is > created in the pimGroupMappingTable the RP with address type in the > pimGroupMappingRPAddressType object is set to unknown(0), and the > PIM Mode in the pimGroupMappingPimMode onject is set to either > ssm(2) or dm(5) to represent group ranges for SSM or Dense mode. > > Also, all the entries which are already included in the SSM Range > table in the IP Mcast MIB [insert reference] are copied to the > pimGroupMappingTable. Such entries have their type in the > pimGroupMappingOrigin object set to configSsm(3), and the RP > address type in the pimGroupMappingRPAddressType object set to > unknown(0) as described above. > END > > In addition, you have a few other changes to make, so I will wait for a new revision before asking the IESG to review the document. > >> -----Original Message----- >> From: Bharat Joshi [mailto:bharat_joshi@infosys.com] >> Sent: 20 December 2010 02:35 >> To: Brian E Carpenter; Andy Kessler (kessler) >> Cc: draft-ietf-pim-group-rp-mapping.all@tools.ietf.org; General Area Review >> Team; Stig Venaas; Mike McBride (mmcbride) >> Subject: RE: Gen-ART LC review of draft-ietf-pim-group-rp-mapping-07.txt >> >> Hi, >> >> > 3. In section 8, "Clarification for MIB Objects", I'm not >>>> sure what we have to say to be sure its understood that this >>>> is a normative reference. Suggestions ? >>> You know, maybe you need to have a MIB expert glance at this text, >>> for example the original MIB Doctor who reviewed the MIB module in >>> the first place. I'm not sure that any language I propose will be >>> any better than what you already have. However, if 'it would be >>> acceptable' becomes a MAY construct and 'would be copied' becomes >>> 'SHOULD be copied', then it's clearly normative. >>> >>>> Bharat, please spin a new version... >>> Or you can wait to see if any other last call comments come in... >>> >> Let us wait for other last call comments. I am hoping one of the MIB Doctors will >> comment on this and we can find a way to address this concern. >> >> Regards, >> Bharat >> >>> Thanks >>> Brian Carpenter >>> >>> >>> On 2010-12-20 07:49, Andy Kessler (kessler) wrote: >>>> Ok, we have made progress. >>>> >>>> These are the suggested changes we need to make: >>>> >>>> 1. In Section 3, Existing Algorithm. Add a new sentence to >>>> the end: >>>> >>>> The full benefits of the new algorithm will not be realized >>>> until it is widely deployed. >>>> >>>> 2. In section 5, Common use cases, first section "Default static >>>> Group-to-RP mapping with dynamically learned entries", add >>>> a sentence to the end: >>>> >>>> This is not an issue for IPv6 Multicast address ranges. >>>> >>>> 3. In section 8, "Clarification for MIB Objects", I'm not >>>> sure what we have to say to be sure its understood that this >>>> is a normative reference. Suggestions ? >>>> >>>> 4. Section 5, Common use cases, remove the subsection "More use >>>> cases". >>>> >>>> Bharat, please spin a new version with these changes when we >>>> resolve number 3 above. >>>> >>>> Thanks, >>>> >>>> Andy >>>> >>>> -----Original Message----- >>>> From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] >>>> Sent: Saturday, December 18, 2010 11:54 AM >>>> To: Andy Kessler (kessler) >>>> Cc: draft-ietf-pim-group-rp-mapping.all@tools.ietf.org; General Area >>> Review Team; Bharat Joshi; Stig Venaas; Mike McBride (mmcbride) >>>> Subject: Re: Gen-ART LC review of draft-ietf-pim-group-rp-mapping- >>> 07.txt >>>> Hi Andy, thanks for responding so promptly. A few comments in line: >>>> >>>> >>>> On 2010-12-18 18:36, Andy Kessler (kessler) wrote: >>>>> 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. >>>> OK. Maybe you could add a sentence to make it clear that adding the >>> new >>>> algorithm doesn't fix the problem completely until it's universally >>> deployed. >>>>> 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. >>>> OK. For someone ignorant of the history, it might be worth adding >>>> "This issue does not arise for IPv6." >>>> >>>>> >>>>> 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. >>>> and the 5th, etc, for IPv6 ;-) >>>> >>>>> Andy> I don't know where that would be defined. Maybe someone else >>> knows. >>>>> Andy> It is not defined in RFC 4601. >>>> I have no idea either. Maybe it's a term of art in routing protocols, >>>> so I won't insist; I was just looking at it from the viewpoint >>>> of a naive implementor. >>>> >>>>> 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. >>>> Yes, it makes sense, but please make it very clear whether you >>>> are writing normatively or not. >>>> >>>>> 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 ? >>>> Either way is fine for me. >>>> >>>>> 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. >>>> Fair enough. Don't be surprised if someone in the IESG asks the same >>> question. >>>> Brian >> **************** CAUTION - Disclaimer ***************** >> This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended >> solely >> for the use of the addressee(s). If you are not the intended recipient, please >> notify the sender by e-mail and delete the original message. Further, you are not >> to copy, disclose, or distribute this e-mail or its contents to any other person and >> any such actions are unlawful. This e-mail may contain viruses. Infosys has taken >> every reasonable precaution to minimize this risk, but is not liable for any damage >> you may sustain as a result of any virus in this e-mail. You should carry out your >> own virus checks before opening the e-mail or attachment. Infosys reserves the >> right to monitor and review the content of all messages sent to or from this e- >> mail >> address. Messages sent to or from this e-mail address may be stored on the >> Infosys e-mail system. >> ***INFOSYS******** End of Disclaimer ********INFOSYS*** > >
- [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