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 [[email protected]]
Sent: Tuesday, December 28, 2010 3:52 AM
To: [email protected]
Cc: Bharat Joshi; 'Andy Kessler (kessler)';
[email protected]; '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:[email protected]]
>> Sent: 20 December 2010 02:35
>> To: Brian E Carpenter; Andy Kessler (kessler)
>> Cc: [email protected]; 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:[email protected]]
>>>> Sent: Saturday, December 18, 2010 11:54 AM
>>>> To: Andy Kessler (kessler)
>>>> Cc: [email protected]; 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 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
