Subject: Traffic Engineering for multicast traffic

From: Liwen Wu <[email-masked]>
Date: Tue, 25 May 1999 08:52:37 -0400

I have a couple of thoughts on multicast traffic engineering which I
would
like to receive comments on them:

-------------------------------------------------------------------
Definition and Benefits
-------------------------------------------------------------------
Multicast traffic engineering means that: a multicast forwarding tree
is built through policies and explicited routed tree, instead of
topology.

Multicast traffic engineering can have similar benefits as unicast
traffic
engineering. It can be used to achieve efficient  network resource
utilization.

-------------------------------------------------------------------
Methods
-------------------------------------------------------------------
The multicast traffic engineering trees can be built by expanding the
existing protocols. There are 2 categories of protocols:

a) Receiver initiated tree setup: this kind of tree can have
a large number of receivers and they join and prune quite frequently.
PIM-SM protocol can be expanded to build this kind of tree.

b) Sender initiated tree setup: this kind of tree  can have
limited number of receivers with very rare join and prune action.
RSVP protocol can be expanded to build this kind of tree.

MPLS label switching can be used to forward multicast traffic down the
tree to avoid RPF checking

-------------------------------------------------------------------
PIM-SM modifications for multicast traffic engineering
-------------------------------------------------------------------

1) The JOIN msg can be expanded to carry the explicited routed path
towards the RP. A PIM-SM router always sends JOIN/PRUNE towards
the upstream (parent)  listed in the explicited routed path.

2) The JOIN msg can be expanded to carry a mpls label allocated by the
downstream LSR.
It can also carry other contraints, such as color, bandwidth etc.

3) A New msg JOIN-NAK can be sent from upstream(parent) to
downstream(child)
if the upstream can not satisfy the contraints listed in the JOIN msg.

-------------------------------------------------------------------
RSVP modification for multicast traffic engineering
-------------------------------------------------------------------
In addition to the extensions listed in
<draft-ietf-mpls-rsvp-lsp-tunnel-02.txt>

1) PATH can be expanded to carry the explicited routed tree.
New semantics can be defined to reprensent explicited routed tree.

If these ideas are acceptable, I would like to expand them to
a internet draft.

Thanks,
Liwen--

---

From: Jon Crowcroft <[email-masked]>
Date: Tue, 25 May 1999 16:48:49 +0100

In message <[email-masked]>, Liwen Wu typed:

there is already a small bodyo of work on QoS multicast routing which
invovles some of these options - check out papers in ACM CCR by
Carlberg, and papers in SIGCOMM and elsewhere by Faloutsos et al - see
http://www.acm.org/sigcomm/sigcomm98/tp/abs_12.html
for a link...

 >>--------------4971525D2938989A0185079B
 >>Content-Type: text/x-vcard; charset=us-ascii;
 >> name="liwen.wu.vcf"
 >>Content-Transfer-Encoding: 7bit
 >>Content-Description: Card for Liwen Wu
 >>Content-Disposition: attachment;
 >> filename="liwen.wu.vcf"
 >>
 >>begin:vcard 
 >>n:Wu;Liwen
 >>tel;fax:703-724-2003
 >>tel;work:703-724-2619
 >>x-mozilla-html:FALSE
 >>org:Alcatel;R&D
 >>version:2.1
 >>email;internet:[email-masked]
 >>adr;quoted-printable:;;44983 Knoll Square=0D=0A;Ashburn;VA;20147;U.S.A
 >>x-mozilla-cpt:;18304
 >>fn:Liwen Wu
 >>end:vcard
 >>
 >>--------------4971525D2938989A0185079B--
 >>

 cheers

   jon

---

From: "Bora Akyol" <[email-masked]>
Date: Tue, 25 May 1999 10:15:39 -0700

Liwen

Can you please explain the differences between the way PIM-SM already works
and
your proposal?

Also, what is performance gain obtained by using traffic engineered
multicast trees vs standard trees. I can see the benefits of explicit
routing for unicast, but in a dynamic multicast environment where locality
of receivers may change rapidly, what benefits do the explicitly routed
multicast trees buy the network operator?

Regards

Bora Akyol
Pluris, http://www.pluris.com

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Liwen Wu
Sent: Tuesday, May 25, 1999 5:53 AM
To: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Traffic Engineering for multicast traffic

Thanks,
Liwen--

---

