Re: [Gen-art] Gen-ART LC review of draft-ietf-pim-group-rp-mapping-07.txt

[Brian E Carpenter <[e-mail]>]

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...

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:[e-mail]] 
> Sent: Saturday, December 18, 2010 11:54 AM
> To: Andy Kessler (kessler)
> Cc: [e-mail]; 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