Fixed.<= /div>

CFM =85 defines concept =85 Maintenance Association =85

Added.<= /div>

Sec.1.3 MEG, Maintenance Entity Group, is object of Y.1731 equivalent to MA= of CFM. Note that MEG is used in MPLS-TP OAM as well.

Added MA to th= e terminology section (picked the CFM terminology to use consistently for t= he document, also per your comment below)

Definition of MIP is not correct. MIP can terminate certain OAM, both Ether= net and MPLS-TP, frames, e.g. ETH-LB.

Good catch, fi= xed.

Maintenance Domain, as mentioned in 1.1, is object of CFM and is not used i= n Y.1731. Suggest use consistent terminology, either CFM or Y.1731.

Good point, we= nt with the CFM terminology.

Figure 2, can use EFM (Ethernet First Mile) OAM instead of 802.3 OAM. (Note= that there are two Figure 2 in the document =96 Section 2.1 and Section 3.= 1.1.2.1)

Fixed figure n= umber.

Section 2.2
- Characterize whether MEP on PEs SHOULD be Up, Down or both.

Added.<= /div>

Section 2.4
- Would BFD (RFC 5880, RFC 5881, RFC 5883, RFC 5884, and RFC 5885) be applica= ble as well as RFC 6428?

RFC 5885 doesn= 't apply, as it is highly unlikely to use pseudowires as an underlying tran= sport mechanism for EVPN. A more likely case would be pseudowire access int= o EVPN network, but in this latter case RFC 5885 acts as a Network OAM, rather than a Transport OAM. By the = same token, for RFC 6428, the LSP related= mechanisms apply (Not the PW). The rest apply. Updated the section accordingly.

Section 2.6
- I think that OAM interworking is most useful when it exists between proacti= ve OAM mechanisms whether it in peer-to-peer or client-server model. I don= =92t see that there=92s requirement of proactive Network OAM. Should there = be one? E.g. =93E-VPN Network OAM SHOULD provide both proactive and on-demand mechanisms of monitoring its data pla= ne operation and data plane conformance to state of its control plane.=94

Agreed. Added.

Section 3.1.1
- Please consider splitting the sentence in two with the second being like = =93=85 without time bound. Certain actions, e.g. protection switchover or a= larm indication signaling, could be associated with events of entering and = clearing fault state=94.
Section 3.1.1.1
- I think that another term for =93a specified path taken by a particular use= r data flow=94 is =93in-band monitoring=94.
- I think that monitoring of =93representative path=94 may not be reliable te= st of MEP hosting node liveliness. As I understand, it still verification o= f the MEP liveliness but out-band. Or it is implied that the target of this= monitoring is not the MEP but an ID associated with the node where the MEP defined? Then wouldn=92t that be ve= rification of a control plane rather than data plane operation?<= /li>
- What is understood as =93test flow=94? Is that using methods of active moni= toring/measurements when specifically constructed test packets being inject= ed vs. passive monitoring/measurements when data flow(s) used to monitor an= d measure performance?
- =93Monitoring of all ECMP paths between MEPs is not a requirement for E-VPN= OAM.=94 Is in regard to concurrent monitoring all paths between two (?) ME= Ps or to problem of exercising particular paths at-will?
Section 3.1.1.2.2
- What is understood by =93support RDI=94? Is it merely ability to signal LoC= defect to remote MEP(s) or ability, as well, to recognize RDI from a remot= e MEP? Should note that in multipoint MA RDI is not really useful as indica= tor of unidirectional fault since there=92s no indication of with which MEP the sender detected LoC defect. If unidire= ctional LoC is likely not guarantee of bi-directional fault, then MA MUST b= e p2p.
Section 3.1.2.2
- Connectivity Verification vs. Continuity Check. There=92s reference to =93c= onnectivity faults=94 in the first paragraph. Should it be changed to =93co= ntinuity=94 or on-demand OAM, at least in E-VPN Service OAM, required to de= tect mis-connectivity? If =93yes=94, why the same is not applicable to proactive OAM for E-VPN Service?
Section 3.2
- I wouldn=92t refer to scheduled on-demand PM tests as =93proactive=94 since= these are still bound in time unlike proactive that are not bound in time.=
- But there is at least one example of truly proactive LM in Y.1731 that uses= ETH-CC frames. So, there=92s a distinction between proactive and on-demand= PM.
Section 3.2.1
- Use of Synthetic LM is usually in out-of-service state as test frames expec= ted to be statistically representative of real data flow. LM in mp2mp netwo= rk can be constructed of set of p2p LM metrics.

draft-vgovindan-l2vpn-ev= pn-bfd-00

= =B7 o If there=92s a need to have BFD session = per ECMP path/EL how such session can be demuxed at the tail if at the boot= strap it would allocate only one myDiscriminator per source IP/FEC combinat= ion?

o Effectively, IMO, there are separate p2p= BFD sessions between head and tail of mp2p tunnel. Right?

= =B7 o Since two types of BFD encapsulation ava= ilable, I think it would be better to require that only one type be used to= monitor particular E-VPN at its Network level. Should it say =93The same t= ype of BFD encapsulation, either IP or VCCV, MUST be used to monitor all tunnels of the particular E-VPN at it= s Network level.=94

o s/G-Ach/G-ACh/

= =B7 o Not clear which BFD modes can be used an= d in what manner as on-demand OAM to troubleshoot and localize fault. AFAIK= , BFD-based OAM used primarily as proactive continuity check and LSP Ping a= s on-demand troubleshooting tool.