From: Liwen Wu <[email-masked]>
Date: Tue, 25 May 1999 14:09:32 -0400

Hello Bora Akyol,

  Please see my replies embedded in your comments.

> Can you please explain the differences between the way PIM-SM already works

A PIM-SM router, as far as I know today, join the upstream (parent) based on
a unicast routing table(RPF checking). It is topology based.

What I am proposing is that:

1) the receiver or a router (e.g border router) specify the whole reverse path
along with the contraints(similar to the ones listed in Daniel O. Awduche's
document) to RP and send the list along with the PIM JOIN msg towards RP.

2) the PIM-SM routers along this reverse path  join the upstream according to
the list
specified in the PIM JOIN msg.

> multicast trees buy the network operator?

The environment that I have in mind is backbone network, not the campus
network.

The benefits of explicit multicast trees over standard trees are very
similar to the benefits of explicit traffic engineering tunnels.

Here are a couple of them, there are maybe more:

1) If all the multicast trees in a backbone network are built by the topology,
there is a possibility that some nodes/links are over congested, whereas
other are not.

2) If a network wants to provide 2 different kinds of service, for example,
premium service and best effort. For the premium service tree, the receiver
may be able to specified the whole reverse path to RP which only contain
premium capable nodes and links. And for the best effort tree, the receiver
can join the upstream the same way as PIM-SM today. With the MPLS
label forwarding, 2 kinds of multicast forwarding services are very easily
achieved.

best regards,
Liwen--

---

From: "Cheng-Yin Lee" <[email-masked]>
Date: Tue, 25 May 1999 14:01:54 -0400

> like to receive comments on them:

i'm also inclined to use an explicit route towards the RP but less inclined
to overload a routing protocol in this manner for traffic engineering.

cheers,
cyl

---

From: "Bora Akyol" <[email-masked]>
Date: Tue, 25 May 1999 12:59:09 -0700

See my comments within:

> Sent: Tuesday, May 25, 1999 12:31 PM
> To: r. venkateswaran
> Cc: Bora Akyol; [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> Subject: Re: Traffic Engineering for multicast traffic
>
>
> Hello Venki,
>
>    Thanks for  raising a very good point.
>
> Here is my explaination:
>
> 1) In terms of  "a bunch of unicast paths to the receivers...",
>
> When a PIM-SM router receives a JOIN msg which includes
> a reverse explicit path and contraints, the router is ALREADY
> on the tree, ALSO the router and the current tree is able to satisfy
> the contraints(e.g. delay, bandwidth etc) specified in the JOIN msg,
> the router should not send a join to a different parent. If the current
> tree is NOT able to satisfy the contraints and the reverse explicit path
> is different than the one specified in the JOIN msg, then the router
> can  JOIN  a different parent. Once the JOIN all the way to
> RP is complete, this router can prune the current tree and use the
> new tree. To konw whether the router has JOIN all the way through
> new reverse path to RP, incoming data or a NEW PIM ACK msg can
> be used.
>
> 2) In terms of "loop",
>
> All the nodes, keeps the reverse explicit path as part of the
> state or context
> of the tree.Once the tree is stablized, there should be one
> reverse explicit path
> per tree. Each JOIN also contains the desired reverse explicit path to RP.
> With these 2 explicit paths, the PIM-SM router can very easily detect the
> "loop" and send the NEW PIM NAK msg downstream.
>
> best regards,
> Liwen--

So does this mean that every time the network topology changes, some process
will need to update the state associated with all multicast sessions on
every node.

I would still assert that even in the backbone routers, I would rather not
circumvent IP routing by creating offline-crafted explicitly routed
multicast trees.

If we are to do something about a problem, that I am not sure exists, why
don't we change the multicast routing to do something similar to
OSPF(ISIS)-OMP proposed by C. Villamizar or by implemented in the ARPANET by
BBN (See SIGCOMM 89 Zinky, Khanna) for multicast instead of unicast: That
is, let us make the multicast routing sensitive to both topology and network
utilization. This way, no explicit routing will be necessary.

The problem statement that you have mentioned then becomes:

Multicast routing must be sensitive to the utilization of the network while
creating multicast trees. If network statistics as well as network topology
are available (such as in OSPF-OMP) then one can create the multicast tree
based on both of these factors, and avoid unnecessary congestion and hot
spotting in the network. Such algorithms can work either in Layer 2 or in
Layer 3.

Regards

