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

From: Brian E Carpenter <[email-masked]>
Date: Sat, 18 Dec 2010 15:34:34 +1300

Please see attached review.

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 19 Dec 2010 08:54:22 +1300

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

---

From: "Andy Kessler (kessler)" <[email-masked]>
Date: Fri, 17 Dec 2010 21:36:30 -0800

Hi, 

Andy

Major issues:
-------------

3.  Existing algorithm
...

5.  Common use cases

6.  Proposed algorithm
...

Nits:
-----

5.  Common use cases
...
   o  More use cases

The checker says:

---

From: "Andy Kessler (kessler)" <[email-masked]>
Date: Sun, 19 Dec 2010 10:49:18 -0800

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

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 20 Dec 2010 08:35:35 +1300

Hi,

>    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

---

From: Bharat Joshi <[email-masked]>
Date: Mon, 20 Dec 2010 08:05:07 +0530

Hi,

> 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
 
> > Cc: [email-masked]; General Area
> Review Team; Bharat Joshi; Stig Venaas; Mike McBride (mmcbride)

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

---

From: Adrian Farrel <[email-masked]>
Date: Fri, 24 Dec 2010 13:16:49 +0000

Hi,

IETF last call completed without further comments.

Can I suggest 

OLD

   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.

> From: Bharat Joshi [mailto:[email-masked]]
> Sent: 20 December 2010 02:35
> To: Brian E Carpenter; Andy Kessler (kessler)
> Cc: [email-masked]; 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,
> 
> 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
> >
> >

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 28 Dec 2010 11:22:02 +1300

Adrian's text looks fine to me (i.e. unambiguous, without
needing RFC 2119 language).

Regards
   Brian Carpenter

---

From: Bharat Joshi <[email-masked]>
Date: Tue, 28 Dec 2010 08:42:09 +0530

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-masked]]
Sent: Tuesday, December 28, 2010 3:52 AM
To: [email-masked]
Cc: Bharat Joshi; 'Andy Kessler (kessler)'; [email-masked]; 'General Area Review Team'; 'Stig Venaas'; 'Mike McBride (mmcbride)'
Subject: Re: Gen-ART LC review of draft-ietf-pim-group-rp-mapping-07.txt

Regards
   Brian Carpenter

---

From: Bharat Joshi <[email-masked]>
Date: Tue, 28 Dec 2010 21:39:34 +0530

Hi Adrian,

     I have submitted a new revision after addressing all the comments from Brian. Its available at:
http://datatracker.ietf.org/doc/draft-ietf-pim-group-rp-mapping/

Thanks,
Bharat
________________________________________
From: Adrian Farrel [[email-masked]]
Sent: Friday, December 24, 2010 6:46 PM
To: Bharat Joshi; 'Brian E Carpenter'; 'Andy Kessler (kessler)'
Cc: [email-masked]; '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,

Can I suggest

OLD