Subject: Last call on MPLS multicast framework

From: George Swallow <[email-masked]>
Date: Fri, 05 Jan 2001 17:31:08 -0500

This message begins a workgroup last call on
draft-ietf-mpls-multicast-04.txt, "Framework for IP Multicast in MPLS"
                     
The last call ends Jan 19, 5pm est.
                               
...George

======================================================================
George Swallow       Cisco Systems                   (978) 244-8143
                     250 Apollo Drive
                     Chelmsford, Ma 01824

---

From: Ron Bonica <[email-masked]>
Date: Wed, 10 Jan 2001 17:23:21 -0500

Dirk,

Two questions:

1) In section 3.8, you say that RPF checks will fail when explicit routing
causes multicast traffic to arrive on "the wrong interface". Won't RPF
checks also fail when MPLS routes traffic through "the wrong interface" for
any other reason (e.g., traffic engineering constraints)?

2) If RPF checks succeed only when traffic arrives on the interface that IGP
metrics dictate, what is the benefit of running IP multicast over MPLS?

                              Ron

---

From: Vijay Gill <[email-masked]>
Date: Wed, 10 Jan 2001 17:48:26 -0500

On Wed, 10 Jan 2001, Ron Bonica wrote:

> 2) If RPF checks succeed only when traffic arrives on the interface
> that IGP metrics dictate, what is the benefit of running IP multicast
> over MPLS?

Raising a heretical thought here, has someone raised the (operational)
solution of just providing an overlay multicast network by emulating a
layer 2 network over mpls and running multicast over that? This also
manages to eliminate a possible S,G state explosion affecting the current
revenue generating unicast network. [1]

Not a very clever solution, but has the added benefit of working without
adding more protocol fragility into already broken system implementations.

/vijay

[1] credit must be given to Giles Heron (L3) for this.

---

From: Dirk Ooms <[email-masked]>
Date: Thu, 11 Jan 2001 14:42:47 +0100

Ron,

Thanks for your question, it made me revisit the RPF stuff and it turns
out that it is not correct anymore (because of an 'evolution' in the
definition of RPF).

from draft-ietf-idmr-dvmrp-v3-10.txt:
The interface on which the best route to the source of the datagram was
received is called the upstream (also called RPF) interface.

from draft-ietf-pim-sm-v2-new-01.txt:
RPF stands for "Reverse Path Forwarding".  The RPF Neighbor of a router
with respect to an address is the neighbor that the MRIB indicates
should be used to forward packets to that address.  In the case of a
PIM-SM multicast group, the RPF neighbor is the router that a Join
message for that group would be directed to, in the absence of modifying
Assert state.

The second definition is more precise because it distinguishes the
unicast and the multicast topology (MRIB) and it does not mention the
confusing word 'best' (='shortest'?) anymore.

According to the newest 'definition' of RPF in the PIM draft the issue
mentioned in section 3.8 (and section 7) does not occur anymore, so I
will remove it.

dirk

---

From: Ali Boudani <[email-masked]>
Date: Thu, 11 Jan 2001 15:39:48 +0100

Hello,

DIRK
Do you mean : that the best route (who's maybe not the shortest one due to
some constraints) is considered as the RPF now

and vijay
what exactly do you mean about your question ??

Thanx
Ali

---

From: Dirk Ooms <[email-masked]>
Date: Thu, 11 Jan 2001 15:58:02 +0100

> some constraints) is considered as the RPF now

I think you got it, but I want to avoid the word 'best'.  In the
multicast topology, there will be a route to the source and this route
is taken into account for the RPF (this can be the shortest route
calculated by e.g. OSPF, but it can also be a route calculated by a more
sophisticated routing algorithm).

dirk

dirk

---

From: Ron Bonica <[email-masked]>
Date: Thu, 11 Jan 2001 12:24:45 -0500

Dirk,

Now I am really confused.

From your response, I infer that the RPF check will succeed, even if traffic
arrives on an interface other than that through which the router would send
traffic in order to reach the source. Is this inference correct? If it is
correct, wouldn't RPF code have to change?

                                   Ron

> -----Original Message-----
> From: Dirk Ooms [mailto:[email-masked]]
> Sent: Thursday, January 11, 2001 8:43 AM
> To: Ron Bonica
> Cc: [email-masked]
> Subject: Re: Last call on MPLS multicast framework
>
>
> Ron,
>