Bora Akyol

>
> "R. Venkateswaran" wrote:
>
> > Hi Liwen,
> >
> > I see some serious problems with this approach. The main concern is
> > that the resulting "multicast tree" may no longer be a "tree" by
> > graph-theory definitions. That is, an intermediate router will receive
> > the same multicast data on more than one incoming link and will have
> > to forward them multiple times to different receivers because each
> > receiver wants a certain path for their data. Eventually, you may end
> > up with a bunch of unicast paths to the receivers, as opposed to a
> > multicast tree.
> >
> > To eliminate these "loops" in the multicast tree, some node
> > has to remember the entire multicast tree structure and eliminate
> > duplicate paths at the time of PIM JOIN. I would assume it would be
> > the RP that has to maintain this information.  For large networks,
> > this will involve too much of state information for the RP to
> > maintain.
> >
> > Regards,
> > venki
> >
> > Disclaimer: The above comments are personal views, and may not
> > necessarily reflect those of my organization.
> > --
> > R. Venkateswaran (Venki)           [email -> mailto:[email-masked] ]
> > [Lucent Technologies Bell Labs (IHP), Room 2E-241,Ph # (630)-979-6253]
>

---

From: Liwen Wu <[email-masked]>
Date: Tue, 25 May 1999 15:30:57 -0400

Hello Venki,

Here is my explaination:

2) In terms of "loop",

All the nodes, keeps the reverse explicit path as part of the state or context
of the tree.Once the tree is stablized, there should be one reverse explicit path
per tree. Each JOIN also contains the desired reverse explicit path to RP.
With these 2 explicit paths, the PIM-SM router can very easily detect the
"loop" and send the NEW PIM NAK msg downstream.

best regards,
Liwen--

---

From: "R. Venkateswaran" <[email-masked]>
Date: Tue, 25 May 1999 15:46:31 -0500 (Central Daylight Time)

Hi Liwen,

> new reverse path to RP, incoming data or a NEW PIM ACK msg can

Please also note that since each node is maintaining the reverse
explicit path to the RP (your point 2 below), the router must ALSO
send this updated reverse path information to ALL the downstream
routers which are part of the multicast tree. So, your JOIN will be
complete only when the information has traversed to every router in
the multicast tree. 

Further complications arise when another receiver tries to JOIN a
downstream PIM-SM router before the updated reverse path information
has traversed to this downstream router. How does it then detect
"loops"? 

Such a scenario is quite common for a dynamic multicast session where
receivers join/leave the multicast group frequently. 

Regards,
venki

---

From: "Bora Akyol" <[email-masked]>
Date: Tue, 25 May 1999 12:59:09 -0700

Regards

Bora Akyol

---

From: Liwen Wu <[email-masked]>
Date: Tue, 25 May 1999 15:30:57 -0400

Hello Venki,

Here is my explaination:

2) In terms of "loop",

best regards,
Liwen--

---

From: "R. Venkateswaran" <[email-masked]>
Date: Tue, 25 May 1999 13:37:09 -0500 (Central Daylight Time)

Hi Liwen,

Regards,
venki

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 25 May 1999 23:27:02 -0700 (PDT)

>> If these ideas are acceptable, I would like to expand them to

    Liwen, wouldn't it be simpler to allocate a different RP for each group
    address (or group range) and engineer your network to have RPs along 
    different paths? 

    That assumes shared trees. Using source-trees you could have the source
    send from different addresses which map to different prefixes which
    are reachable via different paths.

    We have customers that do this today.

Dino

---

From: Jon Crowcroft <[email-masked]>
Date: Wed, 26 May 1999 08:23:08 +0100

>>    We have customers that do this today.

right

