Protocol Independent Multicast (pim)

Chair(s):

Tom Pusateri 
Mike McBride 

Mailing Lists:

General Discussion: pim@ietf.org

IETF 64 : Meeting November 10, 20056

Agenda :

Administrivia
Status of the PIM Draft

draft-ietf-pim-join-attributes-00    Arjen Boers    5min
draft-ietf-pim-rpf-vector-01         Ice Wijnands   5min
draft-ietf-pim-mib-v2-04             David McWalter 10min
draft-ietf-pim-sm-bsr-06             Nidhi Bhaskar  10min
draft-hemige-pim-improved-assert-00  Venu Hemige    10min
L3VPN Issues                         Mike McBride

Scribe : Marshall Eubanks 

-----
Minutes


Administrivia
Status of the PIM Draft

PIM-SM has passed the IESG Last Call, with a few remaining issues. The Chairs 
urged those participating to send in their corrections. The BiDir draft needs 
an implementation report. 


draft-ietf-pim-join-attributes-00    Arjen Boers    5min

The Chairs plan to do a WGLC for this draft after this meeting.

draft-ietf-pim-rpf-vector-01         Ice Wijnands   5min

There is another, expired draft, to solve the same problem. Tom Pusateri 
suggested resurrecting the earlier draft and comparing the two solutions. 

draft-hemige-pim-improved-assert-00  Venu Hemige    10min

The working group raised various issues with this draft. The Chairs suggested 
that 
these be addressed before it is adopted by the Working Group.

draft-ietf-pim-mib-v2-04             David McWalter 10min

The changes in the recent draft update were described. The separate PIM-MIB and 
PIM-State mailing lists will be shut down and traffic should be directed to the 
main PIM list. 

draft-ietf-pim-sm-bsr-06             Nidhi Bhaskar  10min

The author asked for a WGLC on this document before IETF-65.

L3VPN Issues                         Mike McBride

Mike McBride described the results of Thomas Morin's survey about multicast 
requirements. The L3VPN WG is thinking of dropping PIM entirely for BGP based 
Multicast routing on Multicast VPN's. An extensive discussion of this and PIM 
state refresh reduction followed. 

-----
Narrative Minutes 

Mike McBride : A brief update on existing drafts. The tools page is a great 
resource for all of our drafts. You can check what the changes are, etc. 

The PIM anycast draft is progressing. Nothing more for us to do at this point.

PIM-SM has passed the IESG Last Call. There are a few remaining issues.

I wore this shift [a colorful tie-die] specifically for Bill Fenner, to 
encourage him to finish. 

Bill : We had a burst of energy and had two more final PIM spec meetings, and I 
expect it to take one or two more. We're trying to resist more tweaks, but some 
of the issues are real, for example IPsec has changes since we last addressed 
the IPsec issues. 

Tom : Can you give us an estimate ?

Bill Fenner : What year is this ? [laughter]

Tom : The longer it stays like this, the more there is to update.

Bill : We'll try and find time in November for this.

Tom : Isidor [Kouvelas]  wanted everyone to know that his list is done.

Tom : There are changes that are needed to the proposed requirements document, 
but they all seemed like less than nits to me. 

Bill : I actually agree with that. I can bump Alex about this again. I actually 
don't think that it is useful to publish documents like this as RFC's. 

Tom : What is the status of BiDir ? Is it just waiting on PIM ?

Bill : That's a question that I have asked myself.

Tom : Isidor put a new version out 10/25.

Mike : I think it should be publication requested.

Bill : We need an implementation report specifically for BiDir.

Tom : I will get together with Isidor to work on the implementation report.

-----

Arjen Boers : draft-ietf-pim-join-attributes-00

Draft was submitted in June 2004. The original PIM proxy draft was split into 2 
parts, for join attributes and the RPF vector. 

Why do we need this ? For certain situations, we need an additional 
information. For example, edge routers include additional information in PIM 
join. 

We use the attribute to do the RPF check.

This is new encoding from before, and doesn't use the reserved bits, and uses 
an end of stack bit. 

It allows numbers of attributes - with this encoding, we allow for 64 types of 
attributes. 

We incorporated a number of comments from James Lingard.

Mike McBride : I know that there is another, expired, draft with another 
proposal for this solution. 

Tom : This is just attributes for joins. We will do a WGLC for this right after 
this meeting. 

----

The other part is PIM RPF Vector

The problem statement is the same as before.

The edge router will encode the BGP next hop as an attribute 

The target router will remove the attribute.

Simple -- just encode with the IP address.

Tom : In the middle of 2004, another proposal solved the same problem in a 
different way. 
As a WG we may want to look at both proposals. Because it expired, I will try 
and revive it. 

Bill : Is the proposal to publish them both as experimental ?

Tom : Do you want to do it as experimental ?

Arjen : I would like to go for draft standard.

Bill : We try to resist doing two ways to do the same thing, both on the 
standards track. 

Arjen : Maybe for the next IETF we can see what the differences are.

Tom : We may have to meet in a room and discuss this.

Arjen : We'll take some beer with us. [laughter]

Vennu Hemige : Is there a reason why it is not using the encoded source address 
format. 

What if it is a IPv6 address ?

Arjen : You can use encoded source if you want, but it's larger.

Tom : In the first draft, I think that there is stuff left over which makes it 
not 
quite independent enough. I'll send what I noticed to the list.

Bill : I think we should think about using the encoded source address. If we 
have something new to RFP to, we would have to create a new address family. I 
can't say I have any idea how often 

Dino Farinacci : In the spirit of consistency, it would be nice to be like the 
other encoded addresses. 

-----
Vennu Hemige : Improved Assert in PIM-SM

