Subject: Re: I-D ACTION:draft-yasukawa-mpls-rsvp-multicast-00.txt

From: Seisho Yasukawa <[email-masked]>
Date: Mon, 01 Jul 2002 15:40:14 +0900

Dear David

Thank you for your comment.

I agree that classical RSVP was designed around multicast and existing 
RSVP-TE can
cope with multicast in essesntial. But I still think existing RSVP-TE is 
not suitable and
some modifications are necessary to support multicast because its lack of 
TE function.

>In my opinion, this draft is not necessary.  It is based on the incorrect 
>assumption that RSVP-TE, as it is currently defined, does not have 
>supprort for multicast.
>
>Classical RSVP was designed around multicast, and RSVP-TE introduces 
>nothing to change this, even though it does not explicitly describe a 
>multicast implementation.

As mentioned above, I agree with your assumption to RSVP-TE basically.
But please note that our draft describe some modification and extensions 
to existing RSVP-TE in order to cope with
not only multicast application but also p-to-mp application.

>For a multicast LSP, one has only to specify a multicast group address in 
>the SESSION object (the tunnel endpoint address), and do not include an 
>EXPLICIT_ROUTE object.  Normal Path processing should propagate the Path 
>message to all next-hops in the multicast group, according to the 
>multicast table that already exists.

We think some modification is necessary to SESSION object definition when 
considering multicast session.

We think it is important to define multicast LSP tunnel independent to its 
accomodated traffic.
In this design, intermediate node along the LSP must not conscious of its 
accomodated traffic protocol.
And we want a p-to-mp LSP to accomodate both multiple IP multicast group 
traffic and non-IP traffic,
such as Ether traffic.

Therefore, it is not convenient to specify a multicast group address in 
the SESSION object.

To enable the identification and association of such multicast LSP 
tunnels, new MULTICAST_LSP_TUNNEL
session objects are defined in our proposal. Each session object carries 
the sender node address of a p-to-mp LSP
and its tunnel ID. The sender node address is more preferable than 
destination (leaf) node addresses to identify
a multicast LSP tunnel because frequent topological changes may occur and 
destination node addresses are not
stable in this tunnel.

Therefore, the SENDER_TEMPLATE (or FILTER_SPEC) object together with this 
SESSION object uniquely identify
a multicast LSP tunnel. To identify the leaf and topology of this 
multicast LSP tunnel, TREE_EXPLICIT_ROUTE object
and TREE_RECORD_ROUTE object are also defined.

>I am aware that RSVP-TE's definition of EXPLICIT_ROUTE and RECORD_ROUTE 
>does not accommodate multicast.  If there is some need to specify an 
>explicit multicast tree that differs from the multicast routing table, 
>then this might be required.
>
>Personally, I think attempting to traffic-engineer a multicast tree 
>beyond what existing multicast routing protocols already do is pointless. 
>Any automatic process for generating these trees will duplicate all of the 
>work that routing protocols already do.  Any manual process will be 
>unmanageable, since receivers may be continuously joining and leaving the 
>multicast group.

We think Traffic Engineering become more important when considering 
multicast application.
A multicast LSP has more complex topology and it affect network switching 
resource more drastically compared with unicast LSP.

And we think it is not enough to combine existing multicast routing 
protocol and RSVP-TE to enable mulitcast traffic engineering.
We think what existing multicast routing protocol do for 
traffic-engineering is completely weak.

For example, PIM-SM that is most widely used multicast protocol, I think, 
has three phases to establish muticast tree.
Phase 1: Encapsulation transmission to Randezvous Point (RP) + RP 
Multicast Tree distribution
Phase 2: Register Stop Process which switch over to (S,G) transmission 
from RP encapsulation transmission
Phase 3: Shortest Path multicast distribution (switch over from RP transmission)
This mechanism allows very frequent topological change into tree topology.

Therefore we think it is not realistic to make multicast LSP synchronized 
with L3 multicast routing protocol.
We can not control multicast traffic completely in this design.
Moreover, path-protection mechanism or rerouting mechanism are not 
supported in this design.

>Given the infeasability of a manually-configured multicast LSP, we're 
>back to automatic configuration.  RSVP, as it currently stands, is 
>sufficient in this situation.  It reads the existing multicast routing 
>table to determine the next-hops for a multicast group, and monitors the 
>routing table to add and remove next-hops as needed.  Rules for merging 
>FLOWSPEC objects are already in place.  Rules for merging labels are 
>self-evident.
>
>While it is true that current RSVP-TE implementations do not have support 
>for multicast LSPs, there is nothing in RFC 3209 that prohibits the use of 
>RSVP-TE for multicast situations.  Note that the only part of RSVP-TE that 
>is not multicast-friendly is the EXPLICIT_ROUTE object - ant this object 
>is optional in Path messages anyway.
>
>-- David