and if you had Hierarchical PIM (the type we proposed) yo ucould have
multiple RPs at various "levels" and control the tree structure at
quite a fine grain in different regions...
(see ftp://cs.ucl.ac.uk/darpa/hpim.ps.gz)

all:
can we stop CC:ing all the lists - if this is a PIM proposal, it
shoudl stay on the PIM WG list only imho....

 cheers

   jon

...but with SM.....

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 26 May 1999 00:26:17 -0700 (PDT)

>> (see ftp://cs.ucl.ac.uk/darpa/hpim.ps.gz)

    The problems with HPIM (which I explained recently to Mark H) in context
    of unidirectional PIM is that you would have to chain Register messages
    all the way up the hierarchy and then if you wanted to take downstream
    shortcuts while the packet was traveling upstream, you'd have to prevent
    the packet from coming back down from the highest level RP (and causing
    duplicates to receivers).

Dino

---

From: Dirk Ooms <[email-masked]>
Date: Wed, 26 May 1999 11:41:56 +0200

I am wondering whether we need a special traffic engineering method for
multicast.  Is it necessary to make a distinction between unicast and
multicast traffic?

Section 7 of
http://search.ietf.org/internet-drafts/draft-ooms-mpls-multicast-02.txt
explains what explicit routing could mean in a multicast context. 
Either it is overriding the shortest path tree by another explicit tree
(as proposed by Liwen) OR the multicast protocols are using the explicit
unicast routes to construct the multicast trees.

Since traffic engineering does not necessarily need explicit routes
(cfr. OMP), I see 2 methods of doing traffic engineering for multicast
traffic, without having a dedicated 'multicast traffic engineering
method'.  In both methods multicast trees are constructed on top of
influenced unicast routes. 
The influencing of the unicast route can be obtained in following two
ways:

1)having explicit unicast routes.  With the limitation that the explicit
unicast routes need to be bidirectional.

2)use OMP.  Normally in OMP a node starts load balancing when a
downstream link is congested.  The only extension needed for multicast
is that the join messages are load balanced when an upstream link is
congested.

These mechanisms are completely independent of the multicast protocol,
but not independent of the multicast traffic... and traffic engineering
is the thing we want.

Dirk

-- 
Dirk Ooms (DN9)                           Alcatel Research
mailto:[email-masked]          Francis Wellesplein 1
Phone: +32 3 240 4732                       B-2018 Antwerp
Fax:   +32 3 240 9932                              Belgium

---

From: Ken Carlberg <[email-masked]>
Date: Wed, 26 May 1999 08:11:19 -0400

Dino,

does the problem go away with your recent proposal for bi-directional PIM?

-ken

---

From: Liwen Wu <[email-masked]>
Date: Wed, 26 May 1999 08:23:53 -0400

>     are reachable via different paths.

Hello Dino,

   Having different RP definitely helps to have different trees not
overlapping.
But the tree is still built hop-by-hop from leaf to the root, with each
individual
on-tree node choose its parent independently.

  What I am try to propose is to have ONLY the leaf choose the whole
reverse path from the leaf all the way to root. All the other on-tree nodes
just
follow the reverse path that leaf has choosen. This idea is very similar to
the source routing concept in unicast routing, where the first router choose
the
the whole path.

  I can see at least a couple of benefits with this:

1) Only the leaf nodes is making the selection of the reverse path. It is
easier especially
if QoS/COS gets involved. For example, in a network, some nodes are running
with release 1 code, and some nodes are running with release 2 code. There
maybe
a very minor difference in reverseQOS  path selection logic, letting each
on-tree node
choose its parent independently might be harder than only letting the leaf
making
the decision.

2) Very similar to unicast traffic engineering, the leaf node can prune all the
congested
links and nodes out before doing the calculation.

3) Also, if you want to build a colored tree, the leaf can calculate the
reverse colord
path use only the same color links and same color nodes.

best regards,
Liwen--

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 26 May 1999 09:56:29 -0700 (PDT)

>> does the problem go away with your recent proposal for bi-directional PIM?

    I think so as long as you put more encoding semantics in the UMP option.

Dino

---

From: "Cheng-Yin Lee" <[email-masked]>
Date: Wed, 26 May 1999 13:11:34 -0400

> >     address (or group range) and engineer your network to have RPs along

The intent is to be able to direct the join towards paths that are statically
configured or can be computed
(eg using a Constraint Based Routing process as proposed in igp traffic
engineering drafts) to satisfy the
'qos' requirement (as Liwen and Dirk have also mentioned, i think).  When there
are a lot of groups with different 'qos' needs, having the paths towards the
root/RP computed will be more manageable.

> the source routing concept in unicast routing, where the first router choose

Dirk and I have also been working on directing the join using explicit unicast
routes, but not all the way to
the root from each leaf (there are pros and cons to this).  The approach we have
taken is to use MPLS functionalities (label, explicit route object) to do traffic
engineering (by directing the joins) and do forwarding only in the multicast
routing protocol. That way we don't have to include MPLS functionalities in
multicast routing protocols or incorporate multicast routing functionalities in
multicast traffic engineering (using MPLS).