--_000_CECCC86217B95ssalamciscocom_-- From ssalam@cisco.com Tue Dec 10 16:28:21 2013 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB4811AD94A for ; Tue, 10 Dec 2013 16:28:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.501 X-Spam-Level: X-Spam-Status: No, score=-9.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v-bEfwIugYPQ for ; Tue, 10 Dec 2013 16:28:18 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) by ietfa.amsl.com (Postfix) with ESMTP id C05BA1AD8F1 for ; Tue, 10 Dec 2013 16:28:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=55278; q=dns/txt; s=iport; t=1386721692; x=1387931292; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=2Aoi+qedV/chNZ0XbmmuVyRtZbCWgElojCijOoG7wtE=; b=Qu+ihAXFZ6buw2ftF7N4JhAJaGmfWuQSO+L0aN2TqMZaqrNDOr33AnvZ gn/nSXFAF9GbBiAEI/mysPQCB5Re1uAvt79HUZyArw3noy3IHiFpjBSn9 bZODeuyc0k1Hk6jdai7mqkDihsD7SKnzZRe++Q8OlZHSxfaYaWQHC0TPD o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAGWwp1KtJV2d/2dsb2JhbABZgkMjIThTuSGBIBZ0giUBAgQtOiQBCBEDAQIhAQYoERQJCAEBBAESG4dVAw8BulUNhmcXjHOCARiENASWKYFrjFqFOYFrgT6CKg X-IronPort-AV: E=Sophos;i="4.93,867,1378857600"; d="scan'208,217";a="5837274" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-6.cisco.com with ESMTP; 11 Dec 2013 00:28:11 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id rBB0SBZH023380 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 11 Dec 2013 00:28:11 GMT Received: from xmb-aln-x13.cisco.com ([fe80::5404:b599:9f57:834b]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0123.003; Tue, 10 Dec 2013 18:28:11 -0600 From: "Samer Salam (ssalam)" To: Gregory Mirsky , "Ali Sajassi (sajassi)" , "Sam Aldrin (aldrin.ietf@gmail.com)" , "John E Drake (jdrake@juniper.net)" , "Vengada Prasad Govindan (venggovi)" , "l2vpn@ietf.org" Subject: Re: Comments on draft-salam-l2vpn-evpn-oam-req-frmwk and draft-vgovindan-l2vpn-evpn-bfd Thread-Topic: Comments on draft-salam-l2vpn-evpn-oam-req-frmwk and draft-vgovindan-l2vpn-evpn-bfd Thread-Index: Ac7lDSTCOfeFij7fTiOpIkx3ocp0YQQ5iE0AAAD0+QA= Date: Wed, 11 Dec 2013 00:28:10 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [10.21.150.4] Content-Type: multipart/alternative; boundary="_000_CECCEBA217CA3ssalamciscocom_" MIME-Version: 1.0 X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 00:28:22 -0000 --_000_CECCEBA217CA3ssalamciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hit "send" instead of "save", further responses inline=85 From: Samer Salam > Date: Tuesday, 10 December, 2013 4:00 PM To: Gregory Mirsky >, "Ali Sajassi (sajassi)" >, "Sam Aldrin (aldrin.ietf@gmail.com)" <= aldrin.ietf@gmail.com>, "John E Drake (jdrake= @juniper.net)" >, "Vengada Prasad Govindan (venggovi)" >, "l2vpn@ietf.org" > Subject: Re: Comments on draft-salam-l2vpn-evpn-oam-req-frmwk and draft-vgo= vindan-l2vpn-evpn-bfd Hi Greg, Thanks again for your comments. Please find comment resolution/responses on= the Requirements/Framework draft inline=85 From: Gregory Mirsky > Date: Tuesday, 19 November, 2013 4:56 AM To: Samer Salam >, "Ali Sajassi (= sajassi)" >, "Sam Aldrin (aldri= n.ietf@gmail.com)" >, "John E Drake (jdrake@juniper.net)" >, "Vengada = Prasad Govindan (venggovi)" >= , "l2vpn@ietf.org" > Subject: Comments on draft-salam-l2vpn-evpn-oam-req-frmwk and draft-vgovind= an-l2vpn-evpn-bfd Dear Authors, et. al, very useful and timely raised questions. Please find my comments to both do= cuments below. Greatly appreciate your kind consideration and am looking fo= rward to the discussion. Regards, Greg draft-salam-l2vpn-evpn-oam-req-frmwk-01 * Use cases. Multi-carrier E-VPN. Ethernet Service OAM is instrumented,= through MEG Level hierarchy, to present customer, provider, and operator s= copes of OAM. If multi-carrier E-VPN is viable use case, then support of ME= P and its functionalities becomes a MUST for provider and operator scopes. = Then, if multi-carrier E-VPN is viable use case, there might be new require= ments towards E-VPN Network OAM. * Sec.1.1 s/Public/Packet/ Fixed. * CFM =85 defines concept =85 Maintenance Association =85 Added. * Sec.1.3 MEG, Maintenance Entity Group, is object of Y.1731 equivalent= to MA of CFM. Note that MEG is used in MPLS-TP OAM as well. Added MA to the terminology section (picked the CFM terminology to use cons= istently for the document, also per your comment below) * Definition of MIP is not correct. MIP can terminate certain OAM, both= Ethernet and MPLS-TP, frames, e.g. ETH-LB. Good catch, fixed. * Maintenance Domain, as mentioned in 1.1, is object of CFM and is not = used in Y.1731. Suggest use consistent terminology, either CFM or Y.1731. Good point, went with the CFM terminology. * Figure 2, can use EFM (Ethernet First Mile) OAM instead of 802.3 OAM.= (Note that there are two Figure 2 in the document =96 Section 2.1 and Sect= ion 3.1.1.2.1) Fixed figure number. * Section 2.2 * Characterize whether MEP on PEs SHOULD be Up, Down or both. Added. * Section 2.4 * Would BFD (RFC 5880, RFC 5881, RFC 5883, RFC 5884, and RFC 5885) b= e applicable as well as RFC 6428? RFC 5885 doesn't apply, as it is highly unlikely to use pseudowires as an u= nderlying transport mechanism for EVPN. A more likely case would be pseudow= ire access into EVPN network, but in this latter case RFC 5885 acts as a Ne= twork OAM, rather than a Transport OAM. By the same token, for RFC 6428, = the LSP related mechanisms apply (Not the PW). The rest apply. Updated the = section accordingly. * Section 2.6 * I think that OAM interworking is most useful when it exists betwee= n proactive OAM mechanisms whether it in peer-to-peer or client-server mode= l. I don=92t see that there=92s requirement of proactive Network OAM. Shoul= d there be one? E.g. =93E-VPN Network OAM SHOULD provide both proactive and= on-demand mechanisms of monitoring its data plane operation and data plane= conformance to state of its control plane.=94 Agreed. Added. * Section 3.1.1 * Please consider splitting the sentence in two with the second bein= g like =93=85 without time bound. Certain actions, e.g. protection switchov= er or alarm indication signaling, could be associated with events of enteri= ng and clearing fault state=94. Done. * Section 3.1.1.1 * I think that another term for =93a specified path taken by a parti= cular user data flow=94 is =93in-band monitoring=94. Changed. * * I think that monitoring of =93representative path=94 may not be re= liable test of MEP hosting node liveliness. As I understand, it still verif= ication of the MEP liveliness but out-band. Or it is implied that the targe= t of this monitoring is not the MEP but an ID associated with the node wher= e the MEP defined? Then wouldn=92t that be verification of a control plane = rather than data plane operation? The intent was that this is a mechanism to verify that the node is alive, p= rovided that the MEP's operation fate-shares the liveness of the PE. The id= ea is that the messages will use flow entropy parameters corresponding to s= ome test flow (I.E. some MAC, VLAN etc=85 parameters to represent an exampl= e flow =96 not necessarily a customer flow). * What is understood as =93test flow=94? Is that using methods of active moni= toring/measurements when specifically constructed test packets being inject= ed vs. passive monitoring/measurements when data flow(s) used to monitor an= d measure performance? Please see above. * * =93Monitoring of all ECMP paths between MEPs is not a requirement = for E-VPN OAM.=94 Is in regard to concurrent monitoring all paths between t= wo (?) MEPs or to problem of exercising particular paths at-will? Both. A particular path may not be exercisable because the ECMP hashing is = a local function. * * I=92m not sure that the last requirement is applicable to E-VPN Se= rvice OAM. CFM and/or Y.1731 would not be used differently when monitoring = unicast only or unicast and multicast services. Agreed, updated. * * Section 3.1.1.2.2 * What is understood by =93support RDI=94? Is it merely ability to s= ignal LoC defect to remote MEP(s) or ability, as well, to recognize RDI fro= m a remote MEP? Should note that in multipoint MA RDI is not really useful = as indicator of unidirectional fault since there=92s no indication of with = which MEP the sender detected LoC defect. If unidirectional LoC is likely n= ot guarantee of bi-directional fault, then MA MUST be p2p. Added clarification to that effect. * * * Section 3.1.2.2 * Connectivity Verification vs. Continuity Check. There=92s referenc= e to =93connectivity faults=94 in the first paragraph. Should it be changed= to =93continuity=94 or on-demand OAM, at least in E-VPN Service OAM, requi= red to detect mis-connectivity? If =93yes=94, why the same is not applicabl= e to proactive OAM for E-VPN Service? I am not sure I follow the question here. This section is about on-demand f= ault localization (I.E. the equivalent of the Linktrace function in CFM). * * * Section 3.2 * I wouldn=92t refer to scheduled on-demand PM tests as =93proactive= =94 since these are still bound in time unlike proactive that are not bound= in time. * But there is at least one example of truly proactive LM in Y.1731 = that uses ETH-CC frames. So, there=92s a distinction between proactive and = on-demand PM. Updated. * * * Section 3.2.1 * Use of Synthetic LM is usually in out-of-service state as test fra= mes expected to be statistically representative of real data flow. LM in mp= 2mp network can be constructed of set of p2p LM metrics. If this were to rely on data-packet counters, and the solution allows MP2MP= connectivity, then this requires maintaining packet statistics per source-= destination pair, which is typically not available in implementations. At l= east for Y.1731, my experience has been that this function was rarely imple= mented, due to the associated complexity and HW cost implications. Regards, Samer * * draft-vgovindan-l2vpn-evpn-bfd-00 =B7 Section 2.1.1 o If there=92s a need to have BFD session per ECMP path/EL how such sessi= on can be demuxed at the tail if at the bootstrap it would allocate only on= e myDiscriminator per source IP/FEC combination? o Effectively, IMO, there are separate p2p BFD sessions between head and = tail of mp2p tunnel. Right? =B7 Section 3 o Since two types of BFD encapsulation available, I think it would be bet= ter to require that only one type be used to monitor particular E-VPN at it= s Network level. Should it say =93The same type of BFD encapsulation, eithe= r IP or VCCV, MUST be used to monitor all tunnels of the particular E-VPN a= t its Network level.=94 o s/G-Ach/G-ACh/ =B7 Section 4 o Not clear which BFD modes can be used and in what manner as on-demand O= AM to troubleshoot and localize fault. AFAIK, BFD-based OAM used primarily = as proactive continuity check and LSP Ping as on-demand troubleshooting too= l. --_000_CECCEBA217CA3ssalamciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable

Hit "send" instead of "save", further responses inline= =85

From: Samer Salam <ssalam@cisco.com>
Date: Tuesday, 10 December, 2013 4:= 00 PM
To: Gregory Mirsky <gregory.mirsky@ericsson.com>, &qu= ot;Ali Sajassi (sajassi)" <saj= assi@cisco.com>, "Sam Aldrin (aldrin.ietf@gmail.com)" <aldrin.ietf@gmail.com>= , "John E Drake (jdrake@juniper.= net)" <jdrake@juniper.net= >, "Vengada Prasad Govindan (venggovi)" <venggovi@cisco.com>, "l2vpn@ietf.org" <l2vpn@ietf.org>
Subject: Re: Comments on draft-sala= m-l2vpn-evpn-oam-req-frmwk and draft-vgovindan-l2vpn-evpn-bfd

Hi Greg,

Thanks again for your comments. Please find comment resolution/respons= es on the Requirements/Framework draft inline=85

From: Gregory Mirsky <gregory.mirsky@ericsson.com> Date: Tuesday, 19 November, 2013 4:= 56 AM
To: Samer Salam <ssalam@cisco.com>, "Ali Sajassi (sajassi)&= quot; <sajassi@cisco.com>, &= quot;Sam Aldrin (aldrin.ietf@gmail= .com)" <aldrin.ietf@gmail.com>= , "John E Drake (jdrake@juniper.= net)" <jdrake@juniper.net= >, "Vengada Prasad Govindan (venggovi)" <venggovi@cisco.com>, "l2vpn@ietf.org" <l2vpn@ietf.org>
Subject: Comments on draft-salam-l2= vpn-evpn-oam-req-frmwk and draft-vgovindan-l2vpn-evpn-bfd

Dear Authors, et. al,

very useful and timely raised questions. Please find= my comments to both documents below. Greatly appreciate your kind consider= ation and am looking forward to the discussion.

&nbs= p; Regards,

&nbs= p; &= nbsp; Greg=

draft-salam-l2vpn-evpn-oam-req-frmwk-01

Use cases. Multi-carrier E-VPN. Ethernet Service OAM is instrumented, throu= gh MEG Level hierarchy, to present customer, provider, and operator scopes = of OAM. If multi-carrier E-VPN is viable use case, then support of MEP and = its functionalities becomes a MUST for provider and operator scopes. Then, if multi-carrier E-VPN is viable u= se case, there might be new requirements towards E-VPN Network OAM.
Sec.1.1 s/Public/Packet/

Fixed.<= /div>

CFM =85 defines concept =85 Maintenance Association =85

Added.<= /div>

Sec.1.3 MEG, Maintenance Entity Group, is object of Y.1731 equivalent to MA= of CFM. Note that MEG is used in MPLS-TP OAM as well.

Added MA to th= e terminology section (picked the CFM terminology to use consistently for t= he document, also per your comment below)

Definition of MIP is not correct. MIP can terminate certain OAM, both Ether= net and MPLS-TP, frames, e.g. ETH-LB.

Good catch, fi= xed.

Maintenance Domain, as mentioned in 1.1, is object of CFM and is not used i= n Y.1731. Suggest use consistent terminology, either CFM or Y.1731.

Good point, we= nt with the CFM terminology.

Figure 2, can use EFM (Ethernet First Mile) OAM instead of 802.3 OAM. (Note= that there are two Figure 2 in the document =96 Section 2.1 and Section 3.= 1.1.2.1)

Fixed figure n= umber.

Section 2.2
- Characterize whether MEP on PEs SHOULD be Up, Down or both.

Added.<= /div>

Section 2.4
- Would BFD (RFC 5880, RFC 5881, RFC 5883, RFC 5884, and RFC 5885) be applica= ble as well as RFC 6428?

Section 2.6
- I think that OAM interworking is most useful when it exists between proacti= ve OAM mechanisms whether it in peer-to-peer or client-server model. I don= =92t see that there=92s requirement of proactive Network OAM. Should there = be one? E.g. =93E-VPN Network OAM SHOULD provide both proactive and on-demand mechanisms of monitoring its data pla= ne operation and data plane conformance to state of its control plane.=94

Agreed. Added.

Section 3.1.1
- Please consider splitting the sentence in two with the second being like = =93=85 without time bound. Certain actions, e.g. protection switchover or a= larm indication signaling, could be associated with events of entering and = clearing fault state=94.

Done.

Section 3.1.1.1
- I think that another term for =93a specified path taken by a particular use= r data flow=94 is =93in-band monitoring=94.

Changed.

- I think that monitoring of =93representative path=94 may not be reliable te= st of MEP hosting node liveliness. As I understand, it still verification o= f the MEP liveliness but out-band. Or it is implied that the target of this= monitoring is not the MEP but an ID associated with the node where the MEP defined? Then wouldn=92t that be ve= rification of a control plane rather than data plane operation?

The intent w= as that this is a mechanism to verify that the node is alive, provided that= the MEP's operation fate-shares the liveness of the PE. The idea is that t= he messages will use flow entropy parameters corresponding to some test flow (I.E. some MAC, VLAN etc=85 parameters to represent= an example flow =96 not necessarily a customer flow).

What is understood as =93test flow=94? Is that using methods of active= monitoring/measurements when specifically constructed test packets being i= njected vs. passive monitoring/measurements when data flow(s) used to monit= or and measure performance?

Please see above.

- =93Monitoring of all ECMP paths between MEPs is not a requirement for E-VPN= OAM.=94 Is in regard to concurrent monitoring all paths between two (?) ME= Ps or to problem of exercising particular paths at-will?

Both. A particular path may not be exercisable= because the ECMP hashing is a local function.

- I=92m not sure that the last requirement is applicable to E-VPN Service OAM= . CFM and/or Y.1731 would not be used differently when monitoring unicast o= nly or unicast and multicast services.

Agreed, updated.

Section 3.1.1.2.2
- What is understood by =93support RDI=94? Is it merely ability to signal LoC= defect to remote MEP(s) or ability, as well, to recognize RDI from a remot= e MEP? Should note that in multipoint MA RDI is not really useful as indica= tor of unidirectional fault since there=92s no indication of with which MEP the sender detected LoC defect. If unidire= ctional LoC is likely not guarantee of bi-directional fault, then MA MUST b= e p2p.

Added clarification to that effect.

Section 3.1.2.2
- Connectivity Verification vs. Continuity Check. There=92s reference to =93c= onnectivity faults=94 in the first paragraph. Should it be changed to =93co= ntinuity=94 or on-demand OAM, at least in E-VPN Service OAM, required to de= tect mis-connectivity? If =93yes=94, why the same is not applicable to proactive OAM for E-VPN Service?

I am not sure I follow the ques= tion here. This section is about on-demand fault localization (I.E. th= e equivalent of the Linktrace function in CFM).

Section 3.2
- I wouldn=92t refer to scheduled on-demand PM tests as =93proactive=94 since= these are still bound in time unlike proactive that are not bound in time.=
- But there is at least one example of truly proactive LM in Y.1731 that uses= ETH-CC frames. So, there=92s a distinction between proactive and on-demand= PM.

Updated.

Section 3.2.1
- Use of Synthetic LM is usually in out-of-service state as test frames expec= ted to be statistically representative of real data flow. LM in mp2mp netwo= rk can be constructed of set of p2p LM metrics.

If this were to rely on data-packet counters, = and the solution allows MP2MP connectivity, then this requires maintaining = packet statistics per source-destination pair, which is typically not avail= able in implementations. At least for Y.1731, my experience has been that this function was rarely implement= ed, due to the associated complexity and HW cost implications.

Regards,

Samer

draft-vgovindan-l2vpn-evpn-bfd-00

o Effectively, IMO, there are separate p2p= BFD sessions between head and tail of mp2p tunnel. Right?

o s/G-Ach/G-ACh/

--_000_CECCEBA217CA3ssalamciscocom_-- From gregory.mirsky@ericsson.com Wed Dec 11 15:12:11 2013 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70B361AE086 for ; Wed, 11 Dec 2013 15:12:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AE47lhLrPhA3 for ; Wed, 11 Dec 2013 15:12:05 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id CFC061AE041 for ; Wed, 11 Dec 2013 15:12:04 -0800 (PST) X-AuditID: c618062d-b7f278e000005a8f-91-52a8f13b52da Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id C4.C9.23183.C31F8A25; Thu, 12 Dec 2013 00:11:56 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.02.0347.000; Wed, 11 Dec 2013 18:11:57 -0500 From: Gregory Mirsky To: "Vengada Prasad Govindan (venggovi)" , "Samer Salam (ssalam)" , "Ali Sajassi (sajassi)" , "Sam Aldrin (aldrin.ietf@gmail.com)" , "John E Drake (jdrake@juniper.net)" , "l2vpn@ietf.org" Subject: RE: Comments on draft-salam-l2vpn-evpn-oam-req-frmwk and draft-vgovindan-l2vpn-evpn-bfd Thread-Topic: Comments on draft-salam-l2vpn-evpn-oam-req-frmwk and draft-vgovindan-l2vpn-evpn-bfd Thread-Index: Ac7lDSTCOfeFij7fTiOpIkx3ocp0YQBIYKKAACnc4DACLDTCcA== Date: Wed, 11 Dec 2013 23:11:56 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B732DBB@eusaamb103.ericsson.se> References: <7347100B5761DC41A166AC17F22DF1121B71E5A9@eusaamb103.ericsson.se> <315041E4211CB84E86EF7C25A2AB583D33843129@xmb-rcd-x15.cisco.com> In-Reply-To: <315041E4211CB84E86EF7C25A2AB583D33843129@xmb-rcd-x15.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.135] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF1121B732DBBeusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrKLMWRmVeSWpSXmKPExsUyuXRPoK7NxxVBBi+WSFhMaP3CaDHnrrPF 42+H2C3enW1msXgybyW7xcwPm5gd2Dym/N7I6rFz1l12jyVLfjJ5XG+6yh7AEsVlk5Kak1mW WqRvl8CV8ejfcuaC7z4VyxdtYm5gbHLuYuTkkBAwkXj26xYLhC0mceHeerYuRi4OIYEjjBLL 139mA0kICSxnlPgxWRvEZhMwknixsYcdpEhEYBuTxLsHy5hAEsICSRKNj/+CNYgIJEs0XvjI DGE7Seya/IgdxGYRUJXY+bONEcTmFfCVeLj4BSvEti2MEs1rpgAN4uDgBEos224GUsMIdNH3 U2vA5jMLiEvcejKfCeJSAYkle84zQ9iiEi8f/2OFsJUlvs95xAIyhlkgX6K/qwZilaDEyZlP WCYwisxCMmkWQtUsJFUQJToSC3Z/YoOwtSWWLXzNDGOfOfCYCVl8ASP7KkaO0uLUstx0I4NN jMCoOybBpruDcc9Ly0OM0hwsSuK8X946BwkJpCeWpGanphakFsUXleakFh9iZOLglGpgVN5v svMkB2dSkZ+p7qYr8zeLOvi/yOFZ8KiRx//mpbrccq+/ote1PXUevCq50bb4YsHCpceuBpz7 EZb6fq1x2jGxdS418jPDPfbu/MI1PfUV4/MG7yu7vwXPN67kvdwt8bm54p3Dr6LFPxd8y693 T1q3brmNQMSKmGWfa7fkpXx7PV16hYGFohJLcUaioRZzUXEiAKbpJ9yIAgAA X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 23:12:11 -0000 --_000_7347100B5761DC41A166AC17F22DF1121B732DBBeusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Prasad, thank you for you careful consideration of my notes. Proposed text tagged w= ith GIM>>. Regards, Greg [snip] * Section 4 o Not clear which BFD modes can be used and in what manner as on-demand O= AM to troubleshoot and localize fault. AFAIK, BFD-based OAM used primarily = as proactive continuity check and LSP Ping as on-demand troubleshooting too= l. GVP1> The intent of this Section is to highlight the possible scalability = issues that could arise. The term demand-driven manner was used to imply th= at BFD could be turned ON and OFF as desired, instead of an ALWAYS-ON mode.= Do you have any suggestions to improve the text here? Please let us know. GIM>> Bringing BFD session up has its tax of triple handshake to exchange D= iscriminator values. Alternative to turning ON and OFF could be dynamically= changing Rx and Tx intervals to a very large value, i.e. minutes if not h= ours. As I understand, "demand-driven", also referred as "on-demand", OAM t= ools primarily used for fault localization. LSP traceroute is one of widely= used in MPLS networks, ETH-LT (linktrace) - in Ethernet domain. Proactive = tools like BFD or CFM primarily used for fault detection. I don't think tha= t BFD needs to be enhanced to match diagnostic capabilities available in LS= P Ping/traceroute. --_000_7347100B5761DC41A166AC17F22DF1121B732DBBeusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Prasad,<= /span>

