Subject: Re: [pim] Comments to rp mapping discussion

From: Toerless Eckert <[email-masked]>
Date: Mon, 4 Aug 2008 07:46:46 -0700

If i remember the origins of the overall discussion correctly:

I thougth one driving factor for standardizing PIM Mapping was to also produce 
a standards track se of MIB variables for RP to group mapping ranges,
such that an NMS could calculate itself from those variables, which
range was used for which group, and then of course what mode and RP
the group has.

To this end, i think there should be two goals this effort should tackle:

a) A standards track recommendation for not only RP, but group-mode
   and RP selection. This must be simple and supported by all compliant
   platforms.

b) A representation of group-mode and RP selection in MIBs that
   can also easily represent extensions of vendors that may go beyond a),
   because not every vendor and every deployment may be able or
   willing to change algorithm quickly.

Here is my proposal how to do this:

All group-range entries are represented as: 

   (Group-Address/Prefixlength,  mode,  source,  RP,    priority, distance)

   mode is SM, Bidir, SSM, DM, (others TBD)
   source is AutoRP, BSR, static, EmbeddedRP, ...
   RP is zero or more addresses (always zero for  SSM or DM ranges).

   priority and distance , both 0..255 determine the order of selection:

   Four simple rules:
     1. No two overlapping group-ranges may have the same priority
        and distance.

     2. If two or more group ranges matching a group in question have different
        priority, then the one with the lowest priority is choosen, whatever
        the mask length. 

     3. If two or more entries matching the group in question have the same
        priority, the longest mask length is used. 
    
     4. Amongst entries with same lowest priority and longest mask length,
        lowest distance wins.

MIB:
  The MIB would simply enlist the group-ranges as entries shown above.

Standard algorithm:

The standard algorithm fixes priorities and sitances for
a set of (mode, source). This does not mandate support for
the combination of (mode,source), but if that combination is supported,
then the entries must have the according distance and priority.

   1. (<std-range(s)>,   SMM,    Embedded-RP,      <calc>,  0,  0)

   2. (<std-range(s)>,   SSM,    IANA,                  -,  0,  0)
      (*,                SSM,    static,                -, 10,  0)

   3.  (*,            *, Bidir,  static-override,       *, 20, 10) 
       (*,            *, SM,     static-override,       *, 20, 20) 
       (*,            *, DM,     static-override,       -, 20, 30) 

   4.  (*,            *, Bidir,  BSR,                   *, 30, 10)
       (*,            *, SM,     BSR,                   *, 30, 20)

   5.  (*,            *, Bidir,  AutoRP,                *, 30, 30)
       (*,            *, SM,     AutoRP,                *, 30, 40)

   6.  (*,            *, Bidir,  static,                *, 30, 50)
       (*,            *, SM,     static,                *, 30, 60)
       (*,            *, DM,     static,                -, 30, 70)

   7.  New additional mapping must have at least a priority of 30 and
       distance of 80.

Benefits of this approach:

  a) We cover all group-ranges,not only PIM-SM and Bidir-PIM, but
     also SSM and DM, and if someone wants to add another group-range
     of interestest, we can easily add it on later.
  
  b) This is effectively the same algorithm as explained in the current
     draft, but now described in a way that should make it
     crystal clear how to implement. It also cnstrains discussion
     of wha we should do to two simple parameters: priority and
     distance.
  
  c) If a product has a different scheme of selection and/or options
     to configure on how to influence the selection, this algorithm
     should go very far in being able to express what the platform
     is doing by just announcing the right priorities and distance
     in the MIB.
     
     It should be fairly easy for vendors to represent whatever
     on-standard extensions they may support via appropriate distance
     and priority values. An NMS can easily see whether all
     announced (mode, source) and prio, distance combinations follow
     the standard.

Beyond this:
  Suport for hash functions IMHO is subject to specification of
  (mode, source). FOr all i care, we shouldjust allow more than
  one RP in (SM, BSR) and (Bidir, BSR) lines, because that's what
  the current standard track definitions are (aka: BSR is the
  only standards track protocol and currently supports hash, so
  maybe we should keep it there. 

     For all other lines, i think we should just mandate support for
     only one RP.

Thanks
    Toerless

On Fri, Aug 01, 2008 at 02:59:05PM -0700, Andy Kessler (kessler) wrote:
> > -----Original Message-----
> > From: Leonard Giuliano [mailto:[email-masked]] 
> > 
> > So BSR/AutoRP users don't need redundacy?  
> 
> RPs should be backed up with Anycast. 
> BSR and AutoRP should use Anycast and multiple mapping
> agents/BSRs for redundancy. 
> 
> > My suggestion 
> > is that we not waste our time trying to add enhancements like 
> > a better 
> > hashing algorithm.
> 
> We agree. I'd be happy to drop hashing altogether. 
> 
> Andy
> 
> 
> 
> _______________________________________________
> pim mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pim
_______________________________________________
pim mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pim

---

From: "Andy Kessler (kessler)" <[email-masked]>
Date: Wed, 6 Aug 2008 13:21:40 -0700

> From: [email-masked] [mailto:[email-masked]] On 
> 

No. 

The point of this draft is to have a standard algorithm to 
deterministically choose between several group-to-rp mappings 
for the same group. 

This conflict will always be an issue since there are multiple 
methods for defining a group-to-rp mapping - static, bsr, autorp, 
embedded rp - and they can be received from different sources. 

The draft covers the use cases in which this typically happens. 

When there is a conflict between mappings this draft determines the 
priority based on the algorithm. 

SSM ranges are accessible with SNMP through the IP Multicast 
MIB (RFC 5132). 

A range that is defined for SSM will not be accepted as an
group-to-rp mapping. This text needs to be included in the
draft:

  The router should not accept an RP mapping for a group range
  which conflicts with a defined mapping for SSM. The RP mapping 
  will not be put into the RP cache nor will it be considered for 
  PIM-Bidir or PIM-Sparse Mode.

Things we still need to consider in the current draft:

 o Removing the hash function completely as it is defined
   in Section 4.7.2 of RFC 4601 

 o If we decide to keep the hash then it should not be
   used for PIM-Bidir

 o Add the SSM text above

The point of this draft is to have a standard algorithm to 
deterministically choose between several group-to-rp mappings 
for the same group - and we are getting closer to having
that. 
_______________________________________________
pim mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pim