As you mentioned above, it is better to construct multicast LSP automatically.
We can use TERO for this purpose.
Some multicast tree calculation mechanism that is implemented in Network 
Mangement Sytem or Sender node calculate
TERO that represents suitable multicast tree and invoke this multicast 
MPLS protocol to setup multicast LSP tunnel.

And as mentioned in our draft, our scheme also target to support multicast 
LSP setup using multicast routing table information.

We are sevice provider and strongly need this p-to-mp LSP setup mechanism 
to enable Contents delivery service and p-to-mp
L2/MPLS service.

We are willing to modify our proposal to accelerate this discussion.
Please join this discussion and give us comments.

Seisho

---

From: David Charlap <[email-masked]>
Date: Mon, 01 Jul 2002 16:47:03 -0400

Seisho Yasukawa wrote:
> 
> I agree that classical RSVP was designed around multicast and existing RSVP-TE can
> cope with multicast in essesntial. But I still think existing RSVP-TE is not suitable and
> some modifications are necessary to support multicast because its lack 
> of TE function.

You mean the lack of explicit routes.  TE is a very broad and vague term.

If you think you need to define a multicast ERO, you can do that without 
changing the rest of the protocol.

> not only multicast application but also p-to-mp application.

point-to-multipoint is simply a subset of IP multicast, where there is 
only one sender.

> We think some modification is necessary to SESSION object definition 
> when considering multicast session.
> 
> We think it is important to define multicast LSP tunnel independent to its accomodated traffic.
> In this design, intermediate node along the LSP must not conscious of its accomodated traffic protocol.
> And we want a p-to-mp LSP to accomodate both multiple IP multicast group traffic and non-IP traffic,
> such as Ether traffic.

Transit nodes never have to know anything about the data-plane payload.

In unicast scenarios, there is nothing requiring the traffic to be IP. 
As a matter of fact, there are two different explicit mechanisms for 
non-IP traffic.  One is to specify the Ethertype for the payload in the 
LABEL_REQUEST object, and the other is to signal an IP LSP, and use an 
extra label on the stack to identify the protocol (the Martini draft).

Yes, you need to specify an IP address for the tunnel endpoint, but you 
need to do that for unicast LSPs as well.

Note also that you will need _some_ mechanism for defining the endpoints 
of a multicast LSP.  If you don't define an IP multicast group and have 
your egress routers all join that group, then you'll have to re-invent 
the wheel by replicating what existing multicast routing protocols 
already do.  Multicast is difficult enough with established protocols 
(IGMP, DVMRP, PIM-DM and PIM-SM).  Inventing yet another routing 
protocol, and making it part of RSVP (which is already enormously 
complex) is something I would want to avoid at all costs.

> To enable the identification and association of such multicast LSP tunnels, new MULTICAST_LSP_TUNNEL
> session objects are defined in our proposal. Each session object carries the sender node address of a p-to-mp LSP
> and its tunnel ID. The sender node address is more preferable than destination (leaf) node addresses to identify
> a multicast LSP tunnel because frequent topological changes may occur and destination node addresses are not
> stable in this tunnel.

Tunnel ID is not a globally unique value.

And note that you are forcing your multicast to be only p-to-mp.  You 
are not permitting IP multicast (wich is mp-to-mp) to be used.  Which 
means you end up with less funcationality than there was before.

As for topology changes, that's why the concept of a multicast group was 
invented in the first place.  It's a way to uniquely identify the entire 
set of senders, receivers, and links.  By eliminating it, you now have 
to replace it with something else that does the same thing or you make 
your new protocol needlessly complicated.

> Therefore, the SENDER_TEMPLATE (or FILTER_SPEC) object together with 
> this SESSION object uniquely identify a multicast LSP tunnel. To identify the leaf and topology of this 
> multicast LSP tunnel, TREE_EXPLICIT_ROUTE object and TREE_RECORD_ROUTE object are also defined.

All of the work necessary to define and maintain your topology is 
already defined for all of the major multicast routing protocols.  There 
is no need to redefine it in yet another protocol.

> For example, PIM-SM that is most widely used multicast protocol, I 
> think, has three phases to establish muticast tree.
> Therefore we think it is not realistic to make multicast LSP 
> synchronized with L3 multicast routing protocol.