thank you for you care= ful consideration of my notes. Proposed text tagged with GIM>>.<= /o:p>

&nbs= p; Regard= s,

&nbs= p; &= nbsp; &nbs= p; Greg

[snip]

· Section 4

o Not clear which = BFD modes can be used and in what manner as on-demand OAM to troubleshoot a= nd localize fault. AFAIK, BFD-based OAM used primarily as proactive continu= ity check and LSP Ping as on-demand troubleshooting tool.

GVP1> The intent of this Section is to highlight the = possible scalability issues that could arise. The term demand-driven manner= was used to imply that BFD could be turned ON and OFF as desired, instead of an ALWAYS-ON mode. Do you have any suggesti= ons to improve the text here? Please let us know.

GIM>> Bringing B= FD session up has its tax of triple handshake to exchange Discriminator val= ues. Alternative to turning ON and OFF could be dynamically changing Rx and= Tx intervals to a very large value, i.e. minutes if not hours. As I understand, “demand-driven”, also r= eferred as “on-demand”, OAM tools primarily used for fault loca= lization. LSP traceroute is one of widely used in MPLS networks, ETH-LT (li= nktrace) – in Ethernet domain. Proactive tools like BFD or CFM primarily used for fault detection. I don’t think that BFD ne= eds to be enhanced to match diagnostic capabilities available in LSP Ping/t= raceroute.

