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

From: "Dinesh Mohan" <[email-masked]>
Date: Thu, 1 Mar 2007 11:34:01 -0500

Shane,

I agree with the intent here to have clear requirements, however, as
noted in the other email response, not sure about the non-requirements
which are implicit in the group activities and policies. I am hoping
that at the requirements level, we are not presupposing any solutions,
though we may certainly have a view of the solution.

IMO, we could go ahead with the text proposed by Ali, and if you insist,
add a statement to the effect that Ethernet OAM extensions, if any,
required by the solutions should be pursued in relevant SDOs, and
proceed with the last call such that we can move the focus on solution
drafts. Let us know your thoughts.

---
Dinesh

-----Original Message-----
From: Shane Amante [mailto:[email-masked]] 
Sent: Wednesday, February 28, 2007 2:33 AM
To: Mohan, Dinesh (CAR:QW30)
Cc: Ali Sajassi (sajassi); [email-masked]
Subject: Re: WG Last Call: draft-ietf-l2vpn-oam-req-frmk-05
[FrameworkReview]

Dinesh,

On Feb 27, 2007, at 7:25 AM, Dinesh Mohan wrote:
> 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.

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.

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

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

> 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>
>>>> "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."
>>>
>>> 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---
>>>
>>
>> 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.
>
> 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: Shane Amante <[email-masked]>
Date: Thu, 01 Mar 2007 14:01:13 -0700

Dinesh,

> drafts. Let us know your thoughts.

Rather than rush this OAM draft through at the last minute based on 
assumptions, let's make sure that everyone is clear *now* that it 
doesn't conflict with past precedent and even requirements, etc. that 
got us here.  I think we're finally in general agreement on how to solve 
this concern so I'm not sure the value of belaboring this point.

I think you should scrap the text Ali proposed and say something more 
along the lines of Section 5.1 in RFC 4665, or at least refer to it, in 
Section 6 & 7 of the OAM draft as that will be much more clear.  I 
apologize if the original text I suggested was not clear as to my 
concerns and a proposed direction on how to resolve it.

If you agree with my suggestion, please propose text to the list on how 
you think it's best to address it.  After we've had a chance to look at 
that proposed text, fold it in to the OAM draft, publish it and we 
should then be ready for a WG LC.

Also, let's roll this discussion back in to the other e-mail, so we have 
only a single place to discuss it.

-shane

---

From: "Dinesh Mohan" <[email-masked]>
Date: Fri, 2 Mar 2007 18:48:54 -0500

Shane,

I will add the following text at the start of Section 6 and 7:

"It is noted that OAM solutions that meet the following requirements may
make use of existing OAM mechanisms e.g. Ethernet OAM, VCCV, etc.
however must not break these existing OAM mechanisms. If extensions are
required to existing OAM mechanisms, these should be coordinated with
relevant groups responsible for these OAM mechanisms."

In light of recent discussion and your agreement with the above
direction, I will remove the following text proposed earlier by Ali to
resolve your related comment:

Section 4.1.1:
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.

Section 6:
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.

Note: To meet the submission deadline, I will incorporate the changes
and submit the draft. Hopefully, this resolves all outstanding issues.

---
Dinesh

-----Original Message-----
From: Shane Amante [mailto:[email-masked]] 
Sent: Thursday, March 01, 2007 4:01 PM
To: Mohan, Dinesh (CAR:QW30)
Cc: [email-masked]; Ali Sajassi (sajassi)
Subject: Re: WG Last Call: draft-ietf-l2vpn-oam-req-frmk-05
[FrameworkReview]

Dinesh,

> IMO, we could go ahead with the text proposed by Ali, and if you 
> insist, add a statement to the effect that Ethernet OAM extensions, if

> any, required by the solutions should be pursued in relevant SDOs, and

-shane

>> in
> Please refer to the e-mail where I just responded to Ali to see if 
> that clears things up.
> 
> 

> IMO, the point of requirements is to, as much as possible, constrain 
> and guide the "scope" of proposed solutions, so that solutions:
> b)  avoid arguments down the road interpreting what requirements 
> really meant; and, most importantly,

>>>> "VPLS Forwarder" and the "Emulated LAN interface", which connects 
>>>> the VPLS
> 
>>> module ([RFC4664])." Therefore, when we define OAM for the 
>>> end-to-end VPLS service it must include bridge module.

---

From: Shane Amante <[email-masked]>
Date: Mon, 05 Mar 2007 00:03:10 -0700

Dinesh,

> and submit the draft. Hopefully, this resolves all outstanding issues.

Thank you.  This satisfies my concern.

-shane