The MPLS WG Archive

[Eric Rosen <erosen@cisco.com>]

Adrian> To cover  a general  point first,  the scope of  the document  is to
Adrian> provide "Requirements for Point  to Multipoint extension to RSVP-TE"
Adrian> as  requested by  the  WG. This  scope  clearly does  not cover  the
Adrian> questions:
Adrian> - do we need multicast TE?
Adrian> - is RSVP-TE the right protocol for multicast TE? 

Well,  I  found  the title  ambiguous;  I  couldn't  tell whether  it  means
(a) "Extensions to RSVP-TE are required, and here's why", or (b) "If we ever
decide that P2MP Extensions to  RSVP-TE are needed, here are some conditions
those extensions  must satisfy".   I think you're  saying now that  it means
(b), but I'm not  sure it is sensible to argue for  (b) without also arguing
for (a).  How do we know  what the requirements for extending RSVP-TE are if
we  don't understand,  e.g., the  requirements for  mixing TE  multicast and
non-TE multicast in  the same network.  As another example,  in the realm of
unicast we have a pretty good  understanding of how traffic moves between TE
areas and non-TE area; do we have the same understanding for multicast?  

Adrian> These may  be valid  questions for the  WG, although by  the charter
Adrian> items (and the ruling on RSVP-TE as the only MPLS TE protocol) I had
Adrian> assumed that the decision had already been taken. Perhaps it was not
Adrian> sufficiently widely discussed. 

I'm sure there  will be people who  say that TE should be  done by extending
existing multicast routing protocols.  Or  by using RSVP in combination with
existing multicast routing protocols.  If we  do not think this is the case,
we need a stronger argument than "it's required by charter".

Eric> Providing  ethernet  multicast support  is  more  complex than  merely
Eric> setting  up  a   P2MP  LSP,  as  the  ethernet   specs  pose  ordering
Eric> requirements that  would be violated unless unicast  packets were also
Eric> sent on the multicast tree.

Adrian> Is this problem not identical with parallel unicast LSPs? 

Not sure what you're asking.

Adrian> It is  certainly not the intention  to tell anyone how  to solve any
Adrian> other problem, merely to characterise the requirements on RSVP-TE if
Adrian> it were to  be used to solve a particular  problem. It would clearly
Adrian> be bad news to extend RSVP-TE for P2MP and miss a key requirement. 

Unless the document has been given careful consideration by folks working on
all the  various problems that might be  solved via multicast TE,  how do we
know we haven't missed a requirement?

Eric> There is a  "requirement" that the solution be  applicable to GMPLS as
Eric> well as MPLS.  I don't see where this requirement comes from.  For all
Eric> I know,  GMPLS might introduce  a variety of  additional complications
Eric> that aren't necessary in MPLS.  If this is so, I would not necessarily
Eric> support using the same solution in both cases.

Adrian> It is my understanding that the requirement comes from the ADs. 

Then  your document  should clearly  distinguish the  requirements  that are
there because of politics from the requirements that are there for technical
reasons ;-)

Adrian> But,  if   GMPLS  does  not   introduce  a  variety   of  additional
Adrian> complications, it would surely be sensible to have the same protocol
Adrian> extensions in both MPLS and GMPLS.  Further, if a minor tweak to the
Adrian> MPLS solution made it equally  applicable to GMPLS, wouldn't that be
Adrian> a good thing all round? 

Absolutely. Does  GMPLS introduce such  complications?  I have no  idea.  If
GMPLS introduces requirements of its  own, these should be clearly stated in
the  document.  If GMPLS  introduces no  new requirements  of its  own, then
there's no issue, of course.  But what  I get from the document is "we don't
know  what additional requirements  GMPLS may  introduce, but  whatever they
are, they must be satisfied by the  MPLS solution."  I don't think that is a
reasonable position to take.

Adrian> Why is it  not enough to allow the TEDB at  the ingress (or offline)
Adrian> to be processed to derive the multicast distribution tree? 

It's not  completely obvious what this  means, given the  way that receivers
dynamically  join  and  leave  multicast  groups.  It's  worth  noting  that
existing multicast tree creation protocols tend  to set up the tree from the
receivers to  the transmitters, while this  draft seems to  be requiring the
reverse.  A discussion of this difference would be useful.

Adrian> This is,  after all,  a TE (explicitly  routed) solution not  one of
Adrian> hop-by-hop forwarding.

Well,  in unicast  TE is  not  exactly synonymous  with "explicit  routing".
Using the  TE toolset  you have  a mixture of  strict routes,  loose routes,
tunnels,   aggregation.   constraint-based   routing,  admissions   control,
bandwidth guarantees,  link protection, node protection, etc.,  etc.  If one
were  doing a "requirements  for multicast  traffic engineering",  one would
have to understand the applicability of all these things to multicast.

>> 5. Central  to the  original design  of RSVP  was the  goal of  using  it to
>> establish  QoS for  multicast distribution  trees.  This  might  make one
>> think  that RSVP  could be  combined with  PIM to  allow  for dynamically
>> created distribution  trees to which  QoS can be applied.   However, this
>> possibility  seems to  be immediately  ruled out  by  the "requirements".
>> It's  not  very  clear  whether  the  use of  PIM  to  set  up  multicast
>> distribution trees is supposed to  be compatible or incompatible with the
>> traffic engineering of those trees.