There's no big deal if you want to define your own private multicast 
groups, for the purpose of establishing TE across your own routing core. 
  Once the multicast LSPs are in place, you can then transit any traffic 
you want across it.

Remember, you're not interested in setting up LSPs that run from a 
server to all of the millions of hosts receiving from that server. 
You're interested in setting up LSPs to efficiently transit multicast 
traffic to the edges of your network.  This is especially true if you're 
talking about non-IP traffic.

This is no different from how TE is being used in the unicast case. 
People are creating LSPs that connect from one edge of their network to 
the other edge.  The addresses used here do not have to be global 
addresses, since the LSP never leaves the private address space.

Similarly, your choice of multicast group addresses don't have to be 
global addresses, since your group won't ever extend beyond your own 
network.

> We can use TERO for this purpose.  Some multicast tree calculation mechanism that is implemented in Network 
> Mangement Sytem or Sender node calculate TERO that represents suitable multicast tree and invoke this multicast 
> And as mentioned in our draft, our scheme also target to support 
> multicast LSP setup using multicast routing table information.
> 
> We are sevice provider and strongly need this p-to-mp LSP setup 
> mechanism to enable Contents delivery service and p-to-mp L2/MPLS service.

I still think you can accomplish all of your goals using an existing 
multicast routing protocol and an unmodified RSVP-TE protocol.

-- David

---

From: Seisho Yasukawa <[email-masked]>
Date: Fri, 05 Jul 2002 00:35:16 +0900

Dear David

>You mean the lack of explicit routes.  TE is a very broad and vague term.

Yes, I mean that we must add and define the explicit routes function to 
existing RSVP-TE
to enable multicast traffic engineering.

We think TE becomes more important when considering multicast application.

When considering multicast TE, we want to engineer (control) multicast tree 
topology.
But, as you know, most of conventional IP multicast routing protocol only 
establish shortest path
multicast tree because these protocol utlized RPF mechanism when 
constructing multicast route.
Therefore, we need TERO (Tree Explicit Route Object) that can control 
multicast LSP topology.

We also want the scheme to rerouting the multicast traffic when some error 
occurs in the network.
Some multicast routing mechanism may find these error and find another 
available route finally.
But we think we need more reliable and faster rerouting mechanism in 
multicast environment.
Most of multicast tree has tree topology and the error near the root node 
cause tragic effect on
multicast traffic transmission.
To enable first and reliable recovery, we think it is better to devide path 
setup and multicast routing
mechanism seperatory.
Therefore, we design multicast MPLS protocol that only use unicast routing 
information and propose
TERO to control the tree topology and Graft/Prune mechanism to 
setup/release partial multicast
tree.

>changing the rest of the protocol.

We define a TERO with necessary modification in our draft.

>In unicast scenarios, there is nothing requiring the traffic to be IP. As 
>a matter of fact, there are two different explicit mechanisms for non-IP 
>traffic.  One is to specify the Ethertype for the payload in the 

We think that specifying an IP mulitcast group address as the tunnel 
endpoint has completely different meaning compared
with unicast case.
The unicast IP address is attached to physical IF or node and indicates its 
physical location in the network.
Therefore, we can specify the tunnel endpoint by this address.
But multicast group address cannot specify the physical location. As a 
result, we can not specify the tunnel endpoint by
this address.
This is a fundamental problem caused by the definition of SESSION object in 
conventional RSVP-TE protocol.
Therefore, we newly redefine MULTICAST SESSION object in our draft.

In addition to this problem, it is not convenient to use single IP 
multicast address because we cannot accommodate
several IP multicast group traffic and non-IP traffic in a single multicast 
LSP tunnel.

>your egress routers all join that group, then you'll have to re-invent the 
>wheel by replicating what existing multicast routing protocols already do.

We define the endpoint of a multicast LSP by TERO and TRRO.

>   Multicast is difficult enough with established protocols (IGMP, DVMRP, 
> PIM-DM and PIM-SM).  Inventing yet another routing protocol, and making 
> it part of RSVP (which is already enormously complex) is something I 
> would want to avoid at all costs.

We also think that IP multicast routing protocol is difficult to engineer 
and has problem in its scalablity.
And we think it is not good choice to combine the IP multicast routing 
protocol and conventional RSVP-TE.
Therefore, we proposed the combination of extended RSVP-TE protocol that 
has multicast capability and
conventional unicast routing protocol.

