Tom,
I'm acutely aware that I owe you a response to the procedural
issues on this, more so since the questions is relevant to
all the mpls-tp drafts currently being progressed to become
RFCs beginning of June. The mpls working group chairs to a
not insignificant extent share your concerns.
1. The June deadline is there because the ITU-T SG15 has a
plenary meeting two first weeks of June. At that meeting
ITU-T intends to consent the first of the MPLS-TP Recommendations.
ITU-T can only consent Recommendations at study group
pleanry meeting and the date is therefore extremely important
for them.
IETF and ITU-T have agreed that the ITU-T Recommendations to
the largest extent possible shall reference the IETF RFCs
and not develop a parallel standard.
2. The are some unusual aspects to the reviews of mpls-tp documents,
in fact it might actually be that these documents are the most
extensively review documents that have been developed by
the mpls wg for a long time.
However the vehicles for these reviews are somewhat "unusual";
first we have a mailing list explicitly to drive mpls-tp
documents (mpls-tp(_at_)ietf(_dot_)org), second part of the review process
is done by liaisons to and from the SG15 in the ITU-T, third
partly the review and discussion of these documents have taken
place on weekly conference calls.
3. "Normally" the IETF process we use to progress documents could
be seen as a step-by-step process, i.e. first we do A and then B
then C ... then Z.
When we discussed how to make it possible to have documents done
by June it was pointed out to us by Russ Housely that we could
speed things up by doing things in parallel.
Due to the "unusual" elements in the review in the review process
we felt it necessary to run a "final" wg last call in order to
make it possible to discuss the comments received e.g. by liaison
or phone conference on the mailing lists. But we could speed things
up by sending the request for publication at the same time as we
as we started the "final" working group lst call. We also agreed with
the Routing Area ADs to start the IETF last call as soon as they
received the request for publication. This means that we needed
to have the AD review early and that the comments from that review
would be taken care of as part of the resolution of comments from
the "final" working group last call.
This is not how e.g. the mpls working group been running the process,
but it has been done earlier for other working groups.
4. We are currently evaluating whether this is a successful experiment
that helps us to move faster, while maintaining document quality,
or if it means that things are moving too fast.
/Loa
On 2010-04-17 20:02, Tom.Petch wrote:
I have reservations about the readiness of this I-D.
The technical content looks ok, but the process by which it has been arrived at
gives me pause.
It is a crucial document for MPLS-TP, perhaps the most important after the
requirements ones, like, say, RFC3411 for SNMP.
This Last Call is on -11 which shows substantial changes from -10 (eg in S3.4)
and, despite assiduously tracking the list, I am unsure where these changes have
come from. I do not see them discussed, I do not see any consensus declared for
(or against) them nor is there any explanation in the I-D itself.
The topics covered include some that have provoked considerable debate, over the
past two years, involving hundreds of e-mails, including a sequence where
several exceeded one Megabyte in size each. Yet, again, I have not seen any
consensus declared on the list on most of these topics.
The topics I have in mind include; what is MPLS-TP? Is it a layer network, in
the G.805/G.800 sense, a set of such layers or what? (and saying it is a Profile
has no meaning until the word 'Profile' has been defined in this context). S3.1
of this I-D, like its predecessor, talks variously of 'MPLS-TP network', MPLS-TP
layer network' and 'MPLS-TP server' which I find less than clear.
How does MPLS-TP relate to MPLS? My sense is that it is a subset of a superset,
a superset because MPLS lacks, eg, adequate OAM, a subset to make it as simple
as possible but not simpler. (Again, simply saying 'Profile' is really only
tautology.
Are features in or out? ECMP, NNI, PHP, multiple QoS? I think that some of
these are still being debated as the Working Group Last Call proceeds in
parallel with this Last Call.
S-bit; how many allowed in the stack; I think that the consensus is one, but
then what does it mean, and what happens to the meaning it would have had when
there were more than one?
MIP; where and how many?
It is not that a view could not be formed on some of these issues from reading
the I-D, but where does that view come from? Not, as far as I can see, from any
IETF WG list.
Tom Petch
----- Original Message -----
From: "The IESG"<iesg-secretary(_at_)ietf(_dot_)org>
To: "IETF-Announce"<ietf-announce(_at_)ietf(_dot_)org>
Cc:<mpls(_at_)ietf(_dot_)org>
Sent: Wednesday, April 07, 2010 4:33 PM
Subject: [mpls] Last Call: draft-ietf-mpls-tp-framework (A Framework forMPLS in
Transport Networks) to Informational RFC
The IESG has received a request from the Multiprotocol Label Switching WG
(mpls) to consider the following document:
- 'A Framework for MPLS in Transport Networks '
<draft-ietf-mpls-tp-framework-11.txt> as an Informational RFC
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf(_at_)ietf(_dot_)org mailing lists by 2010-04-21. Exceptionally,
comments may be sent to iesg(_at_)ietf(_dot_)org instead. In either case, please
retain the beginning of the Subject line to allow automated sorting.
The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-framework-11.txt
IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=18027&rf
c_flag=0
_______________________________________________
mpls mailing list
mpls(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/mpls
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
--
Loa Andersson email:
loa(_dot_)andersson(_at_)ericsson(_dot_)com
Sr Strategy and Standards Manager loa(_at_)pi(_dot_)nu
Ericsson Inc phone: +46 10 717 52 13
+46 767 72 92 13
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf