Subject: RE: WG Last Call: draft-ietf-l2vpn-oam-req-frmk-05 [FrameworkReview]

From: "Ali Sajassi \(sajassi\)" <[email-masked]>
Date: Thu, 22 Jun 2006 23:09:21 -0700

Shane,

Thank you for your detailed comments. Please refer to our replies in
line. We will incorporate the ones agreed upon in the next rev. of the
document.

Regards,
Ali & Dinesh  

> -----Original Message-----
> From: Shane Amante [mailto:[email-masked]] 
> Sent: Sunday, April 09, 2006 9:41 PM
> To: [email-masked]
> Subject: Re: WG Last Call: draft-ietf-l2vpn-oam-req-frmk-05 
> [FrameworkReview]
> 
> Ali, Dinesh, et. al,
> 
> As stated in an earlier e-mail, below are the comments 
> relating to the Framework section(s).
> 
> ===================================================================
> SUBSTANTIATIVE:
> ===================================================================
> 
> Section 1:
> I understand the intent to have a comprehensive set of OAM 
> reqmt's, but I'm not sure why the L2VPN WG specifically needs 
> to take on the breadth of what this statement suggests, 
> specifically "a reference model for OAM layering and 
> furthermore emphasizes the importance of proper independent 
> layering in design and development of OAM functionality across ..." 
> Wouldn't proper OAM layering be a topic more suitable for the 
> Ops Area?
> ---snip---
> This document provides a description and a reference model 
> for OAM layering and furthermore emphasizes the importance of 
> proper independent layering in design and development of OAM 
> functionality across L2VPN services, Pseudo Wires (PWs) and 
> Public Switched Network (PSN) tunnels.
> ---snip---
> 

In VPLS because the native Ethernet service is transported over PWs and
PSN tunnels, it is important to identify the interaction among these
different layers and identify how the failure in PW or PSN transport
layers can impact VPLS service layer and that is why we have established
this OAM layering model. Also, in the previous discussions, we were
asked to identify the impact of PW and PSN layer failure on VPLS service
layer. If in addition to L2VPN WG, you would like to present this
layering to Ops area, then please make such recommendation.  

> Section 3.3 (MEPs and MIPs)
> It would be *extremely* useful to address this comment, as it 
> relates to "Scalability" of VPLS OAM, in Sections 6 (& 7).  
> Specifically, in a mp2p environment like VPLS, it would be 
> useful to assert some guidelines as it relates to the number 
> of ME's per service instance per PE, (particularly for the 
> "sink PE" that is a receiver of n(n-1)/2 ME messages).
> ---snip---
> A ME is a point-to-point association between a pair of MEPs 
> and represents a monitored entity. For example, in a VPLS 
> service which involves n CEs, all the MEs associated with the 
> VPLS service in the customer OAM domain (i.e. from CE to CE) 
> can be considered to be part of a VPLS MEG, where the n-point 
> MEG consists of a maximum of n(n-1)/2 MEs.
> ---snip---
> 

Accept. We will add a sentence or two to indicate that a MEP on a PE
will receive messages from (n-1) other MEPs (on the same or other PEs
for the same ME group).

> Section 4.1.1 (VPLS as Bridged LAN Service) thru 4.1.3 (VPLS as (V)LAN
> Emulation):
> I'm not sure I'm comfortable with these sections.  
> Specifically, I think what you're describing in Section 4.1.1 
> is VPLS operates as a peer-layer to the native (Ethernet) 
> service-layer.  In Section 4.1.2, I think you are attempting 
> to describe VPLS as a peer-layer as well as a client-layer to 
> an underlying MPLS or IP substrate.  Finally, I think in 
> Section 4.1.3, you're finally up to VPLS as a service-layer 
> in its own right.  Is that correct?

No, that is not correct. The intention of this section is to describe
different interpretation of VPLS as reflected in some of the drafts and
L2VPN framework document because it is important to first clarify what
VPLS refers to, before identifying what OAM tools needed for it. Section
4.1.1 is the most common definition for VPLS (e.g., as an end-to-end
multipoint Ethernet service over different types of network). However,
section 4.1.2 and section 4.1.3 talks about different definitions of
VPLS - e.g., as a network where it support multiple of service instances
and as a LAN emulation part which only contains full mesh of PWs along
with its forwarders and talks about the fact that OAM for those are
handled differently. So, the intention of this section is to clarify
what we mean by VPLS (which is section 4.1.1) and correspondingly what
OAM tools are needed for it.  

> If so, then I think we need to be careful in Sections 4.1.1 and
> 4.1.2 when referring the native Ethernet service-layer 
> (particularly in the context of the access-layer networks), 
> that this is out-of-scope for this work product (and the IETF).