Perhaps we could merge some of these (and other) ideas?

cheers,
cyl

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 26 May 1999 17:24:00 -0700 (PDT)

>> the source routing concept in unicast routing, where the first router choose

    Why would you want to consider doing it this way. You'd have to invent
    a new mechanism to find:

	1) the root of the tree
	2) the path to the root of the tree

    And if you didn't do this apriori to someone joining the group, you'd have
    longer join latencies then today's schemes.

    And to find the path of the tree which has "available" or "non-congested"
    resources would be inventing some the TR stuff going on in unicast
    routing.

>> choose its parent independently might be harder than only letting the leaf

    You want to design a new protocol/mechanism to deal with different
    software releases. I think there are better/(more local) ways to solve 
    this.

    Also, doing path selection in one place doesn't make it any simpler.

>> links and nodes out before doing the calculation.

    You could do this with hop-by-hop state too.

>> path use only the same color links and same color nodes.

    A colored tree is just like joining another group.

    So let's step back and ask what problem you are trying to solve? At first,
    I thought you wanted to solve the fanout issue at any one node. Meaning,
    say we have a fanout of 8 interfaces in a Chicago router that could be 
    split to have 4 in a Houston router and 4 in the Chicago router.

    If this is one of the issues you wanted to address, why would this be
    a good thing. It sounds like you'd be pushing the fanout higher towards
    the root. I don't see providers wanting to do that. They don't want to
    fanout transit traffic, they want fanout to their own customer receivers
    and push the responsiblity of replication on their peers, if they can.

    So, I'd like to hear a clear description of the problem you want to solve.

Dino

---

From: "Cheng-Yin Lee" <[email-masked]>
Date: Wed, 26 May 1999 23:31:32 -0400

Dino Farinacci wrote:
>     So let's step back and ask what problem you are trying to solve?

ok, let's start with a clean slate. Let's forget about the actual
mechanisms used to do traffic engineering (i'm not in favour of putting
MPLS functionalities in multicast routing protocols or to have a leaf
join all the way to the root for TE purposes, either but we can work out
the details later).

What we want to provide are tools that ISPs can use to engineer
multicast traffic. MPLS and constraint based routing allow us to build
those tools. ISPs can then used them to engineer multicast traffic from
certain groups to go on certain paths only or to decrease the fanout for
eg. All the pieces may not be implemented or specified yet, but i think
we have a framework to build these tools.

cheers,
cyl

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 27 May 99 17:16:56 JST

Cheng-Yin;

> we have a framework to build these tools.

From the fact that multicast route aggregation is impossible,
it can directly be derived that MPLS is useless for multicast.
You don't even have to consider policy/QoS.

However, this is a useless arguement, because MPLS a cousin of
ATM and is useless for anything.

							Masataka Ohta

---

From: Liwen Wu <[email-masked]>
Date: Thu, 27 May 1999 08:01:39 -0400

>         2) the path to the root of the tree

No, you can still use the same way that how you choose your RP today. Then
the leaf computes the whole reverse path to this root according to its own topology
database or by some other mechanism(e.g. "manager" mentioned in QoSMIC,
or NMS)

>     resources would be inventing some the TR stuff going on in unicast

Unicast routing is alway doing this today for unicast traffic engineering.

>     You could do this with hop-by-hop state too.

Same argument here as why people is doing source routing for unicast traffic in
addition to hop-by-hop routing.

>     and push the responsiblity of replication on their peers, if they can.

Yes, you raised a very good example here. When there are thousands
of mulitcast groups in a backbone carrier network,
1) for some groups, you want to push fanout higher, and
2) for some groups you want to push fanout lower, also
3) for some group you want to choose certain fanout point
4) for some group you want to avoid certain fanout point.

Also, if some group trees requires certain QoS/COS constraints.

I would thought multicast traffic engineering can help to solve these problems.

And to support this, PIM-SM seems not that hard with only following
extensions:

1) a new PIM-SM msg,   JOIN-ACK/JOIN-NAK

2) a new object(fields) in JOIN msg which carry the reverse explicit
path and QoS/COS contraints

3) At any on-tree node(merge point, or fanout point), merge these
explicit path, and send 1 JOIN with QoS/COS contraint towards
the RP

best regards,
Liwen--

---

From: Yakov Rekhter <[email-masked]>
Date: Thu, 27 May 1999 05:12:04 -0700