Adrian> The requirements rule out  depending on any multicast protocol. They
Adrian> do not rule out using one. 

Insofar as  there is  no requirement for  the extended RSVP-TE  to interwork
with non-TE  multicast in any way,  a solution which  meets the requirements
might be  incompatible with existing  multicast paradigms.  Whether  this is
satisfactory needs to be thought out more fully.

Adrian> I would emphasise that this  draft in no way detracts from multicast
Adrian> routing, but simply recognises that  TE is a different problem space
Adrian> from multicast IP. 

I would say it presupposes that TE is a different problem space, but I think
this deserves some analysis.

Adrian> No  mention  is made  of  how  the ingress  discovers  who  is in  a
Adrian> destination  set when it  builds a  multicast distribution  tree and
Adrian> uses that to signal a P2MP LSP for TE purposes.  

There needs  to be  some discussion of  the requirements for  this discovery
process.  In "conventional" multicast, this  discovery is often based on the
multicast routing protocol  itself.  I read the document  as indicating that
RSVP be  extended (somehow) to  provide this discovery capability,  but it's
not completely obvious that that's the way to go.

Adrian> All that  is stated is that  receivers are expected to  come and go.
Adrian> Consequent on this if the  requirement that it should be possible to
Adrian> add and remove receivers from the LSP. 

Can't argue with that one.  

Eric> The  document  has  a number  of  places  where  it is  asserted  that
Eric> something is or is not "optimal" or "efficient", without any statement
Eric> of just what resource is being used suboptimally or inefficiently.

Adrian> Agreed these  terms are subjective  and are, perhaps, used  a little
Adrian> freely.

Adrian> If I search for "optimal" I find...

I'm not going to go through the use of the term occurrence by occurrence ;-)
But I've  found that in talking  about the scalability/optimality/efficiency
etc. of  multicast schemes, it  is best to  be very specific.   For example,
every multicast  scheme claims to  be scalable, but  some scale well  as the
number  of  receivers increases,  but  not  as  the number  of  transmitters
increases.  Some scale well as the number of transmitters increases, but not
as  the amount  of traffic  increases.   Some scale  well as  the amount  of
traffic  increases, but not  as the  number of  groups increases.   Some are
optimal in that every packet follows  an optimal route, but at the same time
sub-optimal  in the  amount of  state kept  in the  network core.   Some are
optimized for dynamic  join/prune operations, some not.  I'd  think that this
sort of thing needs to be discussed carefully in a requirements document.


Eric> 8. It is not clear to me whether these "requirements" rule out (or are
Eric> intended to rule out) the use of bidirectional multicast trees.

Adrian> Do you  believe we should  add a section outlining  the requirements
Adrian> for bidirectional  multicast trees? Do  you think they  are required
Adrian> for TE or is TE a way of supporting them? 

I  think the  requirements  document needs  to  take one  of two  positions.
Either (a)  it is necessary  to apply  TE to bidir  trees, and here  are the
requirements, or  else (b) it is not  necessary to apply TE  to bidir trees,
and here is why not.

>> 9. There  is  mention of  using  RSVP-TE multicast  LSPs  to  carry layer  2
>> traffic, apparently without a PWE3 encapsulation.  This might be taken to
>> infringe upon PWE3's charter.

Adrian> Well, the text  only floats some options and  certainly doesn't tell
Adrian> anyone that they have to use this facility.

I would suggest  deleting the suggestions on how multicast  TE might be used
to solve VPN or PWE3 problems.   These suggestions tend to make multicast TE
look like a solution in search of a problem.  

On the inter-AS requirements, from the draft: 

         P2MP TE solutions SHOULD support multi-area/AS P2MP LSPs. 

         The precise  requirements in support of multi-area/AS  P2MP LSPs is
         out of the  scope of this document. It is  expected that a separate
         document will cover this requirement.

Adrian> This last point reflects exactly  your concern, and I agree with you
Adrian> whole-heartedly.  That is why we asked in Seoul and got agreement to
Adrian> defer such a complex matter for a future requirements statement once
Adrian> there is more experience with both P2MP and inter-area/AS TE. 

How do  we know that  a solution designed  to the current  requirements will
meet those future requirements?  Especially given the difficulties that have
been encountered in extending both TE and multicast over multiple providers,
why do we think that the RSVP-TE solution will meet this requirement?

Eric> So I think  the document needs considerable additional  work before we
Eric> can consider advancing it.

Adrian> Can you help us narrow it down? 

Gee, I thought I had. 

Insofar as these requirements lead toward a solution which is very different
than existing multicast paradigms, these differences should be addressed and
justified. 

I don't  see any reason  why multicast TE  would not be expected  to coexist
with and  interwork with non-TE  multicast, but I  don't see how  that would
work with a TE solution that meets these requirements. 

Each of  the various capabilities that  TE provides should  be discussed, to
see the requirements that each such capability places on multicast. 

Insofar as  the requirements  tend to lead  toward one solution  rather than
another, the requirements need to have some justification.