To: <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Review of L1VPN framework document
From: [EMAIL PROTECTED]
Date: Fri, 28 Jul 2006 17:11:56 +0200
hi ross,
you will find here below my review of the L1VPN framework document (i have
tried to be as complete as possible) - hope this well help authors and
L1VPN WG
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
----
