I'll only comment on a couple of followups below. I think I've
described my POV and I probably won't do further follow-ups.
On Mon, 19 Oct 2009, Eric Rosen wrote:
Pekka> At the minimum, the status (intent) of the spec should be
Pekka> clarified. Even better would be to improve and include the support
Pekka> here.
In general, the procedures specified in the document will enable an IPv4 SP
backbone to support customer use of IPv6 multicast. You are correct that
section 7.4.2.2 is incomplete in this respect.
Do you intend to correct this? One could argue that this does not
fulfill the requirements for PS as it stands.
Pekka> 2) RP configuration in SP network. It's not clear if SP network
Pekka> needs to know how customer sites have configured their RPs (when
Pekka> the customer provides the RP). At least traditional PIM
Pekka> signalling would require SP to know this. But if auto-rp or BSR
Pekka> is not used by the customer, how is this information learned and
Pekka> maintained? Would it require manual configuration?
A PE router does function as a PIM peer of a CE router, and hence needs some
way to get the group-to-RP mappings of the customer. How this is done is
for the SP and the customer to determine.
Do you intend to spell this out more clearly? This seems like a major
configuration and O&M issue? Unfortunately this does not have good
solutions, and I suppose those ones that do exist do not have rough
consensus in the community. As it stands it seems like the spec chose
to punt an issue that is required to be resolved in order to operate
the protocol.
From the Security Considerations section:
"an implementation SHOULD provide mechanisms that allow a SP to place
limitations on the following:
- total number of (C-*,C-G) and/or (C-S,C-G) states per VRF"
Since SA AD routes are generated only as a result of creating the
corresponding multicast states, limiting the number of multicast states per
VRF results in limiting the number of Source Active routes.
I may be missing something but it's not clear why you say so. At
least in regular PIM-SM, source state can be created without creating
receiver state. S 10.1.2.2 seems to imply that AD routes would be
generated based on the receipt of Register messages, at which point
there is not yet necessarily any join state.
A more specific discussion can be found in the Security Considerations
section of draft-ietf-l3vpn-mcast-bgp:
"In conjunction with the procedures specified in Section "Supporting
PIM-SM without Inter-Site Shared C-trees" an implementation SHOULD
provide capabilities to impose an upper bound on the number of Source
Active A-D routes, as well as on how frequently they may be
originated. This SHOULD be provided on a per PE, per MVPN granularity."
While this is on a different spec, experience with MSDP has shown that
SHOULD is insufficient; these requirements are a MUST from O&M
perspective.
Pekka> 6) PIM-BIDIR usage. May the SP use PIM-BIDIR internally even if the
Pekka> customer interface would use PIM-SM?
I'm not sure I understand exactly what you are asking. The technology for
building the P-tunnels is completely independent of the multicast technology
used by the customer.
Ok, that is what I wanted to hear. Maybe it was clear enough but I
wasn't 100% sure.
3.2. P-Multicast Service Interfaces (PMSIs)
Multicast data packets received by a PE over a PE-CE interface must
be forwarded to one or more of the other PEs in the same MVPN for
delivery to one or more other CEs.
Pekka> .. is this strictly accurate? doesn't this depend on where the RP is
Pekka> configured to be? This seems to assume that the RP configuration is
Pekka> always provided by the customer, never by SP? Because if RP is
Pekka> provided by the service provider, then the same packets could be
Pekka> forwarded back to the CE, without being forwarded at all to other
Pekka> PEs.
I'm not sure I see what the RP has to do with it, but it would be more
accurate to say "A PE must have the ability to forward multicast data
packets received from a CE to one or more of the other PEs in the same MVPN
for delivery to one or more other CEs."
Agreed. This underlines the need for "ability", not that it actually
happens. I was referring to the degenerate case where all MVPN's
sources and receivers would (at that point in time) happen to be
behind the same PE.
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf