Subject: L2VPN (Re-)charter: VPLS OAM

From: Shane Amante <[email-masked]>
Date: Tue, 01 Apr 2008 15:30:43 -0600

All,

Since there been a variety of comments about the re-charter, I'm going 
to attempt to group related comments and respond to them that way. 
Hopefully, this way people can follow along more easily.  See below for 
the first response related to VPLS OAM.

---snip---

Dinesh, Ali,

------Dinesh wrote------
 > "L2VPN's will make use of existing IETF specified mechanisms unless
 > there are technical reasons why the existing mechanisms are
 > insufficient or unnecessary."
 >
 > DM>> Which IETF mechanisms are we referring to? This statement seems
 > quite vague, can we offer some guidance around the relevance of this
 > statement.

Actually, this statement was copied from the PWE3 charter.  The intent 
is to state that L2VPN WG will re-use MPLS (or L2TPv3) as defined by the 
MPLS WG for the PSN, PW's as defined by PWE3 for service-layer 
encapsulation, SNMP for MIB's, etc.  See below for more.

 > "In particular, the L2VPN WG will define extensions to Pseudowire
 > management (OAM) mechanisms, specifically Pseudowire Virtual Circuit
 > Connectivity Verification (VCCV), for VPLS.  Those VCCV extensions '
 > will be reviewed by PWE3 to ensure they are inline with the overall
 > design/architecture of VCCV."
 >
 > DM>> Is it necessary to include this statement in the charter? This is
 > presuming solutions that may not have been completely hashed out yet.
 > Isn't the first statement Sufficient in this para "The L2VPN WG will
 > provide extensions of existing protocols that will be discussed in
 > protocol-specific WG's."

You raise a fair point.  I am willing to change the "will" to a "may" as 
suggested by Ali, (see below for that change).  That leaves open the 
potential of us extending VCCV within this proposed charter, rather than 
having to come back and re-charter again or, worse, toss around multiple 
drafts in both PWE3 and L2VPN if we determine a need to extend VCCV. 
Plus, given all the recent work on T-MPLS and T-MPLS OAM, our AD's 
wanted to make it explicit that a portion of VCCV may be worked on 
within L2VPN, so people/other-SDO's know where to direct 
liaisons/questions/etc.

------Ali wrote------
 > i) "L2VPN's will make use of existing IETF specified mechanisms unless
 > there are technical reasons why the existing mechanisms are
 > insufficient or unnecessary."
 >
 > AS> This statement needs further clarification. I would suggest the
 > following text: "L2VPN solutions will make use of existing IETF PWs
 > and PSN specified mechanisms for providing L2VPN services unless there
 > are technical reasons why the existing mechanisms are insufficient or
 > unnecessary. Furthermore, L2VPN solutions will make use of native
 > service mechanisms when applicable for providing L2VPN services -
 > e.g., use of Ethernet OAM for monitoring Ethernet native service.

First, the intent of the sentence /is not/ to create an exhaustive list 
of all protocols we may (or may not) end up (re-)using from other WG's, 
or other SDO's for that matter.  Second, the last sentence you suggested 
appears to be saying that 802.1ag ("native service-layer mechansims") 
should be the only OAM tool for VPLS.  I'm pretty confident we don't 
have WG consensus to make that statement in the charter, particularly 
given the "lively" debates that have ensued at WG meetings when 
discussing the two proposed OAM solutions.

