Framework and Requirements for Layer 1 Virtual Private Networks
draft-ietf-l1vpn-framework-05

[Ballot comment]
These comments are for the updated version, -05

ASCII art in 7.1,  7.2, 7.3.3, 7.3.4 seems to have been goofed up a bit.

Section 12.2:  "identify authenticated."

s/identify/identity

[Ballot comment]
I did not understand what the L1VPN working group was when it was
chartered.  As I begin to understand what it is about, I think L1VPN
may have been a very bad choice for a name.  I'd ask people to at
least think about whether calling the technology L1VPN will confuse
IETF participants enough that we should consider a change.  This is
very much just something I want people to think about.

[Ballot discuss]
First, and foremost, what is an L1VPN?  The document needs to answer
this question before the terminology section.  Currently The answer
should include a definition of layer 1 network that IETF participants
find not confusing.  I think a lot of participants have a definition
of the difference between L1 and L2 network from ethernet that does
not really apply here.

I think I sort of understand what an L1VPN is from talking to Ross and
reading the document, but I'm not sure I could explain it to someone
else and clearly explaining that concept is an absolute requirement
for this document.  I think of L1VPNs as a way to use GMPLS as a
control plane to set up connections over existing networks without
changing the data protocols. I guess GMPLS already does that; the
difference here is that you give each customer a virtual control
plane.
Whatever it is, please define it so we can all understand.


I think the usage of the term control plane in 10.2 is misleading.
The IETF is kind of sloppy with the control plane.  In most of this
document, control plane refers to the routing and signaling protocols
that are part of GMPLS and TE.  Section 10.2 talks about sharing the
provider's control plane to allow CE-CE control plane connectivity.
As best I can tell though, this is more talking about sharing the
provider's IP network over which the control plane runs.  If it is
talking about sharing the IP network, then make that clear and don't
conflate the network used to implement the control plane from the
control plane itself.  I understand a number of providers do run this
over a separate network.  However that's not inherent; one or more of
these networks may even be the internet.


I could not follow the diagrams in section 5 and 7 and I could not
follow the text without the diagrams.  Please caption the diagrams
well enough that a blind reviewer can follow the document.  I don't
ask for this lightly: this is the first time since joining the IESG
I've complained about diagrams I cannot read.


I'm concerned that section 12 is misleading to the security community.
It seems that when services like authentication, confidentiality and
integrity are discussed, you don't mean communications security
services like the IETF security community normally means.  For
example, I believe the document authors would consider physical
isolation of a line a way to get confidentiality service.  I'm
concerned that when reading the document, the security community may
have read their implied definitions into these terms.  I also don't
understand what is meant by the service contract phase of security--or
especially what is meant by authentication there.  I think we need to
make this section something that means the same thing to the L1VPN
working group and the security community.

[Ballot discuss]
The authentication security feature (Sec 12.2) says the entity
  must be authenticated to the provider (one-way authentication).
  Shouldn't mutual authentication be offered so that the provider
  is also authenticated to the customer?

  Expected text to resolve the above concern:

    The entity requesting the service to the provider MUST be
    identified and have its identify authenticated, and the provider
    providing the service MUST also be identified and have its
    identify authenticated.

[Ballot comment]
Sec 12.2 (authentication): There must be authentication as well as
  identification.  One cannot simply assert an identity; it must go
  with some proof that the asserted identity is appropriate.

  From Sean Turner's SecDir review:
  Sec 12.2 (confidentiality): s/retrieved/disclosed/

[Ballot discuss]
The authentication security feature (Sec 12.2) says the entity
  must be authenticated to the provider (one-way authentication).
  Shouldn't mutual authentication be offered so that the provider
  is also authenticated to the customer?

[Ballot discuss]
It seems rather obvious to me that some of the mechanisms defined for L1VPNs could be used for setting up of a traditional MPLS TE Tunnel just as well as for a lambda or a TDM slot. Further, particularly in the service models where the CE does not seem to have a view into the provider's core network (e.g., "Virtual Node Service Model") I don't see why a pseudowire could not be used, for example, if the provider so desired (perhaps depending upon the type of service level being requested a label vs. lambda might be provisioned). The document seems to avoid this rather obvious point, perhaps in hope of providing a clearer distinction between L1VPNs and L[2,3]VPNs. Avoiding the topic left me scratching my head more than if it was called out directly and stated as explicitly in or out of scope and why.

