RE: L2VPN (Re-)charter: VPLS OAM

["BALUS Florin" <[e-mail]>]

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 

> -----Original Message-----
> From: Ali Sajassi (sajassi) [mailto:[e-mail]] 
> Sent: Wednesday, April 02, 2008 9:00 AM
> To: BALUS Florin; Thomas Nadeau
> Cc: [e-mail]; Shane Amante
> Subject: RE: L2VPN (Re-)charter: VPLS OAM
> 
>  
> 
> > -----Original Message-----
> > From: [e-mail] 
> [mailto:[e-mail]] On Behalf 
> > Of BALUS Florin
> > Sent: Wednesday, April 02, 2008 8:41 AM
> > To: Thomas Nadeau; Ali Sajassi (sajassi)
> > Cc: [e-mail]; Shane Amante
> > 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
> 
> > 
> > 
> > > -----Original Message-----
> > > From: [e-mail]
> > [mailto:[e-mail]] On Behalf
> > > Of Thomas Nadeau
> > > Sent: Wednesday, April 02, 2008 6:53 AM
> > > To: Ali Sajassi (sajassi)
> > > Cc: [e-mail]; Shane Amante
> > > Subject: Re: L2VPN (Re-)charter: VPLS OAM
> > > 
> > > 
> > > On Apr 2, 2008, at 8:39 AM, Ali Sajassi (sajassi) wrote:
> > > >
> > > > Shane,
> > > >
> > > > Please refer to my reply inline ...
> > > >
> > > >> -----Original Message-----
> > > >> From: [e-mail] 
> [mailto:[e-mail]] On 
> > > >> Behalf Of Shane Amante
> > > >> Sent: Tuesday, April 01, 2008 2:31 PM
> > > >> To: [e-mail]
> > > >> 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.
> > > 
> > > 	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
> > > 
> > > 
> > > >>>
> > > >>> 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---
> > > >>
> > > >
> > > > 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  > 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.
> > > >>
> > > >
> > > > 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
> > > >>
> > > >
> > > 
> > > 
> > 
>