The MPLS WG Archive

["Adrian Farrel" <adrian@olddog.co.uk>]

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.

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

As per the note at the head of the email.
The problem that is addressed is as specified in the title of the 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.

Is this problem not identical with parallel unicast LSPs?

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

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.

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

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.

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

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.

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

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.

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

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.

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

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

> 8. It  is not  clear to  me whether  these "requirements"  rule out  (or are
>    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?

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

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.

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

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
> consider advancing it.

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.

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

Thanks again for your thorough review of the document.

Cheers,
Adrian