Subject: RE: [mpls] draft-ietf-mpls-p2mp-requirement-03.txt

From: Matthew Finlayson <[email-masked]>
Date: Fri, 3 Sep 2004 14:31:24 +0100

Seisho,

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.  

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.  

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

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.

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

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

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

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

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

"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)

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

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

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

---
Matthew Finlayson 
VP development and requirements
Network Protocols Group 
Data Connection Ltd 
Tel: +44 20 8366 1177 
Fax: +44 20 8363 1039 
Email: [email-masked] 
Web: http://www.dataconnection.com  

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]On Behalf Of 
> [email-masked]
> Sent: 22 July 2004 11:50
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; 
> Tellabs - Andrew Malis; [email-masked]; 
> [email-masked]
> Subject: [mpls] draft-ietf-mpls-p2mp-requirement-03.txt
> 
> 
> Hi,
> 
> We have updated draft-ietf-mpls-p2mp-requirement to attempt
> to address the comments made during Working Group last call.
> 
> The biggest change we have made is to de-emphasise RSVP-TE
> as the signaling protocol used to establish P2MP TE LSPs. 
> 
> We have also made some smaller editorial changes to ensure that
> the draft does not imply that the applications mentions MUST 
> be addressed through P2MP TE MPLS - the new text is meant to say
> that these applications are only illustrative examples of things
> you might choose to use P2MP MPLS TE for.
> 
> We are still having off-line discussions about whether the
> changes made actually satisfy the concerns raised during
> last call, but in the mean time, we thought that everyone would
> like to see the new version of the draft.
> 
> We have also found several holes in the requirements as we
> attempted to move forward with early versions of solutions drafts.
> 
> We are working to produce a -04 version. Our plan is to have this
> version completed by mid-August.
> 
> Some of these additions will necessitate discussion, and we will be
> sending some questions to the mailing list over the next month.
> 
> Regards,
> Seisho
> 
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mpls
> 

_______________________________________________
mpls mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mpls

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 6 Sep 2004 13:07:05 +0100

Hi Matthew,

Thanks for reading the draft and for sending your comments.

See in-line for some thoughts.

Cheers,
Adrian

> attempts instead to provide a summary / management overview of the later

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.

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

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

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

> it would be good to clarify, if the latter it could probably be deferred to

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

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

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

> detail) later on.  It's not clear why it needs to be presaged in the

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.

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

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

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

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

> section (5.4) to refer back to this application as justification for the

Right.
We can clean this up.

> _why_ they are a requirement - possibly with links back to the sample

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?

---

From: "Seisho Yasukawa" <[email-masked]>
Date: Tue, 7 Sep 2004 04:30:19 +0900

Hi Matthew,

Thank you for reviewing the document and agreeing with many of
our technical arguments.
At first, I would like to let you know that we are now revising the
requirement document and going to submit new revision (04) to
address some new issues which we found during P2MP solution
development.
Because we will clarify our scope and assumption more explicitly
in addition to addressing new requirements, I assume new revision
would eliminate much of your confusion.

Please find my answers and comments belows.

Regards,
Seisho

> attempts instead to provide a summary / management overview of the later

Please note that the "Introduction" section set out clear background that
some P2MP application need MPLS TE capabilities but current P2P MPLS TE
woud not benefit P2MP application because setting up multiple P2P TE LSPs
from ingress LSR to multiple egress LSRs and replicating incoming packets to
the
all the P2P TE LSPs at the ingress is not a scalable solution.
So we have clear assumption that enhancing current P2P TE tool to have
P2MP TE capabilities will be a promissing solution to this problem (P2P TE
meet the problem; lack of scalability when it transmit P2MP application).
And we think our scope should be limited to enhancement of current P2P
TE tool and we should utilize current P2P TE mechanism
as much as possible because we should limit inventing new dedicated
TE mechanism such as FRR, DS-TE, interAS-TE etc.

> detailed requirements for this approach.

Yes, you are right.

> Abstract) would appear to be the appropriate place for this disclaimer.

Even though I am not sure that this document would be recognized as a
fait accoppli because, as I said above, our scope is very limitted to
enhance
P2MP capability of P2P TE tool considering some applicabilities, it is fine
for me to add appropriate disclaimer.
So I would appreciate it if you could give us some example.

> that this is the only sensible approach.

As I explained above, we are not saying that this is the only sensible
approach.

> it would be good to clarify, if the latter it could probably be deferred
to

The author think this is necessary requirement.

> this paragraph needs to be here.

We are clarifying our scope. We would like to address requirements for P2MP
in the document.

> requirements?).

As I explained above, we would like to clarify background of this work
with this example. Our major motivation is to resolve scalability/optimality
concern of P2P TE. So I think we need this kind of background statement
in the introduction section as you suggested above.

> The same remark may apply to the discussion of this option

I understand your concern.
In my understanding, the intention to include this sentence is to clarify
scope
of requirement that solution to have capability to add/remove receivers
to/from
an existing P2MP TE LSP.
So it might be better to modify the text so that one would not confuse this
text
as exact requirement which is discussed later on.

> possible to either make Section 3.2 clearer, or to merge it with section
5?

The intention of this section is to provide overview of requirement with
a sample P2MP TE LSP for easy understanding.
We could make section 3.2. more clearer.

> routing protocol (with the associated management and ramp-up overheads).

I think this is good point.
I suppose a lot of sevice providers have this kind of desire and they need
some P2MP TE capabilities too.

> section (5.4) to refer back to this application as justification for the

I understand your point.
Considering the fact this section only illustrate some of the potential
application
scenarios, it might be better to eliminate the text or word which would
imply
some requirements, especially when these belong to application specific
requirements.

> _why_ they are a requirement - possibly with links back to the sample

I would appreciate it if you could feedback which section you think
need more explanation.
I think we should not link back to the sample applications because
this document should not address aplication specific requirements
and linking back would introduce this kind of misunderstanding.