The MPLS WG Archive

["Seisho Yasukawa" <seisho-yasukawa@apricot.ocn.ne.jp>]

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

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

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.

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

Yes, you are right.

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

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.

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

As I explained above, we are not saying 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 author think this is necessary requirement.

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

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

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

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

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.

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

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.


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

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.


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

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.


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

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.



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