---

From: Dirk Ooms <[email-masked]>
Date: Fri, 12 Jan 2001 10:41:27 +0100

Ron,

Sorry for creating the confusion (I guess it is caused by my
interpretation of the word 'best' in the dvmrp draft).

The RPF check will succeed on the interface where the JOIN message is
sent upstream.  This can be on an interface different from the interface
through which the unicast route would send traffic to reach the
source/root (because the multicast topology can differ from the unicast
topology).  Also,  this can be on an interface different from the
interface through which the shortest path (in the multicast topology) to
the source/root goes (because of traffic-engineered multicast trees,
i.e. JOIN messages are not sent on the shortest path to the
source/root).  The 'RPF check' implementations that I know behave this
way (i.e. according to the RPF definition in the PIM spec).

dirk

---

From: Ron Bonica <[email-masked]>
Date: Sat, 13 Jan 2001 17:35:52 -0500

Dirk,

If this is the case, what benefit does an ISP derive by running IP multicast
traffic over MPLS?

I may be missing something very fundamental. Please reorient me if I am.

                                          Ron

> Sent: Friday, January 12, 2001 4:41 AM
> To: Ron Bonica
> Cc: [email-masked]

---

From: Jonathon Plonka <[email-masked]>
Date: Sat, 13 Jan 2001 15:07:53 -0800

Some ISPs are moving to a strict MPLS backbone and minimizing as much
native IP traffic as possible.  This is in preparation for the eventual
transition to an mpls enabled optically switched core.
-jonp

---

From: Robert Raszuk <[email-masked]>
Date: Sun, 14 Jan 2001 11:14:55 -0800

> >If this is the case, what benefit does an ISP derive by running IP multicast

Another one would be a drastic reduction of m-cast states in the core if
runned in conjunction with hierarchical PIM for example.

R.

> Jonathon Plonka wrote:

---

From: Dirk Ooms <[email-masked]>
Date: Mon, 15 Jan 2001 10:45:49 +0100

The same benefits as running IP unicast over MPLS.

dirk

---

From: Ron Bonica <[email-masked]>
Date: Mon, 15 Jan 2001 11:15:32 -0500

Traffic engineering? VPN?

Could you say a few words about what it means to traffic engineer a
multicast distribution tree? Would multicast routing modules need to
consider traffic engineering attributes when building multicast distribution
trees?

                            Ron

> Sent: Monday, January 15, 2001 4:46 AM
> To: Ron Bonica
> Cc: [email-masked]

---

From: Dirk Ooms <[email-masked]>
Date: Tue, 16 Jan 2001 09:21:05 +0100

> Traffic engineering? VPN?

both

Traffic Engineering:
section 7 talks about one way of traffic engineering, namely explicit
routing (I didn't want to use 'Traffic Engineering' as title of this
section, because TE can be more than that, e.g. things like OMP), this
is about overriding the shortest path (shortest path according to
unicast routing) tree by another tree.  I see two ways of doing this:
1) an offline calculation and then the tree is created by e.g. LDP
signaling (no multicast routing involved anymore)
2) a multicast routing protocol is running, but the multicast routing
messages are not following the shortest path, they follow
traffic-engineered unicast paths
Early 1999 there were two drafts on te-multicast, each describing the
signaling (not the algorithms) for the above approaches
(draft-wu-mpls-multicast-te-00.txt, draft-leecy-multicast-te-01.txt). 
If you want, I can send these long-expired drafts to you.

VPN:
the recent draft draft-rosen-vpn-mcast-00.txt describes how one could
support IP multicast in VPNs: two of the three methods described will
map the IP multicast tree on a point-to-multipoint LSP.

dirk

---

From: "Hal Sandick" <[email-masked]>
Date: Tue, 16 Jan 2001 16:35:43 -0500

Dirk,

> traffic-engineered unicast paths

I have a feeling I've missed earlier discussion on this.  But if you do "2)" how
do you maintain a consistent network view so that there aren't loops?

Regards,

Hal

---

From: Dirk Ooms <[email-masked]>
Date: Thu, 18 Jan 2001 10:08:21 +0100

Hal,

see below

> do you maintain a consistent network view so that there aren't loops?

If the traffic-engineered unicast paths are loop-free, the multicast
tree constructed with "2)" will be loop-free as well (the multicast
routing messages are just following unicast routes towards the
source/root).

dirk