Re: I-D ACTION:draft-ietf-pim-group-rp-mapping-01.txt

On Mon, 29 Jun 2009, Andy Kessler (kessler) wrote:

-) John> Since the hash is the very last thing, I'd prefer that it not be
-) removed since its already
-) 
-) there.  Rather change it to a "MAY" requirement.  I'd hate to see it
-) removed only to 
-) 
-) find it has to be added back in again.
-) 
-)  
-) 
-) Andy>- The hash can't be a 'MAY' because different implementations need
-) to be compatible. 
-) 
-)  We asked in several forums if anyone was using the hash and didn't find
-) anyone that wanted
-) 
-)  to continue using it. We also received support for removing the hash
-) when this was discussed
-) 
-)  on this list previously. It will not come back if this draft is
-) accepted. 
-) 

Why again should the hash be deprecated?  Of all of the objectional 
things about BSR, the hash seems pretty low on the list.  Is it worth 
breaking backward-compatibility just to remove this fairly innocuous 
mechanism?

Re: I-D ACTION:draft-ietf-pim-group-rp-mapping-01.txt

-----Original Message-----
From: Leonard Giuliano [mailto:lenny <at> juniper.net] 

On Mon, 29 Jun 2009, Andy Kessler (kessler) wrote:

-) John> Since the hash is the very last thing, I'd prefer that it not
be
-) removed since its already
-) 
-) there.  Rather change it to a "MAY" requirement.  I'd hate to see it
-) removed only to 
-) 
-) find it has to be added back in again.
-) 
-)  
-) 
-) Andy>- The hash can't be a 'MAY' because different implementations
need
-) to be compatible. 
-) 
-)  We asked in several forums if anyone was using the hash and didn't
find
-) anyone that wanted
-) 
-)  to continue using it. We also received support for removing the hash
-) when this was discussed
-) 
-)  on this list previously. It will not come back if this draft is
-) accepted. 
-) 

I-D Action:draft-ietf-pim-pop-count-01.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Protocol Independent Multicast Working Group of the IETF.

	Title           : Population Count Extensions to PIM
	Author(s)       : D. Farinacci, et al.
	Filename        : draft-ietf-pim-pop-count-01.txt
	Pages           : 17
	Date            : 2009-07-01

This specification defines a method for providing multicast
distribution-tree accounting data.  Simple extensions to the PIM
protocol allow a rough approximation of tree-based data in a scalable
fashion.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pim-pop-count-01.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

_______________________________________________
pim mailing list
pim <at> ietf.org
https://www.ietf.org/mailman/listinfo/pim

Re: I-D ACTION:draft-ietf-pim-group-rp-mapping-01.txt

Andy- to be clear, last year I suggested deprecating BSR, not just the 
hash, as Static Anycast is a much better approach.  However, if you are 
unwise enough to use BSR, the hash doesn't seem like a terribly offensive 
way to load balance among multiple RPs.

I am not following you on the problem with the hash's applicability to 
other mechanisms.  The hash is just a tiebreaker within the BSR mechanism.  
I don't see why it needs to be applicable to static or Auto-RP, just as 
local-pref is only applicable to BGP and means nothing to 
ISIS/OSPF/Static/etc.  What am I missing?

On Wed, 1 Jul 2009, Andy Kessler (kessler) wrote:

-) 
-) Hi Lenny, 
-) 
-) Routers can learn group to RP mapping information from several sources 
-) including statically assigned, BSR, AutoRP and embedded RP. The purpose 
-) of this draft is to develop a deterministic way to select a particular 
-) mapping when we have a conflict. It doesn't have anything to do with 
-) advertising those mappings.
-) 
-) The problem with the hash function is that it only applies to BSR. How 
-) do you apply the hash across static RP or any of the other methods ? We 
-) debated at one point in saying that the BSR code itself could use the 
-) hash and then decide which mappings it would present to the common 
-) group to RP mapping table. Then we thought it would be best just to 
-) drop it and recommend Anycast RP. We discussed this on the list.
-) 

