Subject: wg last call on draft-ietf-mpls-p2mp-requirement-02.txt

From: Loa Andersson <[email-masked]>
Date: Tue, 30 Mar 2004 18:53:51 +0200

WG,

this mails initiates a working group last call on

draft-ietf-mpls-p2mp-requirement-02.txt

The document has been updated as suggested in Seoul.

Comments to the working group mail list and the working group chairs.

The last call end April 16.

/Loa and George

PS from Loa

I've one immediate point myself, in the header of the document
says "Standards Track", my take is that it should be "Informational",
but I'm prepared to hear comments on that also. Becasue of this
I'm not stting whether the doument is for Standards track or not.

-- 

Loa Andersson

mobile +46 739 81 21 64

---

From: Eric Rosen <[email-masked]>
Date: Thu, 01 Apr 2004 13:16:01 -0500

I do not think this document should be advanced to RFC status in its current
form, even as Informational.  I think there are a number of problems: 

1. Basically what this document says  is "obviously we need a solution which
   provides traffic engineered multicast  distribution trees, and we require
   that  the  solution  be  RSVP-TE  extensions  for  setting  up  multicast
   distribution trees". 

   The problem to which this is a solution is not very well characterized or
   explored,  so  it  is hard  to  judge  from  this document  whether  this
   particular solution is  the best one.  There is  no serious consideration
   of  alternatives,  so  we  don't  know really  know  why  one  particular
   solution should be required over another.  In any event, the requirements
   should  be general enough  so that  we can  compare various  solutions to
   them.  If  the requirement is "use  RSVP-TE", it's hard  to compare other
   solutions against it. 

   The solution being  required might be the best  solution to some problem,
   but one really can't tell from this document. 

2. The document  attempts to exhibit the  required solution as  being a good
   solution for a variety of problems being considered by other WGs, such as
   L2VPN,  L3VPN, and  PWE3.   However, the  solutions  which this  document
   sketches out are not fully thought out, and fail to consider a variety of
   thorny issues.  For example:

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

   - The suggestion  to use this solution  for VPN multicast  seems to clash
     with  existing  proposals for  VPN  multicast,  but  this is  not  even
     considered. 

   Frankly, if we are looking for requirements that apply to L2VPN and L3VPN
   problems,  we should  be getting  the  requirements from  those WGs,  not
   telling those WGs that they are required to use a particular solution.

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

4. There  is  a  "requirement" that  it  be  possible  to set  up  multicast
   distribution trees without using multicast routing protocols.  Presumably
   the  assumption is  that setting  up  the distribution  trees is  greatly
   simplified if multicast routing is not  used.  While this may be true, it
   certainly needs  to be argued  in more detail.   I think we also  need to
   understand better  whether TE multicast trees  can be mixed  in a network
   with non-TE multicast trees.

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.

6. The requirement that RSVP be enhanced so that it can add/remove receivers
   dynamically raises  the question of  whether too much multicast  stuff is
   being moved  into RSVP.   Do we need  to invent new  multicast join/prune
   mechanisms?  What's wrong with the ones we already have?

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

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

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. 

10. It is blithely stated that  RSVP-TE multicast allows for the creation of
   inter-AS  multicast distribution  trees.   Since inter-AS  considerations
   have proven to be  quite thorny for both multicast and TE,  it is hard to
   imagine   that   combining  multicast   with   TE   makes  the   inter-AS
   considerations any simpler. 

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

By the  way, these  comments should  not be interpreted  as an  objection to
extending RSVP-TE  to support  multicast traffic engineering.   The comments
are directed  specifically at the particular document  under discussion, and
are not meant to favor or disfavor any particular solution.

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 1 Apr 2004 23:52:37 +0100

Hi Eric,

We certainly welcome your detailed review.

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

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

Further comment in line.

>    but one really can't tell from this document.

As per the note at the head of the email.
The problem that is addressed is as specified in the title of the document.

>      that would  be violated  unless unicast packets  were also sent  on the

Is this problem not identical with parallel unicast LSPs?

>    telling those WGs that they are required to use a particular solution.

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

>    the same solution in both cases.

Well, you know we differ on this subject slightly :-)
It is my understanding that the requirement comes from the ADs.

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

So, yes, a value judgement could be made about the complexity introduced to MPLS by
harmonizing with GMPLS.