>And note that you are forcing your multicast to be only p-to-mp.  You are 
>not permitting IP multicast (wich is mp-to-mp) to be used.  Which means 
>you end up with less funcationality than there was before.

We propose the mp-to-mp LSP setup mechanism in our draft.
Please see, section 7.

>groups, for the purpose of establishing TE across your own routing 
>core.  Once the multicast LSPs are in place, you can then transit any 
>traffic you want across it.
>
>Remember, you're not interested in setting up LSPs that run from a server 
>to all of the millions of hosts receiving from that server. You're 
>interested in setting up LSPs to efficiently transit multicast traffic to 
>the edges of your network.  This is especially true if you're talking 
>about non-IP traffic.

As mentioned above, we are not interested in shortest path tree that is 
calculated by conventinal IP multicast routing protocol.
Although we define the private multicast group, we cannot still control 
tree topology and multicast traffic across it.
We think it is much easier to control traffic by path layer compared with 
routing layer.
MPLS is attractive because it can control traffic by path (LSP) independent 
to routing protocol when considering TE.
Therefore, we think multicast MPLS protocol must support not only multicast 
LSP that is established by multicast routing protocol
but also multicast LSP that is established by TERO.

Best regards,

Seisho Yasukawa

---

From: David Charlap <[email-masked]>
Date: Mon, 08 Jul 2002 12:40:12 -0400

Seisho Yasukawa wrote:
> David Charlap wrote:
> existing RSVP-TE to enable multicast traffic engineering.

I agree, that a definition for multicast EROs would be a good idea, 
although I think such an object will end up consuming a lot of 
bandwidth. A multicast tree, for a non-trivial network will consume 
hundreds, if not thousands of bytes.  Considering that existing RSVP 
messages are on the order of 100-200 bytes, this is not something we can 
just gloss over.

> We also want the scheme to rerouting the multicast traffic when some error occurs in the network.
> Some multicast routing mechanism may find these error and find another available route finally.
> But we think we need more reliable and faster rerouting mechanism in multicast environment.

This is where I think you're reinventing the wheel.  If there is a 
problem with existing multicast routing protocols, then I think 
everyone's effort is best spent trying to improve the routing protocols.

I really don't like the idea of adding routing functionality into a 
signaling protocol.  It makes everything much more complicated than it 
has to be.

> endpoint has completely different meaning compared with unicast case.
> The unicast IP address is attached to physical IF or node and indicates 
> its physical location in the network.
> result, we can not specify the tunnel endpoint by this address.

The session address does more than identify an endpoint.  It also serves 
as a key to group together multiple connections within a router.  When 
you eliminate the field from the SESSION object, you end up deleting 
that key.  The tunnel ID and sender address alone are not sufficient to 
completely specify a multicast session.

I realize that you're only interested in point-to-multipoint, but I 
don't think it's right to declare that this is the one and only form of 
multicast that MPLS will be allowed to support.

> several IP multicast group traffic and non-IP traffic in a single 
> multicast LSP tunnel.

This doesn't follow.  There is no reason why an IP destination address 
in RSVP must necessarily imply an IP payload in the LSP.  There are many 
different mechanisms where you can specify non-IP payload, even though 
the endpoint address is IP.

>> Note also that you will need _some_ mechanism for defining the 
>> endpoints of a multicast LSP.  If you don't define an IP multicast 
>> group and have your egress routers all join that group, then you'll 
>> have to re-invent the wheel by replicating what existing multicast 
>> routing protocols already do.
> 

Which completely redefines a key part of the RSVP protocol.  The SESSION 
is supposed to define the endpoints.  The ERO is supposed to be used to 
override the routing table, where that is necessary.

With your draft, you change the semantics of RSVP so much that it isn't 
even the same protocol anymore.  Your semantics are much closer to 
CR-LDP than they are to RSVP.

>> traffic to the edges of your network.  This is especially true if 
>> you're talking about non-IP traffic.
> 

This is no different from unicast RSVP, where the ERO object overrides 
the local routing table.  We don't eliminate the endpoint address from 
the SESSION object just because we're not using the routing table.

In a unicast environment, the routing protocols continue to run as 
always.  The ingress nodes use the routing table in order to detect 
tunnel endpoints, and to construct explicit routes to those endpoints.

Multicast behavior can be similar.  There is no reason why RSVP has to 
use the multicast routing table.  The ingress nodes can use the 
multicast routing table to detect endpoints (where the tree leaves the 
MPLS cloud), and build a TERO based on those endpoints and the unicast 
routing table.  No changes to RSVP, other than the TERO object are 
necessary for this.

-- David