However, to bring this back to the charter discussion, I believe the 
sentence is OK 'as-is', since it leaves room to discuss and make use of 
alternate mechanisms if "the existing mechansisms are insufficent or 
unnecessary".  Specific to VPLS OAM, Dinesh has already been 
highlighting (in his presentations at the WG meetings) the areas where 
.1ag may provide a superior solution for *some* aspects of VPLS OAM.  In 
addition, Olen's draft (draft-stokes-l2vpn-cfm-vccv-oam-00) has also 
attempted a more in-depth analysis.  Unfortunately, the only debate on 
Olen's draft /on the mailing list/ has been about just one aspect of the 
draft, specifically the H-VPLS reference model, which has already been 
acknowledged as incorrect.  We need to move on from that and look at the 
rest of Olen's draft to objectively determine what are the strengths & 
weaknesses of either or both (i.e. complementary) OAM approaches if 
we're going to make progress on OAM.

 > ii) "The L2VPN WG will provide extensions of existing protocols that
 > will be discussed in protocol-specific WG's.  In particular, the L2VPN
 > WG will define extensions to pseudowire management (OAM) mechanisms,
 > specifically Pseudowire Virtual Circuit Connectivity Verification
 > (VCCV), for VPLS.  Those VCCV extensions will be reviewed by PWE3 to
 > ensure they are inline with the overall design/architecture of VCCV."
 >
 > AS> This statement already assumes that VCCV extensions are needed for
 > VPLS which is not the case. I would prefer to either remove 2nd and
 > 3rd sentences from the above para. If we want to keep these sentences,
 > then we need to change "will" to "may" in 2nd sentence.

OK, I'll accept the change in your last sentence, (change from "will" to 
"may" in the second sentence).  Specifically, I'll reword the charter as 
follows:
---snip---
The L2VPN WG will provide extensions of existing protocols that
will be discussed in protocol-specific WG's.  In particular, the L2VPN
WG may define extensions to pseudowire management (OAM) mechanisms,
specifically Pseudowire Virtual Circuit Connectivity Verification
(VCCV), for VPLS.  Those VCCV extensions will be reviewed by PWE3 to
ensure they are inline with the overall design/architecture of VCCV."
---snip---

 > iii) "Furthermore, the L2VPN WG will not define protocol inter-working
 > between a VPLS or VPWS and native service-layer control, OAM or
 > resiliency mechanisms, as those will be defined by the PWE3 WG.  On
 > the other hand, the L2VPN WG will define how to operate native
 > service-layer control, OAM or resiliency mechanisms on top of a VPLS
 > or VPWS service."
 >
 > AS> This statement needs to be refined to indicate that the
 > interworking between the native service-layer and its associated PW
 > for the purpose of control, OAM, or resiliency mechanisms, shall be
 > defined by the PWE3 WG. However, the interworking between the native
 > service-layer and the VPN service, associated with a group of PWs and
 > their forwarding tables, will be defined by the L2VPN WG when needed.

I'm not sure I understand the intent or need for the last sentence you 
propose.  Can you elaborate on it?  Specifically, I'm trying to 
understand what might just be implementation details irrelevant to 
L2VPN, say specific to the Bridge Module and AC's, vs. some interaction 
between PW's and the Bridge Module or something else.

Thanks,

-shane

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Wed, 2 Apr 2008 05:39:19 -0700

Shane,