--_000_7347100B5761DC41A166AC17F22DF1121B732DBBeusaamb103erics_-- From internet-drafts@ietf.org Wed Dec 11 18:52:46 2013 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C6851AE156; Wed, 11 Dec 2013 18:52:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UEUCl_0qi42t; Wed, 11 Dec 2013 18:52:44 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BEF921AE0AD; Wed, 11 Dec 2013 18:52:44 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-l2vpn-evpn-req-06.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131212025244.6594.38791.idtracker@ietfa.amsl.com> Date: Wed, 11 Dec 2013 18:52:44 -0800 Cc: l2vpn@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Dec 2013 02:52:46 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Layer 2 Virtual Private Networks Working = Group of the IETF. Title : Requirements for Ethernet VPN (EVPN) Author(s) : Ali Sajassi Rahul Aggarwal Nabil Bitar Aldrin Isaac Filename : draft-ietf-l2vpn-evpn-req-06.txt Pages : 15 Date : 2013-12-11 Abstract: The widespread adoption of Ethernet L2VPN services and the advent of new applications for the technology (e.g., data center interconnect) have culminated in a new set of requirements that are not readily addressable by the current Virtual Private LAN Service (VPLS) solution. In particular, multi-homing with all-active forwarding is not supported and there's no existing solution to leverage Multipoint-to-Multipoint (MP2MP) LSPs for optimizing the delivery of multi-destination frames. Furthermore, the provisioning of VPLS, even in the context of BGP-based auto-discovery, requires network operators to specify various network parameters on top of the access configuration. This document specifies the requirements for an Ethernet VPN (EVPN) solution which addresses the above issues. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-l2vpn-evpn-req There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-l2vpn-evpn-req-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-l2vpn-evpn-req-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From gregory.mirsky@ericsson.com Wed Dec 11 19:09:53 2013 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36FB41AE0EE for ; Wed, 11 Dec 2013 19:09:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fap0WjB5f48P for ; Wed, 11 Dec 2013 19:09:49 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 62DC51AE0D2 for ; Wed, 11 Dec 2013 19:09:49 -0800 (PST) X-AuditID: c618062d-b7f278e000005a8f-d4-52a928f5f156 Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id B9.7E.23183.5F829A25; Thu, 12 Dec 2013 04:09:41 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.02.0347.000; Wed, 11 Dec 2013 22:09:42 -0500 From: Gregory Mirsky To: "Samer Salam (ssalam)" , "Ali Sajassi (sajassi)" , "Sam Aldrin (aldrin.ietf@gmail.com)" , "John E Drake (jdrake@juniper.net)" , "Vengada Prasad Govindan (venggovi)" , "l2vpn@ietf.org" Subject: RE: Comments on draft-salam-l2vpn-evpn-oam-req-frmwk and draft-vgovindan-l2vpn-evpn-bfd Thread-Topic: Comments on draft-salam-l2vpn-evpn-oam-req-frmwk and draft-vgovindan-l2vpn-evpn-bfd Thread-Index: Ac7lDSTCOfeFij7fTiOpIkx3ocp0YQQ5iE0AAAD0+QAAM9uyMA== Date: Thu, 12 Dec 2013 03:09:41 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B732E56@eusaamb103.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.135] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF1121B732E56eusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJLMWRmVeSWpSXmKPExsUyuXSPt+5XjZVBBo/nKFpMaP3CaDHnrrPF 42+H2C3enW1msXgybyW7xcwPm5gd2Dym/N7I6rFz1l12jyVLfjJ5XG+6yh7AEsVlk5Kak1mW WqRvl8CVMenFRfaCvmuMFX8O/WduYHy3i7GLkZNDQsBEonX3MShbTOLCvfVsXYxcHEICRxgl Vi88zgThLGeUOH9jEhtIFZuAkcSLjT3sILaIwA4miVuv9EBsYYEkicbHf9kg4skSjRc+MkPY ThI/d7awgtgsAqoS994tBLN5BXwlfrdtApsjJBAo8WrHDiYQm1NAT+LxntNgvYxAF30/tQYs ziwgLnHryXwmiEsFJJbsOc8MYYtKvHz8jxXCVpb4PucRC0R9vsSHvRA38woISpyc+YRlAqPI LCSjZiEpm4WkDCKuI7Fg9yc2CFtbYtnC18ww9pkDj5mQxRcwsq9i5CgtTi3LTTcy2MQIjL5j Emy6Oxj3vLQ8xCjNwaIkzvvlrXOQkEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBsZk/S/sz7rt ujbkTDGY4pLW1sl5YVXVG9vaVo1LvxfvjP7Jea3DL9aJQ+6UaXlA9c+dnY1v77iZZotUJFhY 3FEQKA+MLxLTVdvH82zn1p2qPw9c/Gh+tPKNU43Geket7kdrDzLu9rJlDlzX0iU4n13b4UGO y5KG9L+3RPIu3it1yQr7ymvOosRSnJFoqMVcVJwIABDnfk2MAgAA X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Dec 2013 03:09:53 -0000 --_000_7347100B5761DC41A166AC17F22DF1121B732E56eusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Samer, thank you for kind consideration of my notes. Am glad that we can snip so m= any of them. Please find my answers in-line and tagged by GIM>>. Regards, Greg [...] * I think that monitoring of "representative path" may not be reliab= le test of MEP hosting node liveliness. As I understand, it still verificat= ion of the MEP liveliness but out-band. Or it is implied that the target of= this monitoring is not the MEP but an ID associated with the node where th= e MEP defined? Then wouldn't that be verification of a control plane rather= than data plane operation? The intent was that this is a mechanism to verify that the node is alive, p= rovided that the MEP's operation fate-shares the liveness of the PE. The id= ea is that the messages will use flow entropy parameters corresponding to s= ome test flow (I.E. some MAC, VLAN etc... parameters to represent an exampl= e flow - not necessarily a customer flow). GIM>> Consider Up MEP case. It may be unreachable, i.e. LoC detected, becau= se of problem in bridging element while the hosting node is operational. I = think that "fate-sharing" is in area of uncertainty and assumptions. I'd co= nsider explicitly stating all assumptions, i.e. "LoC detection interpreted = as failure of the hosting node". [...] * "Monitoring of all ECMP paths between MEPs is not a requirement fo= r E-VPN OAM." Is in regard to concurrent monitoring all paths between two (= ?) MEPs or to problem of exercising particular paths at-will? Both. A particular path may not be exercisable because the ECMP hashing is = a local function. GIM>> This is interesting and hard to crack problem. ECMP may be monitored = on link level and AIS-like used to inform client level. [...] * Section 3.1.2.2 * Connectivity Verification vs. Continuity Check. There's reference = to "connectivity faults" in the first paragraph. Should it be changed to "c= ontinuity" or on-demand OAM, at least in E-VPN Service OAM, required to det= ect mis-connectivity? If "yes", why the same is not applicable to proactive= OAM for E-VPN Service? I am not sure I follow the question here. This section is about on-demand f= ault localization (I.E. the equivalent of the Linktrace function in CFM). GIM>> The complete sentence is "That is, given two PEs A and B, localizatio= n of connectivity faults between them requires running fault isolation proc= edures from PE A to PE B as well as from PE B to PE A." ETH-LT/linktrace or IP traceroute helpful in localizing continuity failure.= I don't think that either is helpful in localizing mis-connectivity defect= s. My question is about terminology. "Connectivity defect" and "continuity = defect" are not the same defects and, I believe, should not be used interch= angeably. [...] * Section 3.2.1 * Use of Synthetic LM is usually in out-of-service state as test fra= mes expected to be statistically representative of real data flow. LM in mp= 2mp network can be constructed of set of p2p LM metrics. If this were to rely on data-packet counters, and the solution allows MP2MP= connectivity, then this requires maintaining packet statistics per source-= destination pair, which is typically not available in implementations. At l= east for Y.1731, my experience has been that this function was rarely imple= mented, due to the associated complexity and HW cost implications. GIM>> Alternatively, passive methods of performance measurement may be cons= idered. Regards, Samer --_000_7347100B5761DC41A166AC17F22DF1121B732E56eusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Samer,