The service model of 7.1 seems to dismiss direct CE-PE communication (relegating it to indirect communication via management systems which are out of scope of the framework), while the document states in section 3.1.2:

"First, CE-PE control plane connectivity is essential, and CE-CE data plane connectivity is maintained by signaling mechanisms based on this control plane connectivity."

I think these statements conflict. Perhaps the entire service model in 7.1 should be declared out of scope of this WG (since there is really nothing for it to define in this case?).

Section 4.3.4 Why "Inter-SP" VPN rather than the more commonly used "Inter-AS" terminology used in L[2,3]VPN?

Section 5, the reference model does not seem to depict "C" routers/hosts, which are referred to earlier and later in the document as a potentially important part of the overall system.

Given that we are talking about an IP control plane from a CE, and perhaps even a C device, to a PE, is there worry about "behave" issues with respect to the possible presence of NATs or Firewalls?

[Ballot comment]
1. Section 11 - Manageability Considerations - 'In particular, MIB modules for GMPLS protocols and potential extensions MUST be supported.' It would have been useful to be more specific about the need for supplementary MIB modules or extentions of existing MIB modules - yes/no, if yes what managenent information they would carry.

2. Section 12 - Security Considerations

Confidentiality

    The information exchanged between the customer and the provider
    MUST NOT be retrieved by the third party.

better:

    The information exchanged between the customer and the provider
    MUST NOT be observable by a third party.

o Access control

    Access to the information contained in the provider network MUST be
    restricted to the authorized entity.

It would be good to emphasize in the text that the information that is refered here, although contained in the provider network may be about customer network and customers as well. I hope that this is the intent, anyway.

3. References

I find strange the fact that only RFC2119 is listed as a Normative Reference. True, this document targets Informational status, but it will become the requirements document to be used by other Standards track documents in l1vpn. As it is largely based on documents from ITU-T and GMPLS without which understanding the requirements would be impossible, I would rather see some of the documents included today in the Informational References clause moving to Normative

[Ballot comment]
1. Section 11 - Manageability Considerations - 'In particular, MIB modules for GMPLS protocols and potential extensions MUST be supported.' It would have been useful to be more specific about the need for supplementary MIB modules or extentions of existing MIB modules - yes/no, if yes what managenent information they would carry.

2. Section 12 - Security Considerations

Confidentiality

    The information exchanged between the customer and the provider
    MUST NOT be retrieved by the third party.

better:

    The information exchanged between the customer and the provider
    MUST NOT be observable by a third party.

o Access control

    Access to the information contained in the provider network MUST be
    restricted to the authorized entity.

It would be good to emphasize in the text that the information that is refered here, although contained in the provider network may be about customer network and customers as well. I hope that this is the intent, anyway.

3. References

I find strange the fact that only RFC2119 is listed as a Normative Reference. True, this document targets Informational status, but it will become the requirements document to be used by other Standards track documents in l1vpn. As it is largely based on documents from ITU-T and GMPLS without which understanding the requirements would

Proto write-up by Adrian Farrel

1. Have the chairs personally reviewed this version of the Internet
Draft (ID), and in particular, do they believe this ID is ready to
forward to the IESG for publication?

Yes.
Note that Tomonri is the editor and that Hamid is a co-author.
Adrian has taken responsiblity for sheparding this I-D.


2. Has the document had adequate review from both key WG members and
key non-WG members? Do you have any concerns about the depth or
breadth of the reviews that have been performed?

The document has had good review in and out of the WG.
In particular, an early version of this draft provided the background for the formation of the WG.

The document has had extensive review by SG13 of the ITU-T and lists some members of that organisation as co-authors. The last liaison of this document to the ITU-T notified them of the intention to hold a WG last call and solicited final review comments. None were forthcoming. (Note that relations with the appropriate Quesiton of SG13 are very cordial.)