Please refer to my reply inline ...

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Shane Amante
> Sent: Tuesday, April 01, 2008 2:31 PM
> To: [email-masked]
> Subject: L2VPN (Re-)charter: VPLS OAM
> 
> All,
> 
> Since there been a variety of comments about the re-charter, 
> I'm going to attempt to group related comments and respond to 
> them that way. 
> Hopefully, this way people can follow along more easily.  See 
> below for the first response related to VPLS OAM.
> 
> ---snip---
> 
> Dinesh, Ali,
> 
> ------Dinesh wrote------
>  > "L2VPN's will make use of existing IETF specified 
> mechanisms unless  > there are technical reasons why the 
> existing mechanisms are  > insufficient or unnecessary."
>  >
>  > DM>> Which IETF mechanisms are we referring to? This 
> statement seems  > quite vague, can we offer some guidance 
> around the relevance of this  > statement.
> 
> Actually, this statement was copied from the PWE3 charter.  
> The intent is to state that L2VPN WG will re-use MPLS (or 
> L2TPv3) as defined by the MPLS WG for the PSN, PW's as 
> defined by PWE3 for service-layer encapsulation, SNMP for 
> MIB's, etc.  See below for more.
> 
> 
>  > "In particular, the L2VPN WG will define extensions to 
> Pseudowire  > management (OAM) mechanisms, specifically 
> Pseudowire Virtual Circuit  > Connectivity Verification 
> (VCCV), for VPLS.  Those VCCV extensions '
>  > will be reviewed by PWE3 to ensure they are inline with 
> the overall  > design/architecture of VCCV."
>  >
>  > DM>> Is it necessary to include this statement in the 
> charter? This is  > presuming solutions that may not have 
> been completely hashed out yet.
>  > Isn't the first statement Sufficient in this para "The 
> L2VPN WG will  > provide extensions of existing protocols 
> that will be discussed in  > protocol-specific WG's."
> 
> You raise a fair point.  I am willing to change the "will" to 
> a "may" as suggested by Ali, (see below for that change).  
> That leaves open the potential of us extending VCCV within 
> this proposed charter, rather than having to come back and 
> re-charter again or, worse, toss around multiple drafts in 
> both PWE3 and L2VPN if we determine a need to extend VCCV. 
> Plus, given all the recent work on T-MPLS and T-MPLS OAM, our 
> AD's wanted to make it explicit that a portion of VCCV may be 
> worked on within L2VPN, so people/other-SDO's know where to 
> direct liaisons/questions/etc.
> 
> 
> ------Ali wrote------
>  > i) "L2VPN's will make use of existing IETF specified 
> mechanisms unless  > there are technical reasons why the 
> existing mechanisms are  > insufficient or unnecessary."
>  >
>  > AS> This statement needs further clarification. I would 
> suggest the  > following text: "L2VPN solutions will make use 
> of existing IETF PWs  > and PSN specified mechanisms for 
> providing L2VPN services unless there  > are technical 
> reasons why the existing mechanisms are insufficient or  > 
> unnecessary. Furthermore, L2VPN solutions will make use of 
> native  > service mechanisms when applicable for providing 
> L2VPN services -  > e.g., use of Ethernet OAM for monitoring 
> Ethernet native service.
> 
> First, the intent of the sentence /is not/ to create an 
> exhaustive list of all protocols we may (or may not) end up 
> (re-)using from other WG's, or other SDO's for that matter.  
> Second, the last sentence you suggested appears to be saying 
> that 802.1ag ("native service-layer mechansims") should be 
> the only OAM tool for VPLS.  I'm pretty confident we don't 
> have WG consensus to make that statement in the charter, 
> particularly given the "lively" debates that have ensued at 
> WG meetings when discussing the two proposed OAM solutions.
>

Yes, because the intent is not to create and exhaustive list, I used
"e.g.," rather than listing all the protocols. Also, my intention was
not to say "that 802.1ag should be the only OAM tool for VPLS". So, you
can change "will" to "should" in my second sentence. Basically, all I am
saying is that if there is already a mechanism for a native service,
then that mechanism should be considered first before attempting to
re-invent the wheel. 
 
> However, to bring this back to the charter discussion, I 
> believe the sentence is OK 'as-is', since it leaves room to 
> discuss and make use of alternate mechanisms if "the existing 
> mechansisms are insufficent or unnecessary".  Specific to 
> VPLS OAM, Dinesh has already been highlighting (in his 
> presentations at the WG meetings) the areas where .1ag may 
> provide a superior solution for *some* aspects of VPLS OAM.  
> In addition, Olen's draft 
> (draft-stokes-l2vpn-cfm-vccv-oam-00) has also attempted a 
> more in-depth analysis.  Unfortunately, the only debate on 
> Olen's draft /on the mailing list/ has been about just one 
> aspect of the draft, specifically the H-VPLS reference model, 
> which has already been acknowledged as incorrect.  We need to 
> move on from that and look at the rest of Olen's draft to 
> objectively determine what are the strengths & weaknesses of 
> either or both (i.e. complementary) OAM approaches if we're 
> going to make progress on OAM.
> 

