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

From: "Ali Sajassi \(sajassi\)" <[email-masked]>
Date: Wed, 21 Feb 2007 01:08:39 -0800

Hi Shane,

Please refer to my comments inline. As you can see I think we are very
close in wrapping this up.

Regards,
Ali    

> -----Original Message-----
> From: Shane Amante [mailto:[email-masked]] 
> Sent: Sunday, July 23, 2006 5:20 PM
> To: Ali Sajassi (sajassi)
> Cc: [email-masked]
> Subject: Re: WG Last Call: draft-ietf-l2vpn-oam-req-frmk-05 
> [FrameworkReview]
> 
> Hi Ali,
> 
> Please see below.
> 
> On Jun 23, 2006, at 12:09 AM, Ali Sajassi (sajassi) wrote:
> > 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.
> 
> Perhaps some word-smithing might alleviate this concern.  How about
> this:
> ---snip---
> This document provides a description and reference model for 
> OAM as it relates to L2VPN services, which are comprised of 
> Pseudo Wires
> (PWs) and Public Switched Network (PSN) tunnels.
> ---snip---
> I'm not sure you need to mention OAM layering or its 
> importance in this paragraph, because that is captured by the 
> phrase "description and reference model for OAM" in the 
> sentence above.  It is also captured in much detail 
> throughout the framework portion of the document.
> 
> 

That's fine. I will change it to:
"This document provides a description and reference model for 
OAM as it relates to L2VPN services and their associated 
Pseudo Wires (PWs) and Public Switched Network (PSN) tunnels."

> 
> 
> >> 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).
> 
> OK.
> 
> 
> >> 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.
> 
> Thanks for providing some context around these sections.  A 
> few things might help to be clarified:
> 1)  In 4.1.2, you state that this is out-of-scope for this 
> document; however, it would be useful to state that Sections 
> 4.1.1 and 4.1.3 are what is being addressed by later sections 
> of this OAM document.

O.K. We'll do.

> 2)  In Section 4.1.1, it's stated that:
> ---snip---
> 	To check the end-to-end service integrity, service 
> level OAM mechanisms
>          are needed.
> ---snip---
> I'm not comfortable with the words "service level" as they 
> stand above.  Is it referring to the VPLS service level, 
> (e.g.: VPLS-LDP/ VPLS-BGP signaling, VPLS Forwarders as 
> defined in L2VPN framework,
> etc.) or to the IEEE 802.1 service level or both?
> 

It basically refers to multipoint Ethernet service which is provided via
network elements - PE and bridging devices (for providing
bridging/swtiching) functions and P devices (for providing tunneling
function). And it is from AC to AC. 

> Is there another L2VPN (or PWE3) document to which you can 
> provide a pointer as to a definition of 'service layer'?  
> (See the next comment for more context about a suggestion I 
> have to hopefully address this comment).
> 

Basically service layer is the layer at which the multipoint Ethernet
service is offered. 

> 
> 
> >> 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.
> 
> Section 11 of VPLS-LDP states the following:
> ---snip---
>    The details regarding bridge operation for MTU-s and PE-rs (e.g.,
>    encapsulation format for Q-in-Q messages, customer's Ethernet
>    control protocol handling, etc.) are outside of the scope of this
>    document and they are covered in [802.1ad].  However, the relevant
>    part is the interaction between the bridge module and the MPLS/IP
>    PWs in the PE-rs, which behaves just as in a regular VPLS.
> ---snip---
> The above section from VPLS-LDP states that bridging 
> operation for the MTU-s and PE-rs are outside its scope, but 
> that the interaction between the bridge module and MPLS/IP 
> PWs in the PE-rs are important.  I believe this sentence 
> applies to Section 4.1.1 and, subsequently, the OAM 
> requirements section, specifically as it relates to protocols 
> we may create or augment to address OAM of VPLS/ VPWS 
> services.  Perhaps it's useful to 'borrow' this paragraph 
> from VPLS-LDP in order to clarify that the 'service-layer' to 
> which you refer in the "VPLS as a Bridged LAN service" 
> section relates directly to this interaction.
> 