3. Do you have concerns that the document needs more review from a
particular (broader) perspective (e.g., security, operational
complexity, someone familiar with AAA, etc.)?

I think everything necessary is already done.


4. Do you have any specific concerns/issues with this document that you
believe the ADs and/or IESG should be aware of? For example, perhaps you
are uncomfortable with certain parts of the document, or have concerns
whether there really is a need for it. In any event, if your issues have
been discussed in the WG and the WG has indicated it that it still
wishes to advance the document, detail those concerns in the
write-up.

No concerns.


5. How solid is the WG consensus behind this document? Does it represent
the strong concurrence of a few individuals, with others being silent,
or does the WG as a whole understand and agree with it?

WG agrees and is using this framework as the basis of its ongoing work.


6. Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email to the Responsible Area Director.

No


7. Have the chairs verified that the document adheres to all of the ID
Checklist items ?

The chairs have done their best, but we are poor mortals.


8. Is the document split into normative and informative references?
- Are there normative references to IDs, where the IDs are not also
ready for advancement or are otherwise in an unclear state? (note
here that the RFC editor will not publish an RFC with normative
references to IDs, it will delay publication until all such IDs are
also ready for publication as RFCs.)

Split is OK


9. What is the intended status of the document? (e.g., Proposed
Standard, Informational?)

Informational

For Standards Track and BCP documents, the IESG approval announcement
includes a write-up section...

Hoorah! Another Informational I-D.

Thanks,
Adrian

Routing Directorate Review by Dimitri Papadimitriou:

Generalities
------------


o) missing a good/crisp discussion on addressing such as for inst.
proposed in RFC 4031, Section 5.1, 5.2 and 5.3 (that would provide more
incentive for VPN membership, VPN membership information discovery, single
vs multi-SP VPN, etc.)


o) inter-SP L1VPNs are introduced in 3.1.3 and 4.3.4 but nowhere else in
the text further discussed in terms of requirements, impact, etc. authors
should decide to address such case consistently


Technical
---------


- Section 2: Virtual link, last sentence, if it does, does it correspond
to the classical TE link definition ? pls clarify


- Section 2: Virtual node, last sentence, which links is these sentence
referring to (external of internal to the virtual node) ? pls clarify


- Section 2: CE-device - PE-device


the former states: "A CE device does not have to have the capability to
switch at layer 1, but it must be capable of receiving a layer 1 signal
and either switching it or terminating it with adaptation."


the latter states: "PE device may be an Ethernet Private Line (EPL) type
of device, that maps Ethernet frames onto layer 1 connections."


either authors assume TDMoETH transport - doubtful in the present context
- or the latter PE functionality shall be removed


- Section 2: CE-device - PE-device - P device


CE device can be TDM, PE TDM, OXC, FXC, P device TDM, OXC, FXC => please
indicate that they follow the hierarchy defined in RFC 4206 TDM (TDM-SC) >
OXC (LSC) > FXC (FSC)


- Section 3.1.2: third para "one of the fundamental" => what ar the other
fundamental issues ?


- Section 3.1.2: third para, first sentence data plane vs control plane
connectivity => in this sentence control plane connectivity refers to
CE-PE or CE-CE ?