> we have a framework to build these tools.

I think that the whole issue of traffic engineering for multicast
within an ISP may be of *practical* significance only when the amount
of multicast traffic forms a *significant* percentage of the total
traffic within an ISP. So, how many ISPs have today more than let say
20% of their total traffic as *native* (as opposed to tunneled)
multicast ?

Yakov.

---

From: Liwen Wu <[email-masked]>
Date: Thu, 27 May 1999 08:11:57 -0400

There is also one more point on this:

 If a multicast tree does not have a lot of receivers, and
the receivers are quite static(no dynamic join/leave), RSVP
can be use. In this situation, the whole explicited tree (which
is not a big object for a small tree) can piggybacked in
RSVP path msg.

best regards,
Liwen--

---

From: Lloyd Wood <[email-masked]>
Date: Thu, 27 May 1999 13:17:04 +0100 (BST)

> it can directly be derived that MPLS is useless for multicast.

I'm sorry, I don't see how you get from a) to b).

Can you please elaborate on this compelling argument? Feel free to
compare multicast over MPLS with multicast using EARTH/MARS/VENUS when
you do.

> ATM and is useless for anything.

MPLS appears quite useful for implementing IP routing where it can be
leveraged to IP's benefit. But, hey, what do I know?

Followups set to the mpls list.

L.

> 							Masataka Ohta

<[email-masked]>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>

---

From: "Cheng-Yin Lee" <[email-masked]>
Date: Thu, 27 May 1999 07:28:30 -0400

> 20% of their total traffic as *native* (as opposed to tunneled)

If we can assume the traffic will _never_  grow then sure, we don't have
to worry about traffic engineering.

cheers,
cyl

---

From: "R. Venkateswaran" <[email-masked]>
Date: Thu, 27 May 1999 08:07:07 -0500 (Central Daylight Time)

Liwen,
 
> explicit path, and send 1 JOIN with QoS/COS contraint towards

Maybe it is just me, I just don't understand how this is so simple.
First, when you talk about QoS/COS constraints, do you refer *only* to
bandwidth. If so, then it is quite clear to me.

If you have QoS constraints based on delay, packet loss and delay
jitter, how do you ensure that a new path from a "fanout" node (node
that is already on the tree and the new JOIN message reaches this
node) to the root (or RP) does not violate the QoS constraints of
already existing receivers? Do you maintain all the QoS requirements
of existing receivers at the "fanout" point?
QoS constraints for delay etc are end-to-end constraints, not
link-by-link constraints. So, it is going to be extremely difficult to
calculate link-by-link constraints based on end-to-end constraints. Of
course, this is trivial for bandwidth only.

Second, there is the join latency, which Dino has already explained
in his mail. Other than the JOIN-ACK/JOIN-NAK, there is also the
latency involved with informing *all* the nodes on the multicast tree
about the new path to the root. Currently, in PIM-SM, the JOIN latency
is a one-way trip to the RP. What you are proposing is a round-trip
plus some more. I am not sure whether a single join should involve all
the nodes in the multicast tree. 

My 2 cents.

Regards,
venki

---

From: Shravan Goorah <[email-masked]>
Date: Thu, 27 May 1999 16:07:52 +0100

Hello Cyl,

> to worry about traffic engineering.

Your proposal seems interesting - can you explain how you come to such an
assumption...

Cheers,
Shravan

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 28 May 99 2:41:21 JST

Lloyd;

MPLS was first proposed to show that we don't need NHRP. Nothing
more than that.

When I did so, I was fully aware that it scales poorly
for best effort traffic. I was fully aware that cell swithcing
routers are much slower than packet routers, too.

As we have virtually no PNNI today, we don't have to mind NHPR
nor MPLS.

The only thing you should know about MPLS is that "traffic
engineering" is not the magic word to improve the poor scalability.

> I'm sorry, I don't see how you get from a) to b).

I can give you a hint.

The magic keyword to dismiss useless protocols is "scalability".

> Followups set to the mpls list.

Do you think I am (or was) there?

						Masataka Ohta

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 27 May 1999 12:21:41 -0700 (PDT)

>> Unicast routing is alway doing this today for unicast traffic engineering.

    Right, and multicast should use it. There was a comment (forgot who) that
    it shouldn't be topology based. Well, if unicast routing is already doing
    it, it should be topology based.

