From giles.heron@gmail.com Fri Mar 8 06:08:31 2013 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C63021F8700 for ; Fri, 8 Mar 2013 06:08:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dGck4FTR-J5b for ; Fri, 8 Mar 2013 06:08:30 -0800 (PST) Received: from ivanoab3.miniserver.com (ivanoab3.miniserver.com [89.200.143.206]) by ietfa.amsl.com (Postfix) with ESMTP id 8ADC221F8615 for ; Fri, 8 Mar 2013 06:08:30 -0800 (PST) Received: from [192.168.17.10] (helo=localhost.localdomain) by ivanoab3.miniserver.com with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1UDxua-0001aM-ET; Fri, 08 Mar 2013 14:04:40 +0000 Received: from 64-103-25-233.cisco.com ([64.103.25.233] helo=dhcp-10-55-88-201.cisco.com) by localhost.localdomain with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1UDz1r-000328-3v; Fri, 08 Mar 2013 15:16:15 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: draft agenda for L2VPN @ IETF86 published From: Giles Heron In-Reply-To: <6A22EFAA-7996-4E85-BFFF-06025675DCD7@gmail.com> Date: Fri, 8 Mar 2013 14:08:16 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <1E0B65CC-B4DB-4BA2-B80F-3B4B33B9120E@gmail.com> References: <6A22EFAA-7996-4E85-BFFF-06025675DCD7@gmail.com> To: "l2vpn@ietf.org" X-Mailer: Apple Mail (2.1499) X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2013 14:08:31 -0000 In the absence of any feedback the agenda is now final: http://datatracker.ietf.org/meeting/86/agenda/l2vpn/ speakers please send your slides ASAP, and certainly by Monday. thank you. Nabil & Giles On 27 Feb 2013, at 17:53, Giles Heron wrote: > Hi everyone, >=20 > the draft agenda has now been published: >=20 > http://www.ietf.org/proceedings/86/agenda/agenda-86-l2vpn >=20 > Speakers please check your details are correct. Anyone who wanted to = speak but isn't on the list please contact the chairs ASAP. >=20 > Nabil & Giles From sajassi@cisco.com Tue Mar 12 07:53:53 2013 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC57011E80A5; Tue, 12 Mar 2013 07:53:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G95Ykx81KFlQ; Tue, 12 Mar 2013 07:53:53 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 2140D11E80AD; Tue, 12 Mar 2013 07:53:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1578; q=dns/txt; s=iport; t=1363100033; x=1364309633; h=from:to:cc:subject:date:message-id:mime-version; bh=b/tPMFrxsCWWHTLWH259Lvg9k6QHoG3nwilqImCE+Kg=; b=NBLWru5bwMyeW+4jo9oAR4cO4dc+sTjBcP0CJcRodyJnQ7zAducSjR4j lAp8oR719w95Fr2ii2Hrm0icYkctdFNuYMaf0XoTPRswVAsHTIJGghRuY Sin1ga7rd7rBMEFM3B9eVVPA3uaL8nNPHONNSjK7oulj8e5IsZdBTTsry M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgwLAOdAP1GtJV2b/2dsb2JhbABDhAMjgyaBYbs2gUcWbQeCHwsBBHkSAQsBHlYnBA4NAYgLAQuwc491F45cMYJmYQOnTIMKgig X-IronPort-AV: E=Sophos;i="4.84,831,1355097600"; d="scan'208,217";a="186564175" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-8.cisco.com with ESMTP; 12 Mar 2013 14:53:52 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r2CErquI004439 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 12 Mar 2013 14:53:52 GMT Received: from xmb-aln-x13.cisco.com ([fe80::5404:b599:9f57:834b]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.02.0318.004; Tue, 12 Mar 2013 09:53:52 -0500 From: "Ali Sajassi (sajassi)" To: "idr@ietf.org" Subject: draft-ietf-l2vpn-evpn Thread-Topic: draft-ietf-l2vpn-evpn Thread-Index: AQHOHzFpw7wq2p0F306XvoGHyBm2Og== Date: Tue, 12 Mar 2013 14:53:51 +0000 Message-ID: <69670F7146898C4583F56DA9AD32F77B1230F9D9@xmb-aln-x13.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.1.120420 x-originating-ip: [10.21.68.177] Content-Type: multipart/alternative; boundary="_000_69670F7146898C4583F56DA9AD32F77B1230F9D9xmbalnx13ciscoc_" MIME-Version: 1.0 Cc: "l2vpn@ietf.org" , "Giles Heron \(giheron\)" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 14:53:53 -0000 --_000_69670F7146898C4583F56DA9AD32F77B1230F9D9xmbalnx13ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In preparation for WG last call of this draft, our L2VPN chairs have asked = us to solicit comments on the BGP section of this document (section 8). http://www.ietf.org/id/draft-ietf-l2vpn-evpn-03.txt Please kindly review this draft and post your comments by Friday March/29. Thanks, Ali --_000_69670F7146898C4583F56DA9AD32F77B1230F9D9xmbalnx13ciscoc_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable


In preparation for WG last call of this draft, our L2VPN chairs have a= sked us to solicit comments on the BGP section of this document (section 8)= .


Please kindly review this draft and post your comments by Friday March= /29.