Yes, the brdiging operation are outside of the scope since they are
already specified in IEEE 802.1ad spec; however, the fact that the
aggregation of CE devices can be provided by MTU-s switches still
remains the same. Basically, the mode of operation is H-VPLS with
Ethernet access and Ethernet access is part of provider (not the
customer) and as such when providers want end to end coverage, they want
from AC to AC (e.g., among CE devices) and not just part of a network.
The good thing is that in the draft we have covered both end to end
service as well as the portion that just spans MPLS/IP network and we
have covered the interaction between the two which is very important -
e.g., if a fault happens in MPLS core, then how it is propagated to
MTU-s bridges.

> Because the introduction to Section 6 (VPLS Service OAM 
> Requirements) has a reference back to Section 4.1.1:
> ---snip---
>     These requirements are applicable to VPLS as a Bridged 
> LAN service,
>     as described in Section 4.1.1. Further, the performance 
> metrics used
>     in requirements are based on [MEF10] and [RFC2544].
> ---snip---
> ... I think it's important that you clarify the service-layer.

Sounds good. We will further clarify and describe service-layer.

> 
> In addition, in Section 6, it would useful to state that 
> although the Framework may provide a comprehensive OAM 
> solution set, the requirements for a L2VPN-defined OAM 
> _protocol suite_ will be a subset of the Framework (along the 
> lines of what VPLS-LDP says) related to those aspects of 
> L2VPN protocols, signaling, etc.  
> previously defined, owned & maintained by the L2VPN WG.
>

Considering that MTU-s and PE-rs have bridging modules in them, I don't
think it would make any difference with respect to OAM framework and
requirements specifications as whether they are directly connected with
each other or they are connected via another set of bridges (e.g., via
Ethernet network). In other words, we still need to perform fault
management for MTU-s and PE-rs when the network is H-VPLS with Ethernet
access and when you have the capability to do that, then you can do it
for the intermediate nodes connecting the MTU-s to PE-rs. 
 
> 
> 
> >> 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.
> 
> OK.
> 
> 
> >> 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 ..."
> 
> OK.
> 
> 
> >> 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).
> 
> OK.
> 
> 
> >> 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.
> 
> VPLS-LDP uses PWid's.  VPLS-BGP uses a demultiplexor label 
> defined as (Label Block + VE ID - VE Block Offset).
> Perhaps it would useful to clarify that you are referring to 
> the demultiplexor label, in order to be less specific as to 
> one protocol or the other?  Alternatively, clarify that with 
> VPLS-BGP it would be what's stated above.
> 

It is really the same thing. The VPLS-BGP draft talks about PW and its
associated signaling (setup and tear down). PW by definition is the
demultiplexor label within the PSN tunnel. So both are the same and the
use of PW id makes the reference consistent irregardless of signaling
type (BGP v.s. LDP). 

> 
> >> 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.
> 
> OK.
> 
> 
> >> 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.
> 
> OK.
> 
> 
> >> 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."
> 
> OK.
> 
> [---snipped for brevity---]
> 
> >> ===================================================================
> >> EDITORIAL:
> >> ===================================================================
> 
> [---snip---]
> 
> >> 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
> 
> I was just asking to insert an 'an' into your sentence.  I'm not  
> clear on why you would reject that change?
> 
> 
> [---snipped to end---]
> 
> Thanks,
> 
> -shane
>

---

From: "Ali Sajassi \(sajassi\)" <[email-masked]>
Date: Fri, 23 Feb 2007 17:38:29 -0800

Shane,

I have basically added the text as you have requested/suggested (please
refer to the text inline). Let me know please if there are still some
I's that I need to dot or T's that I need to cross before the WG last
call :-) So, if you are O.K. with these changes, we can either add them
after we go through the last call or do it before hand. My preference is
after the call since I can do all the editing in one shot and avoid
unnecessary overhead of going through multiple edit/release cycles.

I would appreciate your prompt response as this draft has been gating
issue for any work on OAM solution draft.

Regards,
Ali