The motivation is to decouple the control plane dependancy on the data plane to 
detect duplicate traffic. 

The idea is to elect an assert winner before duplicate traffic is seen. For 
applications like IPTV duplicate traffic can be as bad as dropped traffic. 

When a downstream router sends a join, the other routers on a LAN see the joins 
but don't react if they know they wouldn't win an assert. 

In the proposal, joins are sent to all routers, routers see Joins on 
downstreams. 

If a join is seen, and you could win,  then trigger an asset.

Then assert election happens right away.

This is a simple extension of PIM-SM.

Nidhi - This is an interesting application.

Assert processing in PIM can come from other mechanisms, say because you lost 
your join. 

You can't really get rid of your  need to assert.

Vennu : The draft addresses a lot of the assert scenarios.

PIM-SM is a soft state protocol. If you lose the first join, the issues are the 
same. 

Bill : You're going from a data plane detection which would work in seconds to 
something that would take 60 seconds. In the lost join case, I don't think that 
this is better. 

Vennu : In PIm-SSM Asserts are about the only reason to tightly couple the data 
and control plane. 

If joins are lost, there are issues anyway.

Bill : PIM behaves poorly if messages are lost.

What I actually wanted to ask. When you are switching from a (*,G) tree to a 
(S,G) tree, normally, you wait until traffic is flowing. If you pre-assert in 
this way, that advantage goes away. If for some reason, the (S,G) doesn't work, 
the switchover doesn't happen until the SPT bit is set. This is a tricky corner 
case. 

Vennu : I would like to understand this scenario better

Suresh : The idea that you can detect duplicate traffic before it happens. In 
most cases, it just works. 

Dave Thaler : If you do have duplicates in multicast, it can be much worse than 
in unicast. It may be difficult, but it's worth it. 

I think that it is important to detect stuff in data - that's an important 
protection. 

Vennu : In MPLS, there is a solution that says that it's OK to have duplicate 
traffic - it's OK for the duration of the stream. 

Dino : They are wrong.

Toerless : There was a person saying use this as an optimization and keep the 
data trigger as a fall back. I wanted to do this. 

I think that there is a more fundamental problem, which is that the assert by 
itself sucks. If we can move onto something that would avoid asserts 
completely. 

Nidhi : I think that this is a nice optimization for the cases where it work. 
But you can't say that you don't have to do data detection. 

If there is an RPF change, for example. They can show up in surprising cases.

Bill : It is a corner case. PIM has about 150 million corner cases.

Vennu : There is benefit in doing this.

Bill : It's a nice optimization when it works. If the only times it doesn't 
work is when it creates work in the data plane, that's closed. 

Beau : If you can't exhaustively prove that your optimization won't black hole 
traffic you shouldn't do it. 

Dave Thaler : Do you do the join first or the assert first ?

Dino : When a join comes up, there can be lots of (S,G) in there, which could 
cause N Asserts to come out. I don't want one packet to cause an explosion of 
packets. 

Tom : Come up with another version of your draft which addresses these comments 
and we will [adopt it on in the WG]. 

------
draft-ietf-pim-mib-v2-04  - David McWalter

4 major changes in PIM MIB

Added anycast RP
Added 4 traps, two for error cases, 2 are administrative
SSM Range configuration
BSR configuration has been taken out and will be a personal submission

Tom : I want to close down the PIM-MIB and the PIM-State lists. Any traffic can 
go to the main PIM list. 

-----
draft-ietf-pim-sm-bsr-06  - Nidhi Bhaskar

BSR Spec : The ID has been refreshed.

Updated to reflect input - the specification is pretty stable.

Triggered RP-Set changes, we recommend a backoff, and at least 10 seconds.

Can we do a last call before the next meeting ?

John Zweibel : the BSR hold time isn't proportional ?

Nidhi : No it isn't. There is a fixed interval.

John : So you can't change it ?

Nidhi : Unless you configure it on all of the routers.

John : Second, the priority should be non-zero.

And the candidate RP hold time. How is that calculated ?

Nidhi : The value for the hold time is derived from the hold time

The BSR MIB has been removed from the PIM MIB. Should it be added back ?

Tom : I would say not, as it's a dependency we don't need.

Dino : Did you make packet format changes ?

Nidhi : No

Dave Thaler : What's the expected time frames of submitting these ?

Bill : Anycast RP is in IESG last call.

It's not that big a deal to have two different MIB documents.

-----
Mike McBride 

For those of you who attended the L3VPN WG, Thomas Morin showed results of a 
very interesting survey about multicast requirements. 

There doesn't seem to be an urgent need to solve PIM refresh immediately. There 
has been a variety of proposals to handle Multicast in BGP. 

Tom : It would be good to get a summary of the Join Prune ACK stuff that went 
on and why it stopped. 

Mike : Refresh reduction came to a halt because we were waiting on the L3VPN to 
give us requirements. 

Nidhi : Was there ever a clear communication of requirements ? I think it would 
be useful to get that input. 

Tom : Maybe we should ask them for this.

Dino : The basic idea is we introduce a new very lightweight JP-ack mechanism, 
which works well on point to point links and on multi-access LANs. 

If  we wanted to limit it to P2P links it could be ready very quickly.

Nidhi : The alternative to JP reduction is to put Multicast routing in BGP.

The changes that L3VPN will bring to PIM  are more than just refresh reduction.

Mike McBride : Is this something that L3VPN needs to work on ?

Greg Shepherd : This is the PIM WG. Anything that affects PIM should be 
addressed here. 

Dino Farinacci : For the JP ACK version I think that this should be not be PIM 
Version 3. 
This could open it up for all sorts of  revisions.