The MPLS WG Archive

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

Hi Matthew,

 

Thanks for reading the draft and for sending your comments.

 

See in-line for some thoughts.

 

Cheers,

Adrian

 

> I have reviewed this document and, although I agreed with many of the
> technical arguments, I found it quite difficult to understand some of the
> context behind the points that the earlier half of the document was trying
> to make.  It also seemed to half-address some questions that I thought were
> explictly out of scope for the document.  This might mean that some readers
> didn't make it as far as section 5 (which I thought set out the actual
> requirements very clearly).
>
> Much of my confusion was over the split in the document between scope,
> assumptions and requirements, and I thought it might be helpful to provide
> some comments (which are almost entirely editorial).
>
> Hopefully they will be of some value to you.  I'd be happy to talk about
> this further or help in any way if you feel it would be useful.
>
> Regards,
>
> Matthew.
> ---
>
> "1. Introduction"
>
> It seemed to me that the "Introduction" section, rather than setting out the
> background to the document and the scope and assumptions intended for it,
> attempts instead to provide a summary / management overview of the later
> content. 

 

Are you suggesting to remove the summary / management overview?

 

The authors are working on a new revision of the draft and this includes considerably more background material especially related to the basis of MPLS TE. We will surely welcome your comments when you see this to let us know whether this addresses you point.

 

> My understanding from earlier discussions on the mailing list was that in
> this document you do not intend to justify why P2MP MPLS TE is _the_ correct
> or required solution to any particular problem/application.  Instead, you
> intend to start from the assumption that P2MP TE is one (among several)
> valid approaches to solving a number of problems and to go on to set out the
> detailed requirements for this approach. 

 

You are right: the intent of the application scenarios is to give some context to the P2MP MPLS TE requirements from an application perspective, but not to dictate that P2MP MPLS TE is necessarily used to solve the application requirements.

 

The text in 03 tries to make this clear.

In the Abstract...

    There is no intent to either specify solution specific details in
    this document or application specific requirements.
In the Introduction...

    It is intended that solutions that specify procedures for
    P2MP TE LSP setup satisfy these requirements. There is no intent to
    either specify solution specific details in this document or
    application specific requirements.
In section 4...

    The purpose of this section is not to mandate how P2MP TE LSPs must
    be used in certain application scenarios. Rather it is to illustrate
    some of the potential application scenarios so as to highlight the
    features and functions that any P2MP solution must provide in order
    to be of wide use and applicability. This section is not meant to be
    exhaustive, and P2MP is not limited to the described applications.

> If this is true, it would be helpful to state this up-front, so that
> supporters of alternative approaches do not read this document as a fait
> accompli that P2MP MPLS TE is the anointed solution.  The Introduction (or
> Abstract) would appear to be the appropriate place for this disclaimer.

 

I guess we'd be interested if you could supply a disclaimer that is stronger than the text I have quoted.

> Instead the current Introduction states that the collection of problems
> "clearly motivates enhancements of the base MPLS-TE tool box in order to
> support P2MP applications" - which in my reading leans towards suggesting
> that this is the only sensible approach.

 

That is a peculiar reading, IMHO.

The quote you give is intended to mean that the motivation for the adding P2MP to the MPLS TE set of features and functions is the support of P2MP applications. It seems clear to me that one would not add P2MP support to MPLS TE if

- there was already support in place within MPLS TE

- there were no P2MP applications.

The text DOES NOT say that this is the only sensible approach, and I would expect people who wish to propose other approaches to do so.

 

At this point it seems to me that you are questioning the requirements for the requirements. But that is out of scope for this document. This document targets the specific MPLS WG charter item to add P2MP support to MPLS TE.

> A number of the requirements later described in the document are asserted in
> the Introduction without explanation.  There are also some items whose
> relevance in the introduction is not clear.  These include the following.
>
> -  The need to support non-packet-switched networks (including GMPLS).  It's
> not entirely clear if this is a statement of the specified scope of the
> document (imposed by the ADs?) or a desirable requirement.  If the former,
> it would be good to clarify, if the latter it could probably be deferred to
> later in the document.

 

<ccamp-co-chair-hat>

1. Please note that GMPLS includes PCS

2. There is a strong requirement for P2MP in non-PCS networks

3. It is crucial that any extensions to MPLS TE in support of P2MP

   are applicable to GMPLS with the caveat that:

   - P2MP MPLS TE solutions should not be significantly encumbered

     by their applicability to GMPLS. (FWIW, part way through the

     solutions debate, this does not appear to be an issue.)

4. The focus of the MPLS WG on MPLS-TE and GMPLS P2MP extensions

   - was agreed by the four co-chairs and the ADs so that only one

     WG would work in the problem space

   - is mentioned in the MPLS WG charter.

</ccamp-co-chair-hat>

 

Thus it is both mandated and desirable. What would be the value of deferring it?

 