If the intent of this statement is to say:
"that L2VPN WG will re-use MPLS (or L2TPv3) as defined by the MPLS WG
for the PSN, PW's as  defined by PWE3 for service-layer encapsulation,
SNMP for MIB's, etc."
As you stated, then, it should be stated as such as the first sentence
of my proposed text:
"L2VPN solutions will make use of existing IETF PW and PSN specified
mechanisms for providing L2VPN services unless there are technical
reasons why the existing mechanisms are insufficient or unnecessary"
My concern is that by having a vague sentence as such, then it makes it
open to interpretation and some people may claim that VCCV-based OAM
mechanism for VPLS (and Ethernet services) is the preferred mechanism
over native Ethernet OAM (802.1ag/y.1731) because the charter has stated
so !! 
I think we need to select an OAM mechanism for VPLS based on its
technical merit as we are progressing in this direction in the WG. So,
the charter should state that VPLS OAM work is needed without
intentionally/unintentionally favoring one mechanism over the other.  

> 
>  > ii) "The L2VPN WG will provide extensions of existing 
> protocols that  > will be discussed in protocol-specific 
> WG's.  In particular, the L2VPN  > WG will define extensions 
> to pseudowire management (OAM) mechanisms,  > specifically 
> Pseudowire Virtual Circuit Connectivity Verification  > 
> (VCCV), for VPLS.  Those VCCV extensions will be reviewed by 
> PWE3 to  > ensure they are inline with the overall 
>  > AS> This statement already assumes that VCCV extensions 
> are needed for  > VPLS which is not the case. I would prefer 
> to either remove 2nd and  > 3rd sentences from the above 
> para. If we want to keep these sentences,  > then we need to 
> change "will" to "may" in 2nd sentence.
> 
> OK, I'll accept the change in your last sentence, (change 
> from "will" to "may" in the second sentence).  Specifically, 
> I'll reword the charter as
> follows:
> ---snip---
> The L2VPN WG will provide extensions of existing protocols 
> that will be discussed in protocol-specific WG's.  In 
> particular, the L2VPN WG may define extensions to pseudowire 
> management (OAM) mechanisms, specifically Pseudowire Virtual 
> Circuit Connectivity Verification (VCCV), for VPLS.  Those 
> VCCV extensions will be reviewed by PWE3 to ensure they are 
> inline with the overall design/architecture of VCCV."
> ---snip---
>

O.K. Looks good.
 
> 
> 
>  > iii) "Furthermore, the L2VPN WG will not define protocol 
> inter-working  > between a VPLS or VPWS and native 
> service-layer control, OAM or  > resiliency mechanisms, as 
> those will be defined by the PWE3 WG.  On  > the other hand, 
> the L2VPN WG will define how to operate native  > 
> service-layer control, OAM or resiliency mechanisms on top of 
> a VPLS  > or VPWS service."
>  >
>  > AS> This statement needs to be refined to indicate that 
> the  > interworking between the native service-layer and its 
> associated PW  > for the purpose of control, OAM, or 
> resiliency mechanisms, shall be  > defined by the PWE3 WG. 
> However, the interworking between the native  > service-layer 
> and the VPN service, associated with a group of PWs and  > 
> I'm not sure I understand the intent or need for the last 
> sentence you propose.  Can you elaborate on it?  
> Specifically, I'm trying to understand what might just be 
> implementation details irrelevant to L2VPN, say specific to 
> the Bridge Module and AC's, vs. some interaction between PW's 
> and the Bridge Module or something else.
> 

An example of it would be the dual-homing and redundancy support between
an 802.1ah access network and a VPLS core; where, 802.1ah access network
is running L2GP protocol in order to avoid running its MSTP over VPLS
core. In such scenario, upon a topology change, the 802.1ah access
network would signal the PE using MVRP message to indicate the VLANs
that are affected as the result of topology change and if LDP is used
for C-MAC withdraw, then the PE needs to process the MVRP message and
generate LDP MAC withdraw messages for the affected service instances.

Cheers,
Ali

---

