Re: [pim] AD review draft-ietf-pim-group-rp-mapping-05.txt

[Bharat Joshi <[e-mail]>]

Hi Adrian,

     Thanks for responding quickly. I will post a new revision as quickly as I can after addressing all the comments. Please see in line.

Regards,
Bharat

> >> - Is this document updating 4601 by replacing the algorithm?
> >> - Is this document updating 4601 by providing a second algorithm?
> >> - Is this document simply providing an optional second algorithm?
> >> - How does interworking work? I.e., what are the backward
> >>   commpatibility issues and solutions?
> >>
> >> The way to address this probably by adding backward compatibility in your
> >> migration situations in "5. Common use cases".
> >>
> >> It looks like the point of the draft is that vendors have different
> >> algorithms in choosing an RP today, so for multivendor environments it 
> >> would
> >> be good to have a consistent approach in choosing an RP. This improves 
> >> the
> >> 4601 algorithm but backward compatibility needs to be discussed.
> >
> > Yes. The above is the right interpretation.
> >
> > We can do following:
> >
> > 1. Add a use-case for backward compatibility
> > 2. Add some text as suggested above.
> >
> > Do you think this is good enough to clear this confusion?
> 
> Yes, that should be good enough. Thanks.
>

Ok.
 
> >> Section 7
> 
> [snip]
> 
> >> But now I am also worried about what 5060 is trying to do with that
> >> description clause. If the PIM implementation is capable of working
> >> out the Group-to-RP mapping, why isn't the RP simply made available
> >> in a MIB object? Why is the management agent required to read the
> >> whole table and work it out for itself?
> >
> > This is because the router will have a table of group-to-rp mappings.
> > Using MIB, we can fetch the table but can not find the RP that will be
> > used for a given group. This algorithm needs to be run on management
> > station. Is this clear?
> 
> Yes. That's clear.
>

Ok.
 
> >> Section 8.
> >>
> >> Previous comments about this section, but is this an update to a 
> >> Description
> >> clause in 5060? If so, again, are you updating 5060? Is this the best way 
> >> to
> >> do it?
> >
> > Not sure about this. I think we assumed that we can update RFC 5060 this
> > way. Do we need to come up with another draft to update this or an Errata
> > will do?
> 
> I suggest you update the I-D with all of the other changes and then I will 
> take it to the MIB doctors and ask their opinion on updating 5060.
>

Ok.
 
> >> Section 11
> >>
> >> An implementation of PIM SHOULD support configuration to block
> >> specific dynamic mechanism for a valid group prefix range.
> >>
> >> This looks like an update to 4601. Is it?
> >>
> >
> > No. Its not an update.
> 
> I assume you mean that *this* is not an update to 4601, but that the draft 
> in general is (as you agreed in the comment about Section 9).
> 

Yes. I agree that it updates RFC 4601.