That is not the case. Please refer to section 11 of vpls-ldp draft.

> In addition, in Section 4.1.2, there's a vague statement 
> with respect to OAM mechanisms at the "network level".  The 
> way the current sentence is phrased, I believe you are saying 
> that network-layer OAM mechanisms are required; however, it's 
> not in our charter to solve MPLS-layer OAM. (Note, to be 
> fair, you do say in Section 4.2.1 that OAM at the 
> transport-layer is out-of-scope of this doc, but perhaps 
> copying/moving that statement up to here would be useful)?
> ---snip---
> To check the network
> integrity regardless of the network topology, network level 
> OAM mechanisms are needed for the VPLS networks.
> ---snip---
>     Related to the last comment, the words "network level" is 
> IMO vague. 
>   Perhaps it would be better to state that it refers to 
> network-layer protocols such as MPLS, GRE/IP or L2TPv3?
>

O.K., we will add a sentence or two to clarify it further.

> Section 4.2.2:
> It doesn't look like the lines in the diagram in Figure 4, 
> for A, B & C are properly aligned.  You should fix them.
> 

Great! We will do that. 

> Section 4.2.3:
> Again, it doesn't look like the diagram in Figure 5 is 
> properly aligned with the scenarios depicted in A, B & C.
>

It looks pretty align to us, but we will search for mis-alignment. If
you can point out expilictly what is misaligned, it would help. 
 
> Section 4.2.3:
> In general, this section says that it is 'expected' that MEPs 
> and MIPs will be implemented into various components of the 
> VPLS architecture, (VPLS forwarder/briding modules).  Are you 
> discussing the OAM framework here, or do these 'expected' 
> details surrounding an eventual implementation which would 
> mean these would translate into MUSTs or SHOULDs in the 
> reqmt's sections?  (I'm trying to seek clarity of what you're 
> intent is with these statements, because I don't see anything 
> related to MEPs and MIPs in the reqmt's section).
>

Our intention here is to satisfy your previous request as to show the
MEPs and MIPs relate to L2VPN framework. 
 
> Section 4.2.3:
> (D) depicts both MEPs and MIPs, however this sentence only 
> discusses expectations around MEPs ... what about the MIPs in 
> Scenario (D)?
> ---snip---
> (D) represents the MEPs and MIPs
> visible within the service provider domain. These MEPs are 
> expected to be implemented in the bridge module/VPLS 
> forwarder of a PE device, as per the [L2VPN-FRWK].
> ---snip---
> 

Agreed. We will clarify it by adding MIPs to the above sentence: "These
MEPs and MIPs are expected ..."

> Section 4.2.3:
> In which components of the VPLS architecture do you expect 
> the MEPs and MIPs in (E) to be implemented?
> 

Agreed. We will clarify this by indicating that the MIPs for (E) would
exist when you have an Ethernet access network (e.g., section 11 of
vpld-ldp draft).

> Section 4.2.4:
> What about VPLS-BGP?  What identifiers are used for it, since 
> it doesn't use PW-id's?
> 

PW-ids are used in VPLS-BGP but instead they are signaled via BGP and we
don't care about what signaling mechanism is used. 

> Section 4.2.4:
> ---snip---
> Both PW-ids and VLAN tags for a given VPLS instance are 
> associated with a Service Identifier (e.g., VPN identifier).
> ---snip---
> Which identifier do you have in mind, i.e.: VPLS-ID in 
> l2vpn-signaling?
> 

By PW-id, it is meant the associated MPLS label.

> Section 5:
> Diagrams aren't aligned Figure 6, VPWS Reference Model.
> 

We must complement you for your keen eyes :-) We will fix it.

> Section 5.2:
> What are you trying to say here?
> ---snip---
> In common scenarios, it could or simply a point-to-point 
> interface of certain type.  The core network connecting PEs 
> can be IP, MPLS, etc.
> ---snip---
> 

The statement ought to be: "In common scenarios, it could simply be a
point-to-point ... Such as Ethernet PHY" and we will change it.

> Section 5.2:
> To which network types are you referring?  Can you somehow 
> reference back to the heterogenous & homogeneous terminology 
> introduced in the aforementioned section?
> ---snip---
> Therefore, it is important that the OAM mechanisms can be 
> applied to all these network types.
> ---snip---
> 

We will change the sentence to "Therefore, it is important that OAM
mechanisms can be applied to different network types some of which
mentioned above"

> Section 5.2.1:
> Diagrams in Figure 7 are not aligned properly, and I believe 
> you're missing a > describing the right-most end-point in the diagram.
> 

Right, We will fix it.