From: Thomas Nadeau <[email-masked]>
Date: Wed, 2 Apr 2008 09:53:09 -0400

> intentionally/unintentionally favoring one mechanism over the other.

	I would agree with Ali here, although I do agree with the text
stating that we will reuse existing IEEE, MPLS and PWE3 mechanisms where
we can.

	--Tom

---

From: "BALUS Florin" <[email-masked]>
Date: Wed, 2 Apr 2008 10:40:46 -0500

I think the important aspect that Shane is trying to capture in the
L2VPN charter is that our focus is to address required extensions to the
mechanisms specific to the PSNs (IP/MPLS) and PWE3 infrastructure that
is common to both VPLS and VPWS.

I do not think we should try to step over other people's toes and work
on extending the protocols developed by other organizations (e.g. IEEE)
to address needs specific to our PSNs or PWE3 infrastructure. 

We can write specifications showing applicability of native mechanisms
to our services but if changes are required to these protocols and our
existing L2VPN mechanisms can't do it then it should be the task of the
originating organizations to step in and change their protocols. As much
as we do not want people from other organizations stepping in to tell us
what to do with PWE3/MPLS OAM, I do not think we should try to do IEEE
job. 

We can write informational RFCs showing how we can re-use the IEEE stuff
and then push the required protocol work to them. We do not have anyhow
processes aligned to their style of work/document structure to be able
to produce extensions consistent with their models.