Thanks,
Ali
--_000_69670F7146898C4583F56DA9AD32F77B1230F9D9xmbalnx13ciscoc_-- From sajassi@cisco.com Tue Mar 12 08:31:08 2013 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE8C021F8CE2 for ; Tue, 12 Mar 2013 08:31:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.597 X-Spam-Level: X-Spam-Status: No, score=-10.597 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HXNPtgcNVqVY for ; Tue, 12 Mar 2013 08:31:07 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 4B0BE21F8CDF for ; Tue, 12 Mar 2013 08:31:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=42273; q=dns/txt; s=iport; t=1363102267; x=1364311867; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=JNTZNucYvxMSkU0RMdMV4EdGWkLxKPk2Obhxaj9h8nc=; b=OzDBJFlXOiPoVdIBkbDdrD3EAUEV2lvbRnE7qz7OXWGaZubSfNRLCP/o B3cnsRAkGmC0vKtcw+v0tmZ8Shw4W/vf+XmBC3heOKc3oZfroNCi4GCWy PYmrU+Lswm6lkmi3adFjNzUgYl8G83xPfWt/KQ7R9dkZFKpP1y66ZerrL g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFALBIP1GtJV2c/2dsb2JhbABDhAMjwD2BRxZ0gigBAQEEJwY6EhIBCBEDAQEBCxYBBjkUCQgBAQQBDQUIEwSHdQGxG49xF45cIAYLBgGCX2EDp0yDCoIo X-IronPort-AV: E=Sophos;i="4.84,831,1355097600"; d="scan'208,217";a="186579201" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-7.cisco.com with ESMTP; 12 Mar 2013 15:31:06 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r2CFV6F6013196 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 12 Mar 2013 15:31:06 GMT Received: from xmb-aln-x13.cisco.com ([fe80::5404:b599:9f57:834b]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0318.004; Tue, 12 Mar 2013 10:31:06 -0500 From: "Ali Sajassi (sajassi)" To: Linda Dunbar , Lucy yong , Susan Hares Subject: Re: comment on draft-sajassi-l2vpn-evpn-inter-subnet-forwarding-01 Thread-Topic: comment on draft-sajassi-l2vpn-evpn-inter-subnet-forwarding-01 Thread-Index: Ac4V7IyD4mMZ6DH7Q1GTbDhPRXkI2AACv0SAAAAcW7ACS3cggA== Date: Tue, 12 Mar 2013 15:31:05 +0000 Message-ID: <69670F7146898C4583F56DA9AD32F77B1230FAA3@xmb-aln-x13.cisco.com> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645AE56FD@dfweml509-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.1.120420 x-originating-ip: [10.21.68.177] Content-Type: multipart/alternative; boundary="_000_69670F7146898C4583F56DA9AD32F77B1230FAA3xmbalnx13ciscoc_" MIME-Version: 1.0 Cc: "l2vpn@ietf.org" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 15:31:08 -0000 --_000_69670F7146898C4583F56DA9AD32F77B1230FAA3xmbalnx13ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Linda, Sorry for the delayed in response. Please refer to my reply inline =85 From: Linda Dunbar = > Date: Thursday, February 28, 2013 5:28 PM To: Lucy yong >, Susan Ha= res > Cc: "l2vpn@ietf.org" > Subject: RE: comment on draft-sajassi-l2vpn-evpn-inter-subnet-forwarding-01 Ali, et al, I want to add a few more comments to the draft in addition to Lucy=92s poin= ts: When you say =93connecting E-VPN NVEs within a DC=94 in Section 2.1, do yo= u mean allowing a NVE to route data frames among directly attached VMs that= belong to different E-VPN instances? For inter-subnet,yes. In Section 3 =93Default Gateway Addressing=94, you stated that =93NVE behav= es as an IP Gateway from the perspective of the attached end stations=94. However, the default gateway specified in end stations usually won=92t be = any NVE. Therefore letting NVEs to route traffic among different E-VPN inst= ances may violate the intention of traffic separation that L2VPN aims to pr= ovide. We achieve isolation via EVPN instances. If forwarding between different su= bnets are not desired, then one can configure it as such. As the matter of = fact, the default configuration is that unless one configures IRB functiona= lity to allow forwarding among selected subnets. Even though you only allow NVEs to route traffic among IP subnets belonging= to one customers, those NVEs basically merge multiple virtual network inst= ances to one, which might not be the desired behavior by the customer. We have complete flexibility on inter-subnet switching among different VNs = (represented by different VNIs). The operator can decide for what VNs to en= able or disable (by default) IRB functions. Cheers, Ali Linda From: Lucy yong Sent: Thursday, February 28, 2013 1:48 PM To: 'draft-sajassi-l2vpn-evpn-inter-subnet-forwarding@tools.ietf.org' Subject: comment on draft-sajassi-l2vpn-evpn-inter-subnet-forwarding-01 Hello Ali and All, I have read this draft and have some comments. As you may know or not, I ha= ve been thinking and working on this topics since writing nvo3 use case dra= ft (draft-ietf-nvo3-use-case) and nvo3 framework and data plane addition (d= raft-yong-nvo3-frwk-dpreq); glad to see you have drafted the solution docum= ent now and wish to work with you all on this draft as a co-author. Here are some major comments: =B7 Case 2 is about interconnecting DC infrastructure via WAN, where= DC operator can build one IP VPN that contain multiple IP subnets. I think= this is the carrier=92s carrier case in section 9 in rfc4364, not inter-as= case specified in current document. In addition, there are two options for= this case, one is used of routing aggregation, anther one is without routi= ng aggregation. Both let PE not maintain host/vm specific addresses in forw= arding path and DC operator to build an IP VPN over WAN without WAN SP awar= eness. =B7 Case3 may also implemented in following way, which should be doc= umented too. NVE1 GW1 GW2 NVE2 +------------+ +------------+ +------------+ +------------+ | ... ... | | ... ... | | ... | | ... ... | |(EVI)-(VRF) | |(EVI)-(VRF) | | [LS ] | |(VRF)-(EVI) | | .|.| | | .|. .|. | | |...| | | ... |..| | +------------+ +------------+ +------------+ +------------+ ^ v ^ V ^ V ^ V | | | | | | | | VM1->-+ +------>------+ +----------+ +---------------+ +->-VM2 Figure 4b: Inter-Subnet Forwarding Among E-VPN NVEs in Different DCs with Route Aggregation =B7 Case 4 may also implemented in following way, which should be do= cumented too. NVE1 GW1 ASBR NVE2 +------------+ +------------+ +------------+ +------------+ | ... ... | | ... ... | | ... | | ... | |(EVI)-(VRF) | |(EVI)-(VRF) | | [LS ] | | (VRF)| | .|.|. | | |. .| | | |...| | | |..| | +------------+ +------------+ +------------+ +------------+ ^ v ^ V ^ V ^ V | | | | | | | | VM1->-+ +------>-----+ +----------+ +---------------+ +->-H1 Figure 5b: Inter-Subnet Forwarding Among IP-VPN Sites and E-VPN NVEs with Route Aggregation =B7 Document assume that host/vm send inter subnet packet to the MAC= address of IRB. But does not mention how that may happen, i.e. via configu= ration the gateway MAC address on host/vm or via the protocol such as ARP o= r DHCP. IMO: it need to describe it. =B7 It is not clear to me if the VNID is per EVPN instances or per I= P VPN? If it is former, each subnet, i.e. EVPN instance has its own VNID, N= VE may also need to convert the VNID for inter subnet forwarding. =B7 The term =93EVPN site=94 is used in this document, the site has = been used in VPN technology a lot and has some notion to link the physical = location. But I don=92t know that this document has that notion, it is virt= ual site, i.e. EVPN site may spread among many servers. Is that right? Like to hear from you on these. Regards/Thanks, Lucy --_000_69670F7146898C4583F56DA9AD32F77B1230FAA3xmbalnx13ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable

Hi Linda,

Sorry for the delay= ed in response. Please refer to my reply inline =85

From: Linda Dunbar <linda.dunbar@huawei.com>
Date: Thursday, February 28, 2013 5= :28 PM
To: Lucy yong <lucy.yong@huawei.com>, Susan Hares <susan.hares@huawei.com>
Cc: "l2vpn@ietf.org" <l2v= pn@ietf.org>
Subject: RE: comment on draft-sajas= si-l2vpn-evpn-inter-subnet-forwarding-01

Ali, et al,

 

I want to add a few mo= re comments to the draft in addition to Lucy=92s points:

 

When you say =93connecting E-VPN NVEs within a DC=94 in Section 2.1, =  do you mean allowing a NVE to route data frames among directly attach= ed VMs that belong to different  E-VPN instances?

 
For inter-subnet,ye= s. 

In Section 3 =93Default Gateway Addressing=94, you stated that =93NVE= behaves as an IP Gateway from the perspective of the attached end stations= =94.

 

However, the  default gateway specified in end stations usually = won=92t be any NVE. Therefore letting NVEs to route traffic among different= E-VPN instances may violate the intention of traffic separation that L2VPN aims to provide.

We achieve isolatio= n via EVPN instances. If forwarding between different subnets are not desir= ed, then one can configure it as such. As the matter of fact, the default c= onfiguration is that unless one configures IRB functionality to allow forwarding among selected subnets.

 

Even though you only allow NVEs to route traffic among IP subnets bel= onging to one customers, those NVEs basically merge multiple virtual networ= k instances to one, which might not be the desired behavior by the customer.

We have complete fl= exibility on inter-subnet switching among different VNs (represented by dif= ferent VNIs). The operator can decide for what VNs to enable or disable (by= default) IRB functions.

Cheers,
Ali

 

Linda

 

 

 

From: Lucy yong
Sent: Thursday, February 28, 2013 1:48 PM
To: 'draft-sajassi-l2vpn-evpn-inter-subnet-forwarding@tools.ietf.org'
Subject: comment on draft-sajassi-l2vpn-evpn-inter-subnet-forwarding= -01

 

Hello Ali and All,

 

I have read this draft and have some comments. As yo= u may know or not, I have been thinking and working on this topics since wr= iting nvo3 use case draft (draft-ietf-nvo3-use-case) and nvo3 framework and= data plane addition (draft-yong-nvo3-frwk-dpreq); glad to see you have drafted the solution document now and wish to work wi= th you all on this draft as a co-author.

 

Here are some major comments:

 

=B7 &nbs= p;      Case 2 is about interconnecting DC infra= structure via WAN, where DC operator can build one IP VPN that contain mult= iple IP subnets. I think this is the carrier=92s carrier case in section 9 = in rfc4364, not inter-as case specified in current document. In addition, there are two options for this case, one= is used of routing aggregation, anther one is without routing aggregation.= Both let PE not maintain host/vm specific addresses in forwarding path and= DC operator to build an IP VPN over WAN without WAN SP awareness.

=B7 &nbs= p;      Case3 may also implemented in following = way, which should be documented too.

 

        &nbs= p;   NVE1         &n= bsp;  GW1          &= nbsp;  GW2          =   NVE2

      +------------+= ;  +------------+  +------------+  +----= --------+

      | ...   ...=   |  | ...   ...  |  |    ...&= nbsp;    |  | ...   ...  |

      |(EVI)-(VRF) |&n= bsp; |(EVI)-(VRF) |  |   [LS ]    |  |(V= RF)-(EVI) |

      | .|.| &nbs= p;     |  | .|.   .|.  |  |&nb= sp;  |...|    |  | ...   |..| |

      +------------+= ;  +------------+  +------------+  +----= --------+

         ^ v=              ^&= nbsp;    V        &n= bsp; ^   V         &= nbsp;     ^  V

         | |=              |&= nbsp;    |        &n= bsp; |   |         &= nbsp;     |  |

 &= nbsp; VM1->-+ +------>------+     = 3;----------+   +---------------+  +->-VM= 2

&n= bsp;

  Figure 4b: Inter-Subnet Forwarding Among E-VP= N NVEs in Different DCs

 &= nbsp; with Route Aggregation

&n= bsp;

=B7 &nbs= p;      Case 4 may also implemented in following= way, which should be documented too.

 

        &nbs= p;   NVE1         &n= bsp;  GW1          &= nbsp;  ASBR          = ; NVE2

      +------------+= ;  +------------+  +------------+  +----= --------+

      | ...   ...=   |  | ...   ...  |  |    ...&= nbsp;    |  |       = ... |

      |(EVI)-(VRF) |&n= bsp; |(EVI)-(VRF) |  |   [LS ]    |  |&n= bsp;      (VRF)|

      | .|.|. &nb= sp;    |  | |.    .|   | = |   |...|    |  |    &nb= sp;  |..| |

      +------------+= ;  +------------+  +------------+  +----= --------+

         ^ v=             ^ &= nbsp;    V        &n= bsp; ^   V         &= nbsp;     ^  V

         | |=             | &= nbsp;    |        &n= bsp; |   |         &= nbsp;     |  |

   VM1->-+ +------>-----+= ;      +----------+   +-----= ----------+  +->-H1

  Figure 5b: Inter-Subnet Forwarding Among IP-V= PN Sites and E-VPN NVEs

 &= nbsp; with Route Aggregation

&n= bsp;

=B7 &nbs= p;      Document assume that host/vm send inter = subnet packet to the MAC address of IRB. But does not mention how that may = happen, i.e. via configuration the gateway MAC address on host/vm or via th= e protocol such as ARP or DHCP.  IMO: it need to describe it.

=B7 &nbs= p;      It is not clear to me if the VNID is per= EVPN instances or per IP VPN? If it is former, each subnet, i.e. EVPN inst= ance has its own VNID, NVE may also need to convert the VNID for inter subn= et forwarding.

=B7 &nbs= p;      The term =93EVPN site=94 is used in this= document, the site has been used in VPN technology a lot and has some noti= on to link the physical location. But I don=92t know that this document has= that notion, it is virtual site, i.e. EVPN site may spread among many servers. Is that right?

 

Like to hear from you on these.

 

Regards/Thanks,

Lucy

 --_000_69670F7146898C4583F56DA9AD32F77B1230FAA3xmbalnx13ciscoc_-- From shares@ndzh.com Tue Mar 12 10:48:47 2013 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD94811E80D2; Tue, 12 Mar 2013 10:48:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.866 X-Spam-Level: * X-Spam-Status: No, score=1.866 tagged_above=-999 required=5 tests=[AWL=1.360, BAYES_00=-2.599, DOS_OUTLOOK_TO_MX=1, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q9HkLyfCwbSv; Tue, 12 Mar 2013 10:48:44 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 8564521F8A0B; Tue, 12 Mar 2013 10:48:43 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=130.129.16.73; From: "Susan Hares" To: "'Ali Sajassi \(sajassi\)'" , References: <69670F7146898C4583F56DA9AD32F77B1230F9D9@xmb-aln-x13.cisco.com> In-Reply-To: <69670F7146898C4583F56DA9AD32F77B1230F9D9@xmb-aln-x13.cisco.com> Subject: RE: draft-ietf-l2vpn-evpn Date: Tue, 12 Mar 2013 13:48:40 -0400 Message-ID: <005301ce1f49$d5a13a70$80e3af50$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0054_01CE1F28.4E912110" X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AQFMSsAUMmP0/SleNQF+OHtrO2lqeZml/OEw X-Authenticated-User: skh@ndzh.com Cc: l2vpn@ietf.org, "'Giles Heron \(giheron\)'" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 17:48:47 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0054_01CE1F28.4E912110 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Ali: Thanks for sending the draft. Please consider IPv6 in your draft. You may want to talk to the authors of draft-ietf-idr-bgp-ipv6-rt-constrain. https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-ipv6-rt-constrain/ Sue From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Ali Sajassi (sajassi) Sent: Tuesday, March 12, 2013 10:54 AM To: idr@ietf.org Cc: l2vpn@ietf.org; Giles Heron (giheron) Subject: draft-ietf-l2vpn-evpn In preparation for WG last call of this draft, our L2VPN chairs have asked us to solicit comments on the BGP section of this document (section 8). http://www.ietf.org/id/draft-ietf-l2vpn-evpn-03.txt Please kindly review this draft and post your comments by Friday March/29. Thanks, Ali ------=_NextPart_000_0054_01CE1F28.4E912110 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Ali:

 

Thanks for sending the draft. 

 

Please consider IPv6 in your draft. You may want to talk to the = authors of draft-ietf-idr-bgp-ipv6-rt-constrain. =

 

https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-ipv6-rt-constr= ain/

 

Sue

 

 

From:= = l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of = Ali Sajassi (sajassi)
Sent: Tuesday, March 12, 2013 10:54 = AM
To: idr@ietf.org
Cc: l2vpn@ietf.org; Giles Heron = (giheron)
Subject: = draft-ietf-l2vpn-evpn

 

 

 

In preparation for WG last call of this draft, our L2VPN chairs have = asked us to solicit comments on the BGP section of this document = (section 8).

 

 

Please kindly review this draft and post your comments by Friday = March/29.

 

Thanks,

Ali

------=_NextPart_000_0054_01CE1F28.4E912110-- From shares@ndzh.com Tue Mar 12 11:11:03 2013 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CC0A11E8131 for ; Tue, 12 Mar 2013 11:11:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.086 X-Spam-Level: *** X-Spam-Status: No, score=3.086 tagged_above=-999 required=5 tests=[AWL=-0.020, BAYES_50=0.001, DOS_OUTLOOK_TO_MX=1, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eawlYRSvypce for ; Tue, 12 Mar 2013 11:11:01 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 5820711E80E9 for ; Tue, 12 Mar 2013 11:11:01 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=130.129.16.73; From: "Susan Hares" To: Subject: draft-boutros-l2vpn-evpn-vpws-01 and transport group Date: Tue, 12 Mar 2013 14:10:59 -0400 Message-ID: <007901ce1f4c$f35eb990$da1c2cb0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_007A_01CE1F2B.6C4EC740" X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: Ac4fS6AFP3GwTWSkR9KARTZU9RqyuA== X-Authenticated-User: skh@ndzh.com X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 18:11:03 -0000 This is a multipart message in MIME format. ------=_NextPart_000_007A_01CE1F2B.6C4EC740 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sami, Ali, Samer, John and Jeff: Have you examined the work in tsvwg regarding a re-examination of some of the intserv/diff-serv mapping? The idr draft (draft-ietf-idr-sla-exchange-00) provides a BGP mechanisms to pass the QoS SLA mechanisms. It appears that this BGP attribute and that BGP attribute look to specify T-specs and SLAs. Perhaps the harmonizing this work may be useful to your effort. The network management people (who will obviously be concerned about informational models), encourage people to harmonize their data models. Sue ------=_NextPart_000_007A_01CE1F2B.6C4EC740 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Sami, Ali, Samer, John = and Jeff:

 

Have you examined the = work in tsvwg regarding a re-examination of some of the = intserv/diff-serv mapping?

 

The idr =
draft (draft-ietf-idr-sla-exchange-00) provides a BGP mechanisms to pass =
the QoS SLA mechanisms.  It appears that this BGP attribute and =
that BGP attribute look to specify T-specs and SLAs.  Perhaps the =
harmonizing this work may be useful to your =
effort.
 
The =
network management people (who will obviously be concerned about =
informational models), encourage people to harmonize their data =
models.
 
Sue =

 

 

------=_NextPart_000_007A_01CE1F2B.6C4EC740-- From jorge.rabadan@alcatel-lucent.com Thu Mar 14 09:06:45 2013 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1941411E827B for ; Thu, 14 Mar 2013 09:06:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09XudGTWff7x for ; Thu, 14 Mar 2013 09:06:44 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 695F211E8277 for ; Thu, 14 Mar 2013 09:06:43 -0700 (PDT) Received: from us70uusmtp4.zam.alcatel-lucent.com (h135-5-2-66.lucent.com [135.5.2.66]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id r2EG6f7E003994 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 14 Mar 2013 11:06:42 -0500 (CDT) Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id r2EG6f1k028394 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 14 Mar 2013 12:06:41 -0400 Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (135.239.2.74) by US70UWXCHHUB01.zam.alcatel-lucent.com (135.5.2.48) with Microsoft SMTP Server (TLS) id 14.2.247.3; Thu, 14 Mar 2013 12:06:41 -0400 Received: from FR711WXCHMBA03.zeu.alcatel-lucent.com ([169.254.3.41]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Thu, 14 Mar 2013 17:06:25 +0100 From: "Rabadan, Jorge (Jorge)" To: "l2vpn@ietf.org" Subject: bgp encap ext-comm in draft-sd-l2vpn-evpn-overlay-01 Thread-Topic: bgp encap ext-comm in draft-sd-l2vpn-evpn-overlay-01 Thread-Index: AQHOIM3gS8v/40qBHUaAuUV6MlE0Kw== Date: Thu, 14 Mar 2013 16:06:24 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="us-ascii" Content-ID: <0B22E14178E2F8409E8389BF6BE71C51@exchange.lucent.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 16:06:45 -0000 Hi, Following up on the question I asked you during the l2vpn session to Ali: Should we send the BGP encapsulation ext-comm along with the Inclusive mcast route too? Section 5.1: "When the NVEs reside on the hypervisor, the E-VPN BGP routes and attributes associated with multi-homing are no longer required. This reduces the required routes and attributes to the following subset of five out of the set of eight : - MAC Advertisement Route - Inclusive Multicast Ethernet Tag Route - MAC Mobility Extended Community - Default Gateway Extended Community As mentioned in section 3.1.1, BGP Encapsulation Extended Community attribute as defined in [RFC5512] SHOULD be used along with MAC Advertisement Route or Ethernet AD Route to indicate the supported encapsulations." So in this scenario: VM1--NVE1----------NVE2--VM2 If VM2 MAC has not been advertised yet by NVE2 and since there is no AD route, how does NVE1 know what encapsulation to use to send unknown unicast traffic to NVE2? In my view, the BGP encapsulation ext-comm should be sent along with the Inclusive mcast route too, but I might be missing something. Can you please comment on it? Thank you. Jorge From sajassi@cisco.com Thu Mar 14 10:28:54 2013 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A58811E80E9 for ; Thu, 14 Mar 2013 10:28:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l8cTKk1930ib for ; Thu, 14 Mar 2013 10:28:49 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id CA4D311E80D9 for ; Thu, 14 Mar 2013 10:28:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1462; q=dns/txt; s=iport; t=1363282130; x=1364491730; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=+i3CDW6XJgjtkbVrKb+klMkeBZ7ayiHmOoOE1uT8rXM=; b=VmAvU5SMfnXglh3C7eEhEjXkzRetWd5UjnyhvT9qsy/gRCgS+atLmcai kZnkMGNMCarV8QpA7FzxB1jnVOHgQT5Z+6ZxZYF/VXVho/gKK8TQ/GDoY iGfDSM96HvFmq6F37BNwQQ67D3jVsdJZKQiCuJRqX8ns2Cw2jnFTKM9gc 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAHcIQlGtJV2b/2dsb2JhbABDhD/AQ4FlFnSCLQEEOlEBCCIUQiUCBAESCAyIAAHCFI5lOIJfYQOnWoMKgig X-IronPort-AV: E=Sophos;i="4.84,845,1355097600"; d="scan'208";a="187536070" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-7.cisco.com with ESMTP; 14 Mar 2013 17:28:49 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r2EHSmuf019691 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 14 Mar 2013 17:28:48 GMT Received: from xmb-aln-x13.cisco.com ([fe80::5404:b599:9f57:834b]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0318.004; Thu, 14 Mar 2013 12:28:48 -0500 From: "Ali Sajassi (sajassi)" To: "Rabadan, Jorge (Jorge)" , "l2vpn@ietf.org" Subject: Re: bgp encap ext-comm in draft-sd-l2vpn-evpn-overlay-01 Thread-Topic: bgp encap ext-comm in draft-sd-l2vpn-evpn-overlay-01 Thread-Index: AQHOIM3gS8v/40qBHUaAuUV6MlE0K5ilT6cA Date: Thu, 14 Mar 2013 17:28:48 +0000 Message-ID: <69670F7146898C4583F56DA9AD32F77B12310866@xmb-aln-x13.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.1.120420 x-originating-ip: [10.21.69.160] Content-Type: text/plain; charset="us-ascii" Content-ID: <5AAD56C2F4853B4A9ED03EBDB5EAE03D@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 17:28:54 -0000 Hi Rabadan, You're right. We need to include this attribute for Inclusive Multicast route as well. Cheers, Ali On 3/14/13 12:06 PM, "Rabadan, Jorge (Jorge)" wrote: >Hi, > >Following up on the question I asked you during the l2vpn session to Ali: > >Should we send the BGP encapsulation ext-comm along with the Inclusive >mcast route too? > >Section 5.1: >"When the NVEs reside on the hypervisor, the E-VPN BGP routes and >attributes associated with multi-homing are no longer required. >This reduces the required routes and attributes to the following subset of >five out of the set of eight : >- MAC Advertisement Route >- Inclusive Multicast Ethernet Tag Route >- MAC Mobility Extended Community >- Default Gateway Extended Community > >As mentioned in section 3.1.1, BGP Encapsulation Extended Community >attribute as defined in [RFC5512] SHOULD be used along with MAC >Advertisement Route or Ethernet AD Route to indicate the supported >encapsulations." > >So in this scenario: > >VM1--NVE1----------NVE2--VM2 > >If VM2 MAC has not been advertised yet by NVE2 and since there is no AD >route, how does NVE1 know what encapsulation to use to send unknown >unicast traffic to NVE2? >In my view, the BGP encapsulation ext-comm should be sent along with the >Inclusive mcast route too, but I might be missing something. > >Can you please comment on it? >Thank you. >Jorge > From jorge.rabadan@alcatel-lucent.com Thu Mar 14 10:35:16 2013 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5406D21F90F5 for ; Thu, 14 Mar 2013 10:35:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ziA5VL8Z0utl for ; Thu, 14 Mar 2013 10:35:15 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 1BB9F21F90F1 for ; Thu, 14 Mar 2013 10:35:15 -0700 (PDT) Received: from us70tusmtp1.zam.alcatel-lucent.com (h135-5-2-63.lucent.com [135.5.2.63]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id r2EHZCrm012806 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 14 Mar 2013 12:35:12 -0500 (CDT) Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id r2EHZBmL005459 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 14 Mar 2013 13:35:12 -0400 Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (135.239.2.112) by US70UWXCHHUB02.zam.alcatel-lucent.com (135.5.2.49) with Microsoft SMTP Server (TLS) id 14.2.247.3; Thu, 14 Mar 2013 13:35:12 -0400 Received: from FR711WXCHMBA03.zeu.alcatel-lucent.com ([169.254.3.41]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Thu, 14 Mar 2013 18:35:07 +0100 From: "Rabadan, Jorge (Jorge)" To: "Ali Sajassi (sajassi)" , "l2vpn@ietf.org" Subject: Re: bgp encap ext-comm in draft-sd-l2vpn-evpn-overlay-01 Thread-Topic: bgp encap ext-comm in draft-sd-l2vpn-evpn-overlay-01 Thread-Index: AQHOIM3gS8v/40qBHUaAuUV6MlE0K5ilT6cA//+dKIA= Date: Thu, 14 Mar 2013 17:35:06 +0000 Message-ID: In-Reply-To: <69670F7146898C4583F56DA9AD32F77B12310866@xmb-aln-x13.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 17:35:16 -0000 Thank you Ali. Regards, Jorge -----Original Message----- From: "Ali Sajassi (sajassi)" Date: Thursday, March 14, 2013 10:28 AM To: Jorge Rabadan , "l2vpn@ietf.org" Subject: Re: bgp encap ext-comm in draft-sd-l2vpn-evpn-overlay-01 >Hi Rabadan, > > >You're right. We need to include this attribute for Inclusive Multicast >route as well. > >Cheers, >Ali > >On 3/14/13 12:06 PM, "Rabadan, Jorge (Jorge)" > wrote: > >>Hi, >> >>Following up on the question I asked you during the l2vpn session to Ali: >> >>Should we send the BGP encapsulation ext-comm along with the Inclusive >>mcast route too? >> >>Section 5.1: >>"When the NVEs reside on the hypervisor, the E-VPN BGP routes and >>attributes associated with multi-homing are no longer required. >>This reduces the required routes and attributes to the following subset >>of >>five out of the set of eight : >>- MAC Advertisement Route >>- Inclusive Multicast Ethernet Tag Route >>- MAC Mobility Extended Community >>- Default Gateway Extended Community >> >>As mentioned in section 3.1.1, BGP Encapsulation Extended Community >>attribute as defined in [RFC5512] SHOULD be used along with MAC >>Advertisement Route or Ethernet AD Route to indicate the supported >>encapsulations." >> >>So in this scenario: >> >>VM1--NVE1----------NVE2--VM2 >> >>If VM2 MAC has not been advertised yet by NVE2 and since there is no AD >>route, how does NVE1 know what encapsulation to use to send unknown >>unicast traffic to NVE2? >>In my view, the BGP encapsulation ext-comm should be sent along with the >>Inclusive mcast route too, but I might be missing something. >> >>Can you please comment on it? >>Thank you. >>Jorge >> > From smohanty@juniper.net Fri Mar 15 15:20:18 2013 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6387F21F862B; Fri, 15 Mar 2013 15:20:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.466 X-Spam-Level: X-Spam-Status: No, score=-3.466 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cF6GfKRMA06C; Fri, 15 Mar 2013 15:20:16 -0700 (PDT) Received: from exprod7og126.obsmtp.com (exprod7og126.obsmtp.com [64.18.2.206]) by ietfa.amsl.com (Postfix) with ESMTP id B11B121F861B; Fri, 15 Mar 2013 15:20:09 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob126.postini.com ([64.18.6.12]) with SMTP ID DSNKUUOemd5JcbVxyXcbl6b1a0bH4VyrFTzq@postini.com; Fri, 15 Mar 2013 15:20:09 PDT Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 15 Mar 2013 15:16:30 -0700 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.1.355.2; Fri, 15 Mar 2013 15:16:29 -0700 Received: from ch1outboundpool.messaging.microsoft.com (216.32.181.186) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 15 Mar 2013 15:25:48 -0700 Received: from mail153-ch1-R.bigfish.com (10.43.68.230) by CH1EHSOBE010.bigfish.com (10.43.70.60) with Microsoft SMTP Server id 14.1.225.23; Fri, 15 Mar 2013 22:16:28 +0000 Received: from mail153-ch1 (localhost [127.0.0.1]) by mail153-ch1-R.bigfish.com (Postfix) with ESMTP id C0D9C240245; Fri, 15 Mar 2013 22:16:28 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.236.101; KIP:(null); UIP:(null); (null); H:BY2PRD0510HT004.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -22 X-BigFish: PS-22(zz9371Ic85fh4015Izz1f42h1ee6h1de0h1202h1e76h1d1ah1d2ahzz1033IL17326ah8275dh18c673h8275bhz2dh2a8h668h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1155h) Received: from mail153-ch1 (localhost.localdomain [127.0.0.1]) by mail153-ch1 (MessageSwitch) id 136338578741197_15045; Fri, 15 Mar 2013 22:16:27 +0000 (UTC) Received: from CH1EHSMHS008.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.246]) by mail153-ch1.bigfish.com (Postfix) with ESMTP id 0738D380046; Fri, 15 Mar 2013 22:16:27 +0000 (UTC) Received: from BY2PRD0510HT004.namprd05.prod.outlook.com (157.56.236.101) by CH1EHSMHS008.bigfish.com (10.43.70.8) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 15 Mar 2013 22:16:26 +0000 Received: from BY2PRD0510MB377.namprd05.prod.outlook.com ([169.254.5.104]) by BY2PRD0510HT004.namprd05.prod.outlook.com ([10.255.84.39]) with mapi id 14.16.0275.006; Fri, 15 Mar 2013 22:16:14 +0000 From: Satya Mohanty To: "Ali Sajassi (sajassi)" , "idr@ietf.org" Subject: RE: draft-ietf-l2vpn-evpn Thread-Topic: draft-ietf-l2vpn-evpn Thread-Index: AQHOHzFpw7wq2p0F306XvoGHyBm2OpinSaug Date: Fri, 15 Mar 2013 22:16:14 +0000 Message-ID: References: <69670F7146898C4583F56DA9AD32F77B1230F9D9@xmb-aln-x13.cisco.com> In-Reply-To: <69670F7146898C4583F56DA9AD32F77B1230F9D9@xmb-aln-x13.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.224.53] Content-Type: multipart/alternative; boundary="_000_DBDBC40345866E4FA5701A2C8C2684222CC47522BY2PRD0510MB377_" MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%CISCO.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Cc: "l2vpn@ietf.org" , "Giles Heron \(giheron\)" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2013 22:20:18 -0000 --_000_DBDBC40345866E4FA5701A2C8C2684222CC47522BY2PRD0510MB377_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Few comments, 1. Sec 8.3: Please consider putting in a line stating that the per ESI Rout= e (type 4) carries a label with all 0s (like the Type 1 mandatory route) in= the MP-Reach NLRI. 2. This is not explicitly sec 8 but I think there may be a discrepancy in t= he draft. Page 27, top paragraph An PE may advertise the same single E-VPN label for all MAC addresses in a given EVI. This label assignment methodology is referred to as a per EVI label assignment. Alternatively, an PE may advertise a unique E-VPN label per combination. This label assignment methodology is referred to as a per label assignment. As a third option, an PE may advertise a unique E- VPN label per MAC address. All of these methodologies have their tradeoffs. I see a problem with the third option (per-prefix allocation mode), related= to aliasing in the Active/Active case. In such a label allocation mode, what label will be associated with the per= EVI AD route ? Let's say PE1 and PE2 share the same ESI, PE1 and PE1 uses per prefix label= allocation mode, and PE2 uses either per EVI or per l= abel allocation mode. As per the aliasing behavior, a mac route (say p1 wit= h label l1) advertised from PE1, should be reachable from PE3 via PE2, irre= spective of whether PE2 advertised p1 or not. If PE2 did not advertise p1,= but PE3 sends traffic to PE2, what label does PE3 slap on frames? As per t= he draft, it will slap the label what was received in the per EVI AD route.= Moot question is what does it correspond to here ? Should per-prefix label allocation be allowed? If it is, I think then the c= oncept of aliasing will be lost, and all macs with the same EVI, ESI need t= o be advertised from each of the PEs configured to the same ES. PE1 -- --- --| / |_______ CE ________ RR-------PE3 \ | PE2 ---------| Thanks, --Satya From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of A= li Sajassi (sajassi) Sent: Tuesday, March 12, 2013 7:54 AM To: idr@ietf.org Cc: l2vpn@ietf.org; Giles Heron (giheron) Subject: draft-ietf-l2vpn-evpn In preparation for WG last call of this draft, our L2VPN chairs have asked = us to solicit comments on the BGP section of this document (section 8). http://www.ietf.org/id/draft-ietf-l2vpn-evpn-03.txt Please kindly review this draft and post your comments by Friday March/29. Thanks, Ali --_000_DBDBC40345866E4FA5701A2C8C2684222CC47522BY2PRD0510MB377_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Few comments,

 <= /p>

1. Sec 8.3: Please consid= er putting in a line stating that the per ESI Route (type 4) carries a labe= l with all 0s (like the Type 1 mandatory route) in the MP-Reach NLRI.

 <= /p>

2. This is not explicitly= sec 8 but I think there may be a discrepancy in the draft.  Page 27, = top paragraph

 <= /p>

   An PE may adverti= se the same single E-VPN label for all MAC addresses

   in a given EVI. T= his label assignment methodology is referred to as a

   per EVI label ass= ignment. Alternatively, an PE may advertise a unique

   E-VPN label per &= lt;ESI, Ethernet Tag> combination. This label

   assignment method= ology is referred to as a per <ESI, Ethernet Tag>

   label assignment.= As a third option, an PE may advertise a unique E-

   VPN label per MAC= address. All of these methodologies have their

   tradeoffs.

 

I see a problem with the third option (per-prefix allocation mode), rela= ted to aliasing in the Active/Active case.

In such a label allocation mode, what label will be associated with the = per EVI AD route ?

 

Let’s say PE1 and PE2 share the same ESI, PE1 and PE1 uses per pre= fix label  allocation mode, and PE2 uses either per EVI or per <ESI= , Ethernet-tag> label allocation mode. As per the aliasing behavior, a ma= c route (say p1 with label l1) advertised from PE1, should be reachable fro= m PE3 via PE2, irrespective of whether PE2 advertised p1 or not.  If P= E2 did not advertise p1, but PE3 sends traffic to PE2, what label does PE3 slap on frames? As per the draft, it will slap= the label what was received in the per EVI AD route. Moot question is what= does it correspond to here ?

 

Should per-prefix label allocation be allowed? If it is, I think then th= e concept of aliasing will be lost, and all macs with the same EVI, ESI need to be advertised from each of the PEs configured to the= same ES.

 <= /p>

    &= nbsp;  PE1 -- --- --|        &= nbsp; 

    /=             &n= bsp;         |_______  &n= bsp;            = ;   

CE    = ;            &n= bsp;        ________ RR-------PE3

   \  = ;            &n= bsp;         |

    &= nbsp; PE2 ---------|

 <= /p>

Thanks,=

--Satya=

 <= /p>

From: l2vpn-bo= unces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Ali Sajassi (sajassi)
Sent: Tuesday, March 12, 2013 7:54 AM
To: idr@ietf.org
Cc: l2vpn@ietf.org; Giles Heron (giheron)
Subject: draft-ietf-l2vpn-evpn

 

 

 

In preparation for WG last = call of this draft, our L2VPN chairs have asked us to solicit comments on t= he BGP section of this document (section 8).

 

 

Please kindly review this d= raft and post your comments by Friday March/29.

 

Thanks,

Ali

--_000_DBDBC40345866E4FA5701A2C8C2684222CC47522BY2PRD0510MB377_-- From jakob.heitz@ericsson.com Fri Mar 15 16:17:14 2013 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AE7C11E80F8; Fri, 15 Mar 2013 16:17:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.498 X-Spam-Level: X-Spam-Status: No, score=-2.498 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KqLIlDjhhXaB; Fri, 15 Mar 2013 16:17:12 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id B85E821F8771; Fri, 15 Mar 2013 16:17:11 -0700 (PDT) X-AuditID: c6180641-b7faf6d00000096b-33-5143abf6182a Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id D7.CB.02411.6FBA3415; Sat, 16 Mar 2013 00:17:11 +0100 (CET) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.02.0318.004; Fri, 15 Mar 2013 19:17:10 -0400 From: Jakob Heitz To: Satya Mohanty , "Ali Sajassi (sajassi)" , "idr@ietf.org" Subject: RE: draft-ietf-l2vpn-evpn Thread-Topic: draft-ietf-l2vpn-evpn Thread-Index: AQHOHzFpw7wq2p0F306XvoGHyBm2OpinSauggAAcl9A= Date: Fri, 15 Mar 2013 23:17:09 +0000 Message-ID: <2F3EBB88EC3A454AAB08915FBF0B8C7E1C8338@eusaamb109.ericsson.se> References: <69670F7146898C4583F56DA9AD32F77B1230F9D9@xmb-aln-x13.cisco.com> 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_2F3EBB88EC3A454AAB08915FBF0B8C7E1C8338eusaamb109ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJLMWRmVeSWpSXmKPExsUyuXRPgu731c6BBh8Oi1jca9jJbPHq9jMm i8ffDrFbvDvbzGJxpfU+iwOrx5TfG1k9liz5yeRxvekqewBzFJdNSmpOZllqkb5dAlfG6+Ur mApOTmGsuDN5HnMD48JGxi5GTg4JAROJz58XsEPYYhIX7q1n62Lk4hASOMIosXzZP1aQhJDA ckaJPzPcQWw2AR2Jb9e7mEFsEYEyiRlr5wLZHBzMAiES67e6gYSFBZQkem7dZ4UoUZY4P/8X I4RtJbFz61+wOIuAqsSPF8fAxvAKeEs0LlwMtXcxo8S0ja/BGjgFEiXetx0FK2IEOu77qTVM IDazgLjErSfzmSCOFpBYsuc8M4QtKvHyMcTNEkCLv895xAJxW77E3r1xELsEJU7OfMIygVF0 FpJJsxCqZiGpgijRkViw+xMbhK0tsWzha2YY+8yBx0zI4gsY2VcxcpQWp5blphsZbmIERt8x CTbHHYwLPlkeYpTmYFES5w11vRAgJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgXGq717P3xWM HX8F739mmH4/xeX7AcPZPmKx+edFlxxc3aLruGnGBu1fS5ewFQaa/9JiOXvd6rLdqoTY9Z1O QaF50jPlBLUiF8UkfNMROWZytXl7EttWtv+zevYtCLu+YALvwpttR2vOqDdKLX5dxPVbrkHX mDvIuMaHa8Fl1n0z/q9j85G/HaDEUpyRaKjFXFScCAAgbVNljAIAAA== Cc: "l2vpn@ietf.org" , "Giles Heron \(giheron\)" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2013 23:17:14 -0000 --_000_2F3EBB88EC3A454AAB08915FBF0B8C7E1C8338eusaamb109ericsso_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The egress PE can allocate MAC labels anyway it likes as long as it can deliver the frame when it arrives with that label. It is not necessarily the same as the alias label. A frame arriving with the alias label will most likely undergo a MAC/VLAN lookup. This does not prevent it from using a different label allocation scheme for MAC labels than for alias labels. -- Jakob Heitz. x25475. 510-566-2901 ________________________________ From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of S= atya Mohanty Sent: Friday, March 15, 2013 3:16 PM To: Ali Sajassi (sajassi); idr@ietf.org Cc: l2vpn@ietf.org; Giles Heron (giheron) Subject: RE: draft-ietf-l2vpn-evpn Few comments, 1. Sec 8.3: Please consider putting in a line stating that the per ESI Rout= e (type 4) carries a label with all 0s (like the Type 1 mandatory route) in= the MP-Reach NLRI. 2. This is not explicitly sec 8 but I think there may be a discrepancy in t= he draft. Page 27, top paragraph An PE may advertise the same single E-VPN label for all MAC addresses in a given EVI. This label assignment methodology is referred to as a per EVI label assignment. Alternatively, an PE may advertise a unique E-VPN label per combination. This label assignment methodology is referred to as a per label assignment. As a third option, an PE may advertise a unique E- VPN label per MAC address. All of these methodologies have their tradeoffs. I see a problem with the third option (per-prefix allocation mode), related= to aliasing in the Active/Active case. In such a label allocation mode, what label will be associated with the per= EVI AD route ? Let's say PE1 and PE2 share the same ESI, PE1 and PE1 uses per prefix label= allocation mode, and PE2 uses either per EVI or per l= abel allocation mode. As per the aliasing behavior, a mac route (say p1 wit= h label l1) advertised from PE1, should be reachable from PE3 via PE2, irre= spective of whether PE2 advertised p1 or not. If PE2 did not advertise p1,= but PE3 sends traffic to PE2, what label does PE3 slap on frames? As per t= he draft, it will slap the label what was received in the per EVI AD route.= Moot question is what does it correspond to here ? Should per-prefix label allocation be allowed? If it is, I think then the c= oncept of aliasing will be lost, and all macs with the same EVI, ESI need t= o be advertised from each of the PEs configured to the same ES. PE1 -- --- --| / |_______ CE ________ RR-------PE3 \ | PE2 ---------| Thanks, --Satya From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of A= li Sajassi (sajassi) Sent: Tuesday, March 12, 2013 7:54 AM To: idr@ietf.org Cc: l2vpn@ietf.org; Giles Heron (giheron) Subject: draft-ietf-l2vpn-evpn In preparation for WG last call of this draft, our L2VPN chairs have asked = us to solicit comments on the BGP section of this document (section 8). http://www.ietf.org/id/draft-ietf-l2vpn-evpn-03.txt Please kindly review this draft and post your comments by Friday March/29. Thanks, Ali --_000_2F3EBB88EC3A454AAB08915FBF0B8C7E1C8338eusaamb109ericsso_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
The egress PE can alloca= te MAC labels anyway it likes
as long as it can delive= r the frame when it arrives
with that label. It is n= ot necessarily the same
as the alias label. A fr= ame arriving with the alias
label will most likely u= ndergo a MAC/VLAN lookup.
This does not prevent it from using a different
label allocation scheme for MAC labels than fo= r
alias labels.

-- Jakob Heitz. x25475. 5= 10-566-2901

 

From: l2vpn-bounces@ietf.org [mailt= o:l2vpn-bounces@ietf.org] On Behalf Of Satya Mohanty
Sent: Friday, March 15, 2013 3:16 PM
To: Ali Sajassi (sajassi); idr@ietf.org
Cc: l2vpn@ietf.org; Giles Heron (giheron)
Subject: RE: draft-ietf-l2vpn-evpn

Few comments,

 

1. Sec 8.3: Please consider putting in a l= ine stating that the per ESI Route (type 4) carries a label with all 0s (li= ke the Type 1 mandatory route) in the MP-Reach NLRI.

 

2. This is not explicitly sec 8 but I thin= k there may be a discrepancy in the draft.  Page 27, top paragraph

 

   An PE may advertise the = same single E-VPN label for all MAC addresses

   in a given EVI. This lab= el assignment methodology is referred to as a

   per EVI label assignment= . Alternatively, an PE may advertise a unique

   E-VPN label per <ESI,= Ethernet Tag> combination. This label

   assignment methodology i= s referred to as a per <ESI, Ethernet Tag>

   label assignment. As a t= hird option, an PE may advertise a unique E-

   VPN label per MAC addres= s. All of these methodologies have their

   tradeoffs.

 <= /o:p>

I see a prob= lem with the third option (per-prefix allocation mode), related to aliasing= in the Active/Active case.

In such a la= bel allocation mode, what label will be associated with the per EVI AD rout= e ?

 <= /o:p>

Let’s = say PE1 and PE2 share the same ESI, PE1 and PE1 uses per prefix label = allocation mode, and PE2 uses either per EVI or per <ESI, Ethernet-tag> label allocation mode. As per the aliasing b= ehavior, a mac route (say p1 with label l1) advertised from PE1, should be = reachable from PE3 via PE2, irrespective of whether PE2 advertised p1 or no= t.  If PE2 did not advertise p1, but PE3 sends traffic to PE2, what label does PE3 slap on frames? As per the draft= , it will slap the label what was received in the per EVI AD route. Moot qu= estion is what does it correspond to here ?

 <= /o:p>

Should per-p= refix label allocation be allowed? If it is, I think then the concept of al= iasing will be lost, and all macs with the same EVI, ESI need to be advertised from each of the PEs configured to= the same ES.

 

       PE1 -= - --- --|          

    /   &nbs= p;            &= nbsp;      |_______     &= nbsp;           &nbs= p;

CE      &nbs= p;            &= nbsp;     ________ RR-------PE3

   \    &nbs= p;            &= nbsp;      |

      PE2 --= -------|

 

Thanks,

--Satya

 

From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@i= etf.org] On Behalf Of Ali Sajassi (sajassi)
Sent: Tuesday, March 12, 2013 7:54 AM
To: idr@ietf.org
Cc: l2vpn@ietf.org; Giles Heron (giheron)
Subject: draft-ietf-l2vpn-evpn

 

 

 

In preparation for WG last call of this dr= aft, our L2VPN chairs have asked us to solicit comments on the BGP section = of this document (section 8).

 

 

Please kindly review this draft and post y= our comments by Friday March/29.

 

Thanks,

Ali

--_000_2F3EBB88EC3A454AAB08915FBF0B8C7E1C8338eusaamb109ericsso_-- From smohanty@juniper.net Fri Mar 15 17:10:58 2013 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE4261F0D0B; Fri, 15 Mar 2013 17:10:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.466 X-Spam-Level: X-Spam-Status: No, score=-3.466 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PlYiRmT9YJMH; Fri, 15 Mar 2013 17:10:55 -0700 (PDT) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by ietfa.amsl.com (Postfix) with ESMTP id 7C0C61F0D05; Fri, 15 Mar 2013 17:10:55 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP ID DSNKUUO4j1VcNNwF7RA1JpQ03LoYnLO2AaQw@postini.com; Fri, 15 Mar 2013 17:10:55 PDT Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 15 Mar 2013 17:06:12 -0700 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Fri, 15 Mar 2013 17:06:11 -0700 Received: from va3outboundpool.messaging.microsoft.com (216.32.180.12) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 15 Mar 2013 17:08:41 -0700 Received: from mail162-va3-R.bigfish.com (10.7.14.234) by VA3EHSOBE003.bigfish.com (10.7.40.23) with Microsoft SMTP Server id 14.1.225.23; Sat, 16 Mar 2013 00:06:10 +0000 Received: from mail162-va3 (localhost [127.0.0.1]) by mail162-va3-R.bigfish.com (Postfix) with ESMTP id 6B9CB1602A5; Sat, 16 Mar 2013 00:06:10 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.236.101; KIP:(null); UIP:(null); (null); H:BY2PRD0510HT003.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -22 X-BigFish: PS-22(zz9371Ic85fh4015Izz1f42h1ee6h1de0h1202h1e76h1d1ah1d2ahzz1033IL17326ah8275dh18c673h8275bhz2dh2a8h668h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1155h) Received: from mail162-va3 (localhost.localdomain [127.0.0.1]) by mail162-va3 (MessageSwitch) id 1363392310948040_20710; Sat, 16 Mar 2013 00:05:10 +0000 (UTC) Received: from VA3EHSMHS018.bigfish.com (unknown [10.7.14.226]) by mail162-va3.bigfish.com (Postfix) with ESMTP id 5A3C110005D; Sat, 16 Mar 2013 00:04:52 +0000 (UTC) Received: from BY2PRD0510HT003.namprd05.prod.outlook.com (157.56.236.101) by VA3EHSMHS018.bigfish.com (10.7.99.28) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sat, 16 Mar 2013 00:04:49 +0000 Received: from BY2PRD0510MB377.namprd05.prod.outlook.com ([169.254.5.104]) by BY2PRD0510HT003.namprd05.prod.outlook.com ([10.255.84.38]) with mapi id 14.16.0275.006; Sat, 16 Mar 2013 00:04:49 +0000 From: Satya Mohanty To: Jakob Heitz , "Ali Sajassi (sajassi)" , "idr@ietf.org" Subject: RE: draft-ietf-l2vpn-evpn Thread-Topic: draft-ietf-l2vpn-evpn Thread-Index: AQHOHzFpw7wq2p0F306XvoGHyBm2OpinSauggAAcl9CAAAfLcA== Date: Sat, 16 Mar 2013 00:04:48 +0000 Message-ID: References: <69670F7146898C4583F56DA9AD32F77B1230F9D9@xmb-aln-x13.cisco.com> <2F3EBB88EC3A454AAB08915FBF0B8C7E1C8338@eusaamb109.ericsson.se> In-Reply-To: <2F3EBB88EC3A454AAB08915FBF0B8C7E1C8338@eusaamb109.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.224.54] Content-Type: multipart/alternative; boundary="_000_DBDBC40345866E4FA5701A2C8C2684222CC47591BY2PRD0510MB377_" MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%ERICSSON.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%CISCO.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Cc: "l2vpn@ietf.org" , "Giles Heron \(giheron\)" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Mar 2013 00:10:58 -0000 --_000_DBDBC40345866E4FA5701A2C8C2684222CC47591BY2PRD0510MB377_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I am guessing you mean the 'alias label" to be the label in the per EVI AD= route ? I understand that "PE can allocate MAC labels anyway it likes as long as it= can deliver the frame when it arrives with that label." In the case I am mentioning, the frame is not coming with= "that" label, PE2 did not advertise the mac route p1, at all to PE3, so PE= 3 does not know the per prefix label allocated by PE2. So, it will only ha= ve to use the per EVI AD label from PE2. At the egress (PE2), yes, this wil= l defaults to a mac/vlan lookup, but this is like a per vrf or per CE (per = esi per evi) behavior. Also, I was not aware that one can use different allocation scheme for MAC = labels and "alias" labels. So, what I infer is you are suggesting that label allocation mode could be = also per NLRI type? Thanks --Satya From: Jakob Heitz [mailto:jakob.heitz@ericsson.com] Sent: Friday, March 15, 2013 4:17 PM To: Satya Mohanty; Ali Sajassi (sajassi); idr@ietf.org Cc: l2vpn@ietf.org; Giles Heron (giheron) Subject: RE: draft-ietf-l2vpn-evpn The egress PE can allocate MAC labels anyway it likes as long as it can deliver the frame when it arrives with that label. It is not necessarily the same as the alias label. A frame arriving with the alias label will most likely undergo a MAC/VLAN lookup. This does not prevent it from using a different label allocation scheme for MAC labels than for alias labels. -- Jakob Heitz. x25475. 510-566-2901 ________________________________ From: l2vpn-bounces@ietf.org [mailto:l2vpn-b= ounces@ietf.org] On Behalf Of Satya Mohanty Sent: Friday, March 15, 2013 3:16 PM To: Ali Sajassi (sajassi); idr@ietf.org Cc: l2vpn@ietf.org; Giles Heron (giheron) Subject: RE: draft-ietf-l2vpn-evpn Few comments, 1. Sec 8.3: Please consider putting in a line stating that the per ESI Rout= e (type 4) carries a label with all 0s (like the Type 1 mandatory route) in= the MP-Reach NLRI. 2. This is not explicitly sec 8 but I think there may be a discrepancy in t= he draft. Page 27, top paragraph An PE may advertise the same single E-VPN label for all MAC addresses in a given EVI. This label assignment methodology is referred to as a per EVI label assignment. Alternatively, an PE may advertise a unique E-VPN label per combination. This label assignment methodology is referred to as a per label assignment. As a third option, an PE may advertise a unique E- VPN label per MAC address. All of these methodologies have their tradeoffs. I see a problem with the third option (per-prefix allocation mode), related= to aliasing in the Active/Active case. In such a label allocation mode, what label will be associated with the per= EVI AD route ? Let's say PE1 and PE2 share the same ESI, PE1 and PE1 uses per prefix label= allocation mode, and PE2 uses either per EVI or per l= abel allocation mode. As per the aliasing behavior, a mac route (say p1 wit= h label l1) advertised from PE1, should be reachable from PE3 via PE2, irre= spective of whether PE2 advertised p1 or not. If PE2 did not advertise p1,= but PE3 sends traffic to PE2, what label does PE3 slap on frames? As per t= he draft, it will slap the label what was received in the per EVI AD route.= Moot question is what does it correspond to here ? Should per-prefix label allocation be allowed? If it is, I think then the c= oncept of aliasing will be lost, and all macs with the same EVI, ESI need t= o be advertised from each of the PEs configured to the same ES. PE1 -- --- --| / |_______ CE ________ RR-------PE3 \ | PE2 ---------| Thanks, --Satya From: l2vpn-bounces@ietf.org [mailto:l2vpn-b= ounces@ietf.org] On Behalf Of Ali Sajassi (sajassi) Sent: Tuesday, March 12, 2013 7:54 AM To: idr@ietf.org Cc: l2vpn@ietf.org; Giles Heron (giheron) Subject: draft-ietf-l2vpn-evpn In preparation for WG last call of this draft, our L2VPN chairs have asked = us to solicit comments on the BGP section of this document (section 8). http://www.ietf.org/id/draft-ietf-l2vpn-evpn-03.txt Please kindly review this draft and post your comments by Friday March/29. Thanks, Ali --_000_DBDBC40345866E4FA5701A2C8C2684222CC47591BY2PRD0510MB377_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I am guessing you mean the ‘alias= label”  to be the label in the per EVI AD route ?

 

I understand that “PE can all= ocate MAC labels anyway it likes as = long as it can deliver the frame when it arrives

with that label.” In the case I am mentioning, th= e frame is not coming with “that” label, PE2 did not advertise = the mac route p1, at all to PE3, so PE3 does not know  the per prefix label allocated by PE2. So, it will only have to use the per EVI AD label = from PE2. At the egress (PE2), yes, this will defaults to a mac/vlan lookup= , but this is like a per vrf or per CE (per esi per evi) behavior.

 

Also, I was not aware that one can use different alloca= tion scheme for MAC labels and “alias” labels.

So, what I infer is you are suggesting that label alloc= ation mode could be also per NLRI type?

 

Thanks

--Satya

 <= /p>

 <= /p>

 <= /p>

 <= /p>

 <= /p>

 <= /p>

 <= /p>

From: Jakob He= itz [mailto:jakob.heitz@ericsson.com]
Sent: Friday, March 15, 2013 4:17 PM
To: Satya Mohanty; Ali Sajassi (sajassi); idr@ietf.org
Cc: l2vpn@ietf.org; Giles Heron (giheron)
Subject: RE: draft-ietf-l2vpn-evpn

 

The egress PE can allocate MAC labels anyw= ay it likes

as long as it can deliver the frame when i= t arrives

with that label. It is not necessarily the= same

as the alias label. A frame arriving with = the alias

label will most likely undergo a MAC/VLAN = lookup.

This does not prevent it from using a diff= erent

label allocation scheme for MAC label= s than for

alias labels.

--
Jakob Heitz. x25475. 510-566-2901

 

 

From:<= /span> l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Satya Mohanty
Sent: Friday, March 15, 2013 3:16 PM
To: Ali Sajassi (sajassi); idr@ietf.= org
Cc: l2vpn@ietf.org; Giles Hero= n (giheron)
Subject: RE: draft-ietf-l2vpn-evpn

Few comments,

 <= /p>

1. Sec 8.3: Please consid= er putting in a line stating that the per ESI Route (type 4) carries a labe= l with all 0s (like the Type 1 mandatory route) in the MP-Reach NLRI.

 <= /p>

2. This is not explicitly= sec 8 but I think there may be a discrepancy in the draft.  Page 27, = top paragraph

 <= /p>

   An PE may adverti= se the same single E-VPN label for all MAC addresses

   in a given EVI. T= his label assignment methodology is referred to as a

   per EVI label ass= ignment. Alternatively, an PE may advertise a unique

   E-VPN label per &= lt;ESI, Ethernet Tag> combination. This label

   assignment method= ology is referred to as a per <ESI, Ethernet Tag>

   label assignment.= As a third option, an PE may advertise a unique E-

   VPN label per MAC= address. All of these methodologies have their

   tradeoffs.

 

I see a problem with the third option (per-prefix allocation mode), rela= ted to aliasing in the Active/Active case.

In such a label allocation mode, what label will be associated with the = per EVI AD route ?

 

Let’s say PE1 and PE2 share the same ESI, PE1 and PE1 uses per pre= fix label  allocation mode, and PE2 uses either per EVI or per <ESI= , Ethernet-tag> label allocation mode. As per the aliasing behavior, a ma= c route (say p1 with label l1) advertised from PE1, should be reachable fro= m PE3 via PE2, irrespective of whether PE2 advertised p1 or not.  If P= E2 did not advertise p1, but PE3 sends traffic to PE2, what label does PE3 slap on frames? As per the draft, it will slap= the label what was received in the per EVI AD route. Moot question is what= does it correspond to here ?

 

Should per-prefix label allocation be allowed? If it is, I think then th= e concept of aliasing will be lost, and all macs with the same EVI, ESI need to be advertised from each of the PEs configured to the= same ES.

 <= /p>

    &= nbsp;  PE1 -- --- --|        &= nbsp; 

    /=             &n= bsp;         |_______  &n= bsp;            = ;   

CE    = ;            &n= bsp;        ________ RR-------PE3

   \  = ;            &n= bsp;         |

    &= nbsp; PE2 ---------|

 <= /p>

Thanks,=

--Satya=

 <= /p>

From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Ali Sajassi (sajassi)
Sent: Tuesday, March 12, 2013 7:54 AM
To: idr@ietf.org
Cc: l2vpn@ietf.org; Giles Hero= n (giheron)
Subject: draft-ietf-l2vpn-evpn

 

 

 

In preparation for WG last = call of this draft, our L2VPN chairs have asked us to solicit comments on t= he BGP section of this document (section 8).

 

 

Please kindly review this d= raft and post your comments by Friday March/29.

 

Thanks,

Ali

--_000_DBDBC40345866E4FA5701A2C8C2684222CC47591BY2PRD0510MB377_-- From richard.boldy@twcable.com Sat Mar 16 14:16:26 2013 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28AA921F87FB for ; Sat, 16 Mar 2013 14:16:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.138 X-Spam-Level: X-Spam-Status: No, score=0.138 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, J_CHICKENPOX_39=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NtPQWsv-QAgG for ; Sat, 16 Mar 2013 14:16:25 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 1CE3021F86F4 for ; Sat, 16 Mar 2013 14:16:25 -0700 (PDT) X-SENDER-IP: 10.136.163.13 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.84,857,1355115600"; d="png'150?scan'150,208,217,150";a="43789532" Received: from unknown (HELO PRVPEXHUB04.corp.twcable.com) ([10.136.163.13]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 16 Mar 2013 17:16:18 -0400 Received: from PRVPEXVS14.corp.twcable.com ([10.136.163.48]) by PRVPEXHUB04.corp.twcable.com ([10.136.163.13]) with mapi; Sat, 16 Mar 2013 17:16:24 -0400 From: "Boldy, Richard" To: "nabil.n.bitar@verizon.com" , "giheron@cisco.com" Date: Sat, 16 Mar 2013 17:16:21 -0400 Subject: Re: VPLS external Loop Protection Mechanism (VLPM) - draft-l2vpn-vlpm-01 Thread-Topic: VPLS external Loop Protection Mechanism (VLPM) - draft-l2vpn-vlpm-01 Thread-Index: Ac4ii4MEXYITXvJgTPuNFqWrQe2S8g== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.2.120421 acceptlanguage: en-US Content-Type: multipart/related; boundary="_004_CD6A582C82A0Crichardboldytwcablecom_"; type="multipart/alternative" MIME-Version: 1.0 Cc: "l2vpn@ietf.org" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Mar 2013 21:16:26 -0000 --_004_CD6A582C82A0Crichardboldytwcablecom_ Content-Type: multipart/alternative; boundary="_000_CD6A582C82A0Crichardboldytwcablecom_" --_000_CD6A582C82A0Crichardboldytwcablecom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I'd like to advise you of the update to the posted ID as detailed below for= consideration by the L2VPN working group. A new version of I-D, draft-l2vpn-vlpm-01.txt has been successfully submitted by Time Warner Cable and posted to the IETF repository. Filename: draft-l2vpn-vlpm Revision: 01 Title: VPLS external Loop Protection Mechanism (VLPM) Creation date: 2013-03-13 Group: Individual Submission Number of pages: 10 URL: http://www.ietf.org/internet-drafts/draft-l2vpn-vlpm-01.tx= t Status: http://datatracker.ietf.org/doc/draft-l2vpn-vlpm Htmlized: http://tools.ietf.org/html/draft-l2vpn-vlpm-01 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-l2vpn-vlpm-01 Abstract: Virtual Private LAN Service (VPLS) as defined in RFC4761 [RFC4761] and RFC4762 [RFC4762] implementations are highly susceptible to layer-2 loops external to the PE customer-facing interface. Such loops impact performance and can have a detrimental effect on all VPLS traffic throughout the entire instance under certain conditions. Current Layer-2 loop detection and protection mechanisms do not function effectively here. This document describes a protocol function (VPLS External Loop Protection Mechanism (VLPM)) to offer VPLS service providers a mechanism for detecting such layer-2 loops and facilitating configurable actions without the need for inter-operation with customer network protocols, other VPLS PEs or sites. The IETF Secretariat Kind regards Rich./ Rich Boldy Principal Engineer National Network Operations Engineering Advanced Technology Group [cid:409AEEFF-53DC-4EE3-B989-86CBD6A7C762] 13820 Sunrise Valley Dr | Herndon, VA 20171 Office: (703) 713 1573 Mobile:(512) 673-2719 Email:richard.boldy@twcable.com AIM:rboldytwc ________________________________ This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. --_000_CD6A582C82A0Crichardboldytwcablecom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,

I'd like to advise you of the update to the posted ID as detailed below for= consideration by the L2VPN working group.

A new version of = I-D, draft-l2vpn-vlpm-01.txt
has been successf= ully submitted by Time Warner Cable and posted to the
IETF repository.<= /div>

Filename:  draft-l2vpn-vlpm
Revision:  01
Title: &= nbsp;VPLS external Loop Protection Mechanism (VLPM)
Creation date:  2013-03-13
Group: &= nbsp;Individual Submission
Number of pages: = 10
Htmlized: &n= bsp;      http://tools.ietf.org/html/draft-l2vpn-vlpm-01<= /div>

Abstract:
   = ; Virtual Private LAN Service (VPLS) as defined in RFC4761 [RFC4761]
   = ; and RFC4762 [RFC4762] implementations are highly susceptible to
   = ; layer-2 loops external to the PE customer-facing interface. Such
   = ; loops impact performance and can have a detrimental effect on all
   = ; VPLS traffic throughout the entire instance under certain
   = ; conditions.

   = ; Current Layer-2 loop detection and protection mechanisms do not
   = ; function effectively here.

   = ; This document describes a protocol function (VPLS External Loop
   = ; Protection Mechanism (VLPM)) to offer VPLS service providers a
   = ; mechanism for detecting such layer-2 loops and facilitating
   = ; configurable actions without the need for inter-operation with
   = ; customer network protocols, other VPLS PEs or sites.

   = ;            &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;            = ;    


The IETF Secretar= iat



Kind regards
Rich./

Rich Boldy

Principal Engineer
National Network Operations Engineering
Advanced Technology Group
 


13820 Sunrise Valley Dr&= nbsp;| Herndon, VA 20171
Office: = (703) 713 1573

Mobile:(512) 673-2719

Email:richard.boldy@twcable.com
AIM:rboldytwc



This E-mail and any of its a= ttachments may contain Time Warner Cable proprietary information, which is = privileged, confidential, or subject to copyright belonging to Time Warner = Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you a= re not the intended recipient of this E-mail, you are hereby notified that = any dissemination, distribution, copying, or action taken in relation to th= e contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have receiv= ed this E-mail in error, please notify the sender immediately and permanent= ly delete the original and any copy of this E-mail and any printout.
 --_000_CD6A582C82A0Crichardboldytwcablecom_-- --_004_CD6A582C82A0Crichardboldytwcablecom_ Content-Type: image/png; name="409AEEFF-53DC-4EE3-B989-86CBD6A7C762.png" Content-Description: 409AEEFF-53DC-4EE3-B989-86CBD6A7C762.png Content-Disposition: inline; filename="409AEEFF-53DC-4EE3-B989-86CBD6A7C762.png"; size=4520; creation-date="Sat, 16 Mar 2013 21:16:23 GMT"; modification-date="Sat, 16 Mar 2013 21:16:23 GMT" Content-ID: <409AEEFF-53DC-4EE3-B989-86CBD6A7C762> Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAJYAAAASCAYAAAC5ICcsAAAC7mlDQ1BJQ0MgUHJvZmlsZQAAKBWF VM9rE0EU/jZuqdAiCFprDrJ4kCJJWatoRdQ2/RFiawzbH7ZFkGQzSdZuNuvuJrWliOTi0SreRe2h B/+AHnrwZC9KhVpFKN6rKGKhFy3xzW5MtqXqwM5+8943731vdt8ADXLSNPWABOQNx1KiEWlsfEJq /IgAjqIJQTQlVdvsTiQGQYNz+Xvn2HoPgVtWw3v7d7J3rZrStpoHhP1A4Eea2Sqw7xdxClkSAog8 36Epx3QI3+PY8uyPOU55eMG1Dys9xFkifEA1Lc5/TbhTzSXTQINIOJT1cVI+nNeLlNcdB2luZsbI EL1PkKa7zO6rYqGcTvYOkL2d9H5Os94+wiHCCxmtP0a4jZ71jNU/4mHhpObEhj0cGDX0+GAVtxqp +DXCFF8QTSeiVHHZLg3xmK79VvJKgnCQOMpkYYBzWkhP10xu+LqHBX0m1xOv4ndWUeF5jxNn3tTd 70XaAq8wDh0MGgyaDUhQEEUEYZiwUECGPBoxNLJyPyOrBhuTezJ1JGq7dGJEsUF7Ntw9t1Gk3Tz+ KCJxlEO1CJL8Qf4qr8lP5Xn5y1yw2Fb3lK2bmrry4DvF5Zm5Gh7X08jjc01efJXUdpNXR5aseXq8 muwaP+xXlzHmgjWPxHOw+/EtX5XMlymMFMXjVfPqS4R1WjE3359sfzs94i7PLrXWc62JizdWm5dn /WpI++6qvJPmVflPXvXx/GfNxGPiKTEmdornIYmXxS7xkthLqwviYG3HCJ2VhinSbZH6JNVgYJq8 9S9dP1t4vUZ/DPVRlBnM0lSJ93/CKmQ0nbkOb/qP28f8F+T3iuefKAIvbODImbptU3HvEKFlpW5z rgIXv9F98LZua6N+OPwEWDyrFq1SNZ8gvAEcdod6HugpmNOWls05Uocsn5O66cpiUsxQ20NSUtcl 12VLFrOZVWLpdtiZ0x1uHKE5QvfEp0plk/qv8RGw/bBS+fmsUtl+ThrWgZf6b8C8/UV0iLSAAAAO dUlEQVRoBe1ZB3SUVRb+JmXSCekhIQkhBAihBekoqIhrQZC1roqyiFhQLKuLuqtrW8vaj6soi4LY QFGkiKCgiCA1QAgEAkkICSmkQCqpM7PfvZN/MgMTyx73HM8xL2fm/+fV++6797vfuzHZbDZ0lk4N /Noa8Gqb0K11NVvqUVq7D5WnDqOptQq+XiGICOyLqMBUeHn4upWlrC4LOZXfwMNkgwmefHrBamuF lX9ixImh5yDQHI2yun18H8d2b7fz/BqVVlsL0osWIr7rKMrc3zFleV02ck+sw9DuM7gPH0f9npIP EBmQgpguQxx1v8WXVmsjjpzYiLwTG9BiPYX44JFICjsfAebInxS3quEoDpav4t5v7vAMcyvXo6Hl BPpHX/WT83XQgafuptQ0FmHz0VeRdfxz2NCKLj4xNKpgNNC4ahqL4eXpj4HR12JU/B3wN4e5zFBS m4Edhe+wjwmNLVUoqc1DeEAMgnyi0Wq1wodjK0/lYF3Os/jruINs6+My/tf80cD1V2bNwoDoa3DV wPccU3935Glszl+EcP9k9Aq/UOvrmo7j08w/Y2zinN+0YRVV78Sn+2aiov4gooL6wZOOub1wHvUa hJkjvkNEQF/HPt29HKpYg6WZd6qzdeRA2wrfQGHVNvSNnOTieO7m66juDMPKKPkIqw/OoYf3xaR+ /0ZiyDmAyQSLtRme9G5BgcMVX2HjkZcUDSamvIh+kZc75h/U7U+Qj5TcynWYu3UCxic9hmFxtzj6 nDiVhziiSIhfT60TJDNxDaO00CO9nRDRZrPq+l6e7lDShhbLKXh7BhjDHU9/7zAaSRoKqrbQqJtU SS1E4aMnN8uWiFrrHYZVWrcXzZYW9JD9thVZV9DB08OsyGvU61MoRJvMVpuF7Z50QitR2sPRTcba EbF9b0ajtElfmdu5yJomk30OQXpBfKNUNRRg0a4p3Ksvbhu5WfcmbRX12dhx7B01MqOvPFusDbKC yxoiiXxkHSmiF0+uYaL8RpE1ZWuyH+cifaXWXbRqaq2FmWdgyN4uNYdsyn8R63OewmUpr2BI7E04 Vr0dH2dOYzjczYNtUcNK6DoG45Mfxe0jN2FrwRv4ZO90nNszG+N6znGWQd9tFMJejKf9VyEPem/p YvQKuwAWSzPe3zWZsHslw20t9pYsQV1LORK6jsS4xIeQefwTHCxbRWiuphGcj4l9X4GPVxedaHvh W9h5bAEVWEdDDMTwuBkK8XbVybl7MNyehw25z0OMOTIwBaUMwXXNZejWJVEN3zCK/JPfI8A7CLHB Q1HXVEo9PIGjVZtptHU8XB9676UY3+tRKi+Ia87HgbIVXG8mvsl9logegasHfoCPMq5Gctgf9ODT i95DdeNRInV3XNLnOSSEnK0yl9Tu4dxPErUP8bdJw9iE5CcQSETPP7kRXx16GOcl/Z26fRM1TYWY dtZahrhwHbut4HXu4xhuH/WNw6ikQVD/Yq4hpam1Bt/lPYNDFWv1HTStxNCxmJD8JGXppn08aDSF PNvv858nMu1QpxwRPxMj42Y5DMPQoQyQ8Lku5zEU1+ziLxtRsR8uSH5M0dFCoMko/oB7LdRzGRxz Pfy9w9vda3fRu9zwY5g65DM1qo1HnsM7Oy7RECZKmzliI64csEAt/PUfRqjXj2QovPGsz4le/2Jo eVGF/jlfZfVZPJhVaGyt5sERQao2YU3231BWvx8jE2ahb8TFRMOP8R4Nrp4h6pwe99EIz+UaC4iW a3WJDXlPY0XW3TSk6bh20GKkRk0hxN+CPcXvu4ggPK6FIbioZofWC3/o6huPEXG3UlGZVFq+1ueT s3TrMphKCUUxHamgajtGJ8zG5NQ3kRI5EV8ffgHbeNhSyur2I6NkJVYduAfRQalE6OuUR0qYWkPD yC5fjbSY6zCmx710zp00vsd1XHndAczffgHNyURdLqSTvIzDlV9jyd7riCAWnKQs2RWbGZKnq/cP Iwc0ewbqWGnPYd/IwHgNY1rp5kvmOFj+pZ7h5NS5NP5baKRvY93hR9t6mxSHthS8hm5Babioz7OM HHFYunc2nf0jlxkF7eqbK/DOzosgvHRy6huYkjpP5VyUfpmeXzWNrr65XEFIjLqoOl3nUMSSDa84 cCcuT30LPenhgibf5j6NG4esUIKdTpjdWvAWCeJYXDPofQr5D3y2bzpmjU5nqByL69OW4t30S1TQ niSRP1UEaiV02L3CpKR+YMwVXH+eDu0VdqHyhrTYqfS0p7QuJvgsbD/2LpostbqhDZRvVMJtihrS Qch51vFPsa1wLgbH3MAauiWLKC/Q7E80+J6HfSNyGMbjiYYpkZOxOvtBFFRvofPEkAvuoSHdo2N6 h18M+RglKXQ8dhbNpyHu1ioJG97kkNenLaNhDdA6UaocfmrUZUSvD42hyCxZTOQp0d+bjr7Ep5Xt izjeX+smJD+Oj/bchAoimIRNkXpiyqtnEOdmhvu65uOKOkJJOirRQQMxe8weR3OvsAl0gg91f0al RPFJKa8r4Ze63uEXcW99IOc8qNv1bZqDhtDdxQtRTj73wNgchPon6RQTU17Ga5tHI49OmhQ2XsEm NngYnw1E3ijto4YlFjcq/i71PImj3+Y+yQN9Qo1q1YHZyCK6pEZdTlR5CJX1h3E+Q8Ku4gWE0a2c +AINHaIoH297iNKZf9GXjZto50/C48SrzR5+jlkkFIvSPU1mJf+NrfW8GW0gqk1SLiB8peLUESo+ AlYrOY+Hbk03avCsWh6wGJDwvXD/3gj1685wuB4R/n1xiqG2Z+i5up7wSeGa2fR8C7mQ2SuQYYWc qI1TSTjw5PvpFxcJ/eY2g3EITqk9+Cd8qYSGaSW3WZxxbZvMJtQy7Eo51XxCe8p7gM+ZtztP7kcM qpWyyfqG40h/12Ljea3A/tLP6IBV8PMOZpgqplEkOrqJHp3lFGohDnKy4UhbH+lBh+dfIZFbbu4r D9zVFiZNaCZlkVLTVMzwF4y02Btxoj5Hb6VRQfbbt2q/B2OwfKSc4I2tgZuUm5RwnszSj3Hd4E/J EcYgOXwCOdBiXcjPuys32Yj9xz/Dsv23KrTHdhmqc/xvX648TOZo52iuMwoyWNk9gURbjMHIxQ2N nYFgGouHRzsRFQNNZJ9N+S9wL0v0gCX9IPyrB9G2gEQ+mDwowBxKdBukC605NAdbjs7F+UkPEwn7 ESnKsa90mf08nUQxCLBTVYcyy2DhI0E0miGx0yiznRgL+l1I0hvLFMf+4/k6ldHmPK8XnUxufHkM 2cIBBWXdlS1HX2P0uQ9n97hLQ7hchCT9c7rwp+tW9CG6ci2k75TZx8ufUWAqDZupIepd+p6T+CC6 M4pIEWohH+did2unGuE9Xp4+TC8EsdakN4DqxgK+j9HwICGioOoHph1KsKtoEUPMZuVeqVF/dJrl //cqnh/ql8jN8jbFw0mNusLNYq5GmhgyjgT+n/ieN9lI5uC6+ibomGSG3Aw6yvZjb2t49PUOUWcR A+wXNVGRWTrKQa/LeeRHjMaNCE5Vcoji9ZE00uzyteSLEyi/6Ne1nH4Lc22FhvKMki/J9eaSPD/p 0izEX/aVWfoJiX0qLiV/M8oP+a9omDZ+y9M5fyf5yuKaDOpgeFsX0Z/kIT2USmSWLlfD/yWpoTMM K9AcRULdqBAtMfXsxPuxPGs2Ya+UC49gKMnA14ceoRdXEmprMH3YWpfkY5tk+pADsdAx5eblXMQ4 LAxXav7cgIQ5qTOKHISFhNu1zj6XhAJ/cwRGx9+JDTQUXyKnhGNB123kgRGBvajUV42p9Cmk3I+I VFJbyHB/DT3OjmjxIaN44B4kpiXMX92nfSUvJArMrdyoZFluOLuLFjJMVFIqO8rY5WfCl3/tRWRu dpFZ2gSl5CNlTMJ9RL6VWJh+KT3+L5obzCOaHCxfiRnDvtU+oi93iCWNcnMek7AWXx1+Sgl0StRk VaEkPHcUvotpQ5fzAjKIaDtPDSyC+5Db6zEaTVxwms4vZ9HKNb7NfQoj42dpikJyljWNZfx9l10G PR+73EO6T6PjzSflmMJb8SPo4ttdCfoO1glX7CgXdoZhdfVL4OAYEuFlalSjeIByU9rK0LCdtyLJ u8iGBjNXJQf6Y0WutwkhA3lQvV26hTExGR8yXK+5QuIlzBokWDr6enahEQ9DmNO4QGaVE0LS6JVx OteFvZ9BEOVMJ2ruKf6QBuJFAx9Auaa6rCU/AmiIaYTy7PL1GEDDMkqIXxL730DF7+FNdJJWi9EJ sf3i4P1Ytu825VEpERMZCqYwK99P+8hFIYFG6duW9pBK4T/dg4cjOtAeTrUjv+JY18yUhVhAdxLc GcPW8FCf4Y3ybjVqf+8I5XxmIlhXvx4Mz4M0IW2Md37KHqf0/w91M5r7XoAvDtxLJzHxVpdEuvI+ 9zBR0yX1dPo12XPU6XqRXA/nzZlmr1PJ+aZEjWVY7YMvsx9gGqdKHXXqkCWa/pFOgupWaysRy6Qh 7maCx7rDj2Ptob+xhvyM+x4QfdUZ56oLtH2Z2viJs+vpLWIVydodo3ZS6ERH/xZLAyHU7PB4R8OP vEiMdvdvG/F6UZQU4UwGihhTGfkl47c828eIuHY+IN4tUC4G7wzvzuOMd4uNSV6S/9NL+7yuLc2t dTqvPYlJfOKyBoF3L589Ueo8i6IaBwovcS6S1JU2SSo6l45kce5jvMu+5fCNG6ZRL09pk3SBkVS2 yysyCCm3J3KlTs7Uh5cT5yJyiV7tN/f2FuHUYnBmL5H5dD7W3k8a3RqWTLp03zQcq9rJPNVyCMJ0 lk4N/AINuDcsmcDCtMPyrDsYo1eTD9yrIUNCZGfp1MDP0EDHhmUM3sek48a850nmi3iV74n+TACe 3eN+o7nz2akBdxr4acOyj7IxuZfBHMp3jMf+/DdK+z+U3c3aWfe714DDsH73muhUwK+rgf8CWPIc iNscD7oAAAAASUVORK5CYII= --_004_CD6A582C82A0Crichardboldytwcablecom_-- From ghanwani@gmail.com Mon Mar 18 14:27:53 2013 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 298DE21F88C6 for ; Mon, 18 Mar 2013 14:27:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TiiC+ry0KyjO for ; Mon, 18 Mar 2013 14:27:52 -0700 (PDT) Received: from mail-ve0-f176.google.com (mail-ve0-f176.google.com [209.85.128.176]) by ietfa.amsl.com (Postfix) with ESMTP id 7F66121F88C0 for ; Mon, 18 Mar 2013 14:27:52 -0700 (PDT) Received: by mail-ve0-f176.google.com with SMTP id cz10so4751701veb.21 for ; Mon, 18 Mar 2013 14:27:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=ejDF/z50tywgTcmQnM79UXQtWqgS/7rlz9OB9rVQkz0=; b=r+rEUmETNEkaz/d/SXrCQr5Xe8mU8Lq0WGT60YFt9xxVbjf0QETiZ/E6MPPo/KhzlZ cd+7N4Gd+3tPT2DGjh4pu/x89My/mOq2kAoWDYJsrAUx6y7CeNtdcEVPJOKTElQ/ZIlL NaBTPy9fC5NCenvFo8MgOCEocKjmNDXIb8CoLjcDDOeX+VOeNx86tjg7PQ37RH9ZMakp bj3wAGs7WF75EA3X2DPyLi8HRCJDsWNk4U1Y8FoYdW+2Al8nzyARFQVkBPHhQCPOJA1a VyPdcO+km8BJbQLtW08tPyIKNFEmAZbfOsFS2tIevxvE5WRmqiNPyv0ghhoM7QrOT6nZ zJiw== MIME-Version: 1.0 X-Received: by 10.52.90.243 with SMTP id bz19mr19007153vdb.112.1363642071966; Mon, 18 Mar 2013 14:27:51 -0700 (PDT) Sender: ghanwani@gmail.com Received: by 10.58.241.170 with HTTP; Mon, 18 Mar 2013 14:27:51 -0700 (PDT) In-Reply-To: References: Date: Mon, 18 Mar 2013 14:27:51 -0700 X-Google-Sender-Auth: dhFMLlyElB1rLIbugd0qkEaxtzQ Message-ID: Subject: Re: VPLS external Loop Protection Mechanism (VLPM) - draft-l2vpn-vlpm-01 From: Anoop Ghanwani To: "Boldy, Richard" Content-Type: multipart/alternative; boundary=20cf307c9aa44cebac04d839a993 Cc: "l2vpn@ietf.org" , "giheron@cisco.com" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 21:27:53 -0000 --20cf307c9aa44cebac04d839a993 Content-Type: text/plain; charset=ISO-8859-1 Hi Richard, What's the reason for using an "unknown unicast" and not just a regular multicast frame for this? The problem you're trying to solve looks very similar to what TRILL needed to solve. TRILL uses IS-IS hellos to address this problem. Anoop On Sat, Mar 16, 2013 at 2:16 PM, Boldy, Richard wrote: > > Filename: draft-l2vpn-vlpm > Revision: 01 > Title: VPLS external Loop Protection Mechanism (VLPM) > Creation date: 2013-03-13 > Group: Individual Submission > Number of pages: 10 > URL: > http://www.ietf.org/internet-drafts/draft-l2vpn-vlpm-01.txt > Status: http://datatracker.ietf.org/doc/draft-l2vpn-vlpm > Htmlized: http://tools.ietf.org/html/draft-l2vpn-vlpm-01 > Diff: http://www.ietf.org/rfcdiff?url2=draft-l2vpn-vlpm-01 > --20cf307c9aa44cebac04d839a993 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Richard,=A0

What's the reason for using an "= unknown unicast" and not just a regular multicast
frame for = this?

The problem you're trying to solve looks= very similar to what TRILL needed to solve. =A0
TRILL uses IS-IS hellos to address this problem.

<= div>Anoop

On Sat, Mar 16, 2013 at 2:16 PM= , Boldy, Richard <richard.boldy@twcable.com> wrote:<= br>

Filename: =A0draft-l2vpn-vlpm
Revision: =A001
Title: =A0VPLS external Loop Pr= otection Mechanism (VLPM)
Creation date: =A02013-03-13
Group: =A0Individual Submission=
Number of pages: 10
URL:=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0http://www.ietf.org/internet-drafts/dra= ft-l2vpn-vlpm-01.txt
Status:=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0http://datatracker.ietf.org/doc/draft-l2vpn-vlpm
Htmlized:=A0=A0=A0=A0= =A0=A0=A0=A0http://tools.ietf.org/html/draft-l2vpn-vlpm-01
Diff:=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0http://www.ietf.org/rfcdiff?url2=3Ddraft-l2v= pn-vlpm-01
--20cf307c9aa44cebac04d839a993-- From richard.boldy@twcable.com Tue Mar 19 11:55:13 2013 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C77FD21F8CEB for ; Tue, 19 Mar 2013 11:55:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.638 X-Spam-Level: X-Spam-Status: No, score=0.638 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, J_CHICKENPOX_39=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LUOEOE9KdKEb for ; Tue, 19 Mar 2013 11:55:12 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 78E4D21F8A35 for ; Tue, 19 Mar 2013 11:55:12 -0700 (PDT) X-SENDER-IP: 10.136.163.10 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.84,873,1355115600"; d="png'150?scan'150,208,217,150";a="43893338" Received: from unknown (HELO PRVPEXHUB01.corp.twcable.com) ([10.136.163.10]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 19 Mar 2013 14:53:52 -0400 Received: from PRVPEXVS14.corp.twcable.com ([10.136.163.48]) by PRVPEXHUB01.corp.twcable.com ([10.136.163.10]) with mapi; Tue, 19 Mar 2013 14:54:13 -0400 From: "Boldy, Richard" To: Anoop Ghanwani Date: Tue, 19 Mar 2013 14:54:09 -0400 Subject: Re: VPLS external Loop Protection Mechanism (VLPM) - draft-l2vpn-vlpm-01 Thread-Topic: VPLS external Loop Protection Mechanism (VLPM) - draft-l2vpn-vlpm-01 Thread-Index: Ac4k0yVBASvrX39kSYWTd1kQpcIzfA== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.2.120421 acceptlanguage: en-US Content-Type: multipart/related; boundary="_004_CD6D10B783264richardboldytwcablecom_"; type="multipart/alternative" MIME-Version: 1.0 Cc: "l2vpn@ietf.org" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 18:55:13 -0000 --_004_CD6D10B783264richardboldytwcablecom_ Content-Type: multipart/alternative; boundary="_000_CD6D10B783264richardboldytwcablecom_" --_000_CD6D10B783264richardboldytwcablecom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Anoop, Good questions. Firstly though I'd like the group to note that I had a disc= ussion with one of the chairs (Giles) today and I will be breaking this out= into a requirement draft to be followed by a revised VLPM draft once the r= eq doc is fleshed out. That said I will try and answer the questions you posed as you graciously t= ook the time to give feedback on this. ----- Q1 - It's funny you ask this cos it did start life using a multicast frame = but the decision was made to change this to use a specific unknown unicast = address due to the following reasoning, but it's up for debate: 1. To remove the risk that the frames may get filtered due to multicast f= iltering either by IGMP Snooping, MAC ACL or specifically configured comman= d line block statements in the external layer2 segment. IGMP Snooping shoul= d ignore reserved multicast allocated space however there is potential here= for differing vendor interpretation/error/bugs etc. MAC ACL and specific c= ommand line blocking is also possible for unknown unicast however I think i= t's fair to say that this is less common and it would be much more acceptab= le to write into the terms of a VPLS service agreement that unknown unicast= blocking was not to be in place than to do so for multicast blocking where= a customer may not have any need for multicast frames in their network seg= ment at all. 2. To ensure that the frame has the greatest chance of flooding through t= he entirety of the layer2 segment. Depending on configuration the layer2 se= gment could be pruning multicast. 3. Simply it seams more complicated to use a multicast address when there= is no specific multicast need and to the same end it maybe easier to get t= he allocation for unicast for the same reason. Q2 - Please correct me if I'm missing something but I think the solution to= the TRILL problem was different in that it assumes that the full layer2 br= oadcast domain is under one administrative control or that at least there i= s some ability to "bookend" I.e There needs to be an Rbridge for de-encap. = For this issue we are looking to protect a centralized broadcast domain fro= m external layer2 segments that are not in the same administrative control = and we do not want to try and inter=96op here with a stateful protocol or a= nything that is topographically aware. We see this issue with trying to run= STP with a "customer" also. The intent is to be stateless so that the "customer" doesn't need to care t= oo much about it and the service provider can standardize on a their ELAN s= ervice model without needing to care what the customer is doing except for = setting some basic requirements such as split-horizon and no-unicast mac fi= ltering. ----- Thanks for your input. R./ Rich Boldy Principal Engineer National Network Operations Engineering Advanced Technology Group CCNP JNCIS-SP MEF-CECP [cid:948BAC29-EA40-40AF-BDD0-A8510AC3BC32] 13820 Sunrise Valley Dr | Herndon, VA 20171 Office: (703) 713 1573 Mobile: (512) 673-2719 Email: richard.boldy@twcable.com AIM:rboldytwc From: Anoop Ghanwani > To: Richard Boldy > Cc: "nabil.n.bitar@verizon.com" >, "giheron@cisco.com" >, "l2= vpn@ietf.org" = > Subject: Re: VPLS external Loop Protection Mechanism (VLPM) - draft-l2vpn-v= lpm-01 Hi Richard, What's the reason for using an "unknown unicast" and not just a regular mul= ticast frame for this? The problem you're trying to solve looks very similar to what TRILL needed = to solve. TRILL uses IS-IS hellos to address this problem. Anoop On Sat, Mar 16, 2013 at 2:16 PM, Boldy, Richard > wrote: Filename: draft-l2vpn-vlpm Revision: 01 Title: VPLS external Loop Protection Mechanism (VLPM) Creation date: 2013-03-13 Group: Individual Submission Number of pages: 10 URL: http://www.ietf.org/internet-drafts/draft-l2vpn-vlpm-01.tx= t Status: http://datatracker.ietf.org/doc/draft-l2vpn-vlpm Htmlized: http://tools.ietf.org/html/draft-l2vpn-vlpm-01 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-l2vpn-vlpm-01 ________________________________ This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. --_000_CD6D10B783264richardboldytwcablecom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Hi Anoop,

Good questions. Firstly though I'd like the group to note that I had a= discussion with one of the chairs (Giles) today and I will be breaking thi= s out into a requirement draft to be followed by a revised VLPM draft once = the req doc is fleshed out.

That said I will try and answer the questions you posed as you gr= aciously took the time to give feedback on this.

-----
Q1 - It's funny you ask this cos it did start life using a multicast f= rame but the decision was made to change this to use a specific unknown uni= cast address due to the following reasoning, but it's up for debate:
  1. To remove the risk that the frames may get filtered due to multicast fi= ltering either by IGMP Snooping, MAC ACL or specifically configured command= line block statements in the external layer2 segment. IGMP Snooping should= ignore reserved multicast allocated space however there is potential here for differing vendor interpretation/= error/bugs etc. MAC ACL and specific command line blocking is also possible= for unknown unicast however I think it's fair to say that this is less com= mon and it would be much more acceptable to write into the terms of a VPLS service agreement that unknown unicast b= locking was not to be in place than to do so for multicast blocking where a= customer may not have any need for multicast frames in their network segme= nt at all.
  2. To ensure that the frame has the greatest chance of floo= ding through the entirety of the layer2 segment. Depending on configuration= the layer2 segment could be pruning multicast.
  3. Simply it seams mor= e complicated to use a multicast address when there is no specific multicas= t need and to the same end it maybe easier to get the allocation for unicas= t for the same reason.

Q2 - Please correct me if I'm missing something but I think the soluti= on to the TRILL problem was different in that it assumes that the full laye= r2 broadcast domain is under one administrative control or that at least th= ere is some ability to "bookend" I.e There needs to be an Rbridge for de-encap. For this issue we are looki= ng to protect a centralized broadcast domain from external layer2 segments = that are not in the same administrative control and we do not want to try a= nd inter=96op here with a stateful protocol or anything that is topographically aware. We see this issue with= trying to run STP with a "customer" also. 

The intent is to be stateless so that the "customer" doesn't= need to care too much about it and the service provider can standardize on= a their ELAN service model without needing to care what the customer is do= ing except for setting some basic requirements such as split-horizon and no-unicast mac filtering.

-----
Thanks for your input.

R./



Rich Boldy

Principal Engineer
National Network Operations Engineering
Advanced= Technology Group
CCNP JNCIS-SP MEF-C= ECP

 


13820 Sunrise Valley Dr&= nbsp;| Herndon, VA 20171
Office: = (703) 713 1573

Mobile: (512) 673-2719

Email: richard.boldy@twcable.c= om
AIM:rboldytwc




From: Anoop Ghanwani <anoop@alumni.duke.edu>
To: Richard Boldy <richard.boldy@twcable.com>
Cc: "nabil.n.bitar@verizon.com" <nabil.n.bitar@verizon.com>, "giheron@cisco.com" <giheron@cisco.com>, "l2vpn@ietf.org" <l2vpn@ietf.org>
Subject: Re: VPLS external Loop Pro= tection Mechanism (VLPM) - draft-l2vpn-vlpm-01

Hi Richard, 

What's the reason for using an "unknown unicast" and not jus= t a regular multicast
frame for this?

The problem you're trying to solve looks very similar to what TRILL ne= eded to solve.  
TRILL uses IS-IS hellos to address this problem.

Anoop

On Sat, Mar 16, 2013 at 2:16 PM, Boldy, Richard = <richard.= boldy@twcable.com> wrote:

Filename: draft-l2vpn-vlpm
Revision: 01
Title:&nb= sp;VPLS external Loop Protection Mechanism (VLPM)
Creation date: 2013-03-13
Group:&nb= sp;Individual Submission
Number of pages: 10

This E-mail and any of its a= ttachments may contain Time Warner Cable proprietary information, which is = privileged, confidential, or subject to copyright belonging to Time Warner = Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you a= re not the intended recipient of this E-mail, you are hereby notified that = any dissemination, distribution, copying, or action taken in relation to th= e contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have receiv= ed this E-mail in error, please notify the sender immediately and permanent= ly delete the original and any copy of this E-mail and any printout.
 --_000_CD6D10B783264richardboldytwcablecom_-- --_004_CD6D10B783264richardboldytwcablecom_ Content-Type: image/png; name="CE42269E-D6FE-4EE1-B6FF-B091393A5BF3[8].png" Content-Description: CE42269E-D6FE-4EE1-B6FF-B091393A5BF3[8].png Content-Disposition: inline; filename="CE42269E-D6FE-4EE1-B6FF-B091393A5BF3[8].png"; size=4548; creation-date="Tue, 19 Mar 2013 18:54:12 GMT"; modification-date="Tue, 19 Mar 2013 18:54:12 GMT" Content-ID: <948BAC29-EA40-40AF-BDD0-A8510AC3BC32> Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAJYAAAASCAYAAAC5ICcsAAAC0WlDQ1BJQ0MgUHJvZmlsZQAAKJGN lM9LFGEYx7+zjRgoQWBme4ihQ0ioTBZlROWuv9i0bVl/lBLE7Oy7u5Ozs9PM7JoiEV46ZtE9Kg8e +gM8eOiUl8LALALpblFEgpeS7Xlnxt0R7ccLM/N5nx/f53nf4X2BGlkxTT0kAXnDsZJ9Uen66JhU +xEhHEEdwqhTVNuMJBIDoMFjsWtsvofAvyute/v/OurStpoHhP1A6Eea2Sqw7xfZC1lqBBC5XsOE YzrE9zhbnv0x55TH8659KNlFvEh8QDUtHv+auEPNKWmgRiRuyQZiUgHO60XV7+cgPfXMGB6k73Hq 6S6ze3wWZtJKdz9xG/HnNOvu4ZrE8xmtN0bcTM9axuod9lg4oTmxIY9DI4YeH/C5yUjFr/qaoulE k9v6dmmwZ9t+S7mcIA4TJ8cL/TymkXI7p3JD1zwW9KlcV9znd1Yxyeseo5g5U3f/F/UWeoVR6GDQ YNDbgIQk+hBFK0xYKCBDHo0iNLIyN8YitjG+Z6SORIAl8q9TzrqbcxtFyuZZI4jGMdNSUZDkD/JX eVV+Ks/JX2bDxeaqZ8a6qanLD76TLq+8ret7/Z48fZXqRsirI0vWfGVNdqDTQHcZYzZcVeI12P34 ZmCVLFCpFSlXadytVHJ9Nr0jgWp/2j2KXZpebKrWWhUXbqzUL03v2KvCrlWxyqp2zqtxwXwmHhVP ijGxQzwHSbwkdooXxW6anRcHKhnDpKJhwlWyoVCWgUnymjv+mRcL76y5o6GPGczSVImf/4RVyGg6 CxzRf7j/c/B7xaOxIvDCBg6frto2ku4dIjQuV23OFeDCN7oP3lZtzXQeDj0BFs6oRavkSwvCG4pm dxw+6SqYk5aWzTlSuyyflSJ0JTEpZqhtLZKi65LrsiWL2cwqsXQb7Mypdk+lnnal5lO5vEHnr/YR sPWwXP75rFzeek49rAEv9d/AvP1FThgxSQAADq5JREFUaIHtmXl0VVWWxn/33jflDcnLPL8QkkBC gCTIkIAMMtgOCNKFqChII1CWU5W21VZZre3UDm05LVtR2wLECQe0REpBARGNQCBACBACCWR+ISHz S/LGe/qPFx4Zwapl9epezbdWVlb2mb5z93f22WdHEkJwCZfwc0PT83tQdbl9ndR3HKGp6yQubysG TSiR5nSizZloZMOgEzY4jlHWtANZEkgoyJIGVXhRURFCkBw2FbMuhgbHEZLDpiNL2r/X3lCFh8La ddiseUSbRwfsjY5Sypu3MT5hBRpZH7Afsr9HlCmDuOBxfzdOPwe8qpPTzbs41bwTj9qFLSSXlPCZ mHRRFx3b2l3J8cbNjE+4fUgfljdtp9vTzOiYG/5WipJmMGu7s5b8ypc5dubPCLwE6+MwaELo9rbS 7qxDoxgZG3MTebY7MerC+4y1dxSxr3oNGkXC6WnF3nGKCFMcFn0MXlVFrxhp6ipjW9kz/Mv040SY Rv6t5C+Kbk8rXxy7izExN3LD2HcC9u9OP0V+xXoijGmkRlwJgMN1ho3F/8S05Af/Vwurtm0/G4+s 4mzncaIto1AkLQXVb6JXLKya9B2RpvQLjj9xdgufFN+NzZo35D73Vr9Gdete0qPm9Tl4fw0GCKvI /gFfHn+QaHM680b9J8mhU0GS8KluFFmPKjycPPs1u06/QGHtOuZmPM+oqOsD47NibyYr9mYAypu2 sXrPHGalPMqExJWBPs1dp0i05hEaNBwAIQSSJAXaPaoTba/TJISKT3WjUQY7YQKPrwutYhrQYtSG ExecQ1XrbryqC42sx+PrpLIlH0mC8ubtAWHVOw7j9nkYFjq1z7pe1Yki65D7n0EhoIezKnzIkoJA RUIOdPGqzh7HSPSHV3UiIaPIun7TqkiS3DOvt8+6rd1VrD+wAK1i4I7cfOKCcwA421nKvpo1KP2i v0ftRkbps4bU8yOE2sPDhSJpkCQl0EeWNEgSCNR+nF2AGDTSubwd6BRTgHufr/VDxfNsL3uS6zJe Ylz8bdS0FfBR8TLqOw7iUz0osp4k6xRmpT3Cr3J/YE/Va3x8eDkzhpcyffiDAxYTgRu2701b3bqb w/UbSA2fjc/n5t0D8xkdsxCXt4PD9g9xeBpJsuYyPfn3FJ/5mOMNm+n2tJEaMZO56S+h1wQDUFD9 Bvtr1uJRHWhlMxMTVzA+4XbOOVKSZJLDrmBn+XM0d50iypxBveMIDncDscHJlDdtC4iiouV7TFoL 8SHjcbjq2V72OJWt+Xh8DmRJT3rUtcxKfQSdYmF/zVuUNGxiYuIqdpQ/Q7A+kkVj3+ODokWkhf8D WsVAYe07tDkrsegTuGbksySFXg6AveMQ28ueoKnrBCBhC8llTtrjmPUxVLTs4usTD3FFyr+yp+p1 2l3VLLtsKyZdBAB7q16luauGX+XtCIgKIMI0kqtHPtvj4Ha+O/U0J85uxeVtB2SSw6YxJ+0JLPrY HuFAdVsB31c8R3XrPrSKiUm2VeQm3hUQRu/D0NpdybayR6lrPwAIIk2jmJ32KJGmdHzCQ1Hde7Q5 q9FrgsmOuwWjNuL88TpY+zbbyx5lybhPGRd/G7tOP8uafddg0cewaOx7rJq0i4Vj1uJVXbz64yQq W/LJtd3J0sv+zK7T/0F+xfMDhDUUGjqPUdKwGae3zR9BWn9gS+kfaOg8Sm7SXaRHXk1h7Ue8c2A+ na4zTB12P6nhM8ivWMvJs1sB2HnqKTYd+zXjE5ZzU9YGMqMX8EnxSg7VvdtnreSw6XhUldr2fYA/ f7AabExK/CV17cW0dlcAUNG8i9jgbIzaMOo6DlLVWsDkpHuZn/k6GVFz+ebkH9lb9bqfv+MoRfYv 2FzyG2IsmWTFLkYVXmrb9rPlxEOUNn5JTtxipgy7j5q2/ewofwyARkcJbxXMRkJi4Zh1zE1/kZNN 3/Dh4cUI4aOlu4LSs/lsLF6OTjExIWEFOsXsP5rCR1nTN0SZbdiseUN+25buCo43fsW4+NuYn7ma iYkr2VP1J7adfCQgGBXYXfUKsZYcrhr5DKFBiXxy+F4O13/QZy4ZhU73Wdbsv4pGRynzM19jQeab tHRXsL7wOpzeNtq6K+l0N1LTVoDL205tWyHQE7EaHSVsKrmb6zPfYHjYFRyu38C35U+xdNwmksOm U1izhj1Vb5ASPo0bs95l28l/49Mjy7lrciHJodO4JecT3i68hlhLDsPDZ15UWLKkQZYUzgVmIQRj 437B9ZlvApAafiUF1W+SE7+EOWlPAhAXchkFNW/j8nXg9Laxs/wp8pLuYGLiKgCizaM5dmYje6tX kx13K+dOXKwlB7POSEXL9+TELaXs7NfYrLlkRM3ny9LfUdW2G4s+DnvHISYn/QaAERFXMyLi6gDf lLBZ7K99i7r2g37XSApaReKWnM+IsYwB/JFCCB+Z0dexaOz7gbHF9g20u+wA/FD5AqCyaOx6tIoR gDlpj/HBods423UCjaxHAuZmvDwgcXb7unC4z2DRx6JcIO+JsYzl3imHAn+nhs+hyP4+9o7zNiFg XsarpPT4akTEVdS1j6SwZg1ZsbcEYpUi6zhYt47GzuP8dloZYcYUAOZmvMgr+ZM51bSdlPBZeFUX 8SET8KrdmPXRQI+wOt2N5NnuISt2MV7VxbflTzAn7XGSw6azueRejjVsJjP6eraU/p6mzpPMTH2E A3VrqW7dQ0r4bByuerSKEb02eMgNXxgCpde9rQoPEhI6OShg86keJECRdDR1leH0dnK6eSfvHJgX yG3Odp3Goo9EVX3Isv+WN+ujA3lWh8uOveMQExJXEmEcQVhQAuVN24k0ptPlaWN42IyetdwU2T+g tPErfKoTncaMy+vslQcKFEka8HARCHQ9gjkPCRkZVXixtx9EFSobim7q4SzR4aoHoMvdHMjPTPqB rztF1qDIeryqG39qMTBvO8fiWMMmjtZ/itPbSpA2hDZnHWHG5F6M6MNTrwkmxjKGlu7TvXpICATV rQXIkpYvSu7puSYl3N4OANpddeg1IeTEL6W5swyTLopoi//1rQEYFjaNYWHTAGjuKqPb3cyYmBtx eTsorv+IxdkbSQqdQlrEHA7bNyBLWoK0Vryqk6NnPuWzo79k4Zh1xAePH2KzPwUDKx5i8CoIQvhQ BSSFTmV42AzO1eLGx68gJCgBWT6fiEpIJIfN4IeKP1Jc/yGq8GKz5iFJMsNCp1HVkk+IPgGTLoxY SxYAW048yO7K1cxMeYho8ygc7kaO1H82gOK5BPincAaBT3iw6KMYF78sMFaSFK5UTMQHj+PomYoh 59XIQUSa0jnVvAuHqx6LPm7QVXZXvsKmkvu5fNg9ZETNxaM6KWvaQX/y/XlKkow0QKwCVXjQa4xk xy1BkbUg/H2nJv+OhJDLALAabFgNtr58+xNzetvQKHoMGgsgoZENtDmrgCmBK6Kq9UfanXYO1K6n oiWfhWPWkhn9j0N80J8XqvASFpSMXqMDoZIZ/YtBevX9aMmh09lZ/u98f/oFosyZWA1JAKSFX0mR fQMFNX/CZs3FoA3Fqzoprv+QUdFzmZnqz0uEUNlW9vAFRHNhCASypCXKPIrSxq2khs9Br7EM0m+g oHojJ24pRfav2Fu1mtlpT/Rpq2jZhdWQRHH9x8QFZ3Jt+ouBth8rXkIIX5/+vcsIbl8nde1F2KwT A0xAICETa8mhuP5z4oPH/VWloQHCMuui8ficdLjqCTOmcHnyA3x+7F7aXfXYrJOwdxTxzYmHcbib cHrbWT5ha5/iY2/4ywT+53hvqMKLT/UFNuBTPajCe34cAp+q9rP55/Kqboy6SCbb7mbn6RcwaK2k hM/G5e1gb9UbRJpTuTb95T7rxQZnE6QLw95RTVbsjYGntS00D1mSaXTYmZZ8PwCKpCXCNJLypl2U NX2DURvBwdp1tHQ3BRzv56/2E5rAp7r7cAbwCQ8+4QFgStL9HKn/gnWF1zI1+Z8xaEI41bSD441f sGLCt/7+6uARC2B0zEKmJG3l65NP0tJdQUb0fBBwvHEz+6rfZtn4z4kNzmJ35ZsU139MpGkkJQ2b qGkvIjEkp4e7D68K35Y/Sa7tLhRJS37ly7Q7G8i13dPD2YtP9fMel7CMgpq3eOfAAmalPkywIYHa tkL21bzForHrh6yFDRCWNSiJYEMcx858xuXJD5BnuxujNow9laspqHodRdaRET2f7NibSQmfPeik 52DRx5IUOpYI04g+9nBjGrbQiWgVE7KkkBQ6JZAEAxiUYGzWCYT3GmfWRZEUmoPVkAjAlSOexmKI o7B2PYfq3keWNESbx5Adu2QAD5Mukpy4JZQ2bmdM7I0Be2hQCtmxt1LTfoj0yHmA/2qal/Eqfzn+ AJ8duQOjLpyMyLlkxy0gyjQK8D8UkkLzMGjO55SKrCchZCIx5qw+ayeGTMTtcwCChJAJrJiwhW/L n2Zzya+RJRmjNpIJiSvRaSxYg4YxLDSL4CGuOVnSsGD0f2GzTqawdi1/KbkPSZIIDUphcfa7pEfO JT5kPJ3uJraUPohBayU1fBYTE5Yj8AX8mxE9jUjTSL4q/S3dnlaMukiWjPuQ1B5/RpkzUVUvEhJW g43bJ2xl28nH2HriD/78TBPMmJgbBvi1N6Se/KRPjC+yv8/mknu4M28/oUHnkz6PrxuNrOtTTLsY VOEZ9N82vYt/QvgGzHmuvjT4mPPJqxAqbl8niqy7aJXYJ9wokm6AvX8h8hzcXgeKrOspMIqemmjf oujFOAsECNGrPuSHx9fVk+z3LewOxWUwuH2dSEiBF2b/NhklUFT2c/Mn3+ceO6rw4fF1o9eYB3AW Qh2wF6/qRFW96DQmhn48ACANKiwhVD45soya1v0svexzwo1pP2mjl3AJPRhcWAA+1cXnx+6kpOFL pibfR3bsrQQbBg/Rl3AJ/TC0sM7hyJmN7Dr1HB2uWkKChjM6+jouH/bA/xzFS/i/iIsLyw+Bvb2I U83fodcYGZ+w8sLdL+H/OwLCuoRL+Fnx31jyHIjV3M1tAAAAAElFTkSuQmCC --_004_CD6D10B783264richardboldytwcablecom_-- From ghanwani@gmail.com Tue Mar 19 14:07:36 2013 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAC5B21F9039 for ; Tue, 19 Mar 2013 14:07:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.676 X-Spam-Level: X-Spam-Status: No, score=-2.676 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_39=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WYe7ooq7QY3c for ; Tue, 19 Mar 2013 14:07:35 -0700 (PDT) Received: from mail-ve0-f175.google.com (mail-ve0-f175.google.com [209.85.128.175]) by ietfa.amsl.com (Postfix) with ESMTP id 7729721F9024 for ; Tue, 19 Mar 2013 14:07:35 -0700 (PDT) Received: by mail-ve0-f175.google.com with SMTP id cy12so831753veb.20 for ; Tue, 19 Mar 2013 14:07:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=NQEi1GQTIUxBcHG2Q8yBpDJCqZBO5o7LX5L5dUc1VUc=; b=RDvDI/VPOPfKxMqMcQ1tbr/xTe2n1/yQ++bIdIs/JMxsB1GgUUvPnuyiyEpHM84YuY 9ukkga+PTYco6xcHgKG1/1EXfTL6WXGjJOO0piPilF/kfMj42i1yBLRluSk30czI5pwv BfGxdcvTpDxlGtrO80NP1qtPIADkJWQMM4Gg24lhqXclkefKTCdIkRx7Gwy9ns2GPm7b Hhy7g5BsamVzlWJIW1/u3c5+AlzKRTvYxQEACYUzCYRVQ3Cxom7C9KqcVzbbr25CHXMP wCLriSAojC0NzZvCifZ/lQGcPm9EsV3ELx9dYox3wM1Pp6otQXXhC9WpDW3q79S5Fa9Q 6MOA== MIME-Version: 1.0 X-Received: by 10.52.23.38 with SMTP id j6mr3843655vdf.121.1363727254872; Tue, 19 Mar 2013 14:07:34 -0700 (PDT) Sender: ghanwani@gmail.com Received: by 10.58.241.170 with HTTP; Tue, 19 Mar 2013 14:07:34 -0700 (PDT) In-Reply-To: References: Date: Tue, 19 Mar 2013 14:07:34 -0700 X-Google-Sender-Auth: rukp9ajY7F3jDFIuhZrc7VOBwdw Message-ID: Subject: Re: VPLS external Loop Protection Mechanism (VLPM) - draft-l2vpn-vlpm-01 From: Anoop Ghanwani To: "Boldy, Richard" Content-Type: multipart/related; boundary=20cf3079bfe298ea4404d84d7e3c Cc: "l2vpn@ietf.org" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 21:07:37 -0000 --20cf3079bfe298ea4404d84d7e3c Content-Type: multipart/alternative; boundary=20cf3079bfe298ea4204d84d7e3b --20cf3079bfe298ea4204d84d7e3b Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Richard, Thanks for the response. One problem with using a unicast MAC in the DA is what happens if someone spoofs that MAC address as a source MAC? The bridges would all learn this source MAC and the propagation of UPF frames would be restricted. Multicast addresses would not be subject to that security limitation. TRILL uses IS-IS for several functions. The portion of IS-IS that accomplishes the objective of this draft for TRILL can be made to work where it is operated in a domain separate from the "core" broadcast domain that is being protected from these loops. I'm not very active in the VPLS area so I'll let others decide whether the security concern is acceptable or not. Anoop On Tue, Mar 19, 2013 at 11:54 AM, Boldy, Richard wrote: > Hi Anoop, > > Good questions. Firstly though I'd like the group to note that I had a > discussion with one of the chairs (Giles) today and I will be breaking th= is > out into a requirement draft to be followed by a revised VLPM draft once > the req doc is fleshed out. > > That said I will try and answer the questions you posed as you > graciously took the time to give feedback on this. > > ----- > Q1 - It's funny you ask this cos it did start life using a multicast fram= e > but the decision was made to change this to use a specific unknown unicas= t > address due to the following reasoning, but it's up for debate: > > 1. To remove the risk that the frames may get filtered due to > multicast filtering either by IGMP Snooping, MAC ACL or specifically > configured command line block statements in the external layer2 segmen= t. > IGMP Snooping should ignore reserved multicast allocated space however > there is potential here for differing vendor interpretation/error/bugs= etc. > MAC ACL and specific command line blocking is also possible for unknow= n > unicast however I think it's fair to say that this is less common and = it > would be much more acceptable to write into the terms of a VPLS servic= e > agreement that unknown unicast blocking was not to be in place than to= do > so for multicast blocking where a customer may not have any need for > multicast frames in their network segment at all. > 2. To ensure that the frame has the greatest chance of flooding > through the entirety of the layer2 segment. Depending on configuration= the > layer2 segment could be pruning multicast. > 3. Simply it seams more complicated to use a multicast address when > there is no specific multicast need and to the same end it maybe easie= r to > get the allocation for unicast for the same reason. > > > Q2 - Please correct me if I'm missing something but I think the solution > to the TRILL problem was different in that it assumes that the full layer= 2 > broadcast domain is under one administrative control or that at least the= re > is some ability to "bookend" I.e There needs to be an Rbridge for de-enca= p. > For this issue we are looking to protect a centralized broadcast domain > from external layer2 segments that are not in the same administrative > control and we do not want to try and inter=96op here with a stateful > protocol or anything that is topographically aware. We see this issue wit= h > trying to run STP with a "customer" also. > > The intent is to be stateless so that the "customer" doesn't need to > care too much about it and the service provider can standardize on a thei= r > ELAN service model without needing to care what the customer is doing > except for setting some basic requirements such as split-horizon and > no-unicast mac filtering. > > ----- > Thanks for your input. > > R./ > > > > *Rich Boldy* > > Principal Engineer > National Network Operations Engineering > Advanced Technology Group > CCNP JNCIS-SP MEF-CECP > > ** ** > > > 13820 Sunrise Valley Dr | Herndon, VA 20171 > Office: (703) 713 1573**** > > Mobile: (512) 673-2719 > > Email: richard.boldy@twcable.com > AIM:rboldytwc > > * > > * > > > > > From: Anoop Ghanwani > To: Richard Boldy > Cc: "nabil.n.bitar@verizon.com" , " > giheron@cisco.com" , "l2vpn@ietf.org" > Subject: Re: VPLS external Loop Protection Mechanism (VLPM) - > draft-l2vpn-vlpm-01 > > Hi Richard, > > What's the reason for using an "unknown unicast" and not just a regular > multicast > frame for this? > > The problem you're trying to solve looks very similar to what TRILL > needed to solve. > TRILL uses IS-IS hellos to address this problem. > > Anoop > > On Sat, Mar 16, 2013 at 2:16 PM, Boldy, Richard > wrote: > >> >> Filename: draft-l2vpn-vlpm >> Revision: 01 >> Title: VPLS external Loop Protection Mechanism (VLPM) >> Creation date: 2013-03-13 >> Group: Individual Submission >> Number of pages: 10 >> URL: >> http://www.ietf.org/internet-drafts/draft-l2vpn-vlpm-01.txt >> Status: http://datatracker.ietf.org/doc/draft-l2vpn-vlpm >> Htmlized: http://tools.ietf.org/html/draft-l2vpn-vlpm-01 >> Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-l2vpn-vlpm-01 >> > > ------------------------------ > This E-mail and any of its attachments may contain Time Warner Cable > proprietary information, which is privileged, confidential, or subject to > copyright belonging to Time Warner Cable. This E-mail is intended solely > for the use of the individual or entity to which it is addressed. If you > are not the intended recipient of this E-mail, you are hereby notified th= at > any dissemination, distribution, copying, or action taken in relation to > the contents of and attachments to this E-mail is strictly prohibited and > may be unlawful. If you have received this E-mail in error, please notify > the sender immediately and permanently delete the original and any copy o= f > this E-mail and any printout. > --20cf3079bfe298ea4204d84d7e3b Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Richard,

Thanks for the response.

One problem with using a unicast MAC in the DA is what happens if
someone spoofs that MAC address as a source MAC? =A0The bridges
would all learn this source MAC and the propagation of UPF frames=A0
would be restricted. =A0Multicast addresses would not be subject t= o that=A0
security limitation.

TRILL use= s IS-IS for several functions. =A0The portion of IS-IS that accomplishes
the objective of this draft for TRILL can be made to work where it is = operated
in a domain separate from the "core" broadcast= domain that is being=A0
protected from these loops.

I'm not very active in the VPLS area so I'll let oth= ers decide whether
the security concern is acceptable or not.

Anoop

On Tue= , Mar 19, 2013 at 11:54 AM, Boldy, Richard <richard.boldy@twcable.= com> wrote:
Hi Anoop,

Good questions. Firstly though I'd like the group to note that I h= ad a discussion with one of the chairs (Giles) today and I will be breaking= this out into a requirement draft to be followed by a revised VLPM draft o= nce the req doc is fleshed out.

That said=A0I will try and answer the questions you posed as you graci= ously took the time to give feedback on this.

-----
Q1 - It's funny you ask this cos it did start life using a multica= st frame but the decision was made to change this to use a specific unknown= unicast address due to the following reasoning, but it's up for debate= :
  1. To remove the risk that the frames may get filtered due to multicast fi= ltering either by IGMP Snooping, MAC ACL or specifically configured command= line block statements in the external layer2 segment. IGMP Snooping should= ignore reserved multicast allocated space however there is potential here for differing vendor interpretation/= error/bugs etc. MAC ACL and specific command line blocking is also possible= for unknown unicast however I think it's fair to say that this is less= common and it would be much more acceptable to write into the terms of a VPLS service agreement that unknown unicast b= locking was not to be in place than to do so for multicast blocking where a= customer may not have any need for multicast frames in their network segme= nt at all.
  2. To ensure that the frame has the greatest chance of flooding through th= e entirety of the layer2 segment. Depending on configuration the layer2 seg= ment could be pruning multicast.
  3. Simply it seams more complicated t= o use a multicast address when there is no specific multicast need and to t= he same end it maybe easier to get the allocation for unicast for the same = reason.

Q2 - Please correct me if I'm missing something but I think the so= lution to the TRILL problem was different in that it assumes that the full = layer2 broadcast domain is under one administrative control or that at leas= t there is some ability to "bookend" I.e There needs to be an Rbridge for de-encap. For this issue we are looki= ng to protect a centralized broadcast domain from external layer2 segments = that are not in the same administrative control and we do not want to try a= nd inter=96op here with a stateful protocol or anything that is topographically aware. We see this issue with= trying to run STP with a "customer" also.=A0

The intent is to be stateless so that the "customer" doesn&#= 39;t need to care too much about it and the service provider can standardiz= e on a their ELAN service model without needing to care what the customer i= s doing except for setting some basic requirements such as split-horizon and no-unicast mac filtering.

-----
Thanks for your input.

R./



Rich Boldy

Principal Engineer
National Network Operations Engineering
Advanced Technology Group
CCNP JNCIS-SP MEF-CECP

=A0


13820 Sunrise Valley Dr=A0| Herndon, VA 20171
Office: (703) 713 1573=

Mobile: (512) 673-2719

Email: richa= rd.boldy@twcable.com
AIM:rboldytwc



From: Anoop Ghanwani <anoop@alumni.duke.edu&= gt;
To: Richard Boldy <richard.boldy@twcable.com= >
Cc: "nabil.n.bitar@verizon.com" &= lt;nabil.n.b= itar@verizon.com>, "giheron@cisco.com" <giheron@cisco.com>, "l2vpn@ietf.org" <l2vpn@ietf= .org>
Subject: Re: VPLS external Loop Pro= tection Mechanism (VLPM) - draft-l2vpn-vlpm-01

Hi Richard,=A0

What's the reason for using an "unknown unicast" and not= just a regular multicast
frame for this?

The problem you're trying to solve looks very similar to what TRIL= L needed to solve. =A0
TRILL uses IS-IS hellos to address this problem.

Anoop

On Sat, Mar 16, 2013 at 2:16 PM, Boldy, Richard = <richard.= boldy@twcable.com> wrote:

Filename:=A0draft-l2vpn-vlpm
Revision:=A001
Title:=A0= VPLS external Loop Protection Mechanism (VLPM)
Creation date:=A02013-03-13
Group:=A0= Individual Submission
Number of pages: 10
URL:=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0http://www.ietf.org/internet-drafts/dra= ft-l2vpn-vlpm-01.txt
Status:=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0http://datatracker.ietf.org/doc/draft-l2vpn-vlpm
Htmlized:=A0=A0=A0=A0= =A0=A0=A0=A0http://tools.ietf.org/html/draft-l2vpn-vlpm-01
Diff:=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0http://www.ietf.org/rfcdiff?url2=3Ddraft-l2v= pn-vlpm-01

This E-mail and any of its a= ttachments may contain Time Warner Cable proprietary information, which is = privileged, confidential, or subject to copyright belonging to Time Warner = Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you a= re not the intended recipient of this E-mail, you are hereby notified that = any dissemination, distribution, copying, or action taken in relation to th= e contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have receiv= ed this E-mail in error, please notify the sender immediately and permanent= ly delete the original and any copy of this E-mail and any printout.

--20cf3079bfe298ea4204d84d7e3b-- --20cf3079bfe298ea4404d84d7e3c Content-Type: image/png; name="CE42269E-D6FE-4EE1-B6FF-B091393A5BF3[8].png" Content-Transfer-Encoding: base64 Content-ID: <948BAC29-EA40-40AF-BDD0-A8510AC3BC32> X-Attachment-Id: 84be028b7c187314_0.1 iVBORw0KGgoAAAANSUhEUgAAAJYAAAASCAYAAAC5ICcsAAAC0WlDQ1BJQ0MgUHJvZmlsZQAAKJGN lM9LFGEYx7+zjRgoQWBme4ihQ0ioTBZlROWuv9i0bVl/lBLE7Oy7u5Ozs9PM7JoiEV46ZtE9Kg8e +gM8eOiUl8LALALpblFEgpeS7Xlnxt0R7ccLM/N5nx/f53nf4X2BGlkxTT0kAXnDsZJ9Uen66JhU +xEhHEEdwqhTVNuMJBIDoMFjsWtsvofAvyute/v/OurStpoHhP1A6Eea2Sqw7xfZC1lqBBC5XsOE YzrE9zhbnv0x55TH8659KNlFvEh8QDUtHv+auEPNKWmgRiRuyQZiUgHO60XV7+cgPfXMGB6k73Hq 6S6ze3wWZtJKdz9xG/HnNOvu4ZrE8xmtN0bcTM9axuod9lg4oTmxIY9DI4YeH/C5yUjFr/qaoulE k9v6dmmwZ9t+S7mcIA4TJ8cL/TymkXI7p3JD1zwW9KlcV9znd1Yxyeseo5g5U3f/F/UWeoVR6GDQ YNDbgIQk+hBFK0xYKCBDHo0iNLIyN8YitjG+Z6SORIAl8q9TzrqbcxtFyuZZI4jGMdNSUZDkD/JX eVV+Ks/JX2bDxeaqZ8a6qanLD76TLq+8ret7/Z48fZXqRsirI0vWfGVNdqDTQHcZYzZcVeI12P34 ZmCVLFCpFSlXadytVHJ9Nr0jgWp/2j2KXZpebKrWWhUXbqzUL03v2KvCrlWxyqp2zqtxwXwmHhVP ijGxQzwHSbwkdooXxW6anRcHKhnDpKJhwlWyoVCWgUnymjv+mRcL76y5o6GPGczSVImf/4RVyGg6 CxzRf7j/c/B7xaOxIvDCBg6frto2ku4dIjQuV23OFeDCN7oP3lZtzXQeDj0BFs6oRavkSwvCG4pm dxw+6SqYk5aWzTlSuyyflSJ0JTEpZqhtLZKi65LrsiWL2cwqsXQb7Mypdk+lnnal5lO5vEHnr/YR sPWwXP75rFzeek49rAEv9d/AvP1FThgxSQAADq5JREFUaIHtmXl0VVWWxn/33jflDcnLPL8QkkBC gCTIkIAMMtgOCNKFqChII1CWU5W21VZZre3UDm05LVtR2wLECQe0REpBARGNQCBACBACCWR+ISHz S/LGe/qPFx4Zwapl9epezbdWVlb2mb5z93f22WdHEkJwCZfwc0PT83tQdbl9ndR3HKGp6yQubysG TSiR5nSizZloZMOgEzY4jlHWtANZEkgoyJIGVXhRURFCkBw2FbMuhgbHEZLDpiNL2r/X3lCFh8La ddiseUSbRwfsjY5Sypu3MT5hBRpZH7Afsr9HlCmDuOBxfzdOPwe8qpPTzbs41bwTj9qFLSSXlPCZ mHRRFx3b2l3J8cbNjE+4fUgfljdtp9vTzOiYG/5WipJmMGu7s5b8ypc5dubPCLwE6+MwaELo9rbS 7qxDoxgZG3MTebY7MerC+4y1dxSxr3oNGkXC6WnF3nGKCFMcFn0MXlVFrxhp6ipjW9kz/Mv040SY Rv6t5C+Kbk8rXxy7izExN3LD2HcC9u9OP0V+xXoijGmkRlwJgMN1ho3F/8S05Af/Vwurtm0/G4+s 4mzncaIto1AkLQXVb6JXLKya9B2RpvQLjj9xdgufFN+NzZo35D73Vr9Gdete0qPm9Tl4fw0GCKvI /gFfHn+QaHM680b9J8mhU0GS8KluFFmPKjycPPs1u06/QGHtOuZmPM+oqOsD47NibyYr9mYAypu2 sXrPHGalPMqExJWBPs1dp0i05hEaNBwAIQSSJAXaPaoTba/TJISKT3WjUQY7YQKPrwutYhrQYtSG ExecQ1XrbryqC42sx+PrpLIlH0mC8ubtAWHVOw7j9nkYFjq1z7pe1Yki65D7n0EhoIezKnzIkoJA RUIOdPGqzh7HSPSHV3UiIaPIun7TqkiS3DOvt8+6rd1VrD+wAK1i4I7cfOKCcwA421nKvpo1KP2i v0ftRkbps4bU8yOE2sPDhSJpkCQl0EeWNEgSCNR+nF2AGDTSubwd6BRTgHufr/VDxfNsL3uS6zJe Ylz8bdS0FfBR8TLqOw7iUz0osp4k6xRmpT3Cr3J/YE/Va3x8eDkzhpcyffiDAxYTgRu2701b3bqb w/UbSA2fjc/n5t0D8xkdsxCXt4PD9g9xeBpJsuYyPfn3FJ/5mOMNm+n2tJEaMZO56S+h1wQDUFD9 Bvtr1uJRHWhlMxMTVzA+4XbOOVKSZJLDrmBn+XM0d50iypxBveMIDncDscHJlDdtC4iiouV7TFoL 8SHjcbjq2V72OJWt+Xh8DmRJT3rUtcxKfQSdYmF/zVuUNGxiYuIqdpQ/Q7A+kkVj3+ODokWkhf8D WsVAYe07tDkrsegTuGbksySFXg6AveMQ28ueoKnrBCBhC8llTtrjmPUxVLTs4usTD3FFyr+yp+p1 2l3VLLtsKyZdBAB7q16luauGX+XtCIgKIMI0kqtHPtvj4Ha+O/U0J85uxeVtB2SSw6YxJ+0JLPrY HuFAdVsB31c8R3XrPrSKiUm2VeQm3hUQRu/D0NpdybayR6lrPwAIIk2jmJ32KJGmdHzCQ1Hde7Q5 q9FrgsmOuwWjNuL88TpY+zbbyx5lybhPGRd/G7tOP8uafddg0cewaOx7rJq0i4Vj1uJVXbz64yQq W/LJtd3J0sv+zK7T/0F+xfMDhDUUGjqPUdKwGae3zR9BWn9gS+kfaOg8Sm7SXaRHXk1h7Ue8c2A+ na4zTB12P6nhM8ivWMvJs1sB2HnqKTYd+zXjE5ZzU9YGMqMX8EnxSg7VvdtnreSw6XhUldr2fYA/ f7AabExK/CV17cW0dlcAUNG8i9jgbIzaMOo6DlLVWsDkpHuZn/k6GVFz+ebkH9lb9bqfv+MoRfYv 2FzyG2IsmWTFLkYVXmrb9rPlxEOUNn5JTtxipgy7j5q2/ewofwyARkcJbxXMRkJi4Zh1zE1/kZNN 3/Dh4cUI4aOlu4LSs/lsLF6OTjExIWEFOsXsP5rCR1nTN0SZbdiseUN+25buCo43fsW4+NuYn7ma iYkr2VP1J7adfCQgGBXYXfUKsZYcrhr5DKFBiXxy+F4O13/QZy4ZhU73Wdbsv4pGRynzM19jQeab tHRXsL7wOpzeNtq6K+l0N1LTVoDL205tWyHQE7EaHSVsKrmb6zPfYHjYFRyu38C35U+xdNwmksOm U1izhj1Vb5ASPo0bs95l28l/49Mjy7lrciHJodO4JecT3i68hlhLDsPDZ15UWLKkQZYUzgVmIQRj 437B9ZlvApAafiUF1W+SE7+EOWlPAhAXchkFNW/j8nXg9Laxs/wp8pLuYGLiKgCizaM5dmYje6tX kx13K+dOXKwlB7POSEXL9+TELaXs7NfYrLlkRM3ny9LfUdW2G4s+DnvHISYn/QaAERFXMyLi6gDf lLBZ7K99i7r2g37XSApaReKWnM+IsYwB/JFCCB+Z0dexaOz7gbHF9g20u+wA/FD5AqCyaOx6tIoR gDlpj/HBods423UCjaxHAuZmvDwgcXb7unC4z2DRx6JcIO+JsYzl3imHAn+nhs+hyP4+9o7zNiFg XsarpPT4akTEVdS1j6SwZg1ZsbcEYpUi6zhYt47GzuP8dloZYcYUAOZmvMgr+ZM51bSdlPBZeFUX 8SET8KrdmPXRQI+wOt2N5NnuISt2MV7VxbflTzAn7XGSw6azueRejjVsJjP6eraU/p6mzpPMTH2E A3VrqW7dQ0r4bByuerSKEb02eMgNXxgCpde9rQoPEhI6OShg86keJECRdDR1leH0dnK6eSfvHJgX yG3Odp3Goo9EVX3Isv+WN+ujA3lWh8uOveMQExJXEmEcQVhQAuVN24k0ptPlaWN42IyetdwU2T+g tPErfKoTncaMy+vslQcKFEka8HARCHQ9gjkPCRkZVXixtx9EFSobim7q4SzR4aoHoMvdHMjPTPqB rztF1qDIeryqG39qMTBvO8fiWMMmjtZ/itPbSpA2hDZnHWHG5F6M6MNTrwkmxjKGlu7TvXpICATV rQXIkpYvSu7puSYl3N4OANpddeg1IeTEL6W5swyTLopoi//1rQEYFjaNYWHTAGjuKqPb3cyYmBtx eTsorv+IxdkbSQqdQlrEHA7bNyBLWoK0Vryqk6NnPuWzo79k4Zh1xAePH2KzPwUDKx5i8CoIQvhQ BSSFTmV42AzO1eLGx68gJCgBWT6fiEpIJIfN4IeKP1Jc/yGq8GKz5iFJMsNCp1HVkk+IPgGTLoxY SxYAW048yO7K1cxMeYho8ygc7kaO1H82gOK5BPincAaBT3iw6KMYF78sMFaSFK5UTMQHj+PomYoh 59XIQUSa0jnVvAuHqx6LPm7QVXZXvsKmkvu5fNg9ZETNxaM6KWvaQX/y/XlKkow0QKwCVXjQa4xk xy1BkbUg/H2nJv+OhJDLALAabFgNtr58+xNzetvQKHoMGgsgoZENtDmrgCmBK6Kq9UfanXYO1K6n oiWfhWPWkhn9j0N80J8XqvASFpSMXqMDoZIZ/YtBevX9aMmh09lZ/u98f/oFosyZWA1JAKSFX0mR fQMFNX/CZs3FoA3Fqzoprv+QUdFzmZnqz0uEUNlW9vAFRHNhCASypCXKPIrSxq2khs9Br7EM0m+g oHojJ24pRfav2Fu1mtlpT/Rpq2jZhdWQRHH9x8QFZ3Jt+ouBth8rXkIIX5/+vcsIbl8nde1F2KwT A0xAICETa8mhuP5z4oPH/VWloQHCMuui8ficdLjqCTOmcHnyA3x+7F7aXfXYrJOwdxTxzYmHcbib cHrbWT5ha5/iY2/4ywT+53hvqMKLT/UFNuBTPajCe34cAp+q9rP55/Kqboy6SCbb7mbn6RcwaK2k hM/G5e1gb9UbRJpTuTb95T7rxQZnE6QLw95RTVbsjYGntS00D1mSaXTYmZZ8PwCKpCXCNJLypl2U NX2DURvBwdp1tHQ3BRzv56/2E5rAp7r7cAbwCQ8+4QFgStL9HKn/gnWF1zI1+Z8xaEI41bSD441f sGLCt/7+6uARC2B0zEKmJG3l65NP0tJdQUb0fBBwvHEz+6rfZtn4z4kNzmJ35ZsU139MpGkkJQ2b qGkvIjEkp4e7D68K35Y/Sa7tLhRJS37ly7Q7G8i13dPD2YtP9fMel7CMgpq3eOfAAmalPkywIYHa tkL21bzForHrh6yFDRCWNSiJYEMcx858xuXJD5BnuxujNow9laspqHodRdaRET2f7NibSQmfPeik 52DRx5IUOpYI04g+9nBjGrbQiWgVE7KkkBQ6JZAEAxiUYGzWCYT3GmfWRZEUmoPVkAjAlSOexmKI o7B2PYfq3keWNESbx5Adu2QAD5Mukpy4JZQ2bmdM7I0Be2hQCtmxt1LTfoj0yHmA/2qal/Eqfzn+ AJ8duQOjLpyMyLlkxy0gyjQK8D8UkkLzMGjO55SKrCchZCIx5qw+ayeGTMTtcwCChJAJrJiwhW/L n2Zzya+RJRmjNpIJiSvRaSxYg4YxLDSL4CGuOVnSsGD0f2GzTqawdi1/KbkPSZIIDUphcfa7pEfO JT5kPJ3uJraUPohBayU1fBYTE5Yj8AX8mxE9jUjTSL4q/S3dnlaMukiWjPuQ1B5/RpkzUVUvEhJW g43bJ2xl28nH2HriD/78TBPMmJgbBvi1N6Se/KRPjC+yv8/mknu4M28/oUHnkz6PrxuNrOtTTLsY VOEZ9N82vYt/QvgGzHmuvjT4mPPJqxAqbl8niqy7aJXYJ9wokm6AvX8h8hzcXgeKrOspMIqemmjf oujFOAsECNGrPuSHx9fVk+z3LewOxWUwuH2dSEiBF2b/NhklUFT2c/Mn3+ceO6rw4fF1o9eYB3AW Qh2wF6/qRFW96DQmhn48ACANKiwhVD45soya1v0svexzwo1pP2mjl3AJPRhcWAA+1cXnx+6kpOFL pibfR3bsrQQbBg/Rl3AJ/TC0sM7hyJmN7Dr1HB2uWkKChjM6+jouH/bA/xzFS/i/iIsLyw+Bvb2I U83fodcYGZ+w8sLdL+H/OwLCuoRL+Fnx31jyHIjV3M1tAAAAAElFTkSuQmCC --20cf3079bfe298ea4404d84d7e3c-- From richard.boldy@twcable.com Thu Mar 21 08:13:06 2013 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 274BD21F8AB7 for ; Thu, 21 Mar 2013 08:13:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.888 X-Spam-Level: X-Spam-Status: No, score=0.888 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, J_CHICKENPOX_39=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id it6KBf8dgMHz for ; Thu, 21 Mar 2013 08:13:05 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id E9D3C21F910D for ; Thu, 21 Mar 2013 08:13:04 -0700 (PDT) X-SENDER-IP: 10.136.163.13 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.84,887,1355115600"; d="png'150?scan'150,208,217,150";a="45066080" Received: from unknown (HELO PRVPEXHUB04.corp.twcable.com) ([10.136.163.13]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 21 Mar 2013 11:12:34 -0400 Received: from PRVPEXVS14.corp.twcable.com ([10.136.163.48]) by PRVPEXHUB04.corp.twcable.com ([10.136.163.13]) with mapi; Thu, 21 Mar 2013 11:13:04 -0400 From: "Boldy, Richard" To: "l2vpn@ietf.org" Date: Thu, 21 Mar 2013 11:13:00 -0400 Subject: FW: New Version Notification for draft-boldy-l2vpn-vplsloop-req-00.txt Thread-Topic: New Version Notification for draft-boldy-l2vpn-vplsloop-req-00.txt Thread-Index: Ac4mRpUmcSKX54gUQ3S3IidbdFO5SQ== Message-ID: In-Reply-To: <20130321150441.3415.31951.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.2.120421 acceptlanguage: en-US Content-Type: multipart/related; boundary="_004_CD709A558415Brichardboldytwcablecom_"; type="multipart/alternative" MIME-Version: 1.0 X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 15:13:06 -0000 --_004_CD709A558415Brichardboldytwcablecom_ Content-Type: multipart/alternative; boundary="_000_CD709A558415Brichardboldytwcablecom_" --_000_CD709A558415Brichardboldytwcablecom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, At the request of one of our Chairs (Giles) the REQ draft below replaces my= original draft - "draft-l2vpn-vlpm' as a requirements draft for this solut= ion. Once reviewed and chewed I'll be submitting my proposed solution draft (as = per my original ID) but I welcome any others. Let's put the solution discussion on the shelf for now till we get a good p= eer review on this REQ. Kind regards Rich./ Rich Boldy Principal Engineer National Network Operations Engineering Advanced Technology Group CCNP MEF-CECP [cid:A7EAFD73-5965-46E2-88CE-A337A4BB8CF9] 13820 Sunrise Valley Dr | Herndon, VA 20171 Office: (703) 713 1573 Mobile: (512) 673-2719 Email: richard.boldy@twcable.com AIM:rboldytwc From: "internet-drafts@ietf.org" > To: Richard Boldy > Subject: New Version Notification for draft-boldy-l2vpn-vplsloop-req-00.txt A new version of I-D, draft-boldy-l2vpn-vplsloop-req-00.txt has been successfully submitted by Time Warner Cable and posted to the IETF repository. Filename: draft-boldy-l2vpn-vplsloop-req Revision: 00 Title: VPLS External Loop Detection and Protection Requirements Creation date: 2013-03-21 Group: Individual Submission Number of pages: 6 URL: http://www.ietf.org/internet-drafts/draft-boldy-l2vpn-vpls= loop-req-00.txt Status: http://datatracker.ietf.org/doc/draft-boldy-l2vpn-vplsloop= -req Htmlized: http://tools.ietf.org/html/draft-boldy-l2vpn-vplsloop-req-= 00 Abstract: Virtual Private LAN Service (VPLS) implementations, as defined in [RFC4761] and [RFC4762], are highly susceptible to layer-2 loops external to the PE customer-facing interface. Such loops impact performance and can have a detrimental affect on all VPLS traffic throughout the entire instance under certain conditions. Current Layer-2 loop detection and protection mechanisms do not function effectively here. This document describes the requirements for a protocol function to offer VPLS service providers a mechanism for detecting such layer-2 loops and facilitating configurable actions without the need for inter-operation with customer network protocols, other VPLS PEs or customer sourced frames. The IETF Secretariat ________________________________ This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. --_000_CD709A558415Brichardboldytwcablecom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,

At the request of one of our Chairs (Giles) the REQ draf= t below replaces my original draft - "draft-l2vpn-vlpm' as a requirements draft for this solution.

Once reviewed and chewed I'll be submitting my proposed solution draft= (as per my original ID) but I welcome any others. 

Let's put the solution discussion on the shelf for now till we get a g= ood peer review on this REQ.

Kind regards
Rich./



Rich Boldy

Principal Engineer
National Network Operations Engineering
Advanced= Technology Group
CCNP MEF-CECP

 


13820 Sunrise Valley Dr&= nbsp;| Herndon, VA 20171
Office: = (703) 713 1573

Mobile: (512) 673-2719

Email: richard.boldy@twcable.com
AIM:rboldytwc




From: "internet-drafts@ietf.org" <internet-drafts@ietf.org>
To: Richard Boldy <richard.boldy@twcable.com>
Subject: New Version Notification f= or draft-boldy-l2vpn-vplsloop-req-00.txt


A new version of I-D, draft-boldy-l2vpn-vplsloop-req-00.txt
has been successfully submitted by Time Warner Cable and posted to the=
IETF repository.

Filename: draft-boldy-l2vpn-vplsloop-req
Revision: 00
Title: VPLS Exter= nal Loop Detection and Protection Requirements
Creation date: 2013-03-21
Group: Individual= Submission
Number of pages: 6


Abstract:
    Virtual Private LAN Service (VPLS) implementat= ions, as defined in
    [RFC4761] and [RFC4762], are highly susceptibl= e to layer-2 loops
    external to the PE customer-facing interface. = Such loops impact
    performance and can have a detrimental affect = on all VPLS traffic
    throughout the entire instance under certain c= onditions.

    Current Layer-2 loop detection and protection = mechanisms do not
    function effectively here.

    This document describes the requirements for a= protocol function
    to offer VPLS service providers a mechanism fo= r detecting such
    layer-2 loops and facilitating configurable ac= tions without the
    need for inter-operation with customer network= protocols, other
    VPLS PEs or customer sourced frames.

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


The IETF Secretariat



This E-mail and any of its a= ttachments may contain Time Warner Cable proprietary information, which is = privileged, confidential, or subject to copyright belonging to Time Warner = Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you a= re not the intended recipient of this E-mail, you are hereby notified that = any dissemination, distribution, copying, or action taken in relation to th= e contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have receiv= ed this E-mail in error, please notify the sender immediately and permanent= ly delete the original and any copy of this E-mail and any printout.
 --_000_CD709A558415Brichardboldytwcablecom_-- --_004_CD709A558415Brichardboldytwcablecom_ Content-Type: image/png; name="CE42269E-D6FE-4EE1-B6FF-B091393A5BF3[1].png" Content-Description: CE42269E-D6FE-4EE1-B6FF-B091393A5BF3[1].png Content-Disposition: inline; filename="CE42269E-D6FE-4EE1-B6FF-B091393A5BF3[1].png"; size=4548; creation-date="Thu, 21 Mar 2013 15:13:03 GMT"; modification-date="Thu, 21 Mar 2013 15:13:03 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAJYAAAASCAYAAAC5ICcsAAAC0WlDQ1BJQ0MgUHJvZmlsZQAAKJGN lM9LFGEYx7+zjRgoQWBme4ihQ0ioTBZlROWuv9i0bVl/lBLE7Oy7u5Ozs9PM7JoiEV46ZtE9Kg8e +gM8eOiUl8LALALpblFEgpeS7Xlnxt0R7ccLM/N5nx/f53nf4X2BGlkxTT0kAXnDsZJ9Uen66JhU +xEhHEEdwqhTVNuMJBIDoMFjsWtsvofAvyute/v/OurStpoHhP1A6Eea2Sqw7xfZC1lqBBC5XsOE YzrE9zhbnv0x55TH8659KNlFvEh8QDUtHv+auEPNKWmgRiRuyQZiUgHO60XV7+cgPfXMGB6k73Hq 6S6ze3wWZtJKdz9xG/HnNOvu4ZrE8xmtN0bcTM9axuod9lg4oTmxIY9DI4YeH/C5yUjFr/qaoulE k9v6dmmwZ9t+S7mcIA4TJ8cL/TymkXI7p3JD1zwW9KlcV9znd1Yxyeseo5g5U3f/F/UWeoVR6GDQ YNDbgIQk+hBFK0xYKCBDHo0iNLIyN8YitjG+Z6SORIAl8q9TzrqbcxtFyuZZI4jGMdNSUZDkD/JX eVV+Ks/JX2bDxeaqZ8a6qanLD76TLq+8ret7/Z48fZXqRsirI0vWfGVNdqDTQHcZYzZcVeI12P34 ZmCVLFCpFSlXadytVHJ9Nr0jgWp/2j2KXZpebKrWWhUXbqzUL03v2KvCrlWxyqp2zqtxwXwmHhVP ijGxQzwHSbwkdooXxW6anRcHKhnDpKJhwlWyoVCWgUnymjv+mRcL76y5o6GPGczSVImf/4RVyGg6 CxzRf7j/c/B7xaOxIvDCBg6frto2ku4dIjQuV23OFeDCN7oP3lZtzXQeDj0BFs6oRavkSwvCG4pm dxw+6SqYk5aWzTlSuyyflSJ0JTEpZqhtLZKi65LrsiWL2cwqsXQb7Mypdk+lnnal5lO5vEHnr/YR sPWwXP75rFzeek49rAEv9d/AvP1FThgxSQAADq5JREFUaIHtmXl0VVWWxn/33jflDcnLPL8QkkBC gCTIkIAMMtgOCNKFqChII1CWU5W21VZZre3UDm05LVtR2wLECQe0REpBARGNQCBACBACCWR+ISHz S/LGe/qPFx4Zwapl9epezbdWVlb2mb5z93f22WdHEkJwCZfwc0PT83tQdbl9ndR3HKGp6yQubysG TSiR5nSizZloZMOgEzY4jlHWtANZEkgoyJIGVXhRURFCkBw2FbMuhgbHEZLDpiNL2r/X3lCFh8La ddiseUSbRwfsjY5Sypu3MT5hBRpZH7Afsr9HlCmDuOBxfzdOPwe8qpPTzbs41bwTj9qFLSSXlPCZ mHRRFx3b2l3J8cbNjE+4fUgfljdtp9vTzOiYG/5WipJmMGu7s5b8ypc5dubPCLwE6+MwaELo9rbS 7qxDoxgZG3MTebY7MerC+4y1dxSxr3oNGkXC6WnF3nGKCFMcFn0MXlVFrxhp6ipjW9kz/Mv040SY Rv6t5C+Kbk8rXxy7izExN3LD2HcC9u9OP0V+xXoijGmkRlwJgMN1ho3F/8S05Af/Vwurtm0/G4+s 4mzncaIto1AkLQXVb6JXLKya9B2RpvQLjj9xdgufFN+NzZo35D73Vr9Gdete0qPm9Tl4fw0GCKvI /gFfHn+QaHM680b9J8mhU0GS8KluFFmPKjycPPs1u06/QGHtOuZmPM+oqOsD47NibyYr9mYAypu2 sXrPHGalPMqExJWBPs1dp0i05hEaNBwAIQSSJAXaPaoTba/TJISKT3WjUQY7YQKPrwutYhrQYtSG ExecQ1XrbryqC42sx+PrpLIlH0mC8ubtAWHVOw7j9nkYFjq1z7pe1Yki65D7n0EhoIezKnzIkoJA RUIOdPGqzh7HSPSHV3UiIaPIun7TqkiS3DOvt8+6rd1VrD+wAK1i4I7cfOKCcwA421nKvpo1KP2i v0ftRkbps4bU8yOE2sPDhSJpkCQl0EeWNEgSCNR+nF2AGDTSubwd6BRTgHufr/VDxfNsL3uS6zJe Ylz8bdS0FfBR8TLqOw7iUz0osp4k6xRmpT3Cr3J/YE/Va3x8eDkzhpcyffiDAxYTgRu2701b3bqb w/UbSA2fjc/n5t0D8xkdsxCXt4PD9g9xeBpJsuYyPfn3FJ/5mOMNm+n2tJEaMZO56S+h1wQDUFD9 Bvtr1uJRHWhlMxMTVzA+4XbOOVKSZJLDrmBn+XM0d50iypxBveMIDncDscHJlDdtC4iiouV7TFoL 8SHjcbjq2V72OJWt+Xh8DmRJT3rUtcxKfQSdYmF/zVuUNGxiYuIqdpQ/Q7A+kkVj3+ODokWkhf8D WsVAYe07tDkrsegTuGbksySFXg6AveMQ28ueoKnrBCBhC8llTtrjmPUxVLTs4usTD3FFyr+yp+p1 2l3VLLtsKyZdBAB7q16luauGX+XtCIgKIMI0kqtHPtvj4Ha+O/U0J85uxeVtB2SSw6YxJ+0JLPrY HuFAdVsB31c8R3XrPrSKiUm2VeQm3hUQRu/D0NpdybayR6lrPwAIIk2jmJ32KJGmdHzCQ1Hde7Q5 q9FrgsmOuwWjNuL88TpY+zbbyx5lybhPGRd/G7tOP8uafddg0cewaOx7rJq0i4Vj1uJVXbz64yQq W/LJtd3J0sv+zK7T/0F+xfMDhDUUGjqPUdKwGae3zR9BWn9gS+kfaOg8Sm7SXaRHXk1h7Ue8c2A+ na4zTB12P6nhM8ivWMvJs1sB2HnqKTYd+zXjE5ZzU9YGMqMX8EnxSg7VvdtnreSw6XhUldr2fYA/ f7AabExK/CV17cW0dlcAUNG8i9jgbIzaMOo6DlLVWsDkpHuZn/k6GVFz+ebkH9lb9bqfv+MoRfYv 2FzyG2IsmWTFLkYVXmrb9rPlxEOUNn5JTtxipgy7j5q2/ewofwyARkcJbxXMRkJi4Zh1zE1/kZNN 3/Dh4cUI4aOlu4LSs/lsLF6OTjExIWEFOsXsP5rCR1nTN0SZbdiseUN+25buCo43fsW4+NuYn7ma iYkr2VP1J7adfCQgGBXYXfUKsZYcrhr5DKFBiXxy+F4O13/QZy4ZhU73Wdbsv4pGRynzM19jQeab tHRXsL7wOpzeNtq6K+l0N1LTVoDL205tWyHQE7EaHSVsKrmb6zPfYHjYFRyu38C35U+xdNwmksOm U1izhj1Vb5ASPo0bs95l28l/49Mjy7lrciHJodO4JecT3i68hlhLDsPDZ15UWLKkQZYUzgVmIQRj 437B9ZlvApAafiUF1W+SE7+EOWlPAhAXchkFNW/j8nXg9Laxs/wp8pLuYGLiKgCizaM5dmYje6tX kx13K+dOXKwlB7POSEXL9+TELaXs7NfYrLlkRM3ny9LfUdW2G4s+DnvHISYn/QaAERFXMyLi6gDf lLBZ7K99i7r2g37XSApaReKWnM+IsYwB/JFCCB+Z0dexaOz7gbHF9g20u+wA/FD5AqCyaOx6tIoR gDlpj/HBods423UCjaxHAuZmvDwgcXb7unC4z2DRx6JcIO+JsYzl3imHAn+nhs+hyP4+9o7zNiFg XsarpPT4akTEVdS1j6SwZg1ZsbcEYpUi6zhYt47GzuP8dloZYcYUAOZmvMgr+ZM51bSdlPBZeFUX 8SET8KrdmPXRQI+wOt2N5NnuISt2MV7VxbflTzAn7XGSw6azueRejjVsJjP6eraU/p6mzpPMTH2E A3VrqW7dQ0r4bByuerSKEb02eMgNXxgCpde9rQoPEhI6OShg86keJECRdDR1leH0dnK6eSfvHJgX yG3Odp3Goo9EVX3Isv+WN+ujA3lWh8uOveMQExJXEmEcQVhQAuVN24k0ptPlaWN42IyetdwU2T+g tPErfKoTncaMy+vslQcKFEka8HARCHQ9gjkPCRkZVXixtx9EFSobim7q4SzR4aoHoMvdHMjPTPqB rztF1qDIeryqG39qMTBvO8fiWMMmjtZ/itPbSpA2hDZnHWHG5F6M6MNTrwkmxjKGlu7TvXpICATV rQXIkpYvSu7puSYl3N4OANpddeg1IeTEL6W5swyTLopoi//1rQEYFjaNYWHTAGjuKqPb3cyYmBtx eTsorv+IxdkbSQqdQlrEHA7bNyBLWoK0Vryqk6NnPuWzo79k4Zh1xAePH2KzPwUDKx5i8CoIQvhQ BSSFTmV42AzO1eLGx68gJCgBWT6fiEpIJIfN4IeKP1Jc/yGq8GKz5iFJMsNCp1HVkk+IPgGTLoxY SxYAW048yO7K1cxMeYho8ygc7kaO1H82gOK5BPincAaBT3iw6KMYF78sMFaSFK5UTMQHj+PomYoh 59XIQUSa0jnVvAuHqx6LPm7QVXZXvsKmkvu5fNg9ZETNxaM6KWvaQX/y/XlKkow0QKwCVXjQa4xk xy1BkbUg/H2nJv+OhJDLALAabFgNtr58+xNzetvQKHoMGgsgoZENtDmrgCmBK6Kq9UfanXYO1K6n oiWfhWPWkhn9j0N80J8XqvASFpSMXqMDoZIZ/YtBevX9aMmh09lZ/u98f/oFosyZWA1JAKSFX0mR fQMFNX/CZs3FoA3Fqzoprv+QUdFzmZnqz0uEUNlW9vAFRHNhCASypCXKPIrSxq2khs9Br7EM0m+g oHojJ24pRfav2Fu1mtlpT/Rpq2jZhdWQRHH9x8QFZ3Jt+ouBth8rXkIIX5/+vcsIbl8nde1F2KwT A0xAICETa8mhuP5z4oPH/VWloQHCMuui8ficdLjqCTOmcHnyA3x+7F7aXfXYrJOwdxTxzYmHcbib cHrbWT5ha5/iY2/4ywT+53hvqMKLT/UFNuBTPajCe34cAp+q9rP55/Kqboy6SCbb7mbn6RcwaK2k hM/G5e1gb9UbRJpTuTb95T7rxQZnE6QLw95RTVbsjYGntS00D1mSaXTYmZZ8PwCKpCXCNJLypl2U NX2DURvBwdp1tHQ3BRzv56/2E5rAp7r7cAbwCQ8+4QFgStL9HKn/gnWF1zI1+Z8xaEI41bSD441f sGLCt/7+6uARC2B0zEKmJG3l65NP0tJdQUb0fBBwvHEz+6rfZtn4z4kNzmJ35ZsU139MpGkkJQ2b qGkvIjEkp4e7D68K35Y/Sa7tLhRJS37ly7Q7G8i13dPD2YtP9fMel7CMgpq3eOfAAmalPkywIYHa tkL21bzForHrh6yFDRCWNSiJYEMcx858xuXJD5BnuxujNow9laspqHodRdaRET2f7NibSQmfPeik 52DRx5IUOpYI04g+9nBjGrbQiWgVE7KkkBQ6JZAEAxiUYGzWCYT3GmfWRZEUmoPVkAjAlSOexmKI o7B2PYfq3keWNESbx5Adu2QAD5Mukpy4JZQ2bmdM7I0Be2hQCtmxt1LTfoj0yHmA/2qal/Eqfzn+ AJ8duQOjLpyMyLlkxy0gyjQK8D8UkkLzMGjO55SKrCchZCIx5qw+ayeGTMTtcwCChJAJrJiwhW/L n2Zzya+RJRmjNpIJiSvRaSxYg4YxLDSL4CGuOVnSsGD0f2GzTqawdi1/KbkPSZIIDUphcfa7pEfO JT5kPJ3uJraUPohBayU1fBYTE5Yj8AX8mxE9jUjTSL4q/S3dnlaMukiWjPuQ1B5/RpkzUVUvEhJW g43bJ2xl28nH2HriD/78TBPMmJgbBvi1N6Se/KRPjC+yv8/mknu4M28/oUHnkz6PrxuNrOtTTLsY VOEZ9N82vYt/QvgGzHmuvjT4mPPJqxAqbl8niqy7aJXYJ9wokm6AvX8h8hzcXgeKrOspMIqemmjf oujFOAsECNGrPuSHx9fVk+z3LewOxWUwuH2dSEiBF2b/NhklUFT2c/Mn3+ceO6rw4fF1o9eYB3AW Qh2wF6/qRFW96DQmhn48ACANKiwhVD45soya1v0svexzwo1pP2mjl3AJPRhcWAA+1cXnx+6kpOFL pibfR3bsrQQbBg/Rl3AJ/TC0sM7hyJmN7Dr1HB2uWkKChjM6+jouH/bA/xzFS/i/iIsLyw+Bvb2I U83fodcYGZ+w8sLdL+H/OwLCuoRL+Fnx31jyHIjV3M1tAAAAAElFTkSuQmCC --_004_CD709A558415Brichardboldytwcablecom_-- From matthew.bocci@alcatel-lucent.com Wed Mar 27 04:02:01 2013 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42F7621F90ED for ; Wed, 27 Mar 2013 04:02:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.399 X-Spam-Level: X-Spam-Status: No, score=-107.399 tagged_above=-999 required=5 tests=[BAYES_50=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gCYF09m3Nbuz for ; Wed, 27 Mar 2013 04:01:59 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 8218821F90DA for ; Wed, 27 Mar 2013 04:01:58 -0700 (PDT) Received: from us70uusmtp3.zam.alcatel-lucent.com (h135-5-2-65.lucent.com [135.5.2.65]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id r2RB1uHe016666 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 27 Mar 2013 06:01:56 -0500 (CDT) Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id r2RB1n1Z016951 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 27 Mar 2013 07:01:56 -0400 Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (135.239.2.74) by US70UWXCHHUB02.zam.alcatel-lucent.com (135.5.2.49) with Microsoft SMTP Server (TLS) id 14.2.247.3; Wed, 27 Mar 2013 07:01:51 -0400 Received: from FR711WXCHMBA05.zeu.alcatel-lucent.com ([169.254.1.233]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Wed, 27 Mar 2013 12:01:50 +0100 From: "Bocci, Matthew (Matthew)" To: "l2vpn@ietf.org" Subject: Review of draft-ietf-l2vpn-vpms-frmwk-requirements-05.txt Thread-Topic: Review of draft-ietf-l2vpn-vpms-frmwk-requirements-05.txt Thread-Index: AQHOKtp6q2q1GJc0X0qA23yxHfbKTQ== Date: Wed, 27 Mar 2013 11:01:48 +0000 Message-ID: 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: [135.239.27.41] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2013 11:02:01 -0000 Working group, I have been asked by the chairs to review draft-ietf-l2vpn-vpms-frmwk-requirements-05.txt. Please find my comments embedded below, prefixed by MB>. In summary, I think this draft needs another revision clarifying the open points in the use=20 cases, and addressing the questions below. Best regards Matthew =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D [...snip...] 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] . MB> this is an informational draft, so RFC2119 language might not be appropriate. [...snip...] 4. Use Cases 4.1. Ethernet Use Case 4.1.1. Ethernet-based multicast stream For multicast traffic delivery, there is a requirement to deliver a unidirectional P2MP service in addition to the existing P2P service. The demand is growing to provide private (P2MP native Ethernet) services, for various applications such as IP- based delivery of TV broadcasting, content delivery networks, etc. Moreover, many digital audio/video devices (e.g., MPEG-TS, HD-SDI) that support Ethernet MB> ^^^^^^^ ^^^^^^ MB> Please can you expand acronyms on first use, and provide references to MB> these. This comment applies throughout the draft. =20 interfaces are becoming available, which will make Ethernet P2MP service more common. Also there are some applications that naturally suited to static transport of VPMS. For example, MPEG-TS/IP/Ethernet in DVB-H is typically static broadcast without any signaling in the upstream direction. VPMS could be a possible solution to provide these kinds of networking connectivity over PSNs. Currently VPLS [RFC4761][RFC4762] is able to give P2MP-type replication for Ethernet traffic. Native VPLS already supports this capability via a full mesh of PWs, and an extension to optimize replication is also proposed [I-D.ietf-l2vpn-vpls-mcast] as an additional feature. However, VPLS by nature requires MAC-based learning and forwarding, which might not be needed in some cases by particular users. Generally, video distribution applications use unidirectional P2MP traffic, but may not always require any added complexity of MAC address management. In addition, VPLS is a service that essentially provides any-to-any connectivity between all CEs in a L2VPN as it emulates a LAN service. However, if only P2MP connectivity is required, the traffic between leaf nodes is not allowed. It might require extra efforts to guarantee this behavior in VPLS. And in some P2MP scenarios there no traffic from leafs to root. In these cases, VPMS is a service that provides much simpler operation. Note that VPMS provides single coverage of receiver membership; that is, there is no distinct differentiation for multiple multicast groups in one VPN. All traffic from a particular Attachment Circuit (AC) will be forwarded toward the same remote receivers, even if the destination MAC address is changed. Basically in VPMS, destination MAC addresses are not used for forwarding, which is significantly different from VPLS. If MAC-based forwarding is preferred (i.e., Kamite, et al. Expires April 25, 2013 [Page 6] Internet-Draft VPMS Framework and Requirements Oct 2012 multicast/unicast differentiation by MAC address), VPLS should be chosen rather than VPMS. 4.1.2. Ethernet-based time/frequency synchronization Nowadays there exist several solutions to provide synchronization for time and/or frequency reference by the packet-based technology of Ethernet. For example, PTPv2 (Precision Time Protocol version 2) is a time-transfer protocol defined in the IEEE 1588-2008 standard. It provides precise synchronization of packet-based networks (e.g., Ethernet). It adopts two-way time transfer approach for synchronization. Time transfer protocol may be operated in multicast or unicast mode in both directions, and it is mapped over the Ethernet/IP/UDP protocol stack. Moreover, PTPv2 telecom profile is now discussed in ITU-T that defines a set of capabilities and extensions required to support telecommunication applications. It aims at providing frequency distribution with higher level of accuracy. It allows unicast mode or the mix of unicast/multicast modes for the transmission of the PTP messages. In this aspect, VPMS might be considered as a potential packet-based infrastructure to deliver multicast messages in PTPv2 with efficient forwarding. Note, however, in PTPv2 telecom profile, multicast transport may not always be supported in all the parts of a telecom network because multicast might sometimes generate additional PDV (packet delay variation) compared to unicast. Therefore, VPMS use case and the corresponding solution for this purpose will need more study in the future (e.g., PDV issue to be checked). =20 MB> The paragraph above seems to imply that you are not sure that there MB> are requirements that VPMS can address for this use case. I think MB> you are saying that VPMS should not introduce significant PDV. Please MB> can you clarify this section? If it is clear that the requirement not MB> to exceed a certain PDV cannot be met with multicast, then doesn't that=20 MB> rule out the use of VPMS for this use case? 4.2. ATM-based Use Case 4.2.1. ATM-based multicast stream A use case of ATM-based service in VPMS could be to offer the capability for service providers to support IP multicast wholesale services over ATM in case the wholesale customer relies on ATM infrastructure. The P2MP support alleviates the constraint in terms of replication for ATM to support IP multicast services. Another use case of VPMS for ATM is for audio/video stream applications. Today many digital TV broadcasting networks adopt ATM- based distribution systems with point-to-multipoint PVPs/PVCs. The transport network supports replicating ATM cells in transit nodes to efficiently deliver programs to multiple terminals. For migrating such ATM-based networks onto IP/MPLS-based networks, VPMS is considered to be a candidate solution. MB> This section seems to deal with two scenarios. One is IP multicast, MB> where multicast replication of IP packets transported in ATM VCs is MB> required. The other is emulating native ATM multicast, where ATM cells MB> are replicated without regard to their content. The first case seems MB> to be an L3VPN multicast use case with ATM transport, because you need to=20 MB> process/replicate MB> and forward based on the IP packet header, not an L2VPN multicast use case. MB> If so, is this in scope of VPMS? Kamite, et al. Expires April 25, 2013 [Page 7] Internet-Draft VPMS Framework and Requirements Oct 2012 4.3. TDM-based Use Case 4.3.1. TDM-based multicast stream Today the existing VPWS already supports TDM emulation services (SAToP, CESoPSN or TDMoIP). It is a Layer 1 service, not Layer 2 service; however, a common architecture is being used since they are all packet-based emulations over a SP's network. VPMS is also considered to be a solution for such TDM applications that require point-to-multipoint topology. One use case is TDM-based multicast stream delivery, like video delivery. That is, data duplication is simply provided by Layer 1, without using upper layer's multicast protocols. =20 MB> Can you provide more details of this use case? Is this actually a TDM MB> service, or is it just a TDM interface and you could use e.g. ATM multicast? MB> Are there any requirements in terms of preserving the timing information MB> that would impact the solution? Also, is efficient clock distribution MB> a use case (as it is for P2MP TDM PW). 5. Reference Model The VPMS reference model is shown in Figure 1. +-----+ AC1 AC2 +-----+ | CE1 |>---+ ------------------------ +--->| CE2 | +-----+ | | VPMS A's P2MP | | +-----+ VPMS A | +------+ Connection +------+ | VPMS A Sender +->|......>...+.......... >......|>-+ Receiver | VPMS | . | VPMS | | PE1 | . | PE2 | +-<|......<.. . ....+.....<......|<-+ | +------+ . . +------+ | +-----+ | | . . | | +-----+ | CE4 |<---+ |Routed . . VPMS B's P2MP +---<| CE3 | +-----+ AC4 |Backbone. . Connection AC3 +-----+ VPMS B | . . | VPMS B Receiver | +-v-----v-+ | Sender ------| . . |------- | . VPMS. | | . PE3 . | +---------+ v v VPMS A: | | Root AC : AC1 AC5| |AC6 Leaf AC : AC2, AC5 v v VPMS B: +-----+ +-----+ Root AC : AC3 | CE5 | | CE6 | Leaf AC : AC4, AC6 +-----+ +-----+ VPMS A VPMS B =20 MB> I think 'routed backbone' correspond to 'PSN' in L2VPN and PWE3 terminology. MB> I suggest updating this terminology accordingly. Kamite, et al. Expires April 25, 2013 [Page 8] Internet-Draft VPMS Framework and Requirements Oct 2012 Receiver Receiver Figure 1: Reference Model for VPMS A VPMS instance is defined as a service entity manageable in the VPMS architecture. A single VPMS instance provides an isolated service reachability domain to each CE, so it corresponds to a so-called "VPN" as it allows communication among a specific set of sites. A single VPMS instance provides a unique point-to-multipoint L2VPN service. In Figure 1, there are two VPMS instances shown, VPMS A and VPMS B. In principle, there is no traffic exchange allowed between these different instances, so they are treated as different VPNs. In a VPMS, a single CE-PE link connection is used for transmitting frames for delivery to multiple remote CEs, with point-to-multipoint duplication. The SP's network (PE as well as P) has a role to replicate frames so that the sender's CE does not need to send multiple frames to individual receivers. Like VPWS, an Attachment Circuit (AC) is provided to accommodate CEs in a VPMS. In a VPMS, an AC attached to a VPMS MUST be configured as "root" (sender) or "leaf" (receiver) not both. Any AC is associated =20 MB> s/..not both/...,but not both =20 with the role of either sending side (Tx) or receiving side (Rx) from the view of the CE. These will be named the root (sender) AC and leaf (receiver) AC respectively. Unless reverse traffic is optionally supported, a root AC does not transmit traffic back to a CE at upstream side, likewise a leaf AC does not receive traffic from a CE at downstream side. In Figure 1, AC1 and AC3 are configured as root ACs while AC2, AC4, AC5 and AC6 are configured as leaf ACs. In VPMS A, CE1 could send traffic via AC1, and CE2 and CE5 could receive the traffic. A CE which is locally connected to a root AC is called a root (sender) CE. Also a CE which is locally connected to a leaf AC is called a leaf (receiver) CE. However, such CEs's roles will not be managed directly in VPMS because the configured AC's role (root or leaf) will automatically determine them. Similarly, a PE which locally accommodates a root AC is called a root (sender) PE. A PE which locally accommodates a leaf AC is called a leaf (receiver) PE. Root AC and leaf ACs are typically located at separate PEs as shown in Figure 1, but it is also allowed that a single PE locally has both a root AC and one or more leaf ACs. Basically there is a one-to-one mapping between an attachment circuit and a VPMS instance. For example, all traffic from CE1 to PE1 Kamite, et al. Expires April 25, 2013 [Page 9] Internet-Draft VPMS Framework and Requirements Oct 2012 (through AC1) is mapped to VPMS A (to CE2 and CE5). In a VPMS, P2MP tree-shaped reachability is given from a single root AC to several leaf ACs. This will be named a "P2MP connection" in this VPMS framework. P2MP connection is a logical entity between PE/ ACs in a given VPMS instance that transfers unidirectional traffic transparently from one local ingress AC to one or more remote egress ACs. Similar to other L2VPN mechanisms, the VPMS architecture is based on PWs which may be using through IP or MPLS-enabled PSN tunnels over a routed backbone. =20 MB> If this requires PWs, then I propose that we constrain this to PWs MB> defined by PWE3, which are MPLS PWs over an IP or MPLS PSN. That is, every P2MP connection can be instantiated by PW technology that supports P2MP traffic optimization (i.e., P2MP PW. See section 7.2.). P2MP traffic optimization will provide the benefit of traffic replication for high bandwidth efficiency. =20 MB> I think you mean that replication of packets by nodes in the PSN improves MB> bandwidth efficiency when compared with replication by the CE. =20 That is, the sender CE has only to transmit one stream towards the PE and it does not have to replicate traffic. Regarding end-to-end traffic topology between the ACs, a single VPMS instance (i.e., one VPN) may correspond to a single P2MP connection. In Figure 1, VPMS A (one instance) has one P2MP connection (from AC1 to AC2 and AC5). However, there is also a case that a single VPMS consists of two or more P2MP connections grouped, which is typically used for multi-source or redundancy. The details are given in section 6.4 and 6.5. VPMS can support various Layer 2 protocol services such as Ethernet, ATM, etc. =20 MB> I think it is worth breaking this into an explicit list of layer 2 MB> protocols that must be supported, for example: MB> VPMS must support Ethernet, ATM and TDM P2MP services. 6. Customer Requirements MB> I think these are a list of service requirements, so I suggest renaming=20 MB> section 6 accordingly. 6.1. Service Topology 6.1.1. Point-to-Multipoint Traffic Support A solution MUST support unidirectional point-to-multipoint traffic from a sender CE to multiple receiver CEs. A root CE can send traffic to one or more leaf CEs. Leaf CEs include not only the CEs which are located at remote sites, but also the local CEs which are connected to the same root PE (i.e., when a root AC and some of leaf ACs are co-located). If there is only one receiver in the instance, it is considered equivalent to unidirectional point-to-point traffic. 6.1.2. Reverse Traffic Support There are cases where a reverse traffic flow is needed. A root CE may need to receive traffic from leaf CEs. There are some usage Kamite, et al. Expires April 25, 2013 [Page 10] Internet-Draft VPMS Framework and Requirements Oct 2012 scenarios for this, such as stream monitoring through a loopback mechanism, control channels which need feedback communication etc. A possible way to accomplish this is to provide different VPMS instances for reverse traffic, i.e. a root CE is a receiver of another VPMS instance. However, provisioning different VPNs for a particular customer would make its management task more complex. It is desired to have an alternative solution for supporting reverse traffic flow. This section provides additional requirements for this optional capability. Therefore, a VPMS solution MAY support reverse traffic from a leaf AC to a root AC. Each reverse path is basically given in a P2P (unicast) manner. =20 MB> I suggest rephrasing: "Each reverse path is P2P i.e. unicast. =20 In other words, each leaf of the P2MP tree can individually send back traffic to the root. For this purpose a VPMS instance MAY have more than one reverse P2P connections as network entity; However, such network entities MUST have a common indetifier that enables themselves to be managed together in the same VPN. Thus any PWs used for such connections are expected to be assigned a common VPMS instance ID (i.e., VPN ID). Note, a VPMS does not assume any-to-any multipoint reachability. Therefore, in principle, every leaf AC does not need to exchange traffic directly with other leaf ACs even if reverse traffic is supported. =20 MB> Is there a requirement that the VPMS must not forward traffic between leaf MB> ACs? Figure 3 illustrates this kind of scenario, where CE1 is configured as a sender in VPMS A. AC1 is a root AC, and AC2/AC3/AC4 are leaf ACs. P2MP connection is given for traffic in the forward direction. Unidirectional P2P connection is also provided for traffic in the reverse direction, from AC4 to AC1. Other reverse P2P connections can be provided similarly. (from AC2 to AC1 / from AC3 to AC1). In this case, PEs need to deal with two types of traffic, locally- attached CE's sending (Tx) and receiving (Rx) flows. In Figure 3, they are both passing through the same physical PE-CE link (AC1 and AC4 respectively). But it is an implementation matter if Tx and Rx traffic are conveyed on the same physical link or separate links. It is also possible that a root PE multiplexes two ore more reverse traffic from different leaf ACs and transmits it to an upstream CE MB> ^^^^ traffic flows ^^^^^^^^^forwards the resulting flow =20 =20 =20 over the same local physical link. Note, in most implementations of VPWS today, every AC is always considered bidirectional. In contrast, in VPMS, every AC can be chosen unidirectional (if it is a totally unidirectional service), or =20 MB> I suggest removing the word 'chosen' bidirectional (if reverse traffic is supported). Kamite, et al. Expires April 25, 2013 [Page 11] Internet-Draft VPMS Framework and Requirements Oct 2012 +-----+ <-- Rx (bidirectional) | CE1 |--------------+ +-----+ --> Tx | VPMS A Sender | AC1 | +----------+ VPMS | . . | PE1 | . .... | -------| . . |-------- | P2MP +-v------^-+ | Connection . . | (forward) + . | | . . | +------+ . . . . +------+ +-<|......<.. . .. . ......>..... |>-+ | | VPMS | . . | VPMS | | AC2| | PE2 | . . | PE3 | |AC3 | +------+ . . +------+ | +-----+ | | . . P2P | | +-----+ | CE2 |<--+ | Routed . . Connection +-->| CE3 | +-----+ <-- | Backbone. . (reverse)| --> +-----+ VPMS A Rx | +-v------^-+ | Rx VPMS A Receiver -------| . . |-------- Receiver | . .... | | . . | VPMS +----------+ PE4 AC4| | | <-- Tx +-----+ +--------------------| CE4 | (bidirectional) --> Rx +-----+ VPMS A Receiver MB> Replace 'routed backbone' with PSN Figure 3: Reverse traffic support 6.2. Transparency A solution is intended to provide Layer-2 traffic transparency. Transparency SHOULD be supported per VPMS instance basis. In other words, Layer-2 traffic can be transparently transported from a local CE to remote CEs in a given instance. Note, however, if service delimiting fields (VLAN Id in Ethernet, VPI/VCI in ATM, DLCI in FR etc.) are assigned and possibly can be changed by the SP, the Layer-2 traffic is not necessarily transparent. =20 MB> does VPMS need to support FR? It will depend on the SP's choice if they assign it to each AC. Hence, it could be that some of the leaf CEs are receiving traffic that has different delimiting Kamite, et al. Expires April 25, 2013 [Page 12] Internet-Draft VPMS Framework and Requirements Oct 2012 fields than the traffic for the other leaf CEs. MB> any switched service is by definition not transparent to the L2 header. Maybe MB> you mean that the VPMS should be transparent to the L2 service to the same MB> extent that the native multicast service being emulated would be? The VPMS solution SHOULD NOT require any special packet processing by the end users (CEs). 6.3. Quality of Service (QoS) A customer may require that the VPMS service provide guaranteed QoS. In particular, for real time applications which are considered common in point-to-multipoint delivery, delay and loss sensitive traffic MUST be supported. The solution SHOULD provide native QoS techniques for service class differentiation, such as IEEE 802.1p CoS for Ethernet. For bandwidth committed services (e.g., ATM CBR (Constant Bit Rate)), a solution SHOULD guarantee end-to-end bandwidth. It MAY provide flow admission control mechanisms to achieve that. =20 MB> Flow admission is not enough on it own to guarantee bandwidth and other MB> QoS objectives. I sugget you just say 'Flow admission control mechanisms MB> may be provided'. 6.4. Multi-Source Support A VPMS solution SHOULD support multiple sources in each VPN. That is, two or more sender CEs can exist in the same VPMS instance. Each sender CE SHOULD be able to be connected to physically separate root PEs, which will facilitate flexible topology design. Additionally, traffic from sender CEs MAY have a common single coverage to receiver CEs, i.e., data from any sources can reach the same group of receivers. For example, in TV provisioning scenario, customers may need to receive two or more TV channels from different sources. In figure 3, suppose there are 7 hosts, CE1 to CE7 which belong to a given VPMS instance A. CE1, CE2 and CE3 are common sources of this VPN, and are attached to different PEs respectively. Traffic from each source can reach the same group of receivers, CE4 to CE7. This kind of scenario will require multiple P2MP connections in a single VPMS instance (i.e., VPN). Each P2MP connection's root might be a completely different CE/AC, but leaf CE/ACs are overlapped. Since this is basically the same requirement as dual-homed scenario, see section 6.5.1 for details. Kamite, et al. Expires April 25, 2013 [Page 13] Internet-Draft VPMS Framework and Requirements Oct 2012 VPMS A +-----+ +-----+ VPMS A Sender | CE1 | | CE2 | Sender +-----+ +-----+ | | +-----+ VPMS A v AC1 v AC2 | CE3 | Sender +----+ +----+ +-----+ -----|VPMS|-----|VPMS|----- \ | | PE1| | PE2| | \ | +----+ +----+ | \ | | \ AC3 +----+ +----+ +---->|VPMS| |VPMS| AC5 VPMS A | PE3| Routed | PE4|-----+ Receiver +----+ Backbone +----+ | +-----+ / | | \ +-->| CE5 | AC4 / | | \ +-----+ / | | \ AC6 +-----+ / | +----+ | \ +-----+ | CE4 |<--+ -----------|VPMS|---------- +->| CE6 | +-----+ | PE5| +-----+ VPMS A +----+ VPMS A Receiver | AC7 Receiver v +-----+ | CE7 | VPMS A +-----+ Receiver Figure 3: Multi-Source support MB> The figure numbering seems to be duplicated (Figure 3 is already shown on Pg 12) 6.5. High Availability [...snip...] 6.6. Security The basic security requirements from the view of customers are raised in section 6.5 of [RFC4665]. It also applies to VPMS. In addition, a VPMS solution MAY have the mechanisms to activate the appropriate filtering capabilities (for example, MAC/VLAN filtering etc.), and it MAY be added with the control mechanism between particular sender/receiver sites inside a VPMS instance. For example, in Figure 1, filtering can be added such that traffic from CE1 to CE4/CE5 is allowed but traffic from CE1 to CE6 is filtered. MB> But CE4 is not in the VPMS instance for which CE1 is a root, so why should MB> it receive traffic from CE1? Likewise, CE6 cannot receive traffic from CE1 ME> because it is in a different VPMS. This assumes that we can treat each MB> VPMS and its associated ACs and CEs as logically separate. The text following=20 MB> Figure 1 seems to imply that each VPMS MB> is isolated from each other VPMS. I think it would be MB> clearer if the architecture was described in that manner. That does not=20 MB> stop the physical device that hosts a CE from participating in multiple MB> VPMS instances. 6.7. Misordering Prevention A solution SHOULD prevent Layer-2 frame misordering when delivering customer traffic under normal conditions. This is often necessary for real-time based applications. =20 MB> Isn't this a general L2VPN requirement? 6.8. Failure reporting A solution MAY provide information to the customer about failures. For example, if there is a loss of connectivity toward some of the receiver CEs, it is reported to the sender CE. Kamite, et al. Expires April 25, 2013 [Page 17] Internet-Draft VPMS Framework and Requirements Oct 2012 7. Service Provider Network Requirements 7.1. Scalability [...snip....] 7.2.1. Point-to-Multipoint Pseudo Wire MB> I think this section is getting into too much detail about a candidate solution. MB> the P2MP PW requirements draft should reference this draft, but not the other MB> was around. I suggest removing this section. Regarding PW mechanism, [I-D.ietf-pwe3-p2mp-pw-requirements] introduces P2MP PW concept and its requirements, showing two basic approaches of providing replication. One is SS (Single Segment)-PW model that provides replication by PSN tunnel such as P2MP LSP (i.e., by outer label layer), and the other is MS (Multi Segment)-PW model Kamite, et al. Expires April 25, 2013 [Page 18] Internet-Draft VPMS Framework and Requirements Oct 2012 that provides replication by multiple interconnected PWs (i.e., by inner label layer). In either case, end-to-end P2MP topology (i.e., P2MP connection) in VPMS is common from the view of ACs. Requirements as a provider service specified in this document will be commonly applied regardless of P2MP PW's model. It is out of scope of this document how to extend and use PW mechanisms to realize P2MP connections as a solution. For example, it is under the scope of the solution work how to support forward/ reverse traffic by a single PW signaling, coupling multiple PWs, or other ways. 7.2.2. PSN Tunneling Today, there are several standardized PSN tunneling schemes and their control plane protocols that support efficient multicast data replication in MPLS, such as P2MP RSVP-TE [RFC4875] and MLDP [RFC6388]. In general, this document does not restrict which control plane protocols should be mandatory. There is no mandatory limitation either, about a particular type of data replication topology in PSN tunneling (point-to-point, point-to-multipoint and multipoint-to- multipoint). In VPMS, the preferred type of PSN tunneling will depend on each deployment scenario. (e.g., which control plane protocol is available in the core and how much of the network resources that operators will want to optimize). The detailed mechanism needs to be specified by solution work. 7.2.3. Static Solution VPMS solution MAY support static provisioning for PWs and/or PSN tunneling. Due to some operational reasons, there is a scenario where control plane protocol is not used between PSN nodes. In this case, operators will need to have a different method to set up PWs and/or PSN tunnels (e.g., by manual configuration or other outband interfaces). MB> I think this requirement should be in the P2MP PW requirements, not in this MB> draft. 7.3. Auto-discovery A solution SHOULD support auto-discovery methods that dynamically allow VPMS related information to be discovered by the PEs to minimize the amount of configuration the SP must perform. All of the requirements on discovery described in Section 7.3 of [RFC4665] SHOULD be satisfied in VPMS as well. Kamite, et al. Expires April 25, 2013 [Page 19] Internet-Draft VPMS Framework and Requirements Oct 2012 Auto-discovery will help operators' initial configuration of adding a new VPN (i.e., VPMS instance), adding/deleting new sender/receiver, and so on. The candidate information treated in auto-discovery will be as follows: MB> I suggest rephrasing to 'VPMS Auto-discovery requires the following information': - Information to indentify the location of each PE, e.g., PE router ID / IP address - Information to identify the VPMS instance, that is, to identify a VPN - Information to identify the type of ACs (root AC or leaf AC) - Information to identify the P2MP connection that binds ACs - Information to show if reverse traffic support is optionally desired - SP-related information (AS number, etc. for an inter-provider case) Following is an example scenario about adding a new leaf PE: suppose there are three PEs in an existing VPMS, PE1, PE2, PE3. PE1 is a root PE and has a AC1. PE2 and PE3 are leaf PEs and have AC2 and AC3. every PE has the association among the information described above. Now a new PE4 having an AC4 is provisioned in the existing VPMS instance and this AC is configured as leaf. This information will be automatically discovered by the other existing remote PEs (i.e., ingress and egress PEs in the same VPMS instance). Once the ingress PE1 discovers this new PE/AC, it can automatically add AC4 as the new leaf of P2MP connection topology according to P2MP PW signaling mechanism. The ingress PE1 will graft a new leaf (PE4) to the already existing P2MP connection which is now created from AC1 to AC2/AC3/AC4. This operation does not require any new configuration at the existing PEs. Another example is about adding a new root PE: suppose there are one root PE (PE1/AC1) and three leaf PEs (PE2/AC2, PE3/AC3 and PE4/AC4). There is an existing P2MP connection from AC1 to AC2/AC3/AC4. Now the operator adds a new root PE/AC (PE5/AC5) for some reasons (e.g., multiple source sites, dual-homed access, root PE redundancy etc.). Then, auto-discovery mechanism advertises this information to all other members PE1/PE2/PE3/PE4, and a new P2MP connection from AC5 to AC2/AC3/AC4 is created by PW signaling. Note that VPMS instance is created when one root AC and at least one leaf AC are added. In principle VPMS requires such minimum provisioning. Hence in dual-homing case of sender, only backup root PE can be dynamically added/deleted to/from VPMS without destroying the VPN. Kamite, et al. Expires April 25, 2013 [Page 20] Internet-Draft VPMS Framework and Requirements Oct 2012 7.4. Activation and Deactivation [...snip....] 7.7. Operation, Administration and Maintenance 7.7.1. Fault Management 7.7.1.1. Fault Detection A solution MUST provide tools that detect reachability failure and traffic looping of data transport in a VPMS instance. If multiple root ACs are supported (i.e., multiple P2MP connections are grouped together into a single VPMS instance), such tools MUST be able to perform distinguishing each P2MP connection. ^^^^^^^^^^^^^^^^^^^^^^ MB> s/perform distinguishing / distinguish 7.7.1.2. Fault Notification [...snipped to end...]=20 From internet-drafts@ietf.org Sun Mar 31 14:25:35 2013 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55BAA21F8506; Sun, 31 Mar 2013 14:25:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.001 X-Spam-Level: X-Spam-Status: No, score=-100.001 tagged_above=-999 required=5 tests=[NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xg2LW7+h9mJN; Sun, 31 Mar 2013 14:25:34 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C68FA21F8439; Sun, 31 Mar 2013 14:25:34 -0700 (PDT) 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-macflush-ld-03.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.43 Message-ID: <20130331212534.24383.71293.idtracker@ietfa.amsl.com> Date: Sun, 31 Mar 2013 14:25:34 -0700 Cc: l2vpn@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Mar 2013 21:25:35 -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 : MAC Flush Loop Detection in VPLS Author(s) : Paul Kwok Pranjal Kumar Dutta Filename : draft-ietf-l2vpn-vpls-macflush-ld-03.txt Pages : 14 Date : 2013-03-31 Abstract: MAC Address Withdrawal is a mechanism described in [RFC4762] to remove or unlearn MAC addresses that have been dynamically learned in a VPLS instance, for faster convergence on topology change. Failure of mechanisms that control loop free connectivity among VPLS PE-rs nodes may cause MAC Address Withdrawal messages looping among those nodes, leading to Denial of Service (DoS) or complete failure of control plane in the PE-rs nodes. This document describes a mechanism to detect and prevent loops of MAC Address Withdrawal messages in a VPLS PE-rs node on such failures. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-l2vpn-vpls-macflush-ld There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-l2vpn-vpls-macflush-ld-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-l2vpn-vpls-macflush-ld-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/