>    with non-TE multicast trees.

An interesting question.
One might consider extending a multicast routing protocol to support TE, but I suspect
this may be quite a complex problem.

Why is it not enough to allow the TEDB at the ingress (or offline) to be processed to
derive the multicast distribution tree? This is, after all, a TE (explicitly routed)
solution not one of hop-by-hop forwarding.

>    traffic engineering of those trees.

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

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

>    mechanisms?  What's wrong with the ones we already have?

Nothing.
No mention is made of how the ingress discovers who is in a destination set when it builds
a multicast distribution tree and uses that to signal a P2MP LSP for TE purposes.
All that is stated is that receivers are expected to come and go. Consequent on this if
the requirement that it should be possible to add and remove receivers from the LSP.

>    resource is being used suboptimally or inefficiently.

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

If I search for "optimal" I find...
Section 1 - there is a reasonable statement about what is found to be suboptimal
Section 3.1 - the subsequent sentence gives a statement about what is required (but this
could be clarified).
Section 3.1 (2nd usage) - the subsequent sentence gives a clear description
Section 5.8 - this usage is deliberately vague since it refers to reoptimization as
described in section 2.5 of RFC3209

If I search for "efficient" I find...
Section 1 - "efficient" here contrasts with the previous paragraph. This could be clearer
especially as such a bold statement is made.
Section 1 (2nd usage) - I think this is clear in the context of the previous text, but
there would be no harm in explaining the word in the context of packet or data
replication.
Section 3.1 - Here is a good example of "efficient resource optimization" with no further
details. To some extent, this is using the terminology as used in section 2.2 of RFC3209,
but we could probably set out a bit more explicitly what we mean by a network resource.
Section 3.1 (2nd usage) - as section 1 2nd usage
Section 3.2 - I think be this point we will have established what is meant in this context

>    intended to rule out) the use of bidirectional multicast trees.

MPLS LSPs are unicast. GMPLS supports bidirectional LSPs.
Section 5.16 states...
   Finally, note that bi-directional TE LSPs are not applicable to
   multicast traffic. Although many leaf nodes may be considered as
   senders in a multicast group, a P2MP TE LSP models a single
   distribution tree from a sender to multiple recipients. If such
   a tree were made bi-directional it would be a multipoint-to-point
   tree in the reverse direction.

Thus, if you want to model bidirectional multicast trees you would be required to set up
multiple LSPs.

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

>    infringe upon PWE3's charter.

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

No intent to treat on anyone's shadow. If this infringes then I'm sure we'd happily delete
the text. Alternatively, we would happily be corrected if the suggestions are wrong or
need refinement - and especially if additional requirements are imposed by the support of
this function.

>    considerations any simpler.

Blithe? I trust not. I rarely make jokes in IDs and I certainly couldn't be described as
sprightly.

Actually, I don't find anything that says "that  RSVP-TE multicast allows for the creation
of inter-AS  multicast distribution  trees."

I do find...
Section 4.1
   Note that a P2MP TE LSP can be established over multiple areas/ASs
   and that the egress LSRs may deliver data into an IP multicast
   network.
I agree that this should be toned down to something like...
   Note that the egress LSRs of a P2MP TE LSP may deliver data into IP
   multicast networks. There is also a long-term requirement to support
   P2MP TE LSPs that cross area/AS boundaries.

Section 5.3
   Note that a P2MP TE LSP can be established over multiple areas/ASs
   and that the egress LSRs may deliver data into an IP multicast
   network.
A true, but rather skimpy statement. Could use some flesh, but given that multi-area/AS is
largely out of scope (see below) I'm not sure that we should add to it except to refer to
section 5.12.

and finally
5.12 Multi-Area/AS LSP

   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.

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

> So I  think the  document needs considerable  additional work before we can

Can you help us narrow it down?
Some of the points you raise need some editorial attention (as is typical in last call).
Other points may be sticking points for you. With my explanations/comments in place, can
you tell us which these are.

> are not meant to favor or disfavor any particular solution.

Thanks again for your thorough review of the document.

Cheers,
Adrian

---

From: Eric Rosen <[email-masked]>
Date: Mon, 05 Apr 2004 15:52:11 -0400

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.

>> 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.

>> 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: 

         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.