thank you for kind con= sideration of my notes. Am glad that we can snip so many of them. Please fi= nd my answers in-line and tagged by GIM>>.

&nbs= p; Regard= s,

&nbs= p; &= nbsp; &nbs= p; Greg

[…]

&n= bsp;

I think that monitoring of “representative path” may not be rel= iable test of MEP hosting node liveliness. As I understand, it still verifi= cation of the MEP liveliness but out-band. Or it is implied that the target= of this monitoring is not the MEP but an ID associated with the node where the MEP defined? Then wouldn’t that b= e verification of a control plane rather than data plane operation?

The i= ntent was that this is a mechanism to verify that the node is alive, provid= ed that the MEP's operation fate-shares the liveness of the PE. The idea is= that the messages will use flow entropy parameters corresponding to some test flow (I.E. some MAC, VLAN etc…= parameters to represent an example flow – not necessarily = a customer flow).

GIM>> Conside= r Up MEP case. It may be unreachable, i.e. LoC detected, because of problem= in bridging element while the hosting node is operational. I think that &#= 8220;fate-sharing” is in area of uncertainty and assumptions. I’d consider explicitly stating all assumptions, i.e. &= #8220;LoC detection interpreted as failure of the hosting node”.=

[…]

“Monitoring of all ECMP paths between MEPs is not a requirement for E= -VPN OAM.” Is in regard to concurrent monitoring all paths between tw= o (?) MEPs or to problem of exercising particular paths at-will?=