> Section 5.2.2:
> Diagrams in Figure 8a & 8b are not aligned properly, and I 
> believe you're missing a > describing the right-most 
> end-point in the diagram.
> 

That's fine, we'll fix it.

> Section 5.2.2:
> ---snip---
> "The service provider is responsible to monitor the PW ME"
> "... the monitoring requirements across the AC ME are minimal."
> ---snip---
> What is the "PW ME" and "AC ME"?  The term "ME" hasn't been 
> defined as it related specifically to PW's or AC's.  
> Furthermore, does ME refer to the NSP, or some other 
> function/layer of VPWS?
> 

Section 1.1 has a clear definition of ME which one can apply to any
types of entity such as service, PW, AC, etc.

> Section 5.2.2:
> ---snip---
> The
> distinction between Figure 8b (C) and (D) is that (C) MEs 
> have MEPs at CE and PEs and have no MIPs while (D) MEs have 
> MEPs at CEs and PEs and likely MIPs in between, thereby 
> having a visibility to Operator network.
> ---snip---
>     Can you clarify this part of the sentence: "(C) MEs have 
> MEPs at CE and PEs and have no MIPs" ... specifically, it's 
> not clear at all
> (e.g.: to which devices or components of VPWS) where MEPs and 
> MIPs are applicable.
>     Can you also clarify the second half of that sentence 
> "(D) MEs have MEPs at CEs and PEs and likely MIPs in between, 
> thereby having a visibility to Operator network." ... again, 
> it's not clear where (e.g.: 
> to which devices or components of VPWS) MEPs are MIPs are 
> applicable.  I think it's just the way you're phrasing it, so 
> perhaps re-phrasing in a better way would be good.
> 

We belive the phrasing is causing some confusion to you and we will
further clarify it as: "The distinction between Figure 8(b)-C, and
8(b)-D is that in (C), MEs have MEPs at CEs and at Pes, and have no
MIPs. While in (D) MEs have MEPs at CEs and at PEs and furthermore, MIPs
may be present in between the MEPs; thereby providing visibility of the
network to the operator."

> Section 5.2.3:
> Which option are you referring to?
> ---snip---
> The advantage of this option is that end-to-end and segment 
> OAM can be carried out in an independent manner.
> ---snip---
>

Agreed. We will modify the text to clarify it: "The advantage of having
layered OAM is that ..."

> Section 5.2.3:
> Suggest putting this paragraph before the diagram and 
> changing the intro to s/Though, different possible OAM layers 
> have been shown/Although many different OAM layers are 
> possible, as shown in Figure 9,/.
> ---snip---
> Though, different possible OAM layers have been shown in the 
> Figure 9, not all may be realized. For example, Figure (B2) 
> and (D) may be adequate in some cases.
> ---snip---
> 

That's fine.

> 
> ===================================================================
> EDITORIAL:
> ===================================================================
> 1.1) Formatting needs to be fixed/aligned
> 2) Formatting needs to be fixed/aligned
> 2) "CEs that are member of the same service instance 
> communicate with each other as if they are connected via a 
> bridged LAN."
>     s/member/members/

Agreed.

> 4.1.1) "... and it provides a virtual LAN service to the 
> attach CEs belonging to that service instance."
>     s/attach CEs/attached CEs/

Agreed.

> 4.1.1) "The reason it is called bridged LAN service is 
> because the VPLS-capable PE provide this end-to-end virtual 
> LAN service performing bridging functions (either full or a 
> subset) as described in the [L2VPN-FRWK]."
>     s/provide/providing/
>     s/performing/is performing/

Agreed.

> 4.1.3. "Since the emulated LAN segment is presented as a 
> Virtual LAN (VLAN) to the bridge module of a VPLS-capable PE, 
> emulated segment is also referred to as an emulated VLAN."
>     s/VPLS-capable PE, emulated/VPLS-capable PE, the emulated/

Agreed.

> 4.2.4:
> ---snip---
> As described in [VPLS-LDP], VPLS instance can be identified 
> in an Ethernet domain (e.g., 8021.d domain) using VLAN tag
> ---snip---
>     s/VPLS instance/a VPLS instance/
>     s/8021.d/802.1d/

Agreed.

> 4.2.4:
> "For Ethernet services e.g. VPLS,"
>     s/e.g. VPLS,/, e.g. VPLS,/

Agreed.

> Section 4.2.4:
> ---snip---
> MEPs and MIPs Identifiers, i.e. MEP Ids and MIP Ids must be 
> unique within their corresponding Service Identifiers within 
> the OAM domains.
> ---snip---
>     s/, i.e. MEP Ids and MIP Ids must/, i.e. MEP Ids and MIP 
> Ids, must/ 

Agreed.