> -  The desire to avoid mandating use of a multicast routing protocol in the
> network core.  Since this is already discussed later, it's not clear why
> this paragraph needs to be here.

 

Sure. And is there any reason why it doesn't need to be there (except for brevity?). It seems to me that this is a significant point (there has certainly been a lot of debate) and that bringing it out early, rather than burying it in a later section, is helpful. Note that the intention here is NOT to say that a multicast routing protocol must not be used, but it does say that the SIGNALING solution must be capable of operating in separation from the routing plane. The construction of the TED for P2MP MPLS TE is, therefore, deliberately out of scope.

 

> -    The discussion of mapping P2MP flows onto P2P LSPs.  Since this is a
> potential solution to the P2MP TE problems which doesn't meet the
> requirements (for optimality and scalability) that you state later on, it
> might make more sense to delay discussion of this until later (possibly in
> an explicit section looking at potential approaches which don't meet the
> requirements?).  The same remark may apply to the discussion of this option
> again in section 3.1 and the discussion of DiffServ, again in section 3.1.

 

Perhaps.

The intent here is to demonstrate that P2MP TE cannot readily be achieved using P2P MPLS TE. This is surely relevant in the introduction as it is background to the document and helps clarify the scope.

 

> -    The mention of the requirement to "add/remove receivers to/from an
> existing P2MP TE LSP".  Again, this requirement is discussed admirably (in
> detail) later on.  It's not clear why it needs to be presaged in the
> introduction.

 

The authors felt it to be a basic unit of P2MP TE that might not be obvious. Note that from a solutions point of view, this little requirement adds a lot of complexity.

 

I would have no particular objection to removing this text, although I don't see much added value.

> "3.1 Motivation"
>
> Again, it's not quite clear whether this section is trying to justify why
> P2MP MPLS TE is _the_ appropriate approach, whether Multicast TE itself is
> required, or to put the potential applications in context.  If the last,
> might it make sense to merge this with section 4?  If one of the first two,
> I had understood that these were out of scope for this document.

 

I think it says:

- There are applications that do multicast

- P2MP TE may be needed

- IP multicast is great but doesn't do TE

- TE is great, and one way to do it is MPLS

- Trying to do P2MP over P2P MPLS TE is inefficient

- QED.

 

Agree that proof of the second point (perhaps any of these points) is out of scope. But background is useful, isn't it?

> "3.2 Requirements Overview"
>
> General comment - I'm not quite sure what this section is trying to achieve
> in comparison to section 5.  At the very least, it seems far less easy to
> understand than section 5.  In the latter, the requirements are very clearly
> split up and justified one by one.  Here, they are somewhat munged together.
> Furthermore, some of them overlap with requirements covered later in more
> detail in section 5 and some appear only in this section.  Would it be
> possible to either make Section 3.2 clearer, or to merge it with section 5?

 

Certainly.

This seems like a good point in the document to give a brief overview of the requirements. We will try to clarify it. Perhaps we'll make it more of a list.

> "a solution SHOULD satisfy them without requiring that a multicast routing
> protocol"  -  I feel this needs some justification.  I suspect the reasoning
> is that this is because
>
> (1)  there is a belief that it would require unnecessary occupancy and
> processing overhead in many circumstances to require a multicast routing
> protocol (particularly when the likelihood is that the layout of the core
> network will change relatively rarely)

 

Interesting point. Do you believe that multicast routing protocols would cause an unnecessary occupancy and processing overhead in this context?

> (2)  a missing part of the problem statement is that there is a desire to
> allow Service Providers to easily deploy multicast applications over their
> backbone networks without requiring them to add a whole new multicast
> routing protocol (with the associated management and ramp-up overheads).

 

This is certainly a good point. Do you believe that SPs have this desire?

 

I think that it might be clearer if we simply said that the construction of the TED used to compute the paths of the P2MP TE LSPs is out of scope. That would probably have the same effect.

> "4.2 P2MP TE backbone network for IP multicast network"
>
> It's not clear to me that the discussion of the need to add/remove egress
> LSRs to/from the P2MP MPLS TE LSP and the discussion of recommendation for a
> "message exchange mechanism" belong in this section, which is supposed to be
> about applications.  Surely it would be better for the relevant later
> section (5.4) to refer back to this application as justification for the
> requirement.

 

Right.

We can clean this up.

 

> "5. Detailed requirements for P2MP TE extensions"
>
> It might be good if more of the requirements included some explanation of
> _why_ they are a requirement - possibly with links back to the sample
> applications.

 

Can't provide the link back to the sample applications because (if you recall) these applications are just examples of things you might do with P2MP MPLS TE, not things you have to do with P2MP TE. Thus they give context, but don't provide requirements. As such, the requirements stand on their own.

 

Are there any specific requirements (sub-sections of section 5) that you feel would benefit from more detailed justification?

 

 

_______________________________________________
mpls mailing list
mpls@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls