Last Modified: 2005-02-26
|Done||Hold the first Working Group meeting and discuss the charter and the state of progress on the chartered items.|
|Done||Update the PIM-DM version 2 Internet-draft. Go to WG last call. Submision to IESG for considerations as proposed standard.|
|Done||Resubmit the latest PIM-SM version 2 specification to IESG for consideration as a proposed standard RFC|
|Done||Submit PIM-SM Applicability Statements|
|Aug 04||Submit PIMv2 MIB to IESG for consideration as proposed standard.|
|Done||Submit updated PIM-SM and PIM-DM internet-drafts, clarifying any inconsistencies or ambiguities in the previous drafts.|
|Done||Submit PIM-SM version 2 and PIM-DM version 2 specifications to IESG for consideration as Draft Standards.|
|Mar 05||Submit PIMv2 MIB to IESG for consideration as draft standard.|
|RFC3973||E||Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised)|
Protocol Independent Multicast WG (pim)
Wednesday, March 9 at 1530-1730
CHAIRS: Mike McBride <firstname.lastname@example.org>
Tom Pusateri <email@example.com>
update on drafts/charter Tom/Mike
pim refresh reduction design team progress Albert/Venu
BSR specified in RFC 2117/RFC 2362
Work for draft since 2001
New author team produced revision 04 last year
support for admin scoped zones
generalization to bidir-poim as well as pim-sm
backwards compat with rfc2362
remove genuine errors
improve clarity and precision of specs
compat with previous revisions of the draft
adding extra enhancements and optimizations
Major changes in 05 rev
change to handling of ipv6 scopes
clarification to descrioption of admin scoping
Minor technical fixes
fixes to unicast bsm sending/receivpt
fix to checking of ip router alert ptioon
fix to rand_override algorithm
clarification to use of hash mask length
lots of editorial changes
we have made progress
were approx 70 items on issues list
now about 30 remaining
still much to be done
finalize iw/ew issues
issues with the bootstrap fsm
issues with semantic fragmentation
various other minor problems
further editorial work
plan for completion
resolve all remaining known isues
produce one more draft with all known issues resolved
need wg input on certain tech points
recommend to wait for this draft before detailed review
should be ready by may
incorporate wg feedback
one or two further drafts
wg last call
shortly after ietf63
Venu: what are the compatibility issues
James: None that would break
Stig: Scoping is different esp for IPv6
Venu: could these compat issues be sent to the mailing list
initial draft submited june 2004
presented at San Diego and dc ietf
draft spplit into two parts
generic encoding fromat
use of single rpf vector
removed rd+vector and vector stack
5 bits for tlv does not give enough room. Other usage.. should not use all 5
You have the hello option routers understand source encoding format. In case of vector proxy..upsteam might not understand.. it does not guarantee compatibilty..
Move things that do not belong here to the other draft.
Generic encoding .. so proxy does not belong here.
Fenner: Is it enought to change proxy to..
Venu: Is it only for proxy source and is it for any type of source encoding.. can this be of any encoding type.. There other thing is .. if you make this generic field..
fenner: one bit indicating
edge routers have bgp router to source
bgp next-hop is present in the igp in the core routers
edge router add bgp next-hop in the pim jp message
core routers rpf using the vector
receiving edge router removes vector
name proxy will be changed
f-bit good or bad thing to have
use of reserved field to indicate the number of tlvs
in other words there is no reserved field anymore in the new source
iana consideration.. who assigns tlv numbers
Tom: new source encoding type.. will it affect pim snooping switches....
Venu: is this used only for rpf attribute..given that it might break pim snooping..
Tom: Past year work has been done. NMS ppl have been using this mib. They have been asked to do IPV6 changes. People doing ipv6 have been asked to do IPv6 mib.
Define addr family independent
tables using inetaddress data-type
similar objects for v4 and v6 defined in common tables
common updates to both ipv4 and ipv6 mibs
conversion of ipmroute-mib fulfills need for a mcast routing table mib for
currently dependency against ipmroute-mib not removed
represent new protocol features - bidir-pim, new grp-rp mapping, hello
options et all
fenner: Coupling of mibs was a mistake. Removing dependency makes sense
Dave thaler did a draft for ipmroute v6 mib. long expired. no wg. no
pursuing for it.
can ask dave to resurrect that work.
pimnbr entry to have type and address for v4 and v6
represent neadd additional info to the source encoding
no room in current source encoding for additional info
add new source encoing type add info us put in tlv
this is descrived generic
grp to rp mapping extended for static, embedded, autorp
new pim hello options
addr family independent ip-mroute-mib
need to enhance iana ipmrouteproto textual convention
split pim sparsemode into pimssm, pim asm and pim bidir
add in/out pkt stats
plan of action
sync up with discussion in the pi-mib list address any other suggestions
ordering of mib obj
mib compilation issues
send mib for review
Tom: Coming straight to the wg is disappointing before even going to the list
James: No messages on the mailing list?
Fenner:There was one in feb.. where is the mib?
stig: Draft is available?
Fenner: Captured in archives around sept..
Tom: I am happy not if you want to get into the main mailing list. Bharath has not sent his changes. So they might get lost.
Tom is going to do the driving.
PIM Last Hop Threats
draft-mboned-mroutesec does not talk about last hop threats.
There has not been an analysis on last-hop mcast threats.
These issues deserved to be spelled out.
Nodes may send unauthorized register messages
Nodes may become unauthorixed pim nbrs
Router may accept pim messages from unknown-nbrs
The spec should probably be tightened here.
An unauthorized node may be elected as the pim dr.
A node may become an unauhorized asserted forwarder
Dos on the link
Dos on the outside
Confidentiality, integrity and authorization violations
Pim passive mode
Using ipsec among the valid routers on a link
IP filtering of pim messages
Main issues are with multiple valid pim routers on a link
you will have to use ipsec betwen them to be secure with just one router, filtering pim messages is a good method
What is the contribution of this draft?
Explicit threat vulnerablity analysis and speclling out more elabore description compared to the pim spec section 6.1
more extensive discussion of non-ipsec countermeasures
Make this an info rfc of its own
Merge it with pim-sm spec security consideration section.
Wait until IESG evaluates the pim spec, ask/see how they react.
Make this dormant until the pim-sm spec is revised.
Drop the project completly.
Bill Fenner: Should not be merged. Spec has been given to iesg. wait and see.
Tom/Mike: agreed with point 3.
Bill Fenner: Can be made as an informational rfc
PIM Refresh Reduction
pim refresh reduction design team progress
In the last ietf l3vpn requested PIM WG to come up with pim messaging in the
context of scalability.
The PIM WG created a design team to address it. Several solutions were discussed. Tom/Mike working with l3vpn wg to get a requirement. Discussed with l3vpn. Such a doc maybe in the works.
Regardless of that request it is probably not a bad idea to work on this in this WG.
As multicast vpn grows there is a possiblity of scaling issues.. years down the line.. more specific number might be required..
Reduce PIM JP messages. There are no problems currently. But definitely beneficial to reduce the PIM JP messages.
Thomas Morin: About requirement docs. There will be in the mcast requirement in l3vpn. The draft on mcast vpn described two options: pim and bgp. One or both not decided. We are not clear if this is needed or not.
Tom: independent of the vpn case.. in case of large nbrs.. large numer of sources/joins.. this is required in those cases..
Y Cai: How far do we want to go with existing pim. New version of pim(pimv3) or just this draft??
??: what is the improvement needed elsewhere? What are the priorities?
Venu Hemige: scaling for l3vpn and l2vpn
Tom: We should get a picture if other wg's have this issue.
?: We are not making any assertion to fix pim. we are pursuing both options. pim and bgp.. regardless of the outcome.. There is a case scenario.. without improvements.. wrong impression should not be given to l3vpn that this is some kind of a fix.
JP ack scheme
Problem and motivation
Too much processing overhead related to the periodic refresh
several bgp impl can suport over one million routes, but pim impl cannot support even half
mvpns and many apps are capable of generating lage stats
Liming and Albert took this work in 2004 summer.
Joined force with Dino and Yiqun Cai in Nov 2004 and focused on ack based approach.
Yiqun/Liming mentioned checksum based solution.
Highlights of JP ack
Introduce JP ack message to achieve reliable JP message delivery.
Adding sequence number to PIM JP to achieve in-order delivery.
Handle other failures such as losing pim nbr and one way failure.
Disable join suppression and enable explicit member tracking.
Reliable JP delivery
Intrduce reliable JP message that is same as regular JP but added sequence numbers.
Intruduce ack message which is same as reliable JP except message type.
Use Join-Timer as retranmission timer.
Stop the join timer when acked.
Holdtime in reliable join set to oxffff
Possible to still have low frequence refesh
In-order message delivery
A tranmit seq number is maintained seperately for each upstream nbr.
The transmit seq number is incremented each time a JP message is sent to that nbr.
Each upstream keeps track of the max sequence number received from a downstream, only accept higher sequence number than the max.
Encode sequence number as options at the beginning of the reliable JP message.
Using sequence numbers
Each PIM entry on the downstream nbr must keep track of the seq no of the lst outbound pim JP message that contained the pim entry.
And entry is considered acked only when the seq number in the ack mathches the seq number in the pim entry.
Retransmit method 2
Use separate retransmission q and receive q for each nbr(sliding window or the like).
Essentially builds a reliable transmission layer inside pim.
Pros: no need to maintain seq# in each pim entry, easier in handling rpf change
Cons: more work and more memory in retransmission q and receive q.
Prune override no longer works:
One solution is to use explicit tracking.
JP and ack can be sent unicast
Don't have to process JP not intended for you
Less backward compatible concerns and we have more flxibity and how to encode sequence numbers.
More code changes and more memory consumption:requires one extra bit per group per nbr
Recovery from nbr failure?:
All pim entries learned from the failed nbr must be removed.
The upstream can either immdeiatedly remove the pim entries or start the expiry timer for those entries and let the timeout handle the removal.
Recovery from one way failure
Two nbrs x and y and if x to y direction is failing, y could timeout and
remove all pim entries,
learned from x, without x knowing about it.
Need a way for y to inform x that it has lost the nbr and request a refresh.
one solution from Dino is to let y to send a unicast hello with genid 0 to x.
Another: three way hellos
Issues with TCP based solution?
In mvpn appl, each pim peering between c instance would require a seperate TCP connection.
Vpn address family can be introduced to mcast to allow tcp cnnections betwen P-instances to be shared among C-instances but that requires more change in the protocol.
Albert has presented beyond what was agreed on the PIM state mailing list. He had given 4 slides but has presented things that I was supposed to present.
?? : Message based ACK seems more complex and not sure what it achieves.
Bob Kebler: It is more optimal to do ACKs per message - lesser processing. It may not be very intuitive to explain that it is not that complex, but it is.
Albert: There are reordering issues with the current approaches. And there is complexity and a lot of memory requirements to keep retransmission state. So why not use TCP?
Venu: We cannot use TCP because snooping will not work. And there are no reordering issues with the current approaches. If it is designed right, the complexity and memory requirements for retransmission state is almost the same as what we need with the current PIM.
Cisco guy#2: Who said snooping is a requirement? This is news to me.
Venu: There are two drafts in the l2vpn WG on vpls-multicast. Both rely on snooping.
Cisco guy#2: But that does not mean snooping is a requirement for pim refresh reduction.
Venu: Ok, so I guess what is missing is a formal requirement doc from the l2vpn wg, just like one from the l3vpn WG is also missing.
Mike McBride: Yes, we have not received any requirements from them.
Yiqun Cai: Maybe we need to take a step back and see how far we want to take PIM. If the goal is to take a big step than just refresh reduction, then we really should be thinking of TCP.
A few other guys came up and spoke on how we should not be thinking about snooping without any requirements.
Tom Pusateri: Even for refresh reduction, it seems to me that the joins will have to be unicast. Then why not simply use TCP.
Mike McBride: Running out of time, so ended the meeting.