> Section 5.1:
> ---snip---
> . VPWS with homogeneous ACs (where both ACs are same type) . 
> VPWS with heterogeneous ACs (where the ACs are of different
>    types)
> ---snip---
>     s/type/Layer-2 encapsulation/

Agreed.

> 5.2:
> ---snip---
> As an example, the access network between CE and PE on one 
> side can be Ethernet bridged network, ATM network, etc.
> ---snip---
>     s/be Ethernet bridged network/be an Ethernet bridged/ 

Reject. It is intended to say "bridged network" as defined in IEEE
standards

> Section 5.2.1:
> ---snip---
> Service provider network can be considered to be segmented 
> into core network and two types of access network.
> ---snip---
>     s/Service provider network/A service provider network/
>     s/into core network/into a core network/ 

Agreed.

> Section 5.2.1:
> ---snip---
> In most general case, a PE can be client service aware when 
> it processes client service PDUs and is responsible for encapsulating
> ---snip---
>     s/In most general case/In the most general case/ 

Agreed.

> Section 5.2.1:
> ---snip----
> ... is responsible for encapsulating
> and de-encapsulating client service PDUs onto PW and ACs.
> ---snip---
>     s/onto PW and ACs/onto a PW and ACs/ 

Agreed.

> Section 5.2.2
> ---snip---
> PEs of a given operator and could
> also be present in access if the access is
> ---snip---
>     s/present in access/present in the access network/
>     s/if the access/if the ACs are/

Agreed.

> Section 5.2.2:
> "by the customer and customer"
>     s/and customer/and the customer/
> Section 5.2.2:
> "The service provider is responsible to monitor the PW ME"
>     s/responsible to monitor/responsible for monitoring/ 

Agreed.

> Section 5.2.2:
> "responsibility shared between the customer and service provider"
>     Change this whole quote to be:
> "the shared responsibility of the customer and the service provider"
> Section 5.2.2:
> ---snip---
> Figure 8b highlights another management model, where the CEs 
> are managed by the Service Provider and where CEs and PEs are 
> connected via access network.
> ---snip---
>     s/via access network/via an access network/ 

Agreed.

> Section 5.2.3:
> ---snip---
> to specific responsibilities within the network.
> ---snip---
>     s/specific responsibilities/specific areas/ Section 5.2.3:
> ---snip---
> The CE interfaces support MEPs at end-to-end Service Provider 
> OAM level for VPWS end-to-end service as shown in Figure 9 
> (B1) and (B2).
> ---snip---
>     s/MEPs at end-to-end Service Provider/MEPs at the 
> end-to-end Service Provider/
>     s/VPWS end-to-end service/VPWS as an end-to-end service/ 

Agreed.

> Section 5.2.3:
> ---snip---
> Service Provider OAM level when PEs are client service aware, 
> shown in Figure 9 (B2).  As an example, if one considers an 
> enc-to-end Ethernet line service offered to subscriber 
> between between CE1 and CE2 which is realized via ATM type 
> AC1 and AC2 and PW which encapsulates ATM over MPSL, the PEs 
> can be considered as Ethernet service unaware,
> ---snip---
>     s/, shown in Figure 9 (B2)/, as shown in Figure 9 (B2)/
>     s/enc-to-end/end-to-end/
>     s/offered to subscriber between/offered to a subscriber/
>     s/MPSL/MPLS/

Agreed

> Section 5.2.4:
> ---snip---
> In VPWS, the MEPs and MIPs should be identified with their 
> native addressing schemes. MEPs and MIPs Identifiers, i.e. 
> MEP Ids and MIP Ids must be unique within their corresponding 
> OAM domains and must also be unique to the VPWS service instance.
> ---snip---
>     s/i.e. MEP Ids and MIP Ids must/i.e. MEP IDs and MIP IDs, must/
> 

Agreed.

> -shane
> 
> 
> Shane Amante wrote:
> > The authors of draft-ietf-l2vpn-oam-req-frmk-05, have requested a 
> > L2VPN WG Last Call for this I-D, "L2VPN OAM Requirements and 
> > Framework".  It can be found at:
> > 
> http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-oam-req-frmk-05.t
> > xt
> > 
> > Please thoroughly review the document and send any comments 
> to the list. 
> >  Also, please indicate whether you believe this document is 
> ready to 
> > go to the IESG "as is", or whether there should be a cleaner 
> > separation between the requirements and framework.  In the latter 
> > case, the I-D would not pass LC, would need to get 
> re-drafted for WG 
> > comments and the separate components sent out for WG Last 
> Call again.
> > 
> > The WG Last Call will end on 10 Apr 2006 at 1700 MST (UTC/GMT -7).
> > 
> > -shane
> > 
>