- Section 3.1.3: first para, UNI, detail positioning wrt RFC 4208 (in
part. Section 7); E-NNI, detail positioning wrt to L1VPN (section 3.1.2
tells "It is at the interface between CE and PE devices that the L1VPN
services is provided" - add ref. to RFC 4139 - now, more importantly the
latter opens the floor to inter-SP L1VPN (that only very briefly discussed
in this document)


- Section 3.1.3: fourth para, "... high level of service.." - what does
this means ? please clarify (low vs high level of service)


- Section 3.1.3: fourth para, introduces the term "control link" and
"dedicated/shared control link" either def. is provided in the text or in
the termino section (as data vs control link have different purposes &
properties)


- Section 4: three first paragraph, this should editorial normally but the
proposed text is too high level and at the end lacks the real motivations
for considering L1VPN operations as part of the GMPLS realm and the
motivations for standardizing L1VPN provisioning techniques using GMPLS;
in part. wrt to existing vendor proprietary methods - consider also
appropriate refs. L2/3 VPNs frameworks (RFC 4110), RFC 3945, etc.


- Section 4.1: availability, "meets the criteria" - which criteria ?


- Section 4.1: performance, if CE-PE link is TDM and network is OXC (LSC)
how performance parameters are translated to the CE ?


- Section 4.1: Dynamic sevices, soft-permanent connection are defined in
RFC 4139 (and corr. mechanisms in RFC 4208 and 4003) now what a "customer
controlled" soft-permanent connection means ?


- Section 4.1: states "For both service types, connections are
point-to-point, and can be permanent, soft-permanent, or switched." but
the description mentions that static service deals only with permanent
connections - pls clarify


- Section 4.1: "Note that the ITU-T allows the second categorization of
service type to embrace a variety of control plane types." worth provide a
mapping from IETF perspective - what does this sentence really means ? -


- Section 4.1.1: second para, what does prevent to apply "separate
policy", "restricted VPN membership distribution" for the first category ?


- Section 4.2.1: third para, refers to "sharing access to the L1 network"
are the CE-PE links (which is different from CE-CE and PE-PE sharing but
not explicited), authors to clarify the implications of sharing a TDM link
in case


- Section 4.2.1: last para, "... differentiated services..." worth
explaining what this means in the TDM context


- Section 4.2.2: second para, last sentence, is this property specific to
L1VPN or common to any domain service model (like the overlay)


- Section 4.3: first para, is this application specific to L1VPN (which
deals with CE-PE service) ? pls clarify - extend the applicability scope
of L1VPN is not necessarily recommended as overlapping with techniques
discussed as part of other WGs e.g. CCAMP


- Section 4.3.1 vs 4.3.2: what is the exact diff. between these models
(from reading 4.3.1 is about different data plane layers in the same
organisation while 4.3.2 in different organisation + sharing vs dedicated
connectivity and control plane functionality)


- Section 4.3.1: second para, "separating the control functions" between
which partners/entities ?


- Section 4.3.1: fourth para, link failures are common (as link resources
are shared among services), so how to distinguish them wrt to the set of
impacted services and perform "fault isolation"


- Section 4.3.1: fourth para, "resource view" what does this term means,
as it has a clear relationship with routing information exchange further
details are expected to ease understanding


- Section 4.3.3: second para "price changes" but the price of what ? the
whole last sentence is to be reviewed inlight with the feasibility of the
model suggesting that the second-tier provider is going to install
multiple links between a given CE and multiple PEs belonging to different
SPs


- Section 4.3.4: there are multiple implications when dealing with
inter-SP L1VPN, in terms SLS/SLA, contractual agreement, etc. some
discussion is available in RFC3809, Section 6 of RFC4031, Section 4 of
RFC4110


- Section 4.3.5: last para, mentions "... which leads to more efficient
bandwidth usage" add discussion on increasing complexity incurred to the
SP to operate the time dimension - add discussion on how to operate
simultaneous scheduled and non-scheduled L1VPN connections


- Section 4.3.6: is this model provided for completeness ? please clarify
what "CE-PE link" as "VPN connection" means - is this a CE-PE based L1VPN
model


- Section 5: first para, if CE = TDM and PE = OXC (LSC) how does this
represent in Fig. 5. and corr. description


- Section 5.1: RFC4176 provides a good basis for the management system
aspects, complementing this section with input from RFC4176 to better
describe management functionality


- Section 6.1: second para, last sentence, or "by extending the signaling
and routing protocols to allow them to identify the correct VPN." but in
this case disambuiguate per VPN information would result in processing
sig./routing messages


- Section 7: last para, last sentence, is it really over the customer i/f
or over the CE-PE control plane channel ? what is at the end the
relationship between the two ?


- Section 7.1: same comment as for Section 5.1, align/position with/wrt
the RFC4176 description will help to assess last sentence of last para
"... may or may not need ..."


- Section 7.1: last para, second sentence, SPC functionality already
described wrt signaling in RFC 4208 and 4003 or is there some specific not
addressed in these RFCs


- Section 7.2.1: second para, "... there no routing between ..." should be
clarified no routing neigbhor relationship, routing adj, information
exchange, etc.


- Section 7.2.1: second para, last sentence, what are the implications of
assigning public vs private addresses (as left as possible options)


- Section 7.2.1: third para, usage of overlay when the network is
represented as a single node (hose model) vs virtual node where the only
difference is that routing information exchange is possible makes use of
orthogonal/unequal criteria for this comparison e.g. what is the
difference then with the extended overlay model where routing information
is possible (per Section 7.3.1.)


- Section 7.2.1: last para, "Note that in addition, there may be
communication between customer management system(s) and provider
management system(s) in order to provide detailed monitoring, fault
information etc. to customers." how the communication channel is realized
? may it also use the CE-PE control channel ? or are these two separate
communication ? (in SDH for inst. the DCC channels can be used for both CP
and MP); is there a model dependancy (or not) as this paragraph is
mentioned multiple time.


- Section 7.2.1: there is no indication in this section, whether the SP
network shall provide or not PE-to-PE VPN membership information exchange;
if this is the case, how ? (routing protocol exchange, manual
configuration, etc.) ?


- Section 7.3: general comment about these models, there is no description
about the implication of single SP vs multiple SP L1VPNs (since both
are/seems to be considered as part of this document, so elements would be
worth considered); if this is not considered w/i the WG charter or n,
please state so


- Section 7.3: first para, "... discovery of reachability ..." does it
correspond to "VPN membership information dissemination/distribution" if
no please clarify, if yes please use a single term throughout the document
to qualify a given mechanism/function


- Section 7.3: second para, are there conditions where the N square
problem could not be solved ? is there an addressing space dependency ?


- Section 7.3: third and fourth para, contradicts first para, first
sentence (... "limited exchange" ...) since including TE;


- Section 7.3: third para, in order to clarify the routing information
exchange at the CE-PE, the following classification shall be used: VPN
membership (per-VPN reachability) vs TE; and for the TE routing
information distinguish between CE-PE TE link information vs intra-SP TE
information; the third para shall be revisited along these lines - this
would definitely provide clarity for this whole section - (a discussion on
scalability would be advisable if not yet covered in another document)


- Section 7.3: last para, the last sentence deserves clarification, how
the so-called "perception" is build ?


- Section 7.3.2: second para, last sentence, is this equivalent to VPN
membership information and CE-PE TE link routing information for the corr.
CEs ? please clarify (and preferably use a single well defined terminology
througout the document)


- Section 7.3.2: what does happen in case of failure where Virtual node
gets partitioned, are both or more parts operating autonomously ?


- Section 7.3.3: is the Virtual TE link information disseminated to CEs
part of the same VPN only (filtering) ? please clarify. Does this model
consider VPN membership information dissemination toward CEs (not
mentioned) ?


- Section 7.3.4: first para, suggest to add a sentence, detailing that
this model is a generalization + combination of the models described in
Section 7.3.2 and 7.3.3 (i.e. Virtual links not only possible between PE
boundaries and Virtul nodes not only delimited by PEs)


- Section 7.3.4: last para, this restriction is arbitrary per model
description in this section; per VPN TE links is close to description
provided in Section 7.3.3 but the latter does not detail whether TE link
information is only disseminated toward CEs belonging to the same VPN - in
brief, why this dissemination policy is specific to the per VPN peer
service model


- Section 8: Data plane resource allocation, the paragraph reads
"triggered => shared" and "partitioned => dedicated" is "triggered =>
dedicated" impossible ? if yes why ? if no meaning such relationship
doesn't exist


- Section 8: mention at several places "customer network routing
information" (also in the Table) what is this information representing,
and how it differs from the VPN membership information, in the former part
of the L1VPN context ? please explain


- Section 8: Information exchanged between CE and PE, what about link
management information exchange for the CE-PE links ? in the same para,
what about the TE information listed as part of the routing information
exchange for models described in Section 7.3.2/.3 and .4


- Section 8: last para, "Note that when provider network routing
information is provided to customers, customers must be able to specify
explicit links for a VPN connection over the provider network." how this
is verified/guaranteed ?


- Section 8.1: selection of L1 CoS, relationship between CoS, availability
and recoverability (ref. to Section 9) is unclear, CoS =/=> availability
(e.g. BE service can be highly available), CoS relationship wrt
recoverability - is there any specific SLS/SLA providing for such mapping
? ... all this requires first to provide a crisp definition of CoS in the
TDM/L1 context


- Section 8.1: Reception of fault information, mentions "... MAY be
allowed ..." if not allowed how recovery can be triggered toward CE ? via
DP ? and then relying on upper layer ?


- Section 8.1: "Reception of connection information: Customers MAY be
allowed to receive information for current VPN connectionS." such as ? can
a given CE receive info for connections it is not involved in but part of
the same VPN ? if yes how ? if no please state so.


- Section 9.1: PE-PE Recovery, last sentence, should it be possible to
notify the CE when the PE-PE recovery failed (otherwise CE needs to rely
on upper layer)


- Section 9.1: CE-PE Recovery, first sentence, mentions "... THE CE-PE
link..." what about the fact there is an ingress AND an egress CE-PE link
?


- Section 9.1: CE-CE Recovery, last part of the last sentence, if the
element under failure is unknown/hidden and recovery is driven by the CE
this may result in further blocking during the recovery process (several
cases should be analyzed here in light with the model proposed in Section
7)


- Section 9.2: extra-traffic: second para, authors are confusing 1:N with
extra-traffic and re-routing w/o extra-traffic, usage of the backup
resources as proposed is not possible (see CCAMP WG I-D, E2E Recovery)


- Section 10: use of overhead associated with VPN connections, "...
different Switching capability"  does not equal different network layer as
mentioned - please refer to CCAMP MRN work


- Section 10: is about CP connectivity between CEs, its last bullet -
cornerstone of the L1VPN CE-PE control plane connectivity - is discussed
as the last paragraph -> suggest to split section 10 in CE-PE and CE-CE CP
connectivity and provide a complete description of the former including
discussion on addressing (privacy, uniqueness, scope, etc.)


- Section 11: Management systems - which MIB modules must be supported


- Section 11: Management of customer networks - enters into a discussion
comparable to the CE-based models in L3VPN but that model has not been
introduced before in the context of this document; hence, one gets only
the manageability aspects related to the CE-based like L1VPNs; authors
needs to decide how to fix this consistently


- Section 12.1: first para, first two sentences, does these mechanisms
consider mis-connection ? or does these sentences imply that the TDM
traffic gets secured in a mechanism defined outside IETF ?


- Section 12.1: last para, how to secure information exchanged at the
management plane i/f ?


- Section 12.3: service access scenario, first para, "... the provider can
ensure who is requesting the service" but what about the CE (at the egress
side) ? how the latter does perform this identification ?