> From: Ali Sajassi (sajassi) 
> Sent: Wednesday, February 21, 2007 1:09 AM
> To: Shane Amante
> Cc: [email-masked]
> Subject: RE: WG Last Call: draft-ietf-l2vpn-oam-req-frmk-05 
> [FrameworkReview]
> 
>  
> Hi Shane,
> 
> Please refer to my comments inline. As you can see I think we 
> are very close in wrapping this up.
> 
> Regards,
> Ali    
> 
> > This document provides a description and reference model 
> for OAM as it 
> > relates to L2VPN services, which are comprised of Pseudo Wires
> > I'm not sure you need to mention OAM layering or its importance in 
> > this paragraph, because that is captured by the phrase "description 
> > and reference model for OAM" in the sentence above.  It is also 
> > captured in much detail throughout the framework portion of the 
> > document.
> > 
> > 
> 

Proposed text: Change the text to:

> > 4.1.1 and 4.1.3 are what is being addressed by later sections 

Propsosed Text: Add the following sentence at the end of section 4.1.1
and 4.1.3:

"The framework & requirements for this OAM mechanism will be covered in
this draft" 

> e.g., if a fault happens in MPLS core, then how it is propagated to

Proposed Text: Will add the following paragraph 

"The details regarding bridge operation for MTU-s and PE-rs (e.g.,
Ethernet encapsulation format, customer's Ethernet
control protocol handling, etc.) are outside of the scope of this
document as they are covered in IEEE standards unless there is an 
Interaction between these protocols and MPLS/IP protocols."

> Sounds good. We will further clarify and describe service-layer.

Will add the following text to 4.1.1 for further clarification:

"Service layer corresponds to the layer of the network, network
elements, 
that are service aware - e.g., if the service provided to an end-user is

a multipoint Ethernet service, then the service layer constitues the
network 
elements that are aware of the end-user Ethernet frames. " 

> for the intermediate nodes connecting the MTU-s to PE-rs. 

Will add a paragraph the following paragraph to this section:

"The details regarding bridge OAM operation for MTU-s and PE-rs (e.g.,
OAM protocols for Ethernet) are outside of the scope of this
document as they are covered in IEEE standards unless there is an 
Interaction between these protocols and MPLS/IP protocols."

---

From: Shane Amante <[email-masked]>
Date: Sat, 24 Feb 2007 16:47:11 -0700

Ali,

> unnecessary overhead of going through multiple edit/release cycles.

Once we agree to the below changes, let's please make them before WG  
Last Call.  This will be courteous to all WG members by allowing them  
to read the document in its entirety, instead of having to scan the  
list & archives to see the doc in its final state -- particularly  
because they are comments related to the substance of the document,  
not spelling or grammatical typos.

In addition, there are a significant number of 'nits' found (4  
errors, 15 warnings) in the doc that need to get cleaned up before it  
goes to the IESG:
http://tools.ietf.org/wg/l2vpn/draft-ietf-l2vpn-oam-req-frmk/draft- 
ietf-l2vpn-oam-req-frmk-07.nits.txt
Can you, or one of the other co-authors/contributors, please address  
these as well in the final version?

> issue for any work on OAM solution draft.

I think we're getting close to finishing this.  Please see below.   
I'm OK with most of your suggested changes, however there's still  
three outstanding items.

OK.

OK.

> Interaction between these protocols and MPLS/IP protocols."

May I suggest that you re-phrase "MPLS/IP" to be "VPLS or VPWS"?

> elements that are aware of the end-user Ethernet frames. "

These seems like a very broad definition of "service-layer".  Can you  
instead re-phrase your definition for 'service-layer' in terms of RFC  
4664 (L2VPN Framework) and/or RFC 4664 (L2VPN requirements)?  This  
would provide cohesiveness with the framework, requirements,  
solutions (VPLS-LDP/VPLS-BGP) and, ultimately, through OAM reqmt's of  
VPLS & VPWS.

> Interaction between these protocols and MPLS/IP protocols."

May I suggest the above be rephrased as follows, and be put as a new  
paragraph:
---snip---
The details regarding the "bridge module", as defined in the  
framework of L2PVN [RFC 4664], of the PE-rs as well as the native  
Ethernet MTU-s are outside of the scope of this document and the  
solutions defined as a result of this document, as they are covered  
in IEEE standards.  The requirements in this draft apply to the "VPLS  
Forwarder" and the "Emulated LAN interface", which connects the VPLS  
Forwarder to the bridge module.
---snip---

