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

From: Shane Amante <[email-masked]>
Date: Sun, 23 Jul 2006 18:20:11 -0600

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.

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

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

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

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.

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.

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

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