- Section 12.3: service access scenario, first para, "security mechanisms
MUST be available" which mechanisms ?


Editorial
---------


General comment: clearly the first sections of the document found their
source on the ITU work but section 9 and on are clearly derived from IETF
discussions hence the style changes, i'd leave to the editor the
possibility to smooth it (as this may take considerable time so up to
editor's discretion)


- Section 1: first para. add contribution of the L1VPN WG and related
discussion(s)


- Section 2: add RFC 3945, RFC 4208 (at least)


- Section 2: VPN connection, FA add reference to RFC 4206


- Section 2: CE device "switch at layer 1" refer to TDM


- Section 3: second para. the scope is larger than the one initially
intended in 2004 when first discussed at CCAMP WG


- Section 3.1.2: first para. "specific reference" is suppose it means
"focus" so that the present scope is enlarging these docs to L1VPN


- Section 3.1.3: fifth para, replace "deficiences" by "new needs" or
"additional capabilities"


- Section 3.2: first para, "... this doc. is a representation of the
findings ..." which representation are we speaking about ?


- Section 4.1: availability, at the end, add ref. from CCAMP


- Section 4.1: performance, at the end, add ref. (external)


- Section 4.1.1: "above" refers to section 4.1 ?


- Section 4.2.2: "... routing the connection" prefer the term "... dynamic
provisioning..." in the context of this doc


- Section 4.3.1: third para, first sentence, add ref. to MRN CCAMP WG
effort and related I-D's.


- Section 4.3.2: last sentence, replace "dedicated" by "adapted" (would be
surprising to dedicate internal CP mechanisms on P's)


- Section 4.3.3 & Section 4.3.4: first para, "In addition... as mentioned
above" please refer to exact Section/Model


- Section 5: Figure 5.1, no CE to multiple PE links, update if necessary


- Section 7: refers to GMPLS signaling/routing protocol modifications ...
is this the case or authors mean extensions ? if trully modifications than
becomes a technical comment and raise interoperability issues


- Section 7.3.1: first sentence, remove "... slight extension.." and
replace by "... signaling of the overlay service model complemented by
routing information exchange (CE-PE TE link and VPN membership
information)" or so


- Section 8.1: first para, add "in addition to the requirements of Table
1" or so


- Section 9.1: last para, replace "... GMPLS protocol ..." by "... GMPLS
protocols " or "GMPLS protocol suite"


- Section 9.2: second para, replace "... may be able to support..." by
"... may provide..."; also add ref. to appropriate CCAMP I-Ds


- Section 10: "DCC overhead" ... which OH, section overhead ?


- Section 11: accounting management, "record usage" of a connection do we
have any ref. ?


- Section 12.3: service access scenario, what the term "routing
information exchange requests" means ?


- Section 12.3: service access scenario, last para, add ref's RFC 2402,
2406 as appropriate


----

PROTO Write-up

> 1. Have the chairs personally reviewed this version of the Internet
> Draft (ID), and in particular, do they believe this ID is ready to
> forward to the IESG for publication?

Yes.
Note that Tomonri is the editor and that Hamid is a co-author.
Adrian has taken responsiblity for sheparding this I-D.

> 2. Has the document had adequate review from both key WG members and
> key non-WG members? Do you have any concerns about the depth or
> breadth of the reviews that have been performed?

The document has had good review in and out of the WG.
In particular, an early version of this draft provided the background for
the formation of the WG.

The document has had extensive review by SG13 of the ITU-T and lists some
members of that organisation as co-authors. The last liaison of this
document to the ITU-T notified them of the intention to hold a WG last call
and solicited final review comments. None were forthcoming. (Note that
relations with the appropriate Quesiton of SG13 are very cordial.)

> 3. Do you have concerns that the document needs more review from a
> particular (broader) perspective (e.g., security, operational
> complexity, someone familiar with AAA, etc.)?

I think everything necessary is already done.

> 4. Do you have any specific concerns/issues with this document that you
> believe the ADs and/or IESG should be aware of? For example, perhaps you
> are uncomfortable with certain parts of the document, or have concerns
> whether there really is a need for it. In any event, if your issues have
> been discussed in the WG and the WG has indicated it that it still
> wishes to advance the document, detail those concerns in the
> write-up.

No concerns.

> 5. How solid is the WG consensus behind this document? Does it represent
> the strong concurrence of a few individuals, with others being silent,
> or does the WG as a whole understand and agree with it?

WG agrees and is using this framework as the basis of its ongoing work.

> 6. Has anyone threatened an appeal or otherwise indicated extreme
> discontent? If so, please summarise the areas of conflict in separate
> email to the Responsible Area Director.

No

> 7. Have the chairs verified that the document adheres to all of the ID
> Checklist items ?

The chairs have done their best, but we are poor mortals.

> 8. Is the document split into normative and informative references?
> - Are there normative references to IDs, where the IDs are not also
> ready for advancement or are otherwise in an unclear state? (note
> here that the RFC editor will not publish an RFC with normative
> references to IDs, it will delay publication until all such IDs are
> also ready for publication as RFCs.)

Split is OK

> 9. What is the intended status of the document? (e.g., Proposed
> Standard, Informational?)

Informational

> For Standards Track and BCP documents, the IESG approval announcement
> includes a write-up section...

Hoorah! Another Informational I-D.