Both. A particular pat= h may not be exercisable because the ECMP hashing is a local function.=

GIM>> This is= interesting and hard to crack problem. ECMP may be monitored on link level= and AIS-like used to inform client level.

[…]=

Section 3.1.2.2

Connectivity Verification vs. Continuity Check. There’s reference to = “connectivity faults” in the first paragraph. Should it be chan= ged to “continuity” or on-demand OAM, at least in E-VPN Service= OAM, required to detect mis-connectivity? If “yes”, why the sa= me is not applicable to proactive OAM for E-VPN Service?

I am not sure&nbs= p;I follow the question here. This section is about on-demand fau= lt localization (I.E. the equivalent of the Linktrace function in CFM)= .

GIM>> The com= plete sentence is “That is, given two PEs A and B, localization of co= nnectivity faults between them requires running fault isolation procedures = from PE A to PE B as well as from PE B to PE A.”

ETH-LT/linktrace or= IP traceroute helpful in localizing continuity failure. I don’t thin= k that either is helpful in localizing mis-connectivity defects. My questio= n is about terminology. “Connectivity defect” and “continuity defect” are not the same defects and, I believ= e, should not be used interchangeably.

[…]

Section 3.2.1

Use of Synthetic LM is usually in out-of-service state as test frames expec= ted to be statistically representative of real data flow. LM in mp2mp netwo= rk can be constructed of set of p2p LM metrics.