I-D Action:draft-ietf-pim-mtid-01.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Protocol Independent Multicast Working Group of the IETF.

	Title           : PIM Multi-Topology ID (MT-ID) Join-Attribute
	Author(s)       : Y. Cai, H. Ou
	Filename        : draft-ietf-pim-mtid-01.txt
	Pages           : 9
	Date            : 2009-07-02

This document introduces a new type of PIM Join Attribute that
extends PIM signaling to identify a topology that should be used when
constructing a particular multicast distribution tree.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pim-mtid-01.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

_______________________________________________
pim mailing list
pim <at> ietf.org
https://www.ietf.org/mailman/listinfo/pim

Re: I-D ACTION:draft-ietf-pim-group-rp-mapping-01.txt

Lenny, 

Yes, what you describe is what I was suggesting in my first reply
- that BSR applies the hash function to its mapping cache before
they are added to the common group-to-rp mapping table. 

We could go ahead and specify that in this draft and it might 
be fine. However, these are some of the other issues we should 
consider: 

o There are complications with creating hardware forwarding entries
  with PIM-Bidir maybe PIM-SM if the hash is used

o We want to clarify Section 4.7.1 and 4.7.2 of RFC 4601 which 
  describes the steps for group to RP mapping and use of the
  hash function. We are trying to improve the algorithm to also 
  consider: 

  - the origin of a group-to-rp mapping 
    (e.g. bsr, autorp, static, etc)

  - Allow for static override

  - Allow for higher priority of PIM-Bidir over PIM-SM which is
    described in section 3.3 of RFC 5059 [BSR]

Removing the hash from the group-to-rp mapping algorithm makes sense
for these reasons. But if we can come up with some language to describe
how the hash will be applied for BSR mappings and not in the general
case

draft pim agenda for IETF 75

Note that we have now been moved to Thursday!

pim wg meeting Thursday 1510-1610

So far we have the following topics

agenda bashing, status of wg drafts etc		Stig	10 min
draft-ietf-pim-pop-count-01			Greg	10 min
draft-ietf-pim-port-01 (not available yet)	Stig	15 min
draft-wijnands-mpls-mldp-in-band-signaling-00	Ice	10 min

We still got 15 minutes left then. We may extend the times above if
we got nothing more on the agenda.

Please let Mike and me know if you have anything else.

Also, we are looking for volunteers for taking minutes, so if you
know you will be there and would like to do us a big favour...

Stig

basic difference between assert and DR

Hello Friends,

     Can anyone explain me what is the difference between DR and
Asser winner by some diagram? I keep on getting confused between
them.
     Thanks in advance for your kind help.

Regards,
Bhaivn,
Networking Student.

I-D Action:draft-ietf-pim-port-01.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Protocol Independent Multicast Working Group of the IETF.

	Title           : A Reliable Transport Mechanism for PIM
	Author(s)       : D. Farinacci, et al.
	Filename        : draft-ietf-pim-port-01.txt
	Pages           : 27
	Date            : 2009-07-09

This draft describes how a reliable transport mechanism can be used
by the PIM protocol to optimize CPU and bandwidth resource
utilization by eliminating periodic Join/Prune message transmission.
This draft proposes a modular extension to PIM to use either the TCP
or SCTP transport protocol.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pim-port-01.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

_______________________________________________
pim mailing list
pim <at> ietf.org

Re: I-D ACTION:draft-ietf-pim-group-rp-mapping-01.txt

Hi, 

I was speaking to Stig and we came up with what we think is a 
workable compromise for the hash function. 

After steps 1-8 of the algorithm have been executed we have
taken into account all of these factors: 

 Embedded RP
 SSM Range, Dense mode config
 Static with override
 Longest match
 Bidir over SM
 Mapping Origin - BSR, Auto-rp, static, other

The only type of Group-to-RP mappings that can be left at that point is 
a few overlapping mappings from only one of BSR, Auto-RP, static, or 
other. 

Step 9 currently says to pick the highest IP address. Taking into
account
the hash function for BSR and the issues with implementing the hash
with Bidir, we can add a new step 9 for the hash:

9. If the remaining Group-to-RP mappings were learned through  
   BSR and the PIM Mode of the Group is 'PIM-SM' then the hash 
   function will be used to choose the RP. The RP with the highest 
   resulting hash value will be selected. 

   * If more than one RP has the same highest hash value we