[L1vpn] Fwd: Review of L1VPN framework document

[Tomonori TAKEDA <[e-mail]>]

Hi,

For information, we have received comments from our AD and the routing 
directorate review (thanks Ross and Dimitri) as follows.

Currenlty, we are working to resolve issues and update the document.

We may need to go for another WG last call.

Thanks,
Tomonori

---------------------------------------
Hi Ross, Dimitri,

Much thanks for your detailed comments.

I will update the document based on comments.

Please see some specific comments in-line.

<snip>

 > >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

Inter-AS/SP is out of scope of current WG charter.

Therefore, I think current level of description may be good enough. I
will check text more in detail and make appropriate changes if necessary.

<snip>

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

OK.

Please not that L1VPN is a service, while overlay is an architectural
model. L1VPN (basic mode) utilizes overaly architecture, with some
appropriate modifications/enhancement.

 > >- 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

Same as above.

<snip>

 > >- 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 ?

The customer interface includes the management interface, which is not
necessarily colocated with a CE-PE control plane channel.

Will clarify.

<snip>

 > >- 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

I think SPC MIB module is not addressed yet. (But such analysis is not
the main scope of this document.)

<snip>

 > >- 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

In this document, VPN membership information is defined as a list of TE
link addresses within the same VPN (associated with PE). Such address is
associated with a CE port.

In section 7.3, "reachability in remote site" means something different.
This is customer site reachability (e.g., C's addresses), typically
obtained as a result of CE-PE routing exchange.

Will clarify.

<snip>

 > >- 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)

OK. Agreee we need clarification.

Routing (like) information includes:
- VPN membership information (a list of TE link addresses on the CE port)
- CE-PE TE link information
- Customer site routing information (reachability only or TE)
- Intra-SP TE information

Will clarify these. Also will use consistent terminologies.

<snip>

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

Do you have any specific reference in mind?

<snip>

Thanks,
Tomonori

>X-Sender: [e-mail]
>X-Mailer: QUALCOMM Windows Eudora Version 5.0
>Date: Tue, 01 Aug 2006 20:50:50 -0400
>To: [e-mail]
>From: Ross Callon <[e-mail]>
>Subject: Fwd: Review of L1VPN framework document
>Cc: [e-mail], 
>[e-mail],[e-mail], [e-mail], 
>[e-mail],[e-mail], 
>[e-mail],[e-mail]
>
>Takeda;
>
>Attached is the routing directorate review of draft-ietf-l1vpn-framework-03.txt.
>Thanks to Dimitri Papadimitriou for the very careful and detailed review.
>
>I understand that these are very detailed comments, and between these
>and the less detailed comments that I sent you a few days ago it will be
>a bit of work to update the document. Thanks for being willing to take
>this on. I do think that responding to these comments (or at least to most
>of them, as best you can) will help improve the document significantly.
>
>Let me know if you have any questions or would like to discuss any of
>these comments.
>
>thanks, Ross
>
>>To: <[e-mail]>
>>Cc: [e-mail], [e-mail]
>>Subject: Review of L1VPN framework document
>>From: [e-mail]
>>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
>>
>>----


_______________________________________________
L1vpn mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/l1vpn