If this were to rely o= n data-packet counters, and the solution allows MP2MP connectivity, then th= is requires maintaining packet statistics per source-destination pair, which is typically not available in implementations. At least for Y.= 1731, my experience has been that this function was rarely implemented, due= to the associated complexity and HW cost implications.

GIM>> Alterna= tively, passive methods of performance measurement may be considered.<= /o:p>

Regards,

Samer

--_000_7347100B5761DC41A166AC17F22DF1121B732E56eusaamb103erics_-- From venggovi@cisco.com Fri Dec 13 03:01:53 2013 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 552421A8032 for ; Fri, 13 Dec 2013 03:01:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tOR9Yg6x0c0z for ; Fri, 13 Dec 2013 03:01:51 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id CAABD1ADFD4 for ; Fri, 13 Dec 2013 03:01:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12123; q=dns/txt; s=iport; t=1386932505; x=1388142105; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=TKYnqHexYCHEIbzNZ2AAaRIxqpKvx4bnXsOrPzkMBDI=; b=LFqV8GCK33+84DG/hIHFW+0xWfpno4BhhnF08/F9u2vI3WitZ9ItIb9T djcwGxghTbnD6c5sULHeI1+SoIKOI6ZqWKNcAOAlBSAmGPT7ljDHGFkO4 3wprKCAS6kq/QO4o19JIlHmYBeerhC2HwV5tr2Sk0GxsR2vGxsCJXrsZ9 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhsFAOrnqlKtJV2Y/2dsb2JhbABZgkZEOFW4YYEgFnSCJQEBAQQtRhYCAQgRBAEBCx0HIREUCQgBAQQBEgiHaAMRu3ANhwoXjQKBMhEBHzcBgyOBEwSWKo5FhTqBbIE+gXE5 X-IronPort-AV: E=Sophos;i="4.95,477,1384300800"; d="scan'208,217";a="291420407" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-4.cisco.com with ESMTP; 13 Dec 2013 11:01:44 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id rBDB1iBt020314 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 13 Dec 2013 11:01:44 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.86]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0123.003; Fri, 13 Dec 2013 05:01:43 -0600 From: "Vengada Prasad Govindan (venggovi)" To: Gregory Mirsky , "Samer Salam (ssalam)" , "Ali Sajassi (sajassi)" , "Sam Aldrin (aldrin.ietf@gmail.com)" , "John E Drake (jdrake@juniper.net)" , "l2vpn@ietf.org" Subject: RE: Comments on draft-salam-l2vpn-evpn-oam-req-frmwk and draft-vgovindan-l2vpn-evpn-bfd Thread-Topic: Comments on draft-salam-l2vpn-evpn-oam-req-frmwk and draft-vgovindan-l2vpn-evpn-bfd Thread-Index: Ac7lDSTCOfeFij7fTiOpIkx3ocp0YQBIYKKAACnc4DACLDTCcAIa0cfw Date: Fri, 13 Dec 2013 11:01:43 +0000 Message-ID: <315041E4211CB84E86EF7C25A2AB583D3387B461@xmb-rcd-x15.cisco.com> References: <7347100B5761DC41A166AC17F22DF1121B71E5A9@eusaamb103.ericsson.se> <315041E4211CB84E86EF7C25A2AB583D33843129@xmb-rcd-x15.cisco.com> <7347100B5761DC41A166AC17F22DF1121B732DBB@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B732DBB@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.143.25.207] Content-Type: multipart/alternative; boundary="_000_315041E4211CB84E86EF7C25A2AB583D3387B461xmbrcdx15ciscoc_" MIME-Version: 1.0 X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Dec 2013 11:01:53 -0000 --_000_315041E4211CB84E86EF7C25A2AB583D3387B461xmbrcdx15ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Greg, Sincere thanks for your email. Agreed, the BFD sessions could be slowed= down to tolerable (large) timer values instead of tearing down and (re)est= ablishing BFD sessions. I will incorporate this change in the next revision= of this draft. Thanks Prasad From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] Sent: Thursday, December 12, 2013 4:42 AM To: Vengada Prasad Govindan (venggovi); Samer Salam (ssalam); Ali Sajassi (= sajassi); Sam Aldrin (aldrin.ietf@gmail.com); John E Drake (jdrake@juniper.= net); l2vpn@ietf.org Subject: RE: Comments on draft-salam-l2vpn-evpn-oam-req-frmwk and draft-vgo= vindan-l2vpn-evpn-bfd Hi Prasad, thank you for you careful consideration of my notes. Proposed text tagged w= ith GIM>>. Regards, Greg [snip] * Section 4 o Not clear which BFD modes can be used and in what manner as on-demand O= AM to troubleshoot and localize fault. AFAIK, BFD-based OAM used primarily = as proactive continuity check and LSP Ping as on-demand troubleshooting too= l. GVP1> The intent of this Section is to highlight the possible scalability = issues that could arise. The term demand-driven manner was used to imply th= at BFD could be turned ON and OFF as desired, instead of an ALWAYS-ON mode.= Do you have any suggestions to improve the text here? Please let us know. GIM>> Bringing BFD session up has its tax of triple handshake to exchange D= iscriminator values. Alternative to turning ON and OFF could be dynamically= changing Rx and Tx intervals to a very large value, i.e. minutes if not h= ours. As I understand, "demand-driven", also referred as "on-demand", OAM t= ools primarily used for fault localization. LSP traceroute is one of widely= used in MPLS networks, ETH-LT (linktrace) - in Ethernet domain. Proactive = tools like BFD or CFM primarily used for fault detection. I don't think tha= t BFD needs to be enhanced to match diagnostic capabilities available in LS= P Ping/traceroute. --_000_315041E4211CB84E86EF7C25A2AB583D3387B461xmbrcdx15ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello Greg,=

