Subject: [pim] Reg - Scoped address architecture support for PIM -- I am in need of some clarification about the multicast routing when scope-zone support is given

From: Sundara Moorthy M <[email-masked]>
Date: Mon, 9 May 2011 14:09:24 +0530

Hi,

I have some doubts in implementing scoped address architecture support for PIM.

In Scoped Address Architecture support for PIM,

How do we route the multicast packets based on scope-zone information?

How do we check that the multicast and unicast PIM control packets are not crossing the zone boundary.

Is there any RFC standards for resolving the routing issues in PIM for scope-zone support??

"DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus."

---

From: Brian Haberman <[email-masked]>
Date: Mon, 09 May 2011 09:14:35 -0400

In IPv6, this is documented in RFC 4007.

Regards,
Brian

---

From: Toerless Eckert <[email-masked]>
Date: Mon, 9 May 2011 08:39:08 -0700

rfc4007 IMHO defines an architecture that is way too complex for 
IP multicast. Unfortunately we could never get the IETF to fix this even
though we tried.  Nidhi Bhaskar gave a good explanation talk of the problem
back in the days at the IETF and i had a long talk with Steve Deering about
it, but he did not want to go back and revisit the address architecture with
his co-authors. I think rffc4007 was originally written and approved without
ever checking with someone who would have to actually implement it on a
HW assisted router.

This history is of course particularily annoying because on the unicast side,
even the way more simple site local scope addresses where removed after
implementers and deployment folks complained about it due to complexity.
But why fix multicast or make it simple... *sigh* *mumble* ;-).

Reminder for those without the background:

  If you wanted to implement rfc4007 scoped zones where the scope boundaries
  arbitrarily cut through a router leaving two or more interfaces on either
  side, you effectively need to implement a separate virtual routing table
  for each of the zones. It is like what you do for a VRF in an MPLS-VPN/PE
  LSR, just that you now really needed create invisibly something like
  a different VRF for each set of interfaces that is in the same zones for all
  scopes 3 and up. And then of course you would also have some extranet routes
  if some of these sets only share larger scopes but not smaller scopes. Or
  you implemented hierarchical VRF routing. And then try to think how to
  implement that on top of a router that already does support other explicit
  virtual routing contexts (MPLS-VPN/VRFs or others too.

In any case, at the time this was discussed, the slient implication to
implementers was that they just did not support scoped multicast zones > 2 
to cut through a router itself. Instead, like in IPv4 they where only
implemented cutting through a link.  That of course makes it quite 
"interesting" to answer questions about RFC4007 support in RFPs.

If anyone has actually implemented multi-zone IPv6 IP multicast routing
without tying it to VRF or other PE-like infra, i would be very interested
to hear about it.

Cheers
    Toerless

On Mon, May 09, 2011 at 09:14:35AM -0400, Brian Haberman wrote:
> _______________________________________________
> pim mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pim

---

From: Sundara Moorthy M <[email-masked]>
Date: Tue, 10 May 2011 11:32:33 +0530

Hi,

Thanks for your response.

>>In any case, at the time this was discussed, the slient implication to implementers was that they just did not support >>scoped multicast zones > 2 to cut through a router itself. Instead, like in IPv4 they where only implemented cutting
>>through a link.  That of course makes it quite "interesting" to answer questions about RFC4007 support in RFPs.

you meant to say multicast can work with only two scope zones (link local and interface local), then
how to reach the global RP address and BSR?

We are not planning to have VRF kind of routing table for IPv6 scopes.

We are facing problems while finding unicast route lookup for RP, BSR, source
and feel that it may cross the zone boundary.
Shall we have administrative restriction that all the unicast routes to
reach a particular destination should lie in the same scope zone ?

Thanks and Regards,
 Sundara Moorthy M

-----Original Message-----
From: Toerless Eckert [mailto:[email-masked]]
Sent: Monday, May 09, 2011 9:09 PM
To: Brian Haberman
Cc: [email-masked]
Subject: Re: [pim] Reg - Scoped address architecture support for PIM -- I am in need of some clarification about the multicast routing when scope-zone support is given

rfc4007 IMHO defines an architecture that is way too complex for IP multicast. Unfortunately we could never get the IETF to fix this even though we tried.  Nidhi Bhaskar gave a good explanation talk of the problem back in the days at the IETF and i had a long talk with Steve Deering about it, but he did not want to go back and revisit the address architecture with his co-authors. I think rffc4007 was originally written and approved without ever checking with someone who would have to actually implement it on a HW assisted router.

This history is of course particularily annoying because on the unicast side, even the way more simple site local scope addresses where removed after implementers and deployment folks complained about it due to complexity.
But why fix multicast or make it simple... *sigh* *mumble* ;-).

In any case, at the time this was discussed, the slient implication to implementers was that they just did not support scoped multicast zones > 2 to cut through a router itself. Instead, like in IPv4 they where only implemented cutting through a link.  That of course makes it quite "interesting" to answer questions about RFC4007 support in RFPs.

If anyone has actually implemented multi-zone IPv6 IP multicast routing without tying it to VRF or other PE-like infra, i would be very interested to hear about it.

Cheers
    Toerless