The MPLS WG Archive

[Matthew Finlayson <Matthew.Finlayson@dataconnection.com>]

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: matthew.finlayson@dataconnection.com 
Web: http://www.dataconnection.com  

> -----Original Message-----
> From: mpls-bounces@lists.ietf.org 
> [mailto:mpls-bounces@lists.ietf.org]On Behalf Of 
> seisho-goo@mail.goo.ne.jp
> Sent: 22 July 2004 11:50
> To: mpls@ietf.org
> Cc: swallow@cissco.com; jeanlouis.leroux@francetelecom.com; 
> Tellabs - Andrew Malis; jpv@cisco.com; 
> dimitri.papadimitriou@alcatel.be
> 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
> mpls@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/mpls
> 

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