> On Behalf Of Thomas Nadeau
> Sent: Wednesday, April 02, 2008 6:53 AM
> To: Ali Sajassi (sajassi)
> Cc: [email-masked]; Shane Amante
> Subject: Re: L2VPN (Re-)charter: VPLS OAM
> 
> 
> >> From: [email-masked] [mailto:[email-masked]] On 
> >> Behalf Of Shane Amante
> >> Since there been a variety of comments about the re-charter, I'm 
> >> going to attempt to group related comments and respond to 
> them that 
> >> way.
> >> Hopefully, this way people can follow along more easily.  
> See below 
> >> for the first response related to VPLS OAM.
> >>
> >> ---snip---
> >>
> >> Dinesh, Ali,
> >>
> >> ------Dinesh wrote------
> >> mechanisms unless  > there are technical reasons why the existing 
> >> mechanisms are  > insufficient or unnecessary."
> >>>
> >> L2TPv3) as defined by the MPLS WG for the PSN, PW's as defined by 
> >> PWE3 for service-layer encapsulation, SNMP for MIB's, etc. 
>  See below 
> >> for more.
> >>
> >>
> >> Pseudowire  > management (OAM) mechanisms, specifically Pseudowire 
> >> Virtual Circuit  > Connectivity Verification (VCCV), for 
> VPLS.  Those 
> >> VCCV extensions '
> >> charter? This is  > presuming solutions that may not have been 
> >> completely hashed out yet.
> that will 
> >> be discussed in  > protocol-specific WG's."
> >>
> >> You raise a fair point.  I am willing to change the "will" 
> to a "may" 
> >> as suggested by Ali, (see below for that change).
> >> That leaves open the potential of us extending VCCV within this 
> >> proposed charter, rather than having to come back and re-charter 
> >> again or, worse, toss around multiple drafts in both PWE3 
> and L2VPN 
> >> if we determine a need to extend VCCV.
> >> mechanisms unless  > there are technical reasons why the existing 
> >> mechanisms are  > insufficient or unnecessary."
> >>>
> >> suggest the  > following text: "L2VPN solutions will make use of 
> >> existing IETF PWs  > and PSN specified mechanisms for 
> providing L2VPN 
> >> services unless there  > are technical reasons why the existing 
> >> mechanisms are insufficient or  > unnecessary. Furthermore, L2VPN 
> >> solutions will make use of native  > service mechanisms when 
> >> applicable for providing L2VPN services -  > e.g., use of Ethernet 
> >> OAM for monitoring Ethernet native service.
> >>
> >> First, the intent of the sentence /is not/ to create an exhaustive 
> >> list of all protocols we may (or may not) end up (re-)using from 
> >> other WG's, or other SDO's for that matter.
> >> Second, the last sentence you suggested appears to be saying that 
> >> 802.1ag ("native service-layer mechansims") should be the only OAM 
> >> tool for VPLS.  I'm pretty confident we don't have WG consensus to 
> >> make that statement in the charter, particularly given the 
> "lively" 
> >> debates that have ensued at WG meetings when discussing the two 
> >> proposed OAM solutions.
> >>
> >
> > not to say "that 802.1ag should be the only OAM tool for VPLS". So, 
> > you can change "will" to "should" in my second sentence. Basically, 
> > all I am saying is that if there is already a mechanism for 
> a native 
> > service, then that mechanism should be considered first before 
> > attempting to re-invent the wheel.
> >
> believe the 
> >> sentence is OK 'as-is', since it leaves room to discuss 
> and make use 
> >> of alternate mechanisms if "the existing mechansisms are 
> insufficent 
> >> or unnecessary".  Specific to VPLS OAM, Dinesh has already been 
> >> highlighting (in his presentations at the WG meetings) the areas 
> >> where .1ag may provide a superior solution for *some* 
> aspects of VPLS 
> >> OAM.
> >> (draft-stokes-l2vpn-cfm-vccv-oam-00) has also attempted a more 
> >> in-depth analysis.  Unfortunately, the only debate on Olen's draft 
> >> /on the mailing list/ has been about just one aspect of the draft, 
> >> specifically the H-VPLS reference model, which has already been 
> >> acknowledged as incorrect.  We need to move on from that 
> and look at 
> >> the rest of Olen's draft to objectively determine what are the 
> >> strengths & weaknesses of either or both (i.e. complementary) OAM 
> >> approaches if we're going to make progress on OAM.
> >>
> >
> > My concern is that by having a vague sentence as such, then 
> it makes 
> > it open to interpretation and some people may claim that VCCV-based 
> > OAM mechanism for VPLS (and Ethernet services) is the preferred 
> > mechanism over native Ethernet OAM (802.1ag/y.1731) because the 
> > charter has stated so !!
> 	I would agree with Ali here, although I do agree with 
> the text stating that we will reuse existing IEEE, MPLS and 
> PWE3 mechanisms where we can.
> 
> 	--Tom
> 
> 
> >>>
> >> protocols that  > will be discussed in protocol-specific WG's.  In 
> >> particular, the L2VPN  > WG will define extensions to pseudowire 
> >> management (OAM) mechanisms,  > specifically Pseudowire Virtual 
> >> Circuit Connectivity Verification  > (VCCV), for VPLS.  Those VCCV 
> >> extensions will be reviewed by
> >> are needed for  > VPLS which is not the case. I would prefer to 
> >> either remove 2nd and  > 3rd sentences from the above para. If we 
> >> want to keep these sentences,  > then we need to change "will" to 
> >> "may" in 2nd sentence.
> >>
> from "will" 
> >> to "may" in the second sentence).  Specifically, I'll reword the 
> >> charter as
> >> follows:
> >> ---snip---
> that will 
> >> be discussed in protocol-specific WG's.  In particular, 
> the L2VPN WG 
> >> may define extensions to pseudowire management (OAM) mechanisms, 
> >> inter-working  > between a VPLS or VPWS and native service-layer 
> >> control, OAM or  > resiliency mechanisms, as those will be 
> defined by 
> >> the PWE3 WG.  On  > the other hand, the L2VPN WG will 
> define how to 
> >> operate native  > service-layer control, OAM or resiliency 
> mechanisms 
> >> on top of a VPLS  > or VPWS service."
> >>>
> >> associated PW  > for the purpose of control, OAM, or resiliency 
> >> mechanisms, shall be  > defined by the PWE3 WG.
> >> However, the interworking between the native  > 
> service-layer and the 
> >> VPN service, associated with a group of PWs and  > their 
> forwarding 
> >> tables, will be defined by the L2VPN WG when needed.
> >>
> >> I'm not sure I understand the intent or need for the last sentence 
> >> you propose.  Can you elaborate on it?
> >> implementation details irrelevant to L2VPN, say specific to the 
> >> Bridge Module and AC's, vs. some interaction between PW's and the 
> >> Bridge Module or something else.
> >>
> >
> > An example of it would be the dual-homing and redundancy support 
> > between an 802.1ah access network and a VPLS core; where, 802.1ah 
> > access network is running L2GP protocol in order to avoid 
> running its 
> > MSTP over VPLS core. In such scenario, upon a topology change, the 
> > 802.1ah access network would signal the PE using MVRP message to 
> > indicate the VLANs that are affected as the result of 
> topology change 
> > and if LDP is used for C-MAC withdraw, then the PE needs to process 
> > the MVRP message and generate LDP MAC withdraw messages for the 
> > affected service instances.
> >
> > Cheers,
> > Ali
> >
> >
> >> Thanks,
> >>
> >> -shane
> >>
> >
> 
>

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Wed, 2 Apr 2008 09:00:21 -0700

