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

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

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:[e-mail]]
>> Sent: 20 December 2010 02:35
>> To: Brian E Carpenter; Andy Kessler (kessler)
>> Cc: [e-mail]; 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:[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
>> **************** 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***
> 
>