[--snip--]

Thanks,

-shane

---

From: "Ali Sajassi \(sajassi\)" <[email-masked]>
Date: Mon, 26 Feb 2007 09:49:35 -0800

Shane,

Please refer to my reply below with respect to your last three
comments/suggestion. I have removed the remaining texts/comments for
better clarity.

> I'm OK with most of your suggested changes, however there's 
> still three outstanding items.
> 
> 
> > Ethernet encapsulation format, customer's Ethernet control protocol 
> > handling, etc.) are outside of the scope of this document 
> as they are 
> > covered in IEEE standards unless there is an Interaction 
> between these 
> > protocols and MPLS/IP protocols."
> 

O.K.

> > elements, that are service aware - e.g., if the service 
> provided to an 
> > end- user is
> >
> > network elements that are aware of the end-user Ethernet frames. "
> 
> These seems like a very broad definition of "service-layer".  
> Can you instead re-phrase your definition for 'service-layer' 
> in terms of RFC
> 4664 (L2VPN Framework) and/or RFC 4664 (L2VPN requirements)?  
> This would provide cohesiveness with the framework, 
> requirements, solutions (VPLS-LDP/VPLS-BGP) and, ultimately, 
> through OAM reqmt's of VPLS & VPWS.
> 
> 

O.K. I will modify it based on L2VPN Requriement RFC and L2VPN Framwork
RFC.

> > OAM protocols for Ethernet) are outside of the scope of 
> this document 
> > as they are covered in IEEE standards unless there is an 
> Interaction 
> > between these protocols and MPLS/IP protocols."
> 
> framework of L2PVN [RFC 4664], of the PE-rs as well as the 
> native Ethernet MTU-s are outside of the scope of this 
> document and the solutions defined as a result of this 
> document, as they are covered in IEEE standards.  The 
> requirements in this draft apply to the "VPLS Forwarder" and 
> the "Emulated LAN interface", which connects the VPLS 

That is NOT correct !! If you refer to both RFC 4465 and RFC 4464, an
end-to-end VPLS is defined to include bridge module, forwarder, and the
set of PWs. I know better, I helped the authors with these definitions
at the time of the writing of these RFCs. For example RFC4465 says: "
End-to-end VPLS consists of a bridge module and a LAN emulation module
([RFC4664])." Therefore, when we define OAM for the end-to-end VPLS
service it must include bridge module.

-Ali

---

From: Shane Amante <[email-masked]>
Date: Mon, 26 Feb 2007 21:30:30 -0700

Ali,

> O.K. I will modify it based on L2VPN Requriement RFC and L2VPN  

Can you please suggest text that you will use?

> service it must include bridge module.

I don't understand.  Your explanation above is confusing for two  
reasons:
1)  First, if you look above at the top-most comment in this thread  
(relative to the Framework section) you agree that the "details  
regarding bridge operation for MTU-s and PE-rs ... are outside the  
scope of this document as they are covered in the IEEE standards".   
Now, you seem to be saying the opposite in the Requirements section.   
Specifically, that the above statement was irrelevant and now you are  
implying that you do want/need to duplicate IEEE standards in the  
requirements for OAM solutions that will be proposed for VPLS/VPWS.   
Or, perhaps I'm misunderstanding the rationale behind your  
explanation or intent?
2)  Second, and much more germane to the requirements section, is  
what portion(s) of the requirements section apply to OAM solutions  
that will go Standards Track and, separately, what requirement(s)  
apply to OAM solutions that may go Informational, (assuming they are  
not duplicating or interfering with standards/protocols from other  
SDO's)?

Thanks,

-shane

---

From: "Ali Sajassi \(sajassi\)" <[email-masked]>
Date: Mon, 26 Feb 2007 23:15:47 -0800

Shane, 

I have sent out an updated copy of the draft earlier this afternoon;
however, it seems it got parked because of the attachment. Anyway, I
have copied section 4 and 6 at the bottom of this email. Also please
refer to my comments inline ...

> Sent: Monday, February 26, 2007 8:31 PM
> control protocol 
> >> This would provide cohesiveness with the framework, requirements, 
> > O.K. I will modify it based on L2VPN Requriement RFC and L2VPN 
> > Framwork RFC.
> 

I have pasted a copy of the proposed text at the end of this email.

> > end-to-end VPLS is defined to include bridge module, forwarder, and 
> > the set of PWs. I know better, I helped the authors with these 
> > definitions at the time of the writing of these RFCs. For example 
> > RFC4465 says: "
> 1)  First, if you look above at the top-most comment in this 
> thread (relative to the Framework section) you agree that the 
> "details regarding bridge operation for MTU-s and PE-rs ... 
> are outside the  