> On Behalf Of BALUS Florin
> Sent: Wednesday, April 02, 2008 8:41 AM
> To: Thomas Nadeau; Ali Sajassi (sajassi)
> Subject: RE: L2VPN (Re-)charter: VPLS OAM
> 
> 
> I think the important aspect that Shane is trying to capture 
> in the L2VPN charter is that our focus is to address required 
> extensions to the mechanisms specific to the PSNs (IP/MPLS) 
> and PWE3 infrastructure that is common to both VPLS and VPWS.

So, we should capture it as such as I suggested rather and avoid having
a vague statement.

> 
> I do not think we should try to step over other people's toes 
> and work on extending the protocols developed by other 
> organizations (e.g. IEEE) to address needs specific to our 
> PSNs or PWE3 infrastructure. 
> 

No body is suggesting that !! specially with respect to PSN and PWs
infrastructure. The point that I made was that when it comes to support
of native services (e.g., Ethernet in case of VPLS), we should see what
is out there and leveraging existing mechanism rather than trying to
reinvent the wheel. The comment was made specifically wrt VPLS OAM. 

> We can write specifications showing applicability of native 
> mechanisms to our services but if changes are required to 
> these protocols and our existing L2VPN mechanisms can't do it 
> then it should be the task of the originating organizations 
> to step in and change their protocols. As much as we do not 
> want people from other organizations stepping in to tell us 
> what to do with PWE3/MPLS OAM, I do not think we should try 
> to do IEEE job. 
> 

No modifications to Ethernet OAM for VPLS application has been
identified or required. So lets avoid making presumptive statements.
Please take a look at the draft-ietf-l2vpn-oam-req-frmk for better
understanding of OAM requirements and framework for VPLS.

> We can write informational RFCs showing how we can re-use the 
> IEEE stuff and then push the required protocol work to them. 
> We do not have anyhow processes aligned to their style of 
> work/document structure to be able to produce extensions 
> consistent with their models.

No extensions to the existing model has been identified to support VPLS
OAM in the draft-mohan-l2vpn-vpls-oam and I am speaking as one of the
editor unless you know something that I don't :-)

-Ali

> > From: [email-masked] 
> [mailto:[email-masked]] On Behalf 
> > Of Thomas Nadeau
> existing 
> Pseudowire 
> existing 
> exhaustive 
> > stating that we will reuse existing IEEE, MPLS and
> WG's.  In

---

From: "BALUS Florin" <[email-masked]>
Date: Wed, 2 Apr 2008 14:10:16 -0500

My comments were directed at some suggestions I heard during IETF-71
where people were considering adding new TLVs to IEEE 802.1ag to address
mis-connectivity in the PWE3/PSN infrastructure, in the quest to do
everything with Ethernet OAM. 