Sin= cere thanks for your email. Agreed, the BFD sessions could be slowed down t= o tolerable (large) timer values instead of tearing down and (re)establishi= ng BFD sessions. I will incorporate this change in the next revision of this draft.

Thanks

Prasad

From: Gregory = Mirsky [mailto:gregory.mirsky@ericsson.com]
Sent: Thursday, December 12, 2013 4:42 AM
To: Vengada Prasad Govindan (venggovi); Samer Salam (ssalam); Ali Sa= jassi (sajassi); Sam Aldrin (aldrin.ietf@gmail.com); John E Drake (jdrake@j= uniper.net); l2vpn@ietf.org
Subject: RE: Comments on draft-salam-l2vpn-evpn-oam-req-frmwk and dr= aft-vgovindan-l2vpn-evpn-bfd

Hi Prasad,<= /span>

thank you for you care= ful consideration of my notes. Proposed text tagged with GIM>>.<= /o:p>

&nbs= p; Regard= s,

&nbs= p; &= nbsp; &nbs= p; Greg

[snip]

· Section 4

--_000_315041E4211CB84E86EF7C25A2AB583D3387B461xmbrcdx15ciscoc_-- From internet-drafts@ietf.org Thu Dec 19 07:47:07 2013 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3514C1ADFBC; Thu, 19 Dec 2013 07:47:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HOtqUangpMI7; Thu, 19 Dec 2013 07:47:05 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D87B51ADFA3; Thu, 19 Dec 2013 07:47:05 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-l2vpn-vpls-inter-domain-redundancy-03.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.84 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131219154705.10566.63677.idtracker@ietfa.amsl.com> Date: Thu, 19 Dec 2013 07:47:05 -0800 Cc: l2vpn@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Dec 2013 15:47:07 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Layer 2 Virtual Private Networks Working = Group of the IETF. Title : Redundancy provisioning for VPLS Inter-domain Author(s) : Zhihua Liu Lizhong Jin Ran Chen Dennis Cai Samer Salam Filename : draft-ietf-l2vpn-vpls-inter-domain-redundancy-03.txt Pages : 10 Date : 2013-12-19 Abstract: In many VPLS deployments based on RFC4762, inter-domain connectivity has been deployed without node redundancy, or with node redundancy in a single domain. This document describes a solution for inter-domain VPLS based on RFC4762 with node and link redundancy in both domains. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-l2vpn-vpls-inter-domain-redunda= ncy There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-l2vpn-vpls-inter-domain-redundancy-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-l2vpn-vpls-inter-domain-redun= dancy-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From wwwrun@rfc-editor.org Fri Dec 20 13:22:44 2013 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F377A1ADF9B; Fri, 20 Dec 2013 13:22:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.953 X-Spam-Level: X-Spam-Status: No, score=0.953 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.793, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kUI7P2vL_7K6; Fri, 20 Dec 2013 13:22:39 -0800 (PST) Received: from rfc-editor.org (unknown [IPv6:2607:f170:8000:1500::d3]) by ietfa.amsl.com (Postfix) with ESMTP id 0E72E1A1F33; Fri, 20 Dec 2013 13:22:39 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id AEAC27FC15A; Fri, 20 Dec 2013 13:22:36 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org Subject: RFC 7080 on Virtual Private LAN Service (VPLS) Interoperability with Provider Backbone Bridges From: rfc-editor@rfc-editor.org Message-Id: <20131220212236.AEAC27FC15A@rfc-editor.org> Date: Fri, 20 Dec 2013 13:22:36 -0800 (PST) Cc: l2vpn@ietf.org, drafts-update-ref@iana.org, rfc-editor@rfc-editor.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Dec 2013 21:22:44 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7080 Title: Virtual Private LAN Service (VPLS) Interoperability with Provider Backbone Bridges Author: A. Sajassi, S. Salam, N. Bitar, F. Balus Status: Informational Stream: IETF Date: December 2013 Mailbox: sajassi@cisco.com, ssalam@cisco.com, nabil.n.bitar@verizon.com, florin.balus@nuagenetworks.net Pages: 26 Characters: 61560 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-l2vpn-pbb-vpls-interop-06.txt URL: http://www.rfc-editor.org/rfc/rfc7080.txt The scalability of Hierarchical Virtual Private LAN Service (H-VPLS) with Ethernet access networks (RFC 4762) can be improved by incorporating Provider Backbone Bridge functionality in the VPLS access. Provider Backbone Bridging has been standardized as IEEE 802.1ah-2008. It aims to improve the scalability of Media Access Control (MAC) addresses and service instances in Provider Ethernet networks. This document describes different interoperability scenarios where Provider Backbone Bridge functionality is used in H-VPLS with Ethernet or MPLS access network to attain better scalability in terms of number of customer MAC addresses and number of service instances. The document also describes the scenarios and the mechanisms for incorporating Provider Backbone Bridge functionality within H-VPLS with existing Ethernet access and interoperability among them. Furthermore, the document discusses the migration mechanisms and scenarios by which Provider Backbone Bridge functionality can be incorporated into H-VPLS with existing MPLS access. This document is a product of the Layer 2 Virtual Private Networks Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/search/rfc_search.php For downloading RFCs, see http://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC