The MPLS WG Archive

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

FYI GenArt review of this I-D.
Adrian
----- Original Message ----- 
From: "Harald Tveit Alvestrand" <harald@alvestrand.no>
To: <gen-art@ietf.org>
Cc: <yasukawa.seisho@lab.ntt.co.jp>; <dimitri.papadimitriou@alcatel.be>;
<jpv@cisco.com>; <y.kamite@ntt.com>; <rahul@juniper.net>;
<alan.kullberg@motorola.com>; <adrian@olddog.co.uk>;
<mjork@quarrytech.com>; <andy.malis@tellabs.com>;
<jeanlouis.leroux@francetelecom.com>; "Alex Zinin" <zinin@psg.com>; "Bill
Fenner" <fenner@research.att.com>; <loa@pi.se>; <swallow@cisco.com>
Sent: Tuesday, November 22, 2005 1:32 PM
Subject: Gen-ART review of draft-ietf-mpls-p2mp-sig-requirement-03

Document: draft-ietf-mpls-p2mp-sig-requirement-03.txt
Reviewer: Harald Alvestrand
Date: Nov 22, 2005
Summary: Not ready for publication. Fixable.

(Impressively long authors' section!)

This is not an unreasonable document. However, I cannot recommend that it 
be published as-is.

The chief reason is that it does not properly define its target mission. 
For a document that is a requirements document for point-to-multipoint 
signalling, it strangely never defines what a point-to-multipoint service 
is.

>From context, it appears to be an unidirectional service capable of 
delivering a signal (a lightstream, bitstream or packet stream?) to 
multiple destinations. But it never discusses the metric that distinguish 
such a service from a P2P service - namely, whether or not there is a 
requirement for a consistent service to all destinations, or whether the 
consistency is part of the quality constraints that the solution has to 
allow explicit engineering for.

The control model of the service is also unclear.

>From context, it appears that one envisions that recipients can join and 
leave the tree while it's running; it's not clear whether the requirement 
is like that for a P2P path, where establishment always involves the 
head-end of the path, or whether a reasonable solution to the requirements 
can allow grafting and pruning down the tree without the head-end being 
involved (as happens in the "traditional IP multicast" service).

Section 4.20 (on GMPLS) is a surprise. While the rest of the document has 
been carefully phrased in technology-avoiding language (although concepts 
that I think of as RSVP-TE shine through on a regular basis), this section 
blatantly specifies specific RSVP-TE objects and features that "have to be" 
supported. This seems out of place.

The document's security section is inadequate. For a requirements document, 
I expect the security section to state the security requirements for a 
solution - in this case, these are likely to be very similar to those for 
P2P signalling, which (if I understand it correctly) involve identifying 
the LSRs to each other, and validating that the requester of service has 
the right to request service (which requires head-end identification to all 
downstream nodes in some fashion).

In the P2MP context, I would also expect requirements on the listeners - 
whether or not the head-end is required to be able to identify all egress 
points seems like a security issue to me.

I'm also unhappy with the clarity of the writing in a number of places - 
I'll follow up with another message containing a marked-up copy of the 
draft.

Hope this is helpful.

ATT01060.dat

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