>> 1) a new PIM-SM msg,   JOIN-ACK/JOIN-NAK

    Naming the message type provides no value in describing what the message
    does.

>> explicit path, and send 1 JOIN with QoS/COS contraint towards

    Sounds exactly like RSVP to me.

Dino

---

From: Lloyd Wood <[email-masked]>
Date: Thu, 27 May 1999 20:33:33 +0100 (BST)

On Thu, 27 May 1999, Dino Farinacci wrote:

>     And "scalability" is such an overloaded (and sometimes over-rated) term.

Right.

I mean, a finite 128-bit address space for IPv6? Not scalable.
Useless, in fact. Right, so much for IPv6.

If that's the best argument he can come up with...

L.

scalability has to be played off against suitability for purpose.

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 27 May 1999 12:27:34 -0700 (PDT)

Dino

---

From: Liwen Wu <[email-masked]>
Date: Thu, 27 May 1999 16:12:47 -0400

>     Naming the message type provides no value in describing what the message

I agree. But if we can agree on the  idea, we can always work out the details
later.

The idea is:
To build a receiver-initiated explicit multicast tree, the leaf (or border
router) specify  the whole reverse path towards root (or  RP) and
each individual on-tree node join the upstream node (parent) according
to the reverse path specified by the leaf node.

To build a sender-initiated explicit multicast tree, the root of the tree
specify the whole tree and set it up from root to all the receivers.

I would thought PIM-SM can be used to set up receiver-initiated explicit
multicast tree, whereas RSVP can be used to setup sender-initiated explicit
multicast tree.

Receiver-initiated explicit multicast tree is more suitable for a tree which
has a lot of receivers(or more wider, or high fanout).

Sender-initiated explicit multicast tree is more suitable for a tree which
has fewer receivers(or low fanout), so that a whole explicit tree can be
piggybacked in RSVP PATH msg.

>     Sounds exactly like RSVP to me.

No, RSVP PATH msg(in explicit multicast tree scenario) picks the fanout
point from root towards downstream,  whereas in PIM-SM the JOIN msg
(in explicit multicast tree scenario) picks the fanout point from downstream
towards upstream.

best regards,
Liwen--

---

From: Liwen Wu <[email-masked]>
Date: Thu, 27 May 1999 16:23:32 -0400

> leveraged to IP's benefit. But, hey, what do I know?

MPLS Multicast tree can be useful in the following example:

1) In  a core backbone network, if a couple of multicast groups coming in
from a same ingress point and exits the same egress points,

2) you can build ONE MPLS traffic engineering tree which is rooted at
this ingress point and exits the same egress points.

3) then ingress node can put all the multicast traffic for these groups
onto this single MPLS traffic engineering tree.

4) there is no requirement on the relationship of   these multicast group
addresses(they don't need to be aggregatable)

best regards,
Liwen--

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 27 May 1999 13:16:56 -0700 (PDT)

>> I agree. But if we can agree on the  idea, we can always work out the details

    I would like to discuss the problem much more before looking at ideas
    and solutions.

>> multicast tree, whereas RSVP can be used to setup sender-initiated explicit

    RSVP doesn't set up multicast trees.

>> piggybacked in RSVP PATH msg.

    It is more suitable because it couldn't scale for large number of 
    receivers.

>> (in explicit multicast tree scenario) picks the fanout point from downstream

    No, you are wrong. RSVP uses the multicast tree which has already been
    built by your favorite multicast routing protocol. The fanout of PATH
    messages has already been determined before the message is set.

    It is the receivers which initiate reservations, so the merge semantics
    you describe are already performed in RSVP.

Dino

---

From: "Petri Helenius" <[email-masked]>
Date: Fri, 28 May 1999 00:23:44 +0300

>     And "scalability" is such an overloaded (and sometimes over-rated)
term.
...and there are lessons to be remembered from the DVMRP and pre-MSDP PIM
days that insisting on technical perfection does not make things happen in
real life. (quite the contrary)

Pete

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 28 May 99 10:40:40 JST

Liwen;

> addresses(they don't need to be aggregatable)

They don't need to be aggregatable.

They don't need MPLS encapsulation, either.

							Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 28 May 99 10:19:23 JST

>     And "scalability" is such an overloaded (and sometimes over-rated) term.

It keeps those who overload it from the truth, which is a good
thing unless I tried to discuss with them.

							Masataka Ohta