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