In L2VPN WG we should start from the premise that PWE3 and IP/MPLS PSN
infrastructure is in place so the effort should be focused on extending
the available tools - e.g. PW3 or IP/MPLS OAM, VPLS LDP MAC Withdraw -
not on adapting native services to do the job. We need to make sure this
is clearly reflected in the charter.

Ali,
I was not suggesting anything about the content of your existing drafts,
we're talking about the future text for the charter that is supposed to
focus our efforts in L2VPN WG. Glad to hear we are on the same page on
the distribution of work I mentioned below. 

Florin 

> From: Ali Sajassi (sajassi) [mailto:[email-masked]] 
> Sent: Wednesday, April 02, 2008 9:00 AM
> To: BALUS Florin; Thomas Nadeau
> > Of BALUS Florin
> > L2VPN charter is that our focus is to address required 
> extensions to 
> > the mechanisms specific to the PSNs (IP/MPLS) and PWE3 
> infrastructure 
> > that is common to both VPLS and VPWS.
> 
> So, we should capture it as such as I suggested rather and 
> avoid having a vague statement.
> 
> > 
> > on extending the protocols developed by other organizations (e.g. 
> > IEEE) to address needs specific to our PSNs or PWE3 infrastructure.
> > 
> 
> No body is suggesting that !! specially with respect to PSN 
> and PWs infrastructure. The point that I made was that when 
> it comes to support of native services (e.g., Ethernet in 
> case of VPLS), we should see what is out there and leveraging 
> existing mechanism rather than trying to reinvent the wheel. 
> The comment was made specifically wrt VPLS OAM. 
> 
> > existing L2VPN mechanisms can't do it then it should be the task of 
> > the originating organizations to step in and change their 
> protocols. 
> > As much as we do not want people from other organizations 
> stepping in 
> > to tell us what to do with PWE3/MPLS OAM, I do not think we 
> should try 
> > to do IEEE job.
> > 
> 
> No modifications to Ethernet OAM for VPLS application has 
> been identified or required. So lets avoid making presumptive 
> statements.
> Please take a look at the draft-ietf-l2vpn-oam-req-frmk for 
> better understanding of OAM requirements and framework for VPLS.
> 
> > We can write informational RFCs showing how we can re-use the IEEE 
> > stuff and then push the required protocol work to them.
> > work/document structure to be able to produce extensions consistent 
> > with their models.
> 
> No extensions to the existing model has been identified to 
> support VPLS OAM in the draft-mohan-l2vpn-vpls-oam and I am 
> speaking as one of the editor unless you know something that 
> I don't :-)
> 
> -Ali
> 
> > 
> > 
> [mailto:[email-masked]] On 
> > > >> Behalf Of Shane Amante
> service-layer 
> resiliency

---

From: Shane Amante <[email-masked]>
Date: Wed, 2 Apr 2008 21:28:51 -0600

Ali,

In order to address your concern, I think we are likely focusing on  
the wrong part of the charter.  So, if you don't mind, let's address  
that text first.

The following is the proposed text in the first draft of the charter.   
Please pay attention to the last sentence:
---snip---
The L2VPN WG will not define new encapsulations, control (set-up,
configuration, maintenance or tear-down), or resiliency mechanisms
specifically related to pseudowires, because those must be defined by  
the
PWE3 WG.  Furthermore, the L2VPN WG will not define protocol inter-
working between a VPLS or VPWS and native service-layer control, OAM or
or resiliency mechanisms, as those will be defined by the PWE3 WG.  On
                                                                     ^^
the other hand, the L2VPN WG will define how to operate native service-
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
layer control, OAM or resiliency mechanisms on top of a VPLS or VPWS
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
service.
^^^^^^^^
---snip---

The intent with that sentence was specifically to capture use of  
"native service-layer ... OAM" (i.e.: 802.1ag) "/on top of/ a VPLS or  
VPWS service", (i.e.: at the service-layer).

Does the originally proposed sentence address your concern?  If not,  
how can we modify it to address your concern?

Thanks,

-shane

On Apr 2, 2008, at 6:39 AM, Ali Sajassi (sajassi) wrote:
> you
> between