Not really !! The two statements are consistent with each other. I am
saying that we don't want to specify the details regarding the bridge
module and its related protocols since they are already specified in the
IEEE standards. However, we do want to cover the OAM requirements and
framework for an end-to-end VPLS service as they are defined in RFC4445
and RFC4446 which include bridge module. Covering the OAM requirement
and framework for an end-to-end service does NOT mean we need to specify
the details regarding bridge operation !! Otherwise we need to have a
300-page spec. just for the bridge module !! 

To put it simply, if you look at RFC4445 and RFC4446, the end-to-end
VPLS service consist of bridge module and LAN emulation and sec 4.1.1
says that we need an OAM mechanism for an end-to-end service and sec.
4.1.3 says that we need an OAM mechanism for LAN emulation. Basically,
we need to cover both because VPLS functionality is defined in terms of
both as described in RFC4446 and RFC 4445.

> Specifically, that the above statement was irrelevant and now 
> you are implying that you do want/need to duplicate IEEE 
> standards in the  

I think you have misunderstood it. I hope the above explanation is clear
enough.

> 2)  Second, and much more germane to the requirements 
> section, is what portion(s) of the requirements section apply 
> to OAM solutions that will go Standards Track and, 
> separately, what requirement(s) apply to OAM solutions that 
> may go Informational, (assuming they are not duplicating or 
> interfering with standards/protocols from other SDO's)?
> 

I would expect at the time the solution draft we can decide which one
should go standard track and which one not but regarding the
requirements in the above draft, they are very much follow the RFC4445
and RFC4446 and therefore they should be considered as standard track.

Cheers,
Ali

> -shane 

========================================================================
================
   4.1. VPLS as Service/Network 
    
   4.1.1. VPLS as Bridged LAN Service 
    
   The most common definition for VPLS is for bridged LAN service over 
   an MPLS/IP network. The service coverage is considered end-to-end 
   from UNI to UNI (or AC to AC) among the CE devices and it provides a 
   virtual LAN service to the attached CEs belonging to that service 
   instance. The reason it is called bridged LAN service is because the 
   VPLS-capable PE providing this end-to-end virtual LAN service is 
   performing bridging functions (either full or a subset) as described 
   in the [L2VPN-FRWK]. This VPLS definition, as specified in [L2VPN-
   REQ], includes both bridge module and LAN emulation module (as 
   specified in [L2VPN-FRWK]).  

   Mohan & Sajassi     Expires: September 2007               [Page 9] 
   Internet Draft   draft-ietf-l2vpn-oam-req-frmk-08.txt      Jan 2007 
    
   A VPLS service instance is also analogous to a VLAN provided by IEEE 
   802.1Q networks since each VLAN provides a Virtual LAN service to 
   its MAC users. Therefore, when a part of the service provider 
   network is Ethernet based (such as H-VPLS with QinQ access network), 
   there is a one-to-one correspondence between a VPLS service instance 
   and its corresponding provider VLAN in the service provider Ethernet 
   network. To check the end-to-end service integrity, the OAM 
   mechanism needs to cover the end-to-end VPLS service as defined in 
   [L2VPN-REQ] which is from AC to AC including bridge module, VPLS 
   forwarder, and the associated PWs for this service. This draft 
   specifies the framework and requirements for such OAM mechanism.  
    
   The details regarding bridge operation for MTU-s and PE-rs (e.g., 
   Ethernet encapsulation format, customer's Ethernet control protocol 
   handling, etc.) are outside of the scope of this document as they 
   are covered in IEEE standards unless there is an Interaction between 
   these protocols and VPLS or VPWS protocols. 

   4.1.2. VPLS as a Network 
    
   Sometimes VPLS is also used to refer to the underlying network that 
   supports bridged LAN services. This network can be an end-to-end 
   MPLS/IP network as H-VPLS with MPLS/IP access or can be a hybrid 
   network consisting of MPLS/IP core and Ethernet access network as in 
   H-VPLS with QinQ access. In either case, the network consists of a 
   set of VPLS-capable PE devices capable of performing bridging 
   functions (either full or a subset). These VPLS-capable PE devices 
   can be arranged in a certain topology such as hierarchical topology 
   (H-VPLS) or distributed topology (D-VPLS) or some other topologies 
   such as multi-tier or star topologies. To check the network 
   integrity regardless of the network topology, network-level OAM 
   mechanisms (such as OAM for MPLS/IP networks) are needed. The 
   discussion of network-level OAM is outside of the scope of this 
   draft.  

   4.1.3. VPLS as (V)LAN Emulation 
    
   Sometimes VPLS also refers to (V)LAN emulation. In such context, 
   VPLS only refers to the full mesh of PWs with split horizon that 
   emulates a LAN segment over MPLS/IP network for a given service 
   instance and its associated VPLS forwarder. Since the emulated LAN 
   segment is presented as a Virtual LAN (VLAN) to the bridge module of 
   a VPLS-capable PE, the emulated segment is also referred to as an 
   emulated VLAN. The OAM mechanisms in this context refer primarily to 
   integrity check of VPLS forwarders and its associated full-mesh of 
   PWs and the ability to detect and notify a partial mesh failure.  
   This draft also covers the OAM framework and requirements for such 
   OAM mechanism. 

=====================================

   6. VPLS Service OAM Requirements 
    
   These requirements are applicable to VPLS as a Bridged LAN service, 
   as described in Section 4.1.1. Further, the performance metrics used 
   in requirements are based on [MEF10] and [RFC2544]. 
    
   The details regarding "bridge module" operation and its associated 
   protocols are outside of the scope of this document as they are 
   covered in IEEE standards unless there is an Interaction between 
   these protocols and VPLS/VPWS protocols.

---

From: "Dinesh Mohan" <[email-masked]>
Date: Tue, 27 Feb 2007 09:25:21 -0500

Shane,

Regarding your last comment: even the text proposed by you can be cited
to be confusing since on one hand it implies that "bridge module" is
defined in the L2VPN framework - "..."bridge module", as defined in the
framework of L2PVN [RFC 4664].." - and then the text suggests that these
are outside the scope since there are covered in IEEE standards -
"...are outside of the scope of this document and the solutions defined
as a result of this document, as they are covered in IEEE standards...."

At this stage we seem to be simply wordsmithing. This document has been
under review for last 2+ years and received extensive commments from you
and has been updated numerous times, version -07 being a proof of that.

The biggest concern regarding your proposed text is that it implies to
rule out the details of the bridge module, which is OK IMO from the
framework and requirements draft and if I understand correctly was
stated by originally proposed text, however it also rules out from
solutions perspective, and I see no reason for doing such in the
framework or requirements document.

Regarding the germane point, at least I am not personally aware of
requirements having been qualified in this manner in past, please advise
if this is not the case. Whether a solution is standards track or
informational track should not influence the requirements, so far as we
do not have disagreements on the requirements. This is infact a good
reason why solutions should follow requirements instead of other way
round. Engineering requirements from solutions will be
counterproductive, in my view.

Hopefully, we can get to the last call and start addressing the
solutions, which is likely what you are concerned about and likely the
group is also interested in addressing, including us.

Cheers,
---
Dinesh

<snipped>

I don't understand.  Your explanation above is confusing for two
reasons:
1)  First, if you look above at the top-most comment in this thread
(relative to the Framework section) you agree that the "details
regarding bridge operation for MTU-s and PE-rs ... are outside the  
scope of this document as they are covered in the IEEE standards".   
Now, you seem to be saying the opposite in the Requirements section.   
Specifically, that the above statement was irrelevant and now you are
implying that you do want/need to duplicate IEEE standards in the  
requirements for OAM solutions that will be proposed for VPLS/VPWS.   
Or, perhaps I'm misunderstanding the rationale behind your explanation
or intent?
2)  Second, and much more germane to the requirements section, is what
portion(s) of the requirements section apply to OAM solutions that will
go Standards Track and, separately, what requirement(s) apply to OAM
solutions that may go Informational, (assuming they are not duplicating
or interfering with standards/protocols from other SDO's)?

Thanks,

-shane

---

From: "Vinit Bansal \(vbansal\)" <[email-masked]>
Date: Tue, 27 Feb 2007 14:07:12 -0800

Hi Ali & Dinesh,

I have a minor comment on the frame delay and frame delay variation
requirements for VPLS and VPWS service. The frame delay variation
requirements are dependent on the one-way frame delay measurement
requirements and have been prioritized differently.

R(4b) & R(15b): Frame Delay one-way requirement is SHOULD.
R(5)  & R(16) : Frame Delay Variation requirement is MUST.

Thanks
Vinit

---

From: "Ali Sajassi \(sajassi\)" <[email-masked]>
Date: Tue, 27 Feb 2007 14:15:25 -0800

Vinit,

One-way frame delay measurement requires clock synchronization in the
network and that's why it is a "should"; whereas, frame delay variation
doesn't require clock synch and should be lot simpler to implement.

-Ali 

> From: Vinit Bansal (vbansal) 
> Sent: Tuesday, February 27, 2007 2:07 PM
> To: Dinesh Mohan; Ali Sajassi (sajassi)
> Cc: [email-masked]
> I have a minor comment on the frame delay and frame delay 
> variation requirements for VPLS and VPWS service. The frame 
> delay variation requirements are dependent on the one-way 
> frame delay measurement requirements and have been 
> prioritized differently.
>

---

From: Shane Amante <[email-masked]>
Date: Wed, 28 Feb 2007 00:20:18 -0700

Ali,

On Feb 27, 2007, at 12:15 AM, Ali Sajassi (sajassi) wrote:

> and RFC4446 which include bridge module.

Perhaps I wasn't clear in my originally proposed text or follow-up  
comments.  Let me try again, this time using a different approach.

Can we agree that there is a portion of the VPLS architecture that  
relates to native Ethernet, for example, when the communication path  
between an MTU-s and an upstream PE-rs is using Q-in-Q  
encapsulation?  If yes, then I have not seen any *requirement* in the  
requirements section to acknowledge that the goal of any proposed  
solution is to, at most, inter-work with -- but, MUST NOT break! --  
existing IEEE/ITU OAM standards, related to the native Ethernet  
service-layer of VPLS, in order to provide an "end-to-end" solution  
for VPLS OAM.

There are some requirements in Section 6.11, (Transport  
Independence), related to OAM transport independence & interworking/ 
adaptation.  However, what I am recommending is that you be more  
specific in Section 6 and clearly articulate that VPLS OAM solutions  
MUST NOT: a) break existing IEEE/ITU OAM protocols; or, b) define  
extensions or wholly new, competing OAM messages for IEEE/ITU OAM  
protocols.  Clearly, this would indicate to solutions designers that  
if a solution requires (b), they had better work those changes  
through the IEEE/ITU and, only after said changes, extensions, etc.  
are approved in the appropriate SDO, may a VPLS OAM solution consider  
interworking with that protocol.

-shane

> Covering the OAM requirement

---

From: Shane Amante <[email-masked]>
Date: Wed, 28 Feb 2007 00:33:07 -0700

Dinesh,

> framework or requirements document.

Perhaps my point wasn't coming across clearly in my previous  
attempts.  Please refer to the e-mail where I just responded to Ali  
to see if that clears things up.

> counterproductive, in my view.

IMO, the point of requirements is to, as much as possible, constrain  
and guide the "scope" of proposed solutions, so that solutions:
a)  provide benefit to the end-users who will use them;
b)  avoid arguments down the road interpreting what requirements  
really meant; and, most importantly,
c)  assuming there are multiple, competing solutions, then the  
requirements document should be the main reference to evaluate how  
completely each solution satisfies the requirements.

IOW, the more clear the requirements, the more benefit I believe it  
provides everyone down the road.

-shane