From nobody Thu Dec 1 01:43:08 2016 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A0E212954B for ; Thu, 1 Dec 2016 01:43:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.43 X-Spam-Level: X-Spam-Status: No, score=-6.43 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.896, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2P1EZIy4MsLU for ; Thu, 1 Dec 2016 01:43:04 -0800 (PST) Received: from r-mail2.rd.orange.com (r-mail2.rd.orange.com [217.108.152.42]) by ietfa.amsl.com (Postfix) with ESMTP id 06F9E1295C2 for ; Thu, 1 Dec 2016 01:43:04 -0800 (PST) Received: from r-mail2.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id AFB225D85F6 for ; Thu, 1 Dec 2016 10:43:02 +0100 (CET) Received: from FTRDCH01.rd.francetelecom.fr (unknown [10.194.32.11]) by r-mail2.rd.orange.com (Postfix) with ESMTP id A92295D83DB for ; Thu, 1 Dec 2016 10:43:02 +0100 (CET) Received: from [10.193.71.12] (10.193.71.12) by FTRDCH01.rd.francetelecom.fr (10.194.32.11) with Microsoft SMTP Server id 14.3.301.0; Thu, 1 Dec 2016 10:43:02 +0100 To: References: <148054658618.9666.7845242632844754641.idtracker@ietfa.amsl.com> From: Thomas Morin Organization: Orange Message-ID: <0a547035-8dd4-b969-e8f3-3e1dd69965cd@orange.com> Date: Thu, 1 Dec 2016 10:43:02 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.0 MIME-Version: 1.0 In-Reply-To: <148054658618.9666.7845242632844754641.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [bess] WGLC on one addition in draft-ietf-bess-evpn-overlay-07 X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2016 09:43:06 -0000 Hi working group, draft-ietf-bess-evpn-overlay-07 has just been published with a new section on "Unknown Unicast Traffic Designation". This email starts a one week Last Call, for comments specific to this new section, to close on December 8th. Thanks, -Thomas internet-drafts@ietf.org : > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the BGP Enabled ServiceS of the IETF. > > Title : A Network Virtualization Overlay Solution using EVPN > Authors : Ali Sajassi > John Drake > Nabil Bitar > R. Shekhar > James Uttaro > Wim Henderickx > Filename : draft-ietf-bess-evpn-overlay-07.txt > Pages : 28 > Date : 2016-11-30 > > Abstract: > This document describes how Ethernet VPN (EVPN) [RFC7432] can be used > as an Network Virtualization Overlay (NVO) solution and explores the > various tunnel encapsulation options over IP and their impact on the > EVPN control-plane and procedures. In particular, the following > encapsulation options are analyzed: VXLAN, NVGRE, and MPLS over GRE. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-overlay/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-bess-evpn-overlay-07 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-evpn-overlay-07 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Dec 1 07:57:56 2016 Return-Path: X-Original-To: bess@ietf.org Delivered-To: bess@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4806C1293F5; Thu, 1 Dec 2016 07:57:50 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.39.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148060787025.10357.10589592636378029693.idtracker@ietfa.amsl.com> Date: Thu, 01 Dec 2016 07:57:50 -0800 Archived-At: Cc: bess@ietf.org Subject: [bess] I-D Action: draft-ietf-bess-l2l3-vpn-mcast-mib-05.txt X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.17 List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2016 15:57:50 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the BGP Enabled ServiceS of the IETF. Title : L2L3 VPN Multicast MIB Authors : Zhaohui (Jeffrey) Zhang Hiroshi Tsunoda Filename : draft-ietf-bess-l2l3-vpn-mcast-mib-05.txt Pages : 10 Date : 2016-11-30 Abstract: This memo defines a portion of the Management Information Base for use with network management protocols in the Internet community. In particular, it describes common managed objects used by other MIB modules which are designed for monitoring and/or configuring both L2 and L3 VPN Multicast. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bess-l2l3-vpn-mcast-mib/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-bess-l2l3-vpn-mcast-mib-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-l2l3-vpn-mcast-mib-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Dec 1 19:13:42 2016 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EB90129A7B for ; Thu, 1 Dec 2016 19:13:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ieee-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SaeuwB5RL5X7 for ; Thu, 1 Dec 2016 19:13:34 -0800 (PST) Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF001129A75 for ; Thu, 1 Dec 2016 19:13:33 -0800 (PST) Received: by mail-qt0-x22d.google.com with SMTP id w33so240253625qtc.3 for ; Thu, 01 Dec 2016 19:13:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ieee-org.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=rkGyqgvM87BzqXyefJY/oHGdDN5mJyDZgTTZ+Kiwk14=; b=mPHw9ZcfmY3Np8lUxKQskWFyu2BZX+RgtXZmAmvu/14mdWRP/T2JrN9/6pCnTDh7jl xHeqBbQdQdcw/J6v39zjfnzLwHH2S4LmMAZy1MrAW5ziE3+60nKlkphPBwhG0T99UgU3 PXDRTQAEqDXs+8fM7dEFyog51GbmMbuZy7tmmuKUYELmm2Jt3fS0o2mBihKXroHU+d9L gJAgUsz/b2bRUNjR8VCNg9V4eF7a7IlD2lm/EDdBM/9oPYyyT0dSqZM9J1+LL73GE3SH pky7Ymnlw4dIZ+OhA4KPoUCJJ9qC8DKV0RvxUuhHLbomHXLsWKAYlPpedFLo2AjZI/8h HayA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=rkGyqgvM87BzqXyefJY/oHGdDN5mJyDZgTTZ+Kiwk14=; b=i8ZgyYlFx8jGLGkSdLXwTmD3OYQr4zzfzr7x1/q/OVl+ekwB13ay3MeBA2tFVgFRFX q4PRV4GWehok8N1snyip/JgpND/kTzHC0Jcxd0gleaRBj5D6xkkCKlec2uqK4JucFas5 xGdCw+aSopQfLc5yc1MYApcVPAvsmY+4pFtJj7yKVIdqeINAe2wOSebrUnVqUzHYB+wg lwC0XIBrTj1KM11cfBeN5DuOLlZKMSnH/8HzRaEejoRpJqvhVX68L7dktTGwow1RXQ/v qEE2/+kZw+zW0wvpq4slUA2bbx9nDJUvw79fxS/JBgOYH22ATVrZhqTNO9DH5YHZ8d47 nixw== X-Gm-Message-State: AKaTC01IaU3SNrePwRM49hetRchcuRjFN8ExJVTLadDr1jmTaJXZjgbTaTcqYJWoDYkj3ATF7wsiTYYi5WedDp/a X-Received: by 10.200.39.83 with SMTP id h19mr35721585qth.290.1480648412284; Thu, 01 Dec 2016 19:13:32 -0800 (PST) MIME-Version: 1.0 Sender: dr.h.t@ieee.org Received: by 10.140.39.50 with HTTP; Thu, 1 Dec 2016 19:12:51 -0800 (PST) In-Reply-To: References: <56E7D219.7000902@orange.com> <56FBD402.9040102@cisco.com> <56FBDD81.6080502@cysols.com> <11152_1459347064_56FBDE78_11152_10229_1_56FBDE77.6030605@orange.com> <56FBE17E.5090609@cisco.com> <570C9586.7030905@cysols.com> From: Hiroshi Tsunoda Date: Fri, 2 Dec 2016 12:12:51 +0900 X-Google-Sender-Auth: z7-qC9LsXvOG5tMT7NdWhdg9hZc Message-ID: To: Glenn Mansfield Keeni Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Mach Chen , "mib-doctors@ietf.org" , "Jeffrey \(Zhaohui\) Zhang" , "ops-ads@ietf.org" , Benoit Claise , "EXT - thomas.morin@orange.com" , Martin Vigoureux , "bess@ietf.org" Subject: Re: [bess] MIBDoc review of draft-ietf-bess-l2l3-vpn-mcast-mib-04.txt X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2016 03:13:40 -0000 Dear Glenn, Thanks for your careful review and detailed comments/suggestions. I have started to volunteer to help to move this document forward. I posted a new revision and addressed all editorial things in that revision. Please give me some more time for revising other parts, in order to be familiar with the context of the original and related documents. URL: https://www.ietf.org/id/draft-ietf-bess-l2l3-vpn-mcast-mib-05.txt Status: https://datatracker.ietf.org/doc/draft-ietf-bess-l2l3-vpn-mcast-mib/ Htmlized: https://tools.ietf.org/html/draft-ietf-bess-l2l3-vpn-mcast-mib-05 Diff: https://tools.ietf.org/rfcdiff?url2=draft-ietf-bess-l2l3-vpn-mcast-mib-05.txt Please see some notes below. > 0. Abstract. > 0.1. > > it describes common managed objects used to configure > and/or monitor both L2 and L3 VPN Multicast. > > There are no writable MOs in this MIB. So it does not look > as though this MIB will be used for configuration directly. > The use case scenario for monitoring is not clear, either. > It appears that the MIB module(s) in this document will be > used by other modules which are designed for monitoring and/ > or configuring L2 and L3 VPN Multicast. Please re-examine the > wording. Fixed. > 1. Introduction > > 1.1 > Would be very nice if a short explanations of MVPN and > L2 VPN Multicast were given. With emphasis on the operational > aspects. TBD. Please give me some more time to revise. > 1.2 > s/referred to MVPN and L2 VPN Multicast respectively/ > referred to as MVPN and L2 VPN Multicast,respectively/ Fixed. > 1.3 > s/MVPN [RFC6513] [RFC6514]/MVPN [RFC6513],[RFC6514]/. Fixed. > 1.4 .... there are 2 types of PMSIs .. > > > o I-PMSI: Inclusive PMSI - to all PEs in the same VPN. > > o S-PMSI: Selective PMSI - to some of the PEs in the same VPN. > > please make these explanations more gentle(complete) to the reader. > Also, give the references where these terms are defined. TBD. Please give me some more time to revise. > 3. Summary of MIB Module > 3.1 > > Attributes (PTAs) advertised/received in I/S-PSMI Auto-Discovery > Typo: I/S-PMSI, (see 3.3 below). Fixed. > 3.2 some more text like the following will be good. > L2L3-VPN-MCAST-MIB contains > o a Textual Convention L2L3VpnMcastProviderTunnelType that provides > an enumeration of the provider tunnel types and, > o a table l2L3VpnMcastPmsiTunnelAttributeTable. The table index is > composed of multiple attributes that depend on the tunnel type and > uniquely identify a tunnel. This table will be used to ... monitor > the tunnels supported by the system at a given point of time (?) > It may also be used in conjunction with XXXX-mib to obtain the > other details of a tunnel by following the row pointer of the > corresponding tunnel's row in this table. > [ Please treat the above as a template and modify the text as > appropriate ..] TBD. Please give me some more time to revise this point. > 3.3 Since this will become a standard document, please take care of > definitions and notations used in the document. > The notation I/S-PMSI is not defined. If you must use a new > term/notation, define it before use. TBD. Please give me some more time to revise this point. > 4. Definitions > > > IMPORTS > > MODULE-IDENTITY, OBJECT-TYPE, experimental > 4.1 Since this is not a Experimental MIB do not import use experimental. > It is good practice to keep the draft in the as "close to final form" > as possible. (See below) Fixed. > 4.2 > > LAST-UPDATED "201310141200Z" -- October 14, 2013 > Please update this date. Updated. > 4.3 > > DESCRIPTION > > "This MIB contains common managed object definitions for > > multicast in Layer 2 and Layer 3 VPNs, defined by > > [RFC7117] and [RFC6513] [RFC6514] respectively. > Would be good if you could rearrange the text. Something like > "This MIB module will be used for managing multicast in Layer 2 > VPNs [RFC7117] and Layer 3 VPNs [RFC6513], [RFC6514]. > Or, even better > "This MIB module will be used by other MIB modules designed for > managing multicast in Layer 2 VPNs [RFC7117] and Layer 3 VPNs > [RFC6513], [RFC6514] > Or, a combination of both, depending on the envisaged use case > scenarios. Rearranged the text along with your comment. > 4.4 > > ::= { experimental 999 } > Please > o Replace "experimental" by the branch where this mib module will > be anchored; that is a decision that the WG will take, probably. > o Import the branch in the IMPORTS statement > [ In the IANA Considerations section a branch in the mib-2 subtree > is requested. In that case this must be > ::= { mib-2 XXX } > ] Fixed. > 4.5 > > -- Please also remove the ", experimental" text from earlier > > -- IMPORTS section. > Remove these instructions. Removed. > 4.5.2 > > -- Texual convention > Typo: -- Textual convention Fixed. > 4.6 > > L2L3VpnMcastProviderTunnelType ::= TEXTUAL-CONVENTION > > DESCRIPTION > > "Types of provider tunnels used for multicast in > > BGP/MPLS L2 or L3 VPN. Additional types may be defined > > in future RFCs, and those will be allowed as > > valid types for L2L3VpnMcastProviderTunnelType." > The part > > Additional types may be defined > > in future RFCs, and those will be allowed as > > valid types for L2L3VpnMcastProviderTunnelType." > may be deleted. Deleted. > 4.7 > > -- Top level components of this MIB. > > -- tables, scalars, conformance information > > > > l2L3VpnMcastObjects OBJECT IDENTIFIER ::= { l2L3VpnMcastMIB 1 } > > l2L3VpnMcastConformance OBJECT IDENTIFIER ::= { l2L3VpnMcastMIB 2 } > l2L3VpnMcastStates OBJECT IDENTIFIER ::= { l2L3VpnMcastObjects 1 } > > > > -- Table of PMSI Tunnel Attributes > > > > l2L3VpnMcastPmsiTunnelAttributeTable OBJECT-TYPE > > should be > > -- Top level components of this MIB. > > l2L3VpnMcastObjects OBJECT IDENTIFIER ::= { l2L3VpnMcastMIB 1 } > l2L3VpnMcastConformance OBJECT IDENTIFIER ::= { l2L3VpnMcastMIB 2 } > l2L3VpnMcastStates OBJECT IDENTIFIER ::= { l2L3VpnMcastObjects 1 } > > -- tables, scalars, conformance information > -- Table of PMSI Tunnel Attributes > > l2L3VpnMcastPmsiTunnelAttributeTable OBJECT-TYPE Fixed. > 4.8 > > l2L3VpnMcastPmsiTunnelAttributeTable OBJECT-TYPE > > SYNTAX SEQUENCE OF L2L3VpnMcastPmsiTunnelAttributeEntry > > MAX-ACCESS not-accessible > > STATUS current > > DESCRIPTION > > "This table is for PMSI Tunnel Attributes (PTAs) > > advertised/received in I/S-PSMI Auto-Discovery routes. > > The entries may be referred to by I-PMSI or S-PMSI table > > entries defined in other MIBs, e.g. mvpnMIB in > > [I-D.ietf-bess-mvpn-mib]." > > It would seem that each row in this table is an index for a PTA > and may contain pointers to rows in tables of other MIB modules > which may contain more details for the PTA. Is that correct? > Please reword the DESCRIPTION acordingly. > Also see comments in 4.15 TBD. I need some more time to understand the original context. > 4.9 > > l2L3VpnMcastPmsiTunnelAttributeEntry OBJECT-TYPE > > "An entry in this table corresponds to a PTA > > that is advertised/received on this router. > We are in the description of "l2L3VpnMcastPmsiTunnelAttributeEntry" > so "entry in this table" does not fit in well. > A rewording like > "A conceptual row corresponding to a PTA > that is advertised/received on this router. > .... > would be better. Fixed. > 4.10 > > For BGP-based signaling (for I-PMSI via auto-discovery > > procedure, or for S-PMSI via S-PMSI A-D routes), > > they are just as signaled by BGP. > > For UDP-based S-PMSI signaling for PIM-MVPN, > > they're derived from the S-PMSI Join Message. > > > Note that BGP-based signaling may be used for > > PIM-MVPN as well." > Is the signaling mechanism important here? If it isn't then the > above part of the description is redundant. Removed the above part. > 4.10-2 > PIM-MVPN appears for the first time. Defined the notation of PIM-MVPM as follows Protocol Independent Multicast - MVPN (PIM-MVPN) However, I think that some descriptions may be required for this somewhere in this document. That is TBD. > 4.10-3 > the phrase UDP-based S-PMSI appears here for the first time. > Somewhere earlier it should be made clear that UDP too may be used > in signaling. TBD. > 4.11 > l2L3VpnMcastPmsiTunnelAttributeFlags OBJECT-TYPE > > "For UDP-based S-PMSI signaling for PIM-MVPN, this is 0. > "this" is unclear. > Something like "the value of this object is 0" will be better. Fixed. > > More bits may be defined in the future and > > they will be registered in IANA Registry xxxx." > This part is probably redundant. Removed. > 4.12 > > -- RFC Ed. replace xxxx with the actual registry name > > -- that is being created via [I-D.ietf-bess-mvpn-mib] > > -- and remove this note. > > Look at the comments in 6.0 The above description ("IANA Registry xxxx.") was removed, thus this part was also removed. > 4.13 > l2L3VpnMcastPmsiTunnelAttributeType OBJECT-TYPE > > DESCRIPTION > > "As defined for L2L3VpnMcastProviderTunnelType. > > For UDP-based S-PMSI signaling for PIM-MVPN, > > this is pim-asm (3), pim-ssm (4), or pim-bidir (5). > > For BGP-based I/S-PMSI signaling, this is the Tunnel Type > > field in PMSI Tunnel Attribute of the corresponding > > I/S-PMSI A-D or Leaf A-D route." > o Does this description cover all the types? If not, then cover all the > types unless there is a good reason to focus only on the above types. > o I/S-PMSI: unexplained notation. TBD. Please give me some more time to address this point. > 4.14 > > l2L3VpnMcastPmsiTunnelAttributeId OBJECT-TYPE > > SYNTAX OCTET STRING ( SIZE (0|4|8|12|17|24|29) ) > It appears that you also allow sizes "16" and "32"; these must be included. Fixed. > > IPv4/IPv6 l2L3VpnMcastPmsiTunnelAttributeType > Please indicate that the first column gives the size I made a change as follows. Size l2L3VpnMcastPmsiTunnelAttributeType (IPv4/IPv6) -------------------------------------------------- (snip) 8/32 pimAsm (snip) Is this OK? > > 8/32 pimAsm > > 8/32 pimSsm > > 8/32 pimBidir > > 4/16 ingressReplication > > > For UDP-based S-PMSI signaling for PIM-MVPN, the first > > 8 or 32 octets of this attribute are filled with > > the provider tunnel (source, group) IPv4/IPv6 addresses. > > For BGP-based I/S-PMSI signaling, this is the Tunnel > > Identifier field in PMSI Tunnel Attribute of the > > corresponding I/S-PMSI A-D route." > > A more generous description of the AttributeID would be good. All the > cases must be covered. Section 5 of RFC 6514 does it nicely. A simple > summary would be very nice. TBD. Please give me some more time to revise this point. > 4.15 > l2L3VpnMcastPmsiTunnelPointer OBJECT-TYPE > > SYNTAX RowPointer > > DESCRIPTION > > "If the tunnel exists in some MIB table, e.g. mplsTunnelTable > > [RFC3812], this is the row pointer to it. Otherwise, the > > pointer is null." > I am having problems understanding this. Will help if you can give > a use case of how this will be used. As of now the intent is unclear. > A RowPointer cannot be pointing to "some MIB table". It must be > pointer to a specific row in a specific table. If this is a pointer to > a row in the mplsTunnelTable spell it out clearly and unambiguously. TBD. I will need some more time to understand the original context. > 4.16 > l2L3VpnMcastPmsiTunnelIf OBJECT-TYPE > DESCRIPTION > > "If the tunnel has a corresponding interface, this is the > > row pointer to ifXTable. Otherwise, the pointer is null." > This description is better. Would be even better with > "If the tunnel has a corresponding entry in the ifXTable, > this object will point to the row pertaining to the entry ..... Fixed. > 4.17 > l2L3VpnMcastOptionalGroup OBJECT-GROUP > > DESCRIPTION > > "Support of these object is not required." > Support of these objects is not required. Fixed. > 5.0 > >5. Security Considerations > TBD Still TBD. > 6.0 > >6. IANA Considerations > > > IANA is requested to root MIB objects in the MIB module contained in > > this document under the mib-2 subtree. > > Please Note: > To make the L2L3VpnMcastProviderTunnelType TC maintainable you need to > put the definitions in a separate MIB module. That would mean a > separate branch in the mib-2 subtree. Then the maintenance of the > TC can be carried out by some entity ( IANA or, some WG or, whoever is > responsible for maintaining the TC) independent of other MIB objects. > If that is the intent you will need to define 2 mib modules and you will > need to request 2 branches in the mib-2 subtree- one for the module > containing the L2L3VpnMcastProviderTunnelType TC and another for the > module containing the l2L3VpnMcastPmsiTunnelAttributeTable. TBD. I will address this point in the next revision. 2016-06-07 18:39 GMT+09:00 Glenn Mansfield Keeni : > Hi Jeffrey, > Thanks for the good work on draft-ietf-bess-l2l3-vpn-mcast-mib > document. It took me some time to do this review. But now here it > is. A (near complete) review of draft-ietf-bess-l2l3-vpn-mcast-mib-04.txt is > attached. Hope this helps. > I understand that the Security Considerations section is TBD. > > Glenn > > On 2016/05/19 4:48, Jeffrey (Zhaohui) Zhang wrote: >> >> Hi Glenn, >> >>> -----Original Message----- >>> From: Glenn Mansfield Keeni [mailto:glenn@cysols.com] >>> Sent: Sunday, May 08, 2016 11:02 AM >>> To: Jeffrey (Zhaohui) Zhang ; Benoit Claise >>> ; EXT - thomas.morin@orange.com >>> >>> Cc: Mach Chen ; ops-ads@ietf.org; Martin Vigoureux >>> ; bess@ietf.org; mib-doctors@ietf.org >>> Subject: Re: [bess] MIBDoc review of draft-ietf-bess-l2l3-vpn-mcast-mib- >>> 02.txt >>> >>> Jeffrey, >>> > Thanks for your comments. I've addressed most of your comments >>> > in the new revision: >>> Thanks for your cooperation. I will need at least one more revision >>> with the following comments/recommendations addressed before I will >>> be able to complete the detailed review. In the following the numbers >>> refer to the issue numbers in the initial review. The issues that are >>> addressed and closed are not listed. For brevity, the issue >>> descriptions have been trimmed. In case of doubts please look at the >>> response mail appended below. >>> Hope this helps. >> >> >> Thanks for your detailed comments/suggestions. I posted a new revision >> with the following issues addressed. >> >> URL: >> https://www.ietf.org/internet-drafts/draft-ietf-bess-l2l3-vpn-mcast-mib-04.txt >> Status: >> https://datatracker.ietf.org/doc/draft-ietf-bess-l2l3-vpn-mcast-mib/ >> Htmlized: >> https://tools.ietf.org/html/draft-ietf-bess-l2l3-vpn-mcast-mib-04 >> Diff: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-l2l3-vpn-mcast-mib-04 >> >> Please see some notes below. >> >>> >>> Glenn >>> >>> ------------------------------------------------------------------- >>> >>> Comments: >>> >>> 1.1 >>> > I had thought this would be standard/obvious for all MIB objects - >>> We will comeback to this time and again, whereever possible make >>> matters explicit and clear. That will help. >>> > Is it enough to say something similar? For example: >>> > In particular, it describes common managed objects used >>> > to configure and/or monitor both L2 and L3 VPN Multicast. >>> That is better. >> >> >> I take it that this is already closed in -03 revision. >> >>> >>> 2.2 >>> > Having said that, I'll explain PMSI a bit further. >>> PMSI explanation is good. >>> Please use the same style/format for I-PMSI and S-PMSI. >> >> >> I think -03 revision already use the same style/format for I-PMSI and >> S-PMSI? >> >>> >>> 2.3 >>> > No difference. I was using "Layer 3" or "L3" but it was pointed out >>> > that the layer 3 VPN is often referred to IP VPN in other RFCs and I >>> > was advised to change it accordingly. Looks like I did not change all >>> > the cases. >>> > On the other hand, I noticed that RFC 4382 does use "Layer 3 VPN" so >>> > I'll change it back. >>> No problems. just make sure that the same expression/notation is used >>> uniformly. >> >> >> I take it that this is also addressed in -03 already. >> >>> 3. >>> > > > 3. Summary of MIB Module. >>> > > > An overview of the L2L3-VPN-MCAST-MIB will be good- the >>> > > > structure of the MIB, short descriptions of the table(s) >>> > > > including usage of the table(s) for management and/or by >>> > > > other MIB(s). >>> > >>> > I had that, but have added one sentence about the only table. >>> A sentence or two about the textual convention will be good. >> >> >> Added in -04. >> >>> > > > 4. MIB syntax checking: >>> > > > smilint -s -e -l 5 mibs/L2L3-VPN-MCAST-MIB >>> 2>L2L3-VPN-MCAST-MIB.txt >>> > >>> > I used simpleweb's validation tool but looks like I did not use the >>> > strictest level of validation. I've now fixed the following issues and >>> > verified. >>> Good. >>> 5. >>> > > > >>> > > > 5. REFERENCE clauses: Please use REFERENCE clauses liberally. >>> > > > Wherever possible, provide references for objects used in >>> > > > the MIB. The references will point to specific sections/ >>> > > > sub-sections of the RFCs defining the protocol for which the >>> > > > MIB is being designed. It will greatly improve the readability >>> > > > of the document. >>> > >>> > Added. >>> I would recommend using the REFERENCE clause as in rfs4382 and >>> improve on it. >>> Specifically, instead of keeping the reference in the DESCRIPTION >>> clause move it to a separate REFERENCE clause. The addition of the >>> section number is an improvement. It is friendlier to the reader. >>> Note. Same comment for other OBJECTs too. >> >> >> Oh I missed that. All fixed. >> >>> 7.1 >>> > > > 7.1 CONTACT-INFO >>> > > > Following the conventions (including indentation style) will >>> > > > improve the readability. (e.g. RFC4382, RFC5132). >>> > > > Will be good if it does not overflow into the next page. >>> > >>> > Fixed. >>> The format is OK. The Postal address etc., need not have been >>> deleted. Please put the complete contact information as in the >>> Author's Address. (RFC 2578 section 5.7 gives a usage example). >> >> >> Fixed. >> >>> 7.3 >>> > I kept "experimental 99" so that I could continue to use mib tools >>> > to validate; but I added notes for the editor to replace them as you >>> > indicated. >>> Use of "experimental 99" is not recommended. >> >> >> Do you mean 99 is not a good number? What about 9999? As I explained, I >> kept it so that we can use mib tools to validate, and I've added detailed >> notes for the editor. >> >>> 8 >>> > > > 8. Specific MO and TC related comments. >>> > Are spaces allowed? I don't know so I used hyphen. For now I replace >>> > with things like rsvpP2mp. >>> Yes. Camelcase is an allowed practice. SMI does not mind it. >> >> >> Ok this is closed already then. >> >>> 8.2 >>> > > > 8.2 l2L3VpnMcastPmsiTunnelAttributeFlags OBJECT-TYPE >>> > The intent is to simply return the octet value of the flags >>> > field, w/o listing individual bits like "Leaf Information Required". >>> > More bits could be defined in the future but the MIB would not change. >>> > >>> > Is that OK? >>> As far as possible, the meaning of the objects must be made clear. >>> That will help implementors and operators- users of the MIB. >> >> >> I added the definition for one existing bit and reference to the IANA >> registry being created for this flag field. >> >>> >>> 8.3 >>> > > > 8.3 l2L3VpnMcastPmsiTunnelAttributeId OBJECT-TYPE >>> > Depending on the tunnel type, there could be different sizes. >>> > Future tunnel types could have other sizes that not specified >>> > today. I was thinking to just give a size >>> > tPmsiTunnelAttributeId OBJECT-TYPE range so that it is flexible. >>> > Is that ok? >>> I see that you have changed the size upper limit to 50. >>> If the size varies continuously from 0 to 50 the above description >>> is correct. >>> Please confirm, explain and cite appropriate reference. If the size >>> may change in the future that must be stated too. >> >> >> I changed to discrete sizes for currently defined tunnel types. >> >>> >>> 8.4 >>> > > > 8.4 l2L3VpnMcastPmsiTunnelIf OBJECT-TYPE >>> > > > SYNTAX RowPointer >>> > > > MAX-ACCESS read-only >>> > > > STATUS current >>> > > > DESCRIPTION >>> > > > "If the tunnel has a corresponding interface, >>> > > > this is the row pointer to the ifName table." >>> > > > o DESCRIPTION looks incorrect. Please fix it. Do you >>> > > > want to say this object points to the corresponding >>> > > > row in the ifTable? >>> > >>> > Yes. Fixed. >>> Not quite. >>> What is ifName table ? ifName is a columnar object in the ifXTable. >>> Is l2L3VpnMcastPmsiTunnelIf a pointer to the corresponding row in the >>> ifXTable table ? Please fix accordingly. >> >> >> You're right. Fixed. >> >>> >>> 9. >>> > > > 9. The Security Considerations section does not follow >>> > > > the Security Guidelines for IETF MIB Modules >>> > > > http://trac.tools.ietf.org/area/ops/trac/wiki/mib-security. >>> > > > Please fix. >>> > >>> > I was really hoping that it would not have to be that >>> > tedious. SNMP/MIB secur >>> ity should be no different from the >>> > CLI security - once you secure the infrastructure >>> > then what's more to do? >>> > >>> > I'll need more time to work on this. Let me try to address >>> > the issues in the other mib first and come back to this. >>> >>> Please take your time. Looking at examples will help. And let me >>> know where I can help. >> >> >> I will need to work on that later. >> >>> >>> 10.1 >>> > > > 10.1 Checking nits according to >>> > > > http://www.ietf.org/id-info/checklist : >>> > Should I break them into different lines or just keep them >>> > as is? Any example of expected indentation if I break the >>> > lines? >>> No problems at all to break lines. >>> l2L3VpnMcastGroups OBJECT IDENTIFIER >>> ::= {l2L3VpnMcastConformance 1} >>> Should do. >> >> >> Done. >> >>> >>> 10.2 >>> > > > 10.2 Checking references for intended status: Proposed Standard >>> > > > == Missing Reference: 'RFC 7117' is mentioned on line 76, >>> > > > but not defined >>> > > > 'described in [RFC6513, RFC6514, RFC 7117] and other >>> > I hope I understood and fixed it (removing the space in "RFC 7117"). >>> I would recommend that you put it as [RFC6513], [RFC6514], [RFC7117] >>> That is simpler to parse. >> >> >> I see some other documents do not have comma between multiple references >> so I followed that. >> >>> >>> > > > 11. There is another WIP MVPN-MIB in >>> > > > draft-ietf-bess-mvpn-mib-02.txt >>> > > > MVPN-MIB has objects that refer to L2L3-VPN-MCAST-MIB. >>> > > > Is there a good reason for not merging the 2 documents? >>> > > > I have not seen any discussion or explanation on this. >>> > > > I may have missed it. >>> > > > Please clarify or, give some pointers. >>> > >>> > As mentioned in the introduction: >>> > >>> > this memo describes managed objects common to both VPLS >>> > Multicast [RFC7117] and MVPN [RFC6513, RFC6514]. >>> > MVPN-MIB is for MVPN. There was another VPLS Multicast MIB >>> > in the work and both would reference common >>> >>> > objects defined in this MIB. >>> >>> OK. So you are saying that this MIB contains core objects that >>> will be used to manage implementations of various multicast VPN >>> protocols e.g. [RFC7117], [RFC6513],[RFC6514] ? It will help if >>> you spell it out at the beginning. >> >> >> Yes. I thought I did it already: >> >> 1. Introduction >> >> ... and this memo describes managed objects common to both VPLS >> Multicast [RFC7117] and MVPN [RFC6513, RFC6514]. >> >> Thanks! >> Jeffrey >> >>> >>> ---------------------------------------------------------------------- >>> On 2016/04/16 21:47, Jeffrey (Zhaohui) Zhang wrote: >>>> >>>> Glenn, >>>> >>>> Thanks for your comments. I've addressed most of your comments in the >>> >>> new revision: >>>> >>>> >>>> URL: https://www.ietf.org/internet-drafts/draft-ietf-bess- >>> >>> l2l3-vpn-mcast-mib-03.txt >>>> >>>> Status: https://datatracker.ietf.org/doc/draft-ietf-bess-l2l3- >>> >>> vpn-mcast-mib/ >>>> >>>> Htmlized: https://tools.ietf.org/html/draft-ietf-bess-l2l3-vpn- >>> >>> mcast-mib-03 >>>> >>>> Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-l2l3- >>> >>> vpn-mcast-mib-03 >>>> >>>> >>>> Please see below. >>>> >>>>> 1. Abstract: >>>>> 1.1 A sentence on how the managed objects will be used by >>>>> applications for operations, monitoring and management >>>>> would be good. >>>> >>>> >>>> I had thought this would be standard/obvious for all MIB objects - the >>> >>> read-write ones are used to control how a device works, and the read-only >>> ones are used for monitoring. Do I really need to say it explicitly? >>>> >>>> >>>> I see RFC 4382 has the following: >>>> >>>> This memo defines a portion of the Management Information Base (MIB) >>>> for use with network management protocols in the Internet community. >>>> In particular, it describes managed objects to configure and/or >>>> monitor Multiprotocol Label Switching Layer-3 Virtual Private >>>> Networks on a Multiprotocol Label Switching (MPLS) Label Switching >>>> Router (LSR) supporting this feature. >>>> >>>> Is it enough to say something similar? For example: >>>> >>>> In particular, it describes common managed objects used to >>> >>> configure >>>> >>>> and/or monitor both L2 and L3 VPN Multicast. >>>> >>>>> >>>>> 2. Introduction >>>>> 2.1 Please give the full expansion of the abbreviations >>>>> appearing for the first time. (PE, VPLS,..) >>>> >>>> >>>> Fixed. >>>> >>>>> >>>>> 2.2 The terminology section is a bit terse. Explaining the >>>>> terms that are used, nicely with reference to the protocol >>>>> documents will improve readability. >>>>> e.g. >>>>> - PMSI, I-PMSI, S-PMSI, provider tunnels >>>> >>>> >>>> As the paragraph alluded to, this MIB needs to be understood in the >>> >>> general context of L2/L3 multicast VPN and providing good explanation of >>> the terms is not attempted. The references for the terms are the the RFCs >>> for the relevant technologies. >>>> >>>> >>>> Having said that, I'll explain PMSI a bit further. >>>> >>>>> 2.3 Is there a difference between >>>>> "multicast in Layer 2 and Layer 3 VPNs , defined by >>>>> RFC 7117 and RFC 6513/6514" >>>>> used in the DESCRIPTION in the MODULE-IDENTITY >>>>> and >>>>> "multicast in BGP/MPLS L2 or IP VPN" >>>>> used in the DESCRIPTION of L2L3VpnMcastProviderTunnelType ? >>>>> If these are the same, it will be helpful to stick to the >>>>> same expression. If these are not the same, the dictinction >>>>> should be clarified. >>>> >>>> >>>> No difference. I was using "Layer 3" or "L3" but it was pointed out that >>> >>> the layer 3 VPN is often referred to IP VPN in other RFCs and I was >>> advised to change it accordingly. Looks like I did not change all the >>> cases. >>>> >>>> >>>> On the other hand, I noticed that RFC 4382 does use "Layer 3 VPN" so >>> >>> I'll change it back. >>>> >>>> >>>>> >>>>> >>>>> 3. Summary of MIB Module. >>>>> An overview of the L2L3-VPN-MCAST-MIB will be good- the >>>>> structure of the MIB, short descriptions of the table(s) >>>>> including usage of the table(s) for management and/or by >>>>> other MIB(s). >>>> >>>> >>>> I had that, but have added one sentence about the only table. >>>> >>>>> >>>>> MIB definitions: >>>>> 4. MIB syntax checking: >>>>> smilint -s -e -l 5 mibs/L2L3-VPN-MCAST-MIB 2>L2L3-VPN-MCAST-MIB.txt >>>> >>>> >>>> I used simpleweb's validation tool but looks like I did not use the >>> >>> strictest level of validation. I've now fixed the following issues and >>> verified. >>>> >>>> >>>>> >>>>> mibs/L2L3-VPN-MCAST-MIB:63: [4] {hyphen-in-label} warning: named >>> >>> number `rsvp-p2mp' must not include a hyphen in SMIv2 >>>>> >>>>> mibs/L2L3-VPN-MCAST-MIB:64: [4] {hyphen-in-label} warning: named >>> >>> number `ldp-p2mp' must not include a hyphen in SMIv2 >>>>> >>>>> mibs/L2L3-VPN-MCAST-MIB:65: [4] {hyphen-in-label} warning: named >>> >>> number `pim-asm' must not include a hyphen in SMIv2 >>>>> >>>>> mibs/L2L3-VPN-MCAST-MIB:66: [4] {hyphen-in-label} warning: named >>> >>> number `pim-ssm' must not include a hyphen in SMIv2 >>>>> >>>>> mibs/L2L3-VPN-MCAST-MIB:67: [4] {hyphen-in-label} warning: named >>> >>> number `pim-bidir' must not include a hyphen in SMIv2 >>>>> >>>>> mibs/L2L3-VPN-MCAST-MIB:68: [4] {hyphen-in-label} warning: named >>> >>> number `ingress-replication' must not include a hyphen in SMIv2 >>>>> >>>>> mibs/L2L3-VPN-MCAST-MIB:69: [4] {hyphen-in-label} warning: named >>> >>> number `ldp-mp2mp' must not include a hyphen in SMIv2 >>>> >>>> >>>> See later question/comments below. >>>> >>>>> mibs/L2L3-VPN-MCAST-MIB:215: [5] {group-unref} warning: current >>> >>> group `l2L3VpnMcastOptionalGroup' is not referenced in this module >>>>> >>>>> mibs/L2L3-VPN-MCAST-MIB:4: [5] {import-unused} warning: identifier >>> >>> `NOTIFICATION-TYPE' imported from module `SNMPv2-SMI' is never used >>>>> >>>>> mibs/L2L3-VPN-MCAST-MIB:5: [5] {import-unused} warning: identifier >>> >>> `Unsigned32' imported from module `SNMPv2-SMI' is never used >>>>> >>>>> mibs/L2L3-VPN-MCAST-MIB:8: [5] {import-unused} warning: identifier >>> >>> `NOTIFICATION-GROUP' imported from module `SNMPv2-CONF' is never used >>>>> >>>>> mibs/L2L3-VPN-MCAST-MIB:11: [5] {import-unused} warning: identifier >>> >>> `TruthValue' imported from module `SNMPv2-TC' is never used >>>>> >>>>> mibs/L2L3-VPN-MCAST-MIB:11: [5] {import-unused} warning: identifier >>> >>> `RowStatus' imported from module `SNMPv2-TC' is never used >>>>> >>>>> mibs/L2L3-VPN-MCAST-MIB:12: [5] {import-unused} warning: identifier >>> >>> `TimeStamp' imported from module `SNMPv2-TC' is never used >>>>> >>>>> mibs/L2L3-VPN-MCAST-MIB:12: [5] {import-unused} warning: identifier >>> >>> `TimeInterval' imported from module `SNMPv2-TC' is never used >>>>> >>>>> mibs/L2L3-VPN-MCAST-MIB:15: [5] {import-unused} warning: identifier >>> >>> `SnmpAdminString' imported from module `SNMP-FRAMEWORK-MIB' is never used >>>>> >>>>> mibs/L2L3-VPN-MCAST-MIB:18: [5] {import-unused} warning: identifier >>> >>> `InetAddress' imported from module `INET-ADDRESS-MIB' is never used >>>>> >>>>> mibs/L2L3-VPN-MCAST-MIB:18: [5] {import-unused} warning: identifier >>> >>> `InetAddressType' imported from module `INET-ADDRESS-MIB' is never used >>>> >>>> >>>> Removed the above unused imports. >>>> >>>>> >>>>> 5. REFERENCE clauses: Please use REFERENCE clauses liberally. >>>>> Wherever possible, provide references for objects used in >>>>> the MIB. The references will point to specific sections/ >>>>> sub-sections of the RFCs defining the protocol for which the >>>>> MIB is being designed. It will greatly improve the readability >>>>> of the document. >>>> >>>> >>>> Added. >>>> >>>>> >>>>> 6. IMPORTS clause >>>>> MIB modules from which items are imported must be cited and >>>>> included in the normative references. >>>>> The conventional style is >>>>> mplsStdMIB >>>>> FROM MPLS-TC-STD-MIB -- [RFC3811] >>>> >>>> >>>> Added. >>>> >>>>> >>>>> 7. Please update the MODULE-IDENTITY. (There are no syntantic errors.) >>>>> 7.1 CONTACT-INFO >>>>> Following the conventions (including indentation style) will >>>>> improve the readability. (e.g. RFC4382, RFC5132). >>>>> Will be good if it does not overflow into the next page. >>>> >>>> >>>> Fixed. >>>> >>>>> >>>>> 7.2 REVISION clause: follow the convention recommended in RFC4181 >>>>> sec 4.5 >>>>> REVISION "200212132358Z" -- December 13, 2002 >>>>> DESCRIPTION "Initial version, published as RFC yyyy." >>>>> -- RFC Ed.: replace yyyy with actual RFC number & remove this note: >>>> >>>> >>>> Fixed. >>>> >>>>> 7.3 OID assignment: follow the convention recommended in RFC4181 >>>>> sec 4.5 i >>>>> replace >>>>> ::= { experimental 99 } -- number to be assigned >>>>> by >>>>> ::= { XXX } >>>>> -- RFC Ed.: replace XXX with IANA-assigned number & remove this note >>>>> will be the subtree under which the module will be >>>>> registered. >>>>> >>>> >>>> I kept "experimental 99" so that I could continue to use mib tools to >>> >>> validate; but I added notes for the editor to replace them as you >>> indicated. >>>> >>>> >>>>> >>>>> 8. Specific MO and TC related comments. >>>>> L2L3VpnMcastProviderTunnelType ::= TEXTUAL-CONVENTION >>>>> STATUS current >>>>> DESCRIPTION >>>>> "Types of provider tunnels used for multicast in >>>>> BGP/MPLS L2 or IP VPN." >>>>> SYNTAX INTEGER { unconfigured (0), >>>>> rsvp-p2mp (1), >>>>> ldp-p2mp (2), >>>>> pim-asm (3), >>>>> pim-ssm (4), >>>>> pim-bidir (5), >>>>> ingress-replication (6), >>>>> ldp-mp2mp (7) >>>>> >>>>> o Would be nice to align the enumeration labels with the >>>>> labels in the protocol document RFC 6514 unless there is >>>>> a good reason for not doing so. (You will have to take >>>>> care of the smi compilation errors too; '-' is not allowed ). >>>> >>>> >>>> Are spaces allowed? I don't know so I used hyphen. For now I replace >>> >>> with things like rsvpP2mp. >>>> >>>> Or could/should I just remove the definitions, so that if a new type is >>> >>> defined in the future there is no need to update the MIB? >>>> >>>> >>>>> >>>>> 8.1 l2L3VpnMcastPmsiTunnelAttributeEntry OBJECT-TYPE >>>>> SYNTAX L2L3VpnMcastPmsiTunnelAttributeEntry >>>>> MAX-ACCESS not-accessible >>>>> STATUS current >>>>> DESCRIPTION >>>>> "An entry in this table corresponds to an PMSI attribute >>>>> that is advertised/received on this router. >>>>> For BGP-based signaling (for I-PMSI via auto-discovery >>>>> procedure, or for S-PMSI via S-PMSI A-D routes), >>>>> they are just as signaled by BGP (RFC 6514 section 5, >>>>> 'PMSI Tunnel attribute'). >>>>> For UDP-based S-PMSI signaling for PIM-MVPN, >>>>> they're derived from S-PMSI Join Message >>>>> (RFC 6513 section 7.4.2, 'UDP-based Protocol').. >>>>> >>>>> Note that BGP-based signaling may be used for >>>>> PIM-MVPN as well." >>>>> o Fix the ".." in "'UDP-based Protocol').." above. >>>>> o Please give the reference for this Table. >>>>> Is it- "PMSI Tunnel attribute" in RFC 6513 Sec.4 ? >>>>> "PMSI Tunnel attribute" in RFC 6514 Sec.5 ? >>>>> both? >>>>> Any other pointers? >>>> >>>> >>>> Fixed. >>>> >>>>> >>>>> 8.2 l2L3VpnMcastPmsiTunnelAttributeFlags OBJECT-TYPE >>>>> SYNTAX OCTET STRING (SIZE (1)) >>>>> MAX-ACCESS not-accessible >>>>> STATUS current >>>>> DESCRIPTION >>>>> "For UDP-based S-PMSI signaling for PIM-MVPN, this is 0. >>>>> For BGP-based I/S-PMSI signaling, this is the Flags >>>>> field in PMSI Tunnel Attribute of the corresponding >>>>> I/S-PMSI A-D route." >>>>> ::= { l2L3VpnMcastPmsiTunnelAttributeEntry 1 } >>>>> o Please confirm that the above is a complete enumeration of the >>>>> types of signalling. >>>>> o RFC 6514 Sec.5 says that the Flags field indicates >>>>> "Leaf Information Required". That is useful information. >>>>> Please include in the description. >>>> >>>> >>>> The intent is to simply return the octet value of the flags field, w/o >>> >>> listing individual bits like "Leaf Information Required". More bits could >>> be defined in the future but the MIB would not change. >>>> >>>> >>>> Is that OK? >>>> >>>>> >>>>> 8.3 l2L3VpnMcastPmsiTunnelAttributeId OBJECT-TYPE >>>>> SYNTAX OCTET STRING ( SIZE (0..37) ) >>>>> MAX-ACCESS not-accessible >>>>> STATUS current >>>>> DESCRIPTION >>>>> "For UDP-based S-PMSI signaling for PIM-MVPN, the first >>>>> four or sixteen octets of this attribute are filled with >>>>> the provider tunnel group address (IPv4 or IPv6).. >>>>> For BGP-based I/S-PMSI signaling, this is the Tunnel >>> >>> Identifier >>>>> >>>>> Field in PMSI Tunnel Attribute of the corresponding I/S- >>> >>> PMSI >>>>> >>>>> A-D route." >>>>> o Check the size specifications. The specs above say it can be >>>>> all sizes 0..37. That is not clear from the DESCRIPTION clause. >>>>> o Fix the ".." in "(IPv4 or IPv6).." above. >>>>> o RFC 6514 Sec 5. PMSI Tunnel Attribute gives the Tunnel >>> >>> Identifiers >>>>> >>>>> for mLDP, PIM-SM, PIM-SSM, BIDIR-PIM,Ingress Replication,MP2MP. >>>>> It appears that the sizes (range) for each case will be >>>>> different. >>>>> Please clarify that, and if there are discrete sizes, specify >>>>> accordingly. >>>> >>>> >>>> Depending on the tunnel type, there could be different sizes. Future >>> >>> tunnel types could have other sizes that not specified today. I was >>> thinking to just give a size range so that it is flexible. Is that ok? >>>> >>>> >>>>> >>>>> >>>>> 8.3 l2L3VpnMcastPmsiTunnelPointer OBJECT-TYPE >>>>> SYNTAX RowPointer >>>>> MAX-ACCESS read-only >>>>> STATUS current >>>>> DESCRIPTION >>>>> "If the tunnel exists in some MIB table, this is the >>>>> row pointer to it." >>>>> o "some MIB table" : specify which MIB table. >>>> >>>> >>>> I can give an example, like mplsTunnelTable [RFC 3812]. It could be >>> >>> whatever table that a tunnel may be put into. >>>> >>>> >>>>> o In what case will the tunnel exist and in what case will it not? >>>> >>>> >>>> If a device supports mplsTunnelTable and the tunnel is represented >>>> there, >>> >>> then it exists. >>>> >>>> >>>>> o What will be the behaviour if the above condition is not >>> >>> satisfied? >>>> >>>> >>>> A null pointer should be given. >>>> >>>>> >>>>> 8.4 l2L3VpnMcastPmsiTunnelIf OBJECT-TYPE >>>>> SYNTAX RowPointer >>>>> MAX-ACCESS read-only >>>>> STATUS current >>>>> DESCRIPTION >>>>> "If the tunnel has a corresponding interface, this is the >>>>> row pointer to the ifName table." >>>>> o DESCRIPTION looks incorrect. Please fix it. Do you want to say >>>>> this object points to the corresponding row in the ifTable? >>>> >>>> >>>> Yes. Fixed. >>>> >>>>> o In what case does the TunnelIf exist and in what case will it >>> >>> not? >>>> >>>> >>>> Some tunnels may not have a corresponding interface. >>>> >>>>> o What will be expected if the tunnel does not have a >>> >>> corresponding >>>>> >>>>> interface? >>>> >>>> >>>> Null row pointer. >>>> >>>>> >>>>> 9. The Security Considerations section does not follow the Security >>>>> Guidelines for IETF MIB Modules >>>>> http://trac.tools.ietf.org/area/ops/trac/wiki/mib-security. >>>>> Please fix. >>>> >>>> >>>> I was really hoping that it would not have to be that tedious. SNMP/MIB >>> >>> security should be no different from the CLI security - once you secure >>> the infrastructure then what's more to do? >>>> >>>> >>>> I'll need more time to work on this. Let me try to address the issues in >>> >>> the other mib first and come back to this. >>>> >>>> >>>>> >>>>> >>>>> 10.ID-nits >>>>> 10.1 Checking nits according to http://www.ietf.org/id-info/checklist : >>>>> ------------------------------------------------------------------ >>> >>> --------- >>>>> >>>>> >>>>> ** There are 4 instances of too long lines in the document, the >>> >>> longest one >>>>> >>>>> being 3 characters in excess of 72. >>>> >>>> >>>> I fixed some but there still three too long lines: >>>> >>>> l2L3VpnMcastPmsiTunnelAttributeType >>>> L2L3VpnMcastProviderTunnelType, >>>> >>>> l2L3VpnMcastGroups OBJECT IDENTIFIER ::= {l2L3VpnMcastConformance >>> >>> 1} >>>> >>>> l2L3VpnMcastCompliances OBJECT IDENTIFIER ::= {l2L3VpnMcastConformance >>> >>> 2} >>>> >>>> >>>> Should I break them into different lines or just keep them as is? Any >>> >>> example of expected indentation if I break the lines? >>>> >>>> >>>>> >>>>> 10.2 Checking references for intended status: Proposed Standard >>>>> ------------------------------------------------------------------ >>> >>> --------- >>>>> >>>>> >>>>> == Missing Reference: 'RFC 7117' is mentioned on line 76, but not >>>>> defined >>>>> 'described in [RFC6513, RFC6514, RFC 7117] and other documents >>> >>> tha...' >>>> >>>> >>>> I hope I understood and fixed it (removing the space in "RFC 7117"). >>>> >>>>> >>>>> 11. There is another WIP MVPN-MIB in draft-ietf-bess-mvpn-mib-02.txt >>>>> MVPN-MIB has objects that refer to L2L3-VPN-MCAST-MIB. >>>>> Is there a good reason for not merging the 2 documents? I have not >>> >>> seen >>>>> >>>>> any discussion or explanation on this. I may have missed it. >>> >>> Please >>>>> >>>>> clarify or, give some pointers. >>>> >>>> >>>> As mentioned in the introduction: >>>> >>>> this memo describes managed objects common to both VPLS >>>> Multicast [RFC7117] and MVPN [RFC6513, RFC6514]. >>>> >>>> MVPN-MIB is for MVPN. There was another VPLS Multicast MIB in the work >>> >>> and both would reference common objects defined in this MIB. >>>> >>>> >>>> Thanks! >>>> Jeffrey >>>> >>>>> -----Original Message----- >>>>> From: BESS [mailto:bess-bounces@ietf.org] On Behalf Of Glenn Mansfield >>>>> Keeni >>>>> Sent: Tuesday, April 12, 2016 2:28 AM >>>>> To: Benoit Claise ; EXT - thomas.morin@orange.com >>>>> >>>>> Cc: Jeffrey (Zhaohui) Zhang ; ops-ads@ietf.org; >>> >>> Martin >>>>> >>>>> Vigoureux ; bess@ietf.org; Mach Chen >>>>> >>>>> Subject: [bess] MIBDoc review of draft-ietf-bess-l2l3-vpn-mcast-mib- >>> >>> 02.txt >>>>> >>>>> >>>>> Hi, >>>>> I have been asked to do a MIB Doctors review of >>>>> draft-ietf-bess-l2l3-vpn-mcast-mib-02.txt. >>>>> My knowledge of L2L3VPN Multicast is limited to the reading >>>>> of this document and browsing through the documents referred >>>>> to in the draft and bess-wg mailing list archives.( read "shallow"). >>>>> So some of the doubts and questions may sound trivial or >>>>> strange. Please bear with me and help me help you make >>>>> this into a better document :-) >>>>> >>>>> The comments are attached. >>>>> >>>>> Glenn >>>>> >>>> >>>> _______________________________________________ >>>> BESS mailing list >>>> BESS@ietf.org >>>> https://www.ietf.org/mailman/listinfo/bess >>>> >> >> > > > _______________________________________________ > BESS mailing list > BESS@ietf.org > https://www.ietf.org/mailman/listinfo/bess > From nobody Sat Dec 3 04:21:08 2016 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 676C81296EF; Sat, 3 Dec 2016 04:21:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ysfSrpF7Or_6; Sat, 3 Dec 2016 04:21:02 -0800 (PST) Received: from niseko.cysol.co.jp (niseko.cysol.co.jp [210.233.3.236]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB5311296F0; Sat, 3 Dec 2016 04:21:01 -0800 (PST) Received: from [192.168.0.89] (cysvpn02.priv.cysol.co.jp [192.168.0.89]) (authenticated bits=0) by aso.priv.cysol.co.jp (8.14.9/8.14.9) with ESMTP id uB3CJBeB036341 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sat, 3 Dec 2016 21:19:12 +0900 (JST) (envelope-from glenn@cysols.com) To: Hiroshi Tsunoda References: <56E7D219.7000902@orange.com> <56FBD402.9040102@cisco.com> <56FBDD81.6080502@cysols.com> <11152_1459347064_56FBDE78_11152_10229_1_56FBDE77.6030605@orange.com> <56FBE17E.5090609@cisco.com> <570C9586.7030905@cysols.com> From: Glenn Mansfield Keeni Message-ID: <5e663cf0-1418-c410-bcf8-b235ee73fc29@cysols.com> Date: Sat, 3 Dec 2016 21:19:06 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=iso-2022-jp; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Archived-At: Cc: Mach Chen , "mib-doctors@ietf.org" , "Jeffrey \(Zhaohui\) Zhang" , "ops-ads@ietf.org" , Benoit Claise , "EXT - thomas.morin@orange.com" , Martin Vigoureux , "bess@ietf.org" Subject: Re: [bess] MIBDoc review of draft-ietf-bess-l2l3-vpn-mcast-mib-04.txt X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Dec 2016 12:21:06 -0000 Hi Tsunoda, > I have started to volunteer to help to move this document forward. Great! > I posted a new revision and addressed all editorial things in > that revision. Got this. Looks good. > Please give me some more time for revising other parts, No problems. Will be looking forward to the revised document. Glenn On 2016/12/02 12:12, Hiroshi Tsunoda wrote: > Dear Glenn, > > Thanks for your careful review and detailed comments/suggestions. > I have started to volunteer to help to move this document forward. > I posted a new revision and addressed all editorial things in that revision. > Please give me some more time for revising other parts, > in order to be familiar with the context of the original and related documents. > > URL: https://www.ietf.org/id/draft-ietf-bess-l2l3-vpn-mcast-mib-05.txt > Status: https://datatracker.ietf.org/doc/draft-ietf-bess-l2l3-vpn-mcast-mib/ > Htmlized: https://tools.ietf.org/html/draft-ietf-bess-l2l3-vpn-mcast-mib-05 > Diff: > https://tools.ietf.org/rfcdiff?url2=draft-ietf-bess-l2l3-vpn-mcast-mib-05.txt > > Please see some notes below. > >> 0. Abstract. >> 0.1. >>> it describes common managed objects used to configure >> and/or monitor both L2 and L3 VPN Multicast. >> >> There are no writable MOs in this MIB. So it does not look >> as though this MIB will be used for configuration directly. >> The use case scenario for monitoring is not clear, either. >> It appears that the MIB module(s) in this document will be >> used by other modules which are designed for monitoring and/ >> or configuring L2 and L3 VPN Multicast. Please re-examine the >> wording. > > Fixed. > >> 1. Introduction >> >> 1.1 >> Would be very nice if a short explanations of MVPN and >> L2 VPN Multicast were given. With emphasis on the operational >> aspects. > > TBD. Please give me some more time to revise. > >> 1.2 >> s/referred to MVPN and L2 VPN Multicast respectively/ >> referred to as MVPN and L2 VPN Multicast,respectively/ > > Fixed. > >> 1.3 >> s/MVPN [RFC6513] [RFC6514]/MVPN [RFC6513],[RFC6514]/. > > Fixed. > >> 1.4 .... there are 2 types of PMSIs .. >> >>> o I-PMSI: Inclusive PMSI - to all PEs in the same VPN. >>> o S-PMSI: Selective PMSI - to some of the PEs in the same VPN. >> >> please make these explanations more gentle(complete) to the reader. >> Also, give the references where these terms are defined. > > TBD. Please give me some more time to revise. > >> 3. Summary of MIB Module >> 3.1 >>> Attributes (PTAs) advertised/received in I/S-PSMI Auto-Discovery >> Typo: I/S-PMSI, (see 3.3 below). > > Fixed. > >> 3.2 some more text like the following will be good. >> L2L3-VPN-MCAST-MIB contains >> o a Textual Convention L2L3VpnMcastProviderTunnelType that provides >> an enumeration of the provider tunnel types and, >> o a table l2L3VpnMcastPmsiTunnelAttributeTable. The table index is >> composed of multiple attributes that depend on the tunnel type and >> uniquely identify a tunnel. This table will be used to ... monitor >> the tunnels supported by the system at a given point of time (?) >> It may also be used in conjunction with XXXX-mib to obtain the >> other details of a tunnel by following the row pointer of the >> corresponding tunnel's row in this table. >> [ Please treat the above as a template and modify the text as >> appropriate ..] > > TBD. Please give me some more time to revise this point. > >> 3.3 Since this will become a standard document, please take care of >> definitions and notations used in the document. >> The notation I/S-PMSI is not defined. If you must use a new >> term/notation, define it before use. > > TBD. Please give me some more time to revise this point. > >> 4. Definitions >> >>> IMPORTS >>> MODULE-IDENTITY, OBJECT-TYPE, experimental >> 4.1 Since this is not a Experimental MIB do not import use experimental. >> It is good practice to keep the draft in the as "close to final form" >> as possible. (See below) > > Fixed. > >> 4.2 >>> LAST-UPDATED "201310141200Z" -- October 14, 2013 >> Please update this date. > > Updated. > >> 4.3 >>> DESCRIPTION >>> "This MIB contains common managed object definitions for >>> multicast in Layer 2 and Layer 3 VPNs, defined by >>> [RFC7117] and [RFC6513] [RFC6514] respectively. >> Would be good if you could rearrange the text. Something like >> "This MIB module will be used for managing multicast in Layer 2 >> VPNs [RFC7117] and Layer 3 VPNs [RFC6513], [RFC6514]. >> Or, even better >> "This MIB module will be used by other MIB modules designed for >> managing multicast in Layer 2 VPNs [RFC7117] and Layer 3 VPNs >> [RFC6513], [RFC6514] >> Or, a combination of both, depending on the envisaged use case >> scenarios. > > Rearranged the text along with your comment. > >> 4.4 >>> ::= { experimental 999 } >> Please >> o Replace "experimental" by the branch where this mib module will >> be anchored; that is a decision that the WG will take, probably. >> o Import the branch in the IMPORTS statement >> [ In the IANA Considerations section a branch in the mib-2 subtree >> is requested. In that case this must be >> ::= { mib-2 XXX } >> ] > > Fixed. > >> 4.5 >>> -- Please also remove the ", experimental" text from earlier >>> -- IMPORTS section. >> Remove these instructions. > > Removed. > >> 4.5.2 >>> -- Texual convention >> Typo: -- Textual convention > > Fixed. > >> 4.6 >>> L2L3VpnMcastProviderTunnelType ::= TEXTUAL-CONVENTION >>> DESCRIPTION >>> "Types of provider tunnels used for multicast in >>> BGP/MPLS L2 or L3 VPN. Additional types may be defined >>> in future RFCs, and those will be allowed as >>> valid types for L2L3VpnMcastProviderTunnelType." >> The part >>> Additional types may be defined >>> in future RFCs, and those will be allowed as >>> valid types for L2L3VpnMcastProviderTunnelType." >> may be deleted. > > Deleted. > >> 4.7 >>> -- Top level components of this MIB. >>> -- tables, scalars, conformance information >>> >>> l2L3VpnMcastObjects OBJECT IDENTIFIER ::= { l2L3VpnMcastMIB 1 } >>> l2L3VpnMcastConformance OBJECT IDENTIFIER ::= { l2L3VpnMcastMIB 2 } >> l2L3VpnMcastStates OBJECT IDENTIFIER ::= { l2L3VpnMcastObjects 1 } >>> >>> -- Table of PMSI Tunnel Attributes >>> >>> l2L3VpnMcastPmsiTunnelAttributeTable OBJECT-TYPE >> >> should be >> >> -- Top level components of this MIB. >> >> l2L3VpnMcastObjects OBJECT IDENTIFIER ::= { l2L3VpnMcastMIB 1 } >> l2L3VpnMcastConformance OBJECT IDENTIFIER ::= { l2L3VpnMcastMIB 2 } >> l2L3VpnMcastStates OBJECT IDENTIFIER ::= { l2L3VpnMcastObjects 1 } >> >> -- tables, scalars, conformance information >> -- Table of PMSI Tunnel Attributes >> >> l2L3VpnMcastPmsiTunnelAttributeTable OBJECT-TYPE > > Fixed. > >> 4.8 >>> l2L3VpnMcastPmsiTunnelAttributeTable OBJECT-TYPE >>> SYNTAX SEQUENCE OF L2L3VpnMcastPmsiTunnelAttributeEntry >>> MAX-ACCESS not-accessible >>> STATUS current >>> DESCRIPTION >>> "This table is for PMSI Tunnel Attributes (PTAs) >>> advertised/received in I/S-PSMI Auto-Discovery routes. >>> The entries may be referred to by I-PMSI or S-PMSI table >>> entries defined in other MIBs, e.g. mvpnMIB in >>> [I-D.ietf-bess-mvpn-mib]." >> >> It would seem that each row in this table is an index for a PTA >> and may contain pointers to rows in tables of other MIB modules >> which may contain more details for the PTA. Is that correct? >> Please reword the DESCRIPTION acordingly. >> Also see comments in 4.15 > > TBD. I need some more time to understand the original context. > >> 4.9 >>> l2L3VpnMcastPmsiTunnelAttributeEntry OBJECT-TYPE >>> "An entry in this table corresponds to a PTA >>> that is advertised/received on this router. >> We are in the description of "l2L3VpnMcastPmsiTunnelAttributeEntry" >> so "entry in this table" does not fit in well. >> A rewording like >> "A conceptual row corresponding to a PTA >> that is advertised/received on this router. >> .... >> would be better. > > Fixed. > >> 4.10 >>> For BGP-based signaling (for I-PMSI via auto-discovery >>> procedure, or for S-PMSI via S-PMSI A-D routes), >>> they are just as signaled by BGP. >>> For UDP-based S-PMSI signaling for PIM-MVPN, >>> they're derived from the S-PMSI Join Message. >> >>> Note that BGP-based signaling may be used for >>> PIM-MVPN as well." >> Is the signaling mechanism important here? If it isn't then the >> above part of the description is redundant. > > Removed the above part. > >> 4.10-2 >> PIM-MVPN appears for the first time. > > Defined the notation of PIM-MVPM as follows > Protocol Independent Multicast - MVPN (PIM-MVPN) > However, I think that some descriptions may be required for this > somewhere in this document. That is TBD. > >> 4.10-3 >> the phrase UDP-based S-PMSI appears here for the first time. >> Somewhere earlier it should be made clear that UDP too may be used >> in signaling. > > TBD. > >> 4.11 >> l2L3VpnMcastPmsiTunnelAttributeFlags OBJECT-TYPE >>> "For UDP-based S-PMSI signaling for PIM-MVPN, this is 0. >> "this" is unclear. >> Something like "the value of this object is 0" will be better. > > Fixed. > >>> More bits may be defined in the future and >>> they will be registered in IANA Registry xxxx." >> This part is probably redundant. > > Removed. > >> 4.12 >>> -- RFC Ed. replace xxxx with the actual registry name >>> -- that is being created via [I-D.ietf-bess-mvpn-mib] >>> -- and remove this note. >> >> Look at the comments in 6.0 > > The above description ("IANA Registry xxxx.") was removed, > thus this part was also removed. > >> 4.13 >> l2L3VpnMcastPmsiTunnelAttributeType OBJECT-TYPE >>> DESCRIPTION >>> "As defined for L2L3VpnMcastProviderTunnelType. >>> For UDP-based S-PMSI signaling for PIM-MVPN, >>> this is pim-asm (3), pim-ssm (4), or pim-bidir (5). >>> For BGP-based I/S-PMSI signaling, this is the Tunnel Type >>> field in PMSI Tunnel Attribute of the corresponding >>> I/S-PMSI A-D or Leaf A-D route." >> o Does this description cover all the types? If not, then cover all the >> types unless there is a good reason to focus only on the above types. >> o I/S-PMSI: unexplained notation. > > TBD. Please give me some more time to address this point. > >> 4.14 >> >> l2L3VpnMcastPmsiTunnelAttributeId OBJECT-TYPE >>> SYNTAX OCTET STRING ( SIZE (0|4|8|12|17|24|29) ) >> It appears that you also allow sizes "16" and "32"; these must be included. > > Fixed. > >>> IPv4/IPv6 l2L3VpnMcastPmsiTunnelAttributeType >> Please indicate that the first column gives the size > > I made a change as follows. > > Size l2L3VpnMcastPmsiTunnelAttributeType > (IPv4/IPv6) > -------------------------------------------------- > (snip) > 8/32 pimAsm > (snip) > > Is this OK? > >>> 8/32 pimAsm >>> 8/32 pimSsm >>> 8/32 pimBidir >>> 4/16 ingressReplication >> >>> For UDP-based S-PMSI signaling for PIM-MVPN, the first >>> 8 or 32 octets of this attribute are filled with >>> the provider tunnel (source, group) IPv4/IPv6 addresses. >>> For BGP-based I/S-PMSI signaling, this is the Tunnel >>> Identifier field in PMSI Tunnel Attribute of the >>> corresponding I/S-PMSI A-D route." >> >> A more generous description of the AttributeID would be good. All the >> cases must be covered. Section 5 of RFC 6514 does it nicely. A simple >> summary would be very nice. > > TBD. Please give me some more time to revise this point. > >> 4.15 >> l2L3VpnMcastPmsiTunnelPointer OBJECT-TYPE >>> SYNTAX RowPointer >>> DESCRIPTION >>> "If the tunnel exists in some MIB table, e.g. mplsTunnelTable >>> [RFC3812], this is the row pointer to it. Otherwise, the >>> pointer is null." >> I am having problems understanding this. Will help if you can give >> a use case of how this will be used. As of now the intent is unclear. >> A RowPointer cannot be pointing to "some MIB table". It must be >> pointer to a specific row in a specific table. If this is a pointer to >> a row in the mplsTunnelTable spell it out clearly and unambiguously. > > TBD. I will need some more time to understand the original context. > >> 4.16 >> l2L3VpnMcastPmsiTunnelIf OBJECT-TYPE >> DESCRIPTION >>> "If the tunnel has a corresponding interface, this is the >>> row pointer to ifXTable. Otherwise, the pointer is null." >> This description is better. Would be even better with >> "If the tunnel has a corresponding entry in the ifXTable, >> this object will point to the row pertaining to the entry ..... > > Fixed. > >> 4.17 >> l2L3VpnMcastOptionalGroup OBJECT-GROUP >>> DESCRIPTION >>> "Support of these object is not required." >> Support of these objects is not required. > > Fixed. > >> 5.0 >>> 5. Security Considerations >> TBD > > Still TBD. > >> 6.0 >>> 6. IANA Considerations >> >>> IANA is requested to root MIB objects in the MIB module contained in >>> this document under the mib-2 subtree. >> >> Please Note: >> To make the L2L3VpnMcastProviderTunnelType TC maintainable you need to >> put the definitions in a separate MIB module. That would mean a >> separate branch in the mib-2 subtree. Then the maintenance of the >> TC can be carried out by some entity ( IANA or, some WG or, whoever is >> responsible for maintaining the TC) independent of other MIB objects. >> If that is the intent you will need to define 2 mib modules and you will >> need to request 2 branches in the mib-2 subtree- one for the module >> containing the L2L3VpnMcastProviderTunnelType TC and another for the >> module containing the l2L3VpnMcastPmsiTunnelAttributeTable. > > TBD. I will address this point in the next revision. > > 2016-06-07 18:39 GMT+09:00 Glenn Mansfield Keeni : >> Hi Jeffrey, >> Thanks for the good work on draft-ietf-bess-l2l3-vpn-mcast-mib >> document. It took me some time to do this review. But now here it >> is. A (near complete) review of draft-ietf-bess-l2l3-vpn-mcast-mib-04.txt is >> attached. Hope this helps. >> I understand that the Security Considerations section is TBD. >> >> Glenn >> >> On 2016/05/19 4:48, Jeffrey (Zhaohui) Zhang wrote: >>> >>> Hi Glenn, >>> >>>> -----Original Message----- >>>> From: Glenn Mansfield Keeni [mailto:glenn@cysols.com] >>>> Sent: Sunday, May 08, 2016 11:02 AM >>>> To: Jeffrey (Zhaohui) Zhang ; Benoit Claise >>>> ; EXT - thomas.morin@orange.com >>>> >>>> Cc: Mach Chen ; ops-ads@ietf.org; Martin Vigoureux >>>> ; bess@ietf.org; mib-doctors@ietf.org >>>> Subject: Re: [bess] MIBDoc review of draft-ietf-bess-l2l3-vpn-mcast-mib- >>>> 02.txt >>>> >>>> Jeffrey, >>>> > Thanks for your comments. I've addressed most of your comments >>>> > in the new revision: >>>> Thanks for your cooperation. I will need at least one more revision >>>> with the following comments/recommendations addressed before I will >>>> be able to complete the detailed review. In the following the numbers >>>> refer to the issue numbers in the initial review. The issues that are >>>> addressed and closed are not listed. For brevity, the issue >>>> descriptions have been trimmed. In case of doubts please look at the >>>> response mail appended below. >>>> Hope this helps. >>> >>> >>> Thanks for your detailed comments/suggestions. I posted a new revision >>> with the following issues addressed. >>> >>> URL: >>> https://www.ietf.org/internet-drafts/draft-ietf-bess-l2l3-vpn-mcast-mib-04.txt >>> Status: >>> https://datatracker.ietf.org/doc/draft-ietf-bess-l2l3-vpn-mcast-mib/ >>> Htmlized: >>> https://tools.ietf.org/html/draft-ietf-bess-l2l3-vpn-mcast-mib-04 >>> Diff: >>> https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-l2l3-vpn-mcast-mib-04 >>> >>> Please see some notes below. >>> >>>> >>>> Glenn >>>> >>>> ------------------------------------------------------------------- >>>> >>>> Comments: >>>> >>>> 1.1 >>>> > I had thought this would be standard/obvious for all MIB objects - >>>> We will comeback to this time and again, whereever possible make >>>> matters explicit and clear. That will help. >>>> > Is it enough to say something similar? For example: >>>> > In particular, it describes common managed objects used >>>> > to configure and/or monitor both L2 and L3 VPN Multicast. >>>> That is better. >>> >>> >>> I take it that this is already closed in -03 revision. >>> >>>> >>>> 2.2 >>>> > Having said that, I'll explain PMSI a bit further. >>>> PMSI explanation is good. >>>> Please use the same style/format for I-PMSI and S-PMSI. >>> >>> >>> I think -03 revision already use the same style/format for I-PMSI and >>> S-PMSI? >>> >>>> >>>> 2.3 >>>> > No difference. I was using "Layer 3" or "L3" but it was pointed out >>>> > that the layer 3 VPN is often referred to IP VPN in other RFCs and I >>>> > was advised to change it accordingly. Looks like I did not change all >>>> > the cases. >>>> > On the other hand, I noticed that RFC 4382 does use "Layer 3 VPN" so >>>> > I'll change it back. >>>> No problems. just make sure that the same expression/notation is used >>>> uniformly. >>> >>> >>> I take it that this is also addressed in -03 already. >>> >>>> 3. >>>> > > > 3. Summary of MIB Module. >>>> > > > An overview of the L2L3-VPN-MCAST-MIB will be good- the >>>> > > > structure of the MIB, short descriptions of the table(s) >>>> > > > including usage of the table(s) for management and/or by >>>> > > > other MIB(s). >>>> > >>>> > I had that, but have added one sentence about the only table. >>>> A sentence or two about the textual convention will be good. >>> >>> >>> Added in -04. >>> >>>> > > > 4. MIB syntax checking: >>>> > > > smilint -s -e -l 5 mibs/L2L3-VPN-MCAST-MIB >>>> 2>L2L3-VPN-MCAST-MIB.txt >>>> > >>>> > I used simpleweb's validation tool but looks like I did not use the >>>> > strictest level of validation. I've now fixed the following issues and >>>> > verified. >>>> Good. >>>> 5. >>>> > > > >>>> > > > 5. REFERENCE clauses: Please use REFERENCE clauses liberally. >>>> > > > Wherever possible, provide references for objects used in >>>> > > > the MIB. The references will point to specific sections/ >>>> > > > sub-sections of the RFCs defining the protocol for which the >>>> > > > MIB is being designed. It will greatly improve the readability >>>> > > > of the document. >>>> > >>>> > Added. >>>> I would recommend using the REFERENCE clause as in rfs4382 and >>>> improve on it. >>>> Specifically, instead of keeping the reference in the DESCRIPTION >>>> clause move it to a separate REFERENCE clause. The addition of the >>>> section number is an improvement. It is friendlier to the reader. >>>> Note. Same comment for other OBJECTs too. >>> >>> >>> Oh I missed that. All fixed. >>> >>>> 7.1 >>>> > > > 7.1 CONTACT-INFO >>>> > > > Following the conventions (including indentation style) will >>>> > > > improve the readability. (e.g. RFC4382, RFC5132). >>>> > > > Will be good if it does not overflow into the next page. >>>> > >>>> > Fixed. >>>> The format is OK. The Postal address etc., need not have been >>>> deleted. Please put the complete contact information as in the >>>> Author's Address. (RFC 2578 section 5.7 gives a usage example). >>> >>> >>> Fixed. >>> >>>> 7.3 >>>> > I kept "experimental 99" so that I could continue to use mib tools >>>> > to validate; but I added notes for the editor to replace them as you >>>> > indicated. >>>> Use of "experimental 99" is not recommended. >>> >>> >>> Do you mean 99 is not a good number? What about 9999? As I explained, I >>> kept it so that we can use mib tools to validate, and I've added detailed >>> notes for the editor. >>> >>>> 8 >>>> > > > 8. Specific MO and TC related comments. >>>> > Are spaces allowed? I don't know so I used hyphen. For now I replace >>>> > with things like rsvpP2mp. >>>> Yes. Camelcase is an allowed practice. SMI does not mind it. >>> >>> >>> Ok this is closed already then. >>> >>>> 8.2 >>>> > > > 8.2 l2L3VpnMcastPmsiTunnelAttributeFlags OBJECT-TYPE >>>> > The intent is to simply return the octet value of the flags >>>> > field, w/o listing individual bits like "Leaf Information Required". >>>> > More bits could be defined in the future but the MIB would not change. >>>> > >>>> > Is that OK? >>>> As far as possible, the meaning of the objects must be made clear. >>>> That will help implementors and operators- users of the MIB. >>> >>> >>> I added the definition for one existing bit and reference to the IANA >>> registry being created for this flag field. >>> >>>> >>>> 8.3 >>>> > > > 8.3 l2L3VpnMcastPmsiTunnelAttributeId OBJECT-TYPE >>>> > Depending on the tunnel type, there could be different sizes. >>>> > Future tunnel types could have other sizes that not specified >>>> > today. I was thinking to just give a size >>>> > tPmsiTunnelAttributeId OBJECT-TYPE range so that it is flexible. >>>> > Is that ok? >>>> I see that you have changed the size upper limit to 50. >>>> If the size varies continuously from 0 to 50 the above description >>>> is correct. >>>> Please confirm, explain and cite appropriate reference. If the size >>>> may change in the future that must be stated too. >>> >>> >>> I changed to discrete sizes for currently defined tunnel types. >>> >>>> >>>> 8.4 >>>> > > > 8.4 l2L3VpnMcastPmsiTunnelIf OBJECT-TYPE >>>> > > > SYNTAX RowPointer >>>> > > > MAX-ACCESS read-only >>>> > > > STATUS current >>>> > > > DESCRIPTION >>>> > > > "If the tunnel has a corresponding interface, >>>> > > > this is the row pointer to the ifName table." >>>> > > > o DESCRIPTION looks incorrect. Please fix it. Do you >>>> > > > want to say this object points to the corresponding >>>> > > > row in the ifTable? >>>> > >>>> > Yes. Fixed. >>>> Not quite. >>>> What is ifName table ? ifName is a columnar object in the ifXTable. >>>> Is l2L3VpnMcastPmsiTunnelIf a pointer to the corresponding row in the >>>> ifXTable table ? Please fix accordingly. >>> >>> >>> You're right. Fixed. >>> >>>> >>>> 9. >>>> > > > 9. The Security Considerations section does not follow >>>> > > > the Security Guidelines for IETF MIB Modules >>>> > > > http://trac.tools.ietf.org/area/ops/trac/wiki/mib-security. >>>> > > > Please fix. >>>> > >>>> > I was really hoping that it would not have to be that >>>> > tedious. SNMP/MIB secur >>>> ity should be no different from the >>>> > CLI security - once you secure the infrastructure >>>> > then what's more to do? >>>> > >>>> > I'll need more time to work on this. Let me try to address >>>> > the issues in the other mib first and come back to this. >>>> >>>> Please take your time. Looking at examples will help. And let me >>>> know where I can help. >>> >>> >>> I will need to work on that later. >>> >>>> >>>> 10.1 >>>> > > > 10.1 Checking nits according to >>>> > > > http://www.ietf.org/id-info/checklist : >>>> > Should I break them into different lines or just keep them >>>> > as is? Any example of expected indentation if I break the >>>> > lines? >>>> No problems at all to break lines. >>>> l2L3VpnMcastGroups OBJECT IDENTIFIER >>>> ::= {l2L3VpnMcastConformance 1} >>>> Should do. >>> >>> >>> Done. >>> >>>> >>>> 10.2 >>>> > > > 10.2 Checking references for intended status: Proposed Standard >>>> > > > == Missing Reference: 'RFC 7117' is mentioned on line 76, >>>> > > > but not defined >>>> > > > 'described in [RFC6513, RFC6514, RFC 7117] and other >>>> > I hope I understood and fixed it (removing the space in "RFC 7117"). >>>> I would recommend that you put it as [RFC6513], [RFC6514], [RFC7117] >>>> That is simpler to parse. >>> >>> >>> I see some other documents do not have comma between multiple references >>> so I followed that. >>> >>>> >>>> > > > 11. There is another WIP MVPN-MIB in >>>> > > > draft-ietf-bess-mvpn-mib-02.txt >>>> > > > MVPN-MIB has objects that refer to L2L3-VPN-MCAST-MIB. >>>> > > > Is there a good reason for not merging the 2 documents? >>>> > > > I have not seen any discussion or explanation on this. >>>> > > > I may have missed it. >>>> > > > Please clarify or, give some pointers. >>>> > >>>> > As mentioned in the introduction: >>>> > >>>> > this memo describes managed objects common to both VPLS >>>> > Multicast [RFC7117] and MVPN [RFC6513, RFC6514]. >>>> > MVPN-MIB is for MVPN. There was another VPLS Multicast MIB >>>> > in the work and both would reference common >>>> >>>> > objects defined in this MIB. >>>> >>>> OK. So you are saying that this MIB contains core objects that >>>> will be used to manage implementations of various multicast VPN >>>> protocols e.g. [RFC7117], [RFC6513],[RFC6514] ? It will help if >>>> you spell it out at the beginning. >>> >>> >>> Yes. I thought I did it already: >>> >>> 1. Introduction >>> >>> ... and this memo describes managed objects common to both VPLS >>> Multicast [RFC7117] and MVPN [RFC6513, RFC6514]. >>> >>> Thanks! >>> Jeffrey >>> >>>> >>>> ---------------------------------------------------------------------- >>>> On 2016/04/16 21:47, Jeffrey (Zhaohui) Zhang wrote: >>>>> >>>>> Glenn, >>>>> >>>>> Thanks for your comments. I've addressed most of your comments in the >>>> >>>> new revision: >>>>> >>>>> >>>>> URL: https://www.ietf.org/internet-drafts/draft-ietf-bess- >>>> >>>> l2l3-vpn-mcast-mib-03.txt >>>>> >>>>> Status: https://datatracker.ietf.org/doc/draft-ietf-bess-l2l3- >>>> >>>> vpn-mcast-mib/ >>>>> >>>>> Htmlized: https://tools.ietf.org/html/draft-ietf-bess-l2l3-vpn- >>>> >>>> mcast-mib-03 >>>>> >>>>> Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-l2l3- >>>> >>>> vpn-mcast-mib-03 >>>>> >>>>> >>>>> Please see below. >>>>> >>>>>> 1. Abstract: >>>>>> 1.1 A sentence on how the managed objects will be used by >>>>>> applications for operations, monitoring and management >>>>>> would be good. >>>>> >>>>> >>>>> I had thought this would be standard/obvious for all MIB objects - the >>>> >>>> read-write ones are used to control how a device works, and the read-only >>>> ones are used for monitoring. Do I really need to say it explicitly? >>>>> >>>>> >>>>> I see RFC 4382 has the following: >>>>> >>>>> This memo defines a portion of the Management Information Base (MIB) >>>>> for use with network management protocols in the Internet community. >>>>> In particular, it describes managed objects to configure and/or >>>>> monitor Multiprotocol Label Switching Layer-3 Virtual Private >>>>> Networks on a Multiprotocol Label Switching (MPLS) Label Switching >>>>> Router (LSR) supporting this feature. >>>>> >>>>> Is it enough to say something similar? For example: >>>>> >>>>> In particular, it describes common managed objects used to >>>> >>>> configure >>>>> >>>>> and/or monitor both L2 and L3 VPN Multicast. >>>>> >>>>>> >>>>>> 2. Introduction >>>>>> 2.1 Please give the full expansion of the abbreviations >>>>>> appearing for the first time. (PE, VPLS,..) >>>>> >>>>> >>>>> Fixed. >>>>> >>>>>> >>>>>> 2.2 The terminology section is a bit terse. Explaining the >>>>>> terms that are used, nicely with reference to the protocol >>>>>> documents will improve readability. >>>>>> e.g. >>>>>> - PMSI, I-PMSI, S-PMSI, provider tunnels >>>>> >>>>> >>>>> As the paragraph alluded to, this MIB needs to be understood in the >>>> >>>> general context of L2/L3 multicast VPN and providing good explanation of >>>> the terms is not attempted. The references for the terms are the the RFCs >>>> for the relevant technologies. >>>>> >>>>> >>>>> Having said that, I'll explain PMSI a bit further. >>>>> >>>>>> 2.3 Is there a difference between >>>>>> "multicast in Layer 2 and Layer 3 VPNs , defined by >>>>>> RFC 7117 and RFC 6513/6514" >>>>>> used in the DESCRIPTION in the MODULE-IDENTITY >>>>>> and >>>>>> "multicast in BGP/MPLS L2 or IP VPN" >>>>>> used in the DESCRIPTION of L2L3VpnMcastProviderTunnelType ? >>>>>> If these are the same, it will be helpful to stick to the >>>>>> same expression. If these are not the same, the dictinction >>>>>> should be clarified. >>>>> >>>>> >>>>> No difference. I was using "Layer 3" or "L3" but it was pointed out that >>>> >>>> the layer 3 VPN is often referred to IP VPN in other RFCs and I was >>>> advised to change it accordingly. Looks like I did not change all the >>>> cases. >>>>> >>>>> >>>>> On the other hand, I noticed that RFC 4382 does use "Layer 3 VPN" so >>>> >>>> I'll change it back. >>>>> >>>>> >>>>>> >>>>>> >>>>>> 3. Summary of MIB Module. >>>>>> An overview of the L2L3-VPN-MCAST-MIB will be good- the >>>>>> structure of the MIB, short descriptions of the table(s) >>>>>> including usage of the table(s) for management and/or by >>>>>> other MIB(s). >>>>> >>>>> >>>>> I had that, but have added one sentence about the only table. >>>>> >>>>>> >>>>>> MIB definitions: >>>>>> 4. MIB syntax checking: >>>>>> smilint -s -e -l 5 mibs/L2L3-VPN-MCAST-MIB 2>L2L3-VPN-MCAST-MIB.txt >>>>> >>>>> >>>>> I used simpleweb's validation tool but looks like I did not use the >>>> >>>> strictest level of validation. I've now fixed the following issues and >>>> verified. >>>>> >>>>> >>>>>> >>>>>> mibs/L2L3-VPN-MCAST-MIB:63: [4] {hyphen-in-label} warning: named >>>> >>>> number `rsvp-p2mp' must not include a hyphen in SMIv2 >>>>>> >>>>>> mibs/L2L3-VPN-MCAST-MIB:64: [4] {hyphen-in-label} warning: named >>>> >>>> number `ldp-p2mp' must not include a hyphen in SMIv2 >>>>>> >>>>>> mibs/L2L3-VPN-MCAST-MIB:65: [4] {hyphen-in-label} warning: named >>>> >>>> number `pim-asm' must not include a hyphen in SMIv2 >>>>>> >>>>>> mibs/L2L3-VPN-MCAST-MIB:66: [4] {hyphen-in-label} warning: named >>>> >>>> number `pim-ssm' must not include a hyphen in SMIv2 >>>>>> >>>>>> mibs/L2L3-VPN-MCAST-MIB:67: [4] {hyphen-in-label} warning: named >>>> >>>> number `pim-bidir' must not include a hyphen in SMIv2 >>>>>> >>>>>> mibs/L2L3-VPN-MCAST-MIB:68: [4] {hyphen-in-label} warning: named >>>> >>>> number `ingress-replication' must not include a hyphen in SMIv2 >>>>>> >>>>>> mibs/L2L3-VPN-MCAST-MIB:69: [4] {hyphen-in-label} warning: named >>>> >>>> number `ldp-mp2mp' must not include a hyphen in SMIv2 >>>>> >>>>> >>>>> See later question/comments below. >>>>> >>>>>> mibs/L2L3-VPN-MCAST-MIB:215: [5] {group-unref} warning: current >>>> >>>> group `l2L3VpnMcastOptionalGroup' is not referenced in this module >>>>>> >>>>>> mibs/L2L3-VPN-MCAST-MIB:4: [5] {import-unused} warning: identifier >>>> >>>> `NOTIFICATION-TYPE' imported from module `SNMPv2-SMI' is never used >>>>>> >>>>>> mibs/L2L3-VPN-MCAST-MIB:5: [5] {import-unused} warning: identifier >>>> >>>> `Unsigned32' imported from module `SNMPv2-SMI' is never used >>>>>> >>>>>> mibs/L2L3-VPN-MCAST-MIB:8: [5] {import-unused} warning: identifier >>>> >>>> `NOTIFICATION-GROUP' imported from module `SNMPv2-CONF' is never used >>>>>> >>>>>> mibs/L2L3-VPN-MCAST-MIB:11: [5] {import-unused} warning: identifier >>>> >>>> `TruthValue' imported from module `SNMPv2-TC' is never used >>>>>> >>>>>> mibs/L2L3-VPN-MCAST-MIB:11: [5] {import-unused} warning: identifier >>>> >>>> `RowStatus' imported from module `SNMPv2-TC' is never used >>>>>> >>>>>> mibs/L2L3-VPN-MCAST-MIB:12: [5] {import-unused} warning: identifier >>>> >>>> `TimeStamp' imported from module `SNMPv2-TC' is never used >>>>>> >>>>>> mibs/L2L3-VPN-MCAST-MIB:12: [5] {import-unused} warning: identifier >>>> >>>> `TimeInterval' imported from module `SNMPv2-TC' is never used >>>>>> >>>>>> mibs/L2L3-VPN-MCAST-MIB:15: [5] {import-unused} warning: identifier >>>> >>>> `SnmpAdminString' imported from module `SNMP-FRAMEWORK-MIB' is never used >>>>>> >>>>>> mibs/L2L3-VPN-MCAST-MIB:18: [5] {import-unused} warning: identifier >>>> >>>> `InetAddress' imported from module `INET-ADDRESS-MIB' is never used >>>>>> >>>>>> mibs/L2L3-VPN-MCAST-MIB:18: [5] {import-unused} warning: identifier >>>> >>>> `InetAddressType' imported from module `INET-ADDRESS-MIB' is never used >>>>> >>>>> >>>>> Removed the above unused imports. >>>>> >>>>>> >>>>>> 5. REFERENCE clauses: Please use REFERENCE clauses liberally. >>>>>> Wherever possible, provide references for objects used in >>>>>> the MIB. The references will point to specific sections/ >>>>>> sub-sections of the RFCs defining the protocol for which the >>>>>> MIB is being designed. It will greatly improve the readability >>>>>> of the document. >>>>> >>>>> >>>>> Added. >>>>> >>>>>> >>>>>> 6. IMPORTS clause >>>>>> MIB modules from which items are imported must be cited and >>>>>> included in the normative references. >>>>>> The conventional style is >>>>>> mplsStdMIB >>>>>> FROM MPLS-TC-STD-MIB -- [RFC3811] >>>>> >>>>> >>>>> Added. >>>>> >>>>>> >>>>>> 7. Please update the MODULE-IDENTITY. (There are no syntantic errors.) >>>>>> 7.1 CONTACT-INFO >>>>>> Following the conventions (including indentation style) will >>>>>> improve the readability. (e.g. RFC4382, RFC5132). >>>>>> Will be good if it does not overflow into the next page. >>>>> >>>>> >>>>> Fixed. >>>>> >>>>>> >>>>>> 7.2 REVISION clause: follow the convention recommended in RFC4181 >>>>>> sec 4.5 >>>>>> REVISION "200212132358Z" -- December 13, 2002 >>>>>> DESCRIPTION "Initial version, published as RFC yyyy." >>>>>> -- RFC Ed.: replace yyyy with actual RFC number & remove this note: >>>>> >>>>> >>>>> Fixed. >>>>> >>>>>> 7.3 OID assignment: follow the convention recommended in RFC4181 >>>>>> sec 4.5 i >>>>>> replace >>>>>> ::= { experimental 99 } -- number to be assigned >>>>>> by >>>>>> ::= { XXX } >>>>>> -- RFC Ed.: replace XXX with IANA-assigned number & remove this note >>>>>> will be the subtree under which the module will be >>>>>> registered. >>>>>> >>>>> >>>>> I kept "experimental 99" so that I could continue to use mib tools to >>>> >>>> validate; but I added notes for the editor to replace them as you >>>> indicated. >>>>> >>>>> >>>>>> >>>>>> 8. Specific MO and TC related comments. >>>>>> L2L3VpnMcastProviderTunnelType ::= TEXTUAL-CONVENTION >>>>>> STATUS current >>>>>> DESCRIPTION >>>>>> "Types of provider tunnels used for multicast in >>>>>> BGP/MPLS L2 or IP VPN." >>>>>> SYNTAX INTEGER { unconfigured (0), >>>>>> rsvp-p2mp (1), >>>>>> ldp-p2mp (2), >>>>>> pim-asm (3), >>>>>> pim-ssm (4), >>>>>> pim-bidir (5), >>>>>> ingress-replication (6), >>>>>> ldp-mp2mp (7) >>>>>> >>>>>> o Would be nice to align the enumeration labels with the >>>>>> labels in the protocol document RFC 6514 unless there is >>>>>> a good reason for not doing so. (You will have to take >>>>>> care of the smi compilation errors too; '-' is not allowed ). >>>>> >>>>> >>>>> Are spaces allowed? I don't know so I used hyphen. For now I replace >>>> >>>> with things like rsvpP2mp. >>>>> >>>>> Or could/should I just remove the definitions, so that if a new type is >>>> >>>> defined in the future there is no need to update the MIB? >>>>> >>>>> >>>>>> >>>>>> 8.1 l2L3VpnMcastPmsiTunnelAttributeEntry OBJECT-TYPE >>>>>> SYNTAX L2L3VpnMcastPmsiTunnelAttributeEntry >>>>>> MAX-ACCESS not-accessible >>>>>> STATUS current >>>>>> DESCRIPTION >>>>>> "An entry in this table corresponds to an PMSI attribute >>>>>> that is advertised/received on this router. >>>>>> For BGP-based signaling (for I-PMSI via auto-discovery >>>>>> procedure, or for S-PMSI via S-PMSI A-D routes), >>>>>> they are just as signaled by BGP (RFC 6514 section 5, >>>>>> 'PMSI Tunnel attribute'). >>>>>> For UDP-based S-PMSI signaling for PIM-MVPN, >>>>>> they're derived from S-PMSI Join Message >>>>>> (RFC 6513 section 7.4.2, 'UDP-based Protocol').. >>>>>> >>>>>> Note that BGP-based signaling may be used for >>>>>> PIM-MVPN as well." >>>>>> o Fix the ".." in "'UDP-based Protocol').." above. >>>>>> o Please give the reference for this Table. >>>>>> Is it- "PMSI Tunnel attribute" in RFC 6513 Sec.4 ? >>>>>> "PMSI Tunnel attribute" in RFC 6514 Sec.5 ? >>>>>> both? >>>>>> Any other pointers? >>>>> >>>>> >>>>> Fixed. >>>>> >>>>>> >>>>>> 8.2 l2L3VpnMcastPmsiTunnelAttributeFlags OBJECT-TYPE >>>>>> SYNTAX OCTET STRING (SIZE (1)) >>>>>> MAX-ACCESS not-accessible >>>>>> STATUS current >>>>>> DESCRIPTION >>>>>> "For UDP-based S-PMSI signaling for PIM-MVPN, this is 0. >>>>>> For BGP-based I/S-PMSI signaling, this is the Flags >>>>>> field in PMSI Tunnel Attribute of the corresponding >>>>>> I/S-PMSI A-D route." >>>>>> ::= { l2L3VpnMcastPmsiTunnelAttributeEntry 1 } >>>>>> o Please confirm that the above is a complete enumeration of the >>>>>> types of signalling. >>>>>> o RFC 6514 Sec.5 says that the Flags field indicates >>>>>> "Leaf Information Required". That is useful information. >>>>>> Please include in the description. >>>>> >>>>> >>>>> The intent is to simply return the octet value of the flags field, w/o >>>> >>>> listing individual bits like "Leaf Information Required". More bits could >>>> be defined in the future but the MIB would not change. >>>>> >>>>> >>>>> Is that OK? >>>>> >>>>>> >>>>>> 8.3 l2L3VpnMcastPmsiTunnelAttributeId OBJECT-TYPE >>>>>> SYNTAX OCTET STRING ( SIZE (0..37) ) >>>>>> MAX-ACCESS not-accessible >>>>>> STATUS current >>>>>> DESCRIPTION >>>>>> "For UDP-based S-PMSI signaling for PIM-MVPN, the first >>>>>> four or sixteen octets of this attribute are filled with >>>>>> the provider tunnel group address (IPv4 or IPv6).. >>>>>> For BGP-based I/S-PMSI signaling, this is the Tunnel >>>> >>>> Identifier >>>>>> >>>>>> Field in PMSI Tunnel Attribute of the corresponding I/S- >>>> >>>> PMSI >>>>>> >>>>>> A-D route." >>>>>> o Check the size specifications. The specs above say it can be >>>>>> all sizes 0..37. That is not clear from the DESCRIPTION clause. >>>>>> o Fix the ".." in "(IPv4 or IPv6).." above. >>>>>> o RFC 6514 Sec 5. PMSI Tunnel Attribute gives the Tunnel >>>> >>>> Identifiers >>>>>> >>>>>> for mLDP, PIM-SM, PIM-SSM, BIDIR-PIM,Ingress Replication,MP2MP. >>>>>> It appears that the sizes (range) for each case will be >>>>>> different. >>>>>> Please clarify that, and if there are discrete sizes, specify >>>>>> accordingly. >>>>> >>>>> >>>>> Depending on the tunnel type, there could be different sizes. Future >>>> >>>> tunnel types could have other sizes that not specified today. I was >>>> thinking to just give a size range so that it is flexible. Is that ok? >>>>> >>>>> >>>>>> >>>>>> >>>>>> 8.3 l2L3VpnMcastPmsiTunnelPointer OBJECT-TYPE >>>>>> SYNTAX RowPointer >>>>>> MAX-ACCESS read-only >>>>>> STATUS current >>>>>> DESCRIPTION >>>>>> "If the tunnel exists in some MIB table, this is the >>>>>> row pointer to it." >>>>>> o "some MIB table" : specify which MIB table. >>>>> >>>>> >>>>> I can give an example, like mplsTunnelTable [RFC 3812]. It could be >>>> >>>> whatever table that a tunnel may be put into. >>>>> >>>>> >>>>>> o In what case will the tunnel exist and in what case will it not? >>>>> >>>>> >>>>> If a device supports mplsTunnelTable and the tunnel is represented >>>>> there, >>>> >>>> then it exists. >>>>> >>>>> >>>>>> o What will be the behaviour if the above condition is not >>>> >>>> satisfied? >>>>> >>>>> >>>>> A null pointer should be given. >>>>> >>>>>> >>>>>> 8.4 l2L3VpnMcastPmsiTunnelIf OBJECT-TYPE >>>>>> SYNTAX RowPointer >>>>>> MAX-ACCESS read-only >>>>>> STATUS current >>>>>> DESCRIPTION >>>>>> "If the tunnel has a corresponding interface, this is the >>>>>> row pointer to the ifName table." >>>>>> o DESCRIPTION looks incorrect. Please fix it. Do you want to say >>>>>> this object points to the corresponding row in the ifTable? >>>>> >>>>> >>>>> Yes. Fixed. >>>>> >>>>>> o In what case does the TunnelIf exist and in what case will it >>>> >>>> not? >>>>> >>>>> >>>>> Some tunnels may not have a corresponding interface. >>>>> >>>>>> o What will be expected if the tunnel does not have a >>>> >>>> corresponding >>>>>> >>>>>> interface? >>>>> >>>>> >>>>> Null row pointer. >>>>> >>>>>> >>>>>> 9. The Security Considerations section does not follow the Security >>>>>> Guidelines for IETF MIB Modules >>>>>> http://trac.tools.ietf.org/area/ops/trac/wiki/mib-security. >>>>>> Please fix. >>>>> >>>>> >>>>> I was really hoping that it would not have to be that tedious. SNMP/MIB >>>> >>>> security should be no different from the CLI security - once you secure >>>> the infrastructure then what's more to do? >>>>> >>>>> >>>>> I'll need more time to work on this. Let me try to address the issues in >>>> >>>> the other mib first and come back to this. >>>>> >>>>> >>>>>> >>>>>> >>>>>> 10.ID-nits >>>>>> 10.1 Checking nits according to http://www.ietf.org/id-info/checklist : >>>>>> ------------------------------------------------------------------ >>>> >>>> --------- >>>>>> >>>>>> >>>>>> ** There are 4 instances of too long lines in the document, the >>>> >>>> longest one >>>>>> >>>>>> being 3 characters in excess of 72. >>>>> >>>>> >>>>> I fixed some but there still three too long lines: >>>>> >>>>> l2L3VpnMcastPmsiTunnelAttributeType >>>>> L2L3VpnMcastProviderTunnelType, >>>>> >>>>> l2L3VpnMcastGroups OBJECT IDENTIFIER ::= {l2L3VpnMcastConformance >>>> >>>> 1} >>>>> >>>>> l2L3VpnMcastCompliances OBJECT IDENTIFIER ::= {l2L3VpnMcastConformance >>>> >>>> 2} >>>>> >>>>> >>>>> Should I break them into different lines or just keep them as is? Any >>>> >>>> example of expected indentation if I break the lines? >>>>> >>>>> >>>>>> >>>>>> 10.2 Checking references for intended status: Proposed Standard >>>>>> ------------------------------------------------------------------ >>>> >>>> --------- >>>>>> >>>>>> >>>>>> == Missing Reference: 'RFC 7117' is mentioned on line 76, but not >>>>>> defined >>>>>> 'described in [RFC6513, RFC6514, RFC 7117] and other documents >>>> >>>> tha...' >>>>> >>>>> >>>>> I hope I understood and fixed it (removing the space in "RFC 7117"). >>>>> >>>>>> >>>>>> 11. There is another WIP MVPN-MIB in draft-ietf-bess-mvpn-mib-02.txt >>>>>> MVPN-MIB has objects that refer to L2L3-VPN-MCAST-MIB. >>>>>> Is there a good reason for not merging the 2 documents? I have not >>>> >>>> seen >>>>>> >>>>>> any discussion or explanation on this. I may have missed it. >>>> >>>> Please >>>>>> >>>>>> clarify or, give some pointers. >>>>> >>>>> >>>>> As mentioned in the introduction: >>>>> >>>>> this memo describes managed objects common to both VPLS >>>>> Multicast [RFC7117] and MVPN [RFC6513, RFC6514]. >>>>> >>>>> MVPN-MIB is for MVPN. There was another VPLS Multicast MIB in the work >>>> >>>> and both would reference common objects defined in this MIB. >>>>> >>>>> >>>>> Thanks! >>>>> Jeffrey >>>>> >>>>>> -----Original Message----- >>>>>> From: BESS [mailto:bess-bounces@ietf.org] On Behalf Of Glenn Mansfield >>>>>> Keeni >>>>>> Sent: Tuesday, April 12, 2016 2:28 AM >>>>>> To: Benoit Claise ; EXT - thomas.morin@orange.com >>>>>> >>>>>> Cc: Jeffrey (Zhaohui) Zhang ; ops-ads@ietf.org; >>>> >>>> Martin >>>>>> >>>>>> Vigoureux ; bess@ietf.org; Mach Chen >>>>>> >>>>>> Subject: [bess] MIBDoc review of draft-ietf-bess-l2l3-vpn-mcast-mib- >>>> >>>> 02.txt >>>>>> >>>>>> >>>>>> Hi, >>>>>> I have been asked to do a MIB Doctors review of >>>>>> draft-ietf-bess-l2l3-vpn-mcast-mib-02.txt. >>>>>> My knowledge of L2L3VPN Multicast is limited to the reading >>>>>> of this document and browsing through the documents referred >>>>>> to in the draft and bess-wg mailing list archives.( read "shallow"). >>>>>> So some of the doubts and questions may sound trivial or >>>>>> strange. Please bear with me and help me help you make >>>>>> this into a better document :-) >>>>>> >>>>>> The comments are attached. >>>>>> >>>>>> Glenn >>>>>> >>>>> >>>>> _______________________________________________ >>>>> BESS mailing list >>>>> BESS@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/bess >>>>> >>> >>> >> >> >> _______________________________________________ >> BESS mailing list >> BESS@ietf.org >> https://www.ietf.org/mailman/listinfo/bess >> From nobody Tue Dec 6 01:55:37 2016 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2DB8129F26; Tue, 6 Dec 2016 01:55:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.129 X-Spam-Level: X-Spam-Status: No, score=-4.129 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-2.896, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id st72UCsa0KxQ; Tue, 6 Dec 2016 01:55:30 -0800 (PST) Received: from p-mail2.rd.orange.com (p-mail2.rd.orange.com [161.106.1.3]) by ietfa.amsl.com (Postfix) with ESMTP id E8A4E129F23; Tue, 6 Dec 2016 01:55:28 -0800 (PST) Received: from p-mail2.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id E4E9EE3007C; Tue, 6 Dec 2016 10:55:27 +0100 (CET) Received: from FTRDCH01.rd.francetelecom.fr (unknown [10.194.32.11]) by p-mail2.rd.orange.com (Postfix) with ESMTP id CD7CDE30078; Tue, 6 Dec 2016 10:55:27 +0100 (CET) Received: from [10.193.71.12] (10.193.71.12) by FTRDCH01.rd.francetelecom.fr (10.194.32.11) with Microsoft SMTP Server id 14.3.301.0; Tue, 6 Dec 2016 10:55:27 +0100 From: Thomas Morin To: "Ali Sajassi (sajassi)" , "draft-ietf-bess-evpn-etree@ietf.org" , Loa Andersson , "George Swallow -T (swallow - MBO PARTNERS INC at Cisco)" , Eric Rosen , BESS References: <3323ddae-c96f-49a4-2dec-1bfc4ed857dc@orange.com> <6cb41698-b98b-ecbf-9e34-660771bd3fb8@orange.com> Organization: Orange Message-ID: <0b846411-4526-c6d3-3ea4-87ebd90de953@orange.com> Date: Tue, 6 Dec 2016 10:55:27 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------C32DDCF9198071689B8A4AD0" Archived-At: Cc: Martin Vigoureux Subject: Re: [bess] shepherd review of draft-ietf-bess-evpn-etree X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2016 09:55:35 -0000 --------------C32DDCF9198071689B8A4AD0 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit Hi Ali, Ali Sajassi (sajassi): > Thanks again for your additional comments. Below, please find my > comment resolutions. Let me know please if there are any further > comments. Answers below... >>> EVI. The purpose of this topology constraint is to avoid having PEs >>> with only Leaf sites importing and processing BGP MAC routes from >>> each other. To support such topology constrain in EVPN, two BGP >>> Route-Targets (RTs) are used for every EVPN Instance (EVI): one RT is >>> associated with the Root sites and the other is associated with the >>> Leaf sites. On a per EVI basis, every PE exports the single RT >>> associated with its type of site(s). Furthermore, a PE with Root >>> site(s) imports both Root and Leaf RTs, whereas a PE with Leaf >>> site(s) only imports the Root RT. >> >> The text seems to imply that the above is sufficient to deliver the >> service, but I fail to see what would prevent Leaf-to-Leaf traffic >> between Leaves bound to the same MAC-VRF (ES2 and ES3 in firgure1). >> Shouldn't the text mention the use of a split-horizon in Leaf MAC-VRFs ? >> >> >> Agree, nice catch!. I changed the first sentence from: >> "In such scenario, an EVPN PE implementation MAY provide E-TREE >> service using topology constraint among the PEs belonging to the same >> EVI." >> TO >> "In such scenario, topology constraint, provided by BGP Route Target >> (RT) import/export policies among the PEs belonging to the same EVI, >> can be used to restrict the communications among Leaf PEs." > > The sentence above does not address my question in fact, which was > about communication between Leaf ACs (rather than about communication > between Leaf PEs) > Let me restate here, more clearly: I fail to see what would prevent > Leaf-to-Leaf traffic between **ACs** bound to the same MAC-VRF (ES2 > and ES3 in firgure1). Shouldn't the text mention the use of a > split-horizon in Leaf MAC-VRFs ? > > OK. I mentioned the use of split-horizon filtering explicitly for > blocking inter-Leaf communication within the same PE. > > "In such scenario, using tailored BGP Route Target (RT) import/export > policies among the PEs belonging to the same EVI, can be used to > restrict the communications among Leaf PEs. To restrict the > communications among leaf sites connected to the same PE and > belonging to the same EVI, split-horizon filtering is used - i.e., the > interfaces associated with Leaf sites are placed in the same > split-horizon group. " > Mentioning this here is an improvement. Perhaps a reference is needed to explain what a split-horizon _group_ is though, or simply rephrase to avoid the notion ? Proposal: "split-horizon is used to block traffic from one Leaf interface to another Leaf interface of a given E-TREE EVI". >> >> (assuming the previous point is resolved:) >> >> With this mechanism above, isn't it possible to have on a given PE, >> for a single E-TREE EVI, both Leaves and Roots, as long as distinct >> MAC-VRFs are used (one for Leaves and one for Roots) ? (it seems to >> me that the assymetric import/export RT would do what is needed to >> build an E-TREE, we would just have a particular case where a Leaf >> MAC-VRF and a Root MAC-VRF for a given E-TREE end up on a single PE) >> >> >> That’s not possible because per definition of an EVI, there is only a >> single MAC-VRF per EVI for a PE. > > Where can I read such a definition ? (the Terminology section in > RFC7432 does not say that, unless I'm missing something). > And that seems a completely arbitrary restriction. > (just thinking that a given PE device can be split in two logical > devices show that it can work) > > Section 6 of RFC7432 where it gives definitions for different service > interface types, it specifies the relationship between MAC-VRF and > VLAN (bridge table) and how many MAC-VRF (and bridge tables) can be > per EVI. This section of RFC7434 discusses many different things for the different variants. Can you provide a specific pointer about "how many MAC-VRFs can be per EVI" ? > In bridging world, there can only be a single bridge table per VLAN in > a device. I still don't find here anything that would preclude having, on a given PE, for a given E-TREE EVI, one Leaves MAC-VRF and one Roots MAC-VRF: can't these two MAC-VRFs use different internal VLANs (with translation if the external VLANs are constrained). > >> Besides, I don’t understand what good does it do to have two MAC-VRFs >> on the same PE (one for Leafs and another for Roots) > > Well, the "what is good for" is pretty simple: it means you can have, > just by tailoring the import/export policies like in 2.1, something as > useful as the scenario in 2.2. > > There can only be a single bridge table per VLAN. Now even if you add > some kind of logic to form two logical PEs in single physical PE, you > end up replicating all the MAC addresses associated with the root > sites in two bridge tables. Your point above certainly does not sound to me as "it can't be done": some may think that the above is an acceptable cost, some others may find ways to make this "replication" with a low overhead, on some platforms the cost may be negligible, etc. > > >> because Leafs and Roots need to talk to each other and thus we want >> them to be in the same MAC-VRF. > > The fact that Leafs and Roots need to talk to each other does not mean > that they *have* to be in the same MAC-VRF, you can rely on the local > MPLS dataplane inside the PE to carry the traffic between Roots and > Leaves can be passed between a Leaf MAC-VRF and a Root MAC-VRF (and > you can possibly implement a shortcut not involving MPLS encap/decap). > > Anything is possible but at what cost. You know, for cost it is not always obvious to reach conclusions that are true for all implementations and all targets. > The current proposal is very efficient in terms of forwarding path as > well as control plane. Sure, but what I question is not the new solution but the lack of discussion on why using the existing specs was not considered good enough. I think that my concern of clearly explaining the scenarios and motivations for this new spec could be addressed by splitting section 2.2 into a 2.2.1 describing the approach from 2.1 and its possible drawbacks, and a 2.2.2 having essentially the content of current section 2.2. Here is a proposal: 2.2 Scenario 2: Leaf of Root site(s) per AC In these scenarii, a PE receives traffic from either Root OR Leaf sites (but not both) on a given Attachment Circuit (AC) of an EVI. In other words, an AC (ES or ES/VLAN) is either associated with Root(s) or Leaf(s) (but not both). 2.2.1 Scenario 2a: Leaf OR Root site(s) per AC, separate Leaf/Root MAC-VRFs +---------+ +---------+ | PE1 | | PE2 | +---+ | +---+ | +------+ | +---+ | +---+ |CE1+-----ES1----+--+ | | | | | |MAC+--+---ES2/AC1--+CE2| +---+ (Leaf) | |MAC| | | MPLS | | |VRF| | (Leaf) +---+ | |VRF| | | /IP | | '---' | | | | | | | | .---. | | | | | | | | |MAC| | +---+ | | | | | | | |VRF+--+---ES2/AC2--+CE3| | +---+ | +------+ | +---+ | (Root) +---+ +---------+ +---------+ Figure 2: Scenario 2a In this scenario, the RT constraint procedures described in section 2.1 could also be used. The feasibility and efficiency of this approach depends on platforms specifics. This approach will lead toduplication of a large proportion of MAC addresseson PEs having both Leaf and Root sites, and is hence considered less suitable for deployment contexts where the vast majority of PEs are likely to ultimately have both Leaf and Root sites attached to them. 2.2.2 Scenario 2b: Leaf OR Root site(s) per AC, single MAC-VRF +---------+ +---------+ | PE1 | | PE2 | +---+ | +---+ | +------+ | +---+ | +---+ |CE1+-----ES1----+--+ | | | | | | +--+---ES2/AC1--+CE2| +---+ (Leaf) | |MAC| | | MPLS | | |MAC| | (Leaf) +---+ | |VRF| | | /IP | | |VRF| | | | | | | | | | | | +---+ | | | | | | | | +--+---ES2/AC2--+CE3| | +---+ | +------+ | +---+ | (Root) +---+ +---------+ +---------+ Figure 2: Scenario 2b This scenario will alleviate keys drawbacks from Scenario 2a, in particular by avoiding duplication of MAC addresses on Leaf/Root PEs and avoiding the operational overhead of managing more than one RT. This approach comes at the expense of having routes for unneeded MAC addresses on Leaf-only PEs, and is hence considered less suitable for deployment contexts where the vast majority of PEs would remain Leaf-only. Unlike Scenario 1 and Scenario 2a, this scenario requires additional procedures provided in this document. (And this last sentence should be added to section 2.3 as well) > >>> For this scenario, if for a given >>> EVI, the majority of PEs will eventually have both Leaf and Root >>> sites attached, even though they may start as Root-only or Leaf-only >>> PEs, then it is recommended to use a single RT per EVI and avoid >>> additional configuration and operational overhead. >> >> Why this recommendation ? >> Even with a majority of PEs having both Leaves and Roots, there can >> remain (up to 49% of) PEs having only Leaves, which will uselessly >> have all routes to other Leaves. >> >> So "it is recommended" above, deserves to be explained more, I think. >> >> OK, I changed “majority” to “vast majority” :-) > > My point was not to nit pick on "majority", but was that you should > explain why you recommend that. > As the text currently reads, the cost of the recommendation can be > identified: having useless routes on the fraction of PEs having only > Leaves. > But the gain brought by the recommendation is not even mentioned, not > to say explained. > Hence: why ? > (Why is it a useful tradeoff to have useless routes on some, even if > only one, PE ?) > > Changed the last sentence from: > "then it is recommended to use a single RT per EVI and avoid > additional configuration and operational overhead.” > To > "then it is recommended to use a single RT per EVI and avoid > additional configuration and operational overhead > at the expense of having unwanted MAC addresses on the Leaf PEs." Ok. I adapted and incorporated this addition into my proposed text splitting 2.2 into a 2.2.1 and a 2.2.2. Best, -Thomas --------------C32DDCF9198071689B8A4AD0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 8bit
Hi Ali,

Ali Sajassi (sajassi):
Thanks again for your additional comments. Below, please find my comment resolutions. Let me know please if there are any further comments.

Answers below...


   EVI. The purpose of this topology constraint is to avoid having PEs
   with only  Leaf sites importing and processing BGP MAC routes from
   each other. To support such topology constrain in EVPN, two BGP
   Route-Targets (RTs) are used for every EVPN Instance (EVI): one RT is
   associated with the Root sites and the other is associated with the
   Leaf sites. On a per EVI basis, every PE exports the single RT
   associated with its type of site(s). Furthermore, a PE with Root
   site(s) imports both Root and Leaf RTs, whereas a PE with Leaf
   site(s) only imports the Root RT.

The text seems to imply that the above is sufficient to deliver the service, but I fail to see what would prevent Leaf-to-Leaf traffic between Leaves bound to the same MAC-VRF (ES2 and ES3 in firgure1).  Shouldn't the text mention the use of a split-horizon in Leaf MAC-VRFs ?

Agree, nice catch!. I changed the first sentence from:
"In such scenario, an EVPN PE implementation MAY provide E-TREE service using topology constraint among the PEs belonging to the same EVI."
TO
"In such scenario, topology constraint, provided by BGP Route Target (RT) import/export policies among the PEs belonging to the same EVI, can be used to restrict the communications among Leaf PEs."

The sentence above does not address my question in fact, which was about communication between Leaf ACs (rather than about communication between Leaf PEs)
Let me restate here, more clearly:  I fail to see what would prevent Leaf-to-Leaf traffic between **ACs** bound to the same MAC-VRF (ES2 and ES3 in firgure1).  Shouldn't the text mention the use of a split-horizon in Leaf MAC-VRFs ?

OK. I mentioned the use of split-horizon filtering explicitly for blocking inter-Leaf communication within the same PE.

"In such scenario, using tailored BGP Route Target (RT) import/export policies among the PEs belonging to the same EVI, can be used to restrict the communications among Leaf PEs. To restrict the communications among leaf sites connected to the same PE  and belonging to the same EVI, split-horizon filtering is used - i.e., the interfaces associated with Leaf sites are placed in the same split-horizon group. "


Mentioning this here is an improvement.
Perhaps a reference is needed to explain what a split-horizon _group_ is though, or simply rephrase to avoid the notion ?

Proposal: "split-horizon is used to block traffic from one Leaf interface to another Leaf interface of a given E-TREE EVI".


(assuming the previous point is resolved:)

With this mechanism above, isn't it possible to have on a given PE, for a single E-TREE EVI, both Leaves and Roots, as long as distinct MAC-VRFs are used (one for Leaves and one for Roots) ?   (it seems to me that the assymetric import/export RT would do what is needed to build an E-TREE, we would just have a particular case where a Leaf MAC-VRF and a Root MAC-VRF for a given E-TREE end up on a single PE)

That’s not possible because per definition of an EVI, there is only a single MAC-VRF per EVI for a PE.

Where can I read such a definition ? (the Terminology section in RFC7432 does not say that, unless I'm missing something).
And that seems a completely arbitrary restriction.
(just thinking that a given PE device can be split in two logical devices show that it can work)

Section 6 of RFC7432 where it gives definitions for different service interface types, it specifies the relationship between MAC-VRF and VLAN (bridge table) and how many MAC-VRF (and bridge tables) can be per EVI.

This section of RFC7434 discusses many different things for the different variants.
Can you provide a specific pointer about "how many MAC-VRFs can be per EVI" ?

In bridging world, there can only be a single bridge table per VLAN in a device.

I still don't find here anything that would preclude having, on a given PE, for a given E-TREE EVI, one Leaves MAC-VRF and one Roots MAC-VRF: can't these two MAC-VRFs use different internal VLANs (with translation if the external VLANs are constrained).



Besides, I don’t understand what good does it do to have two MAC-VRFs on the same PE (one for Leafs and another for Roots)

Well, the "what is good for" is pretty simple: it means you can have, just by tailoring the import/export policies like in 2.1, something as useful as the scenario in 2.2.

There can only be a single bridge table per VLAN. Now even if you add some kind of logic to form two logical PEs in single physical PE, you end up replicating all the MAC addresses associated with the root sites in two bridge tables.

Your point above certainly does not sound to me as "it can't be done": some may think that the above is an acceptable cost, some others may find ways to make this "replication" with a low overhead, on some platforms the cost may be negligible, etc.




because Leafs and Roots need to talk to each other and thus we want them to be in the same MAC-VRF.

The fact that Leafs and Roots need to talk to each other does not mean that they *have* to be in the same MAC-VRF, you can rely on the local MPLS dataplane inside the PE to carry the traffic between Roots and Leaves can be passed between a Leaf MAC-VRF and a Root MAC-VRF (and you can possibly implement a shortcut not involving MPLS encap/decap).

Anything is possible but at what cost.

You know, for cost it is not always obvious to reach conclusions that are true for all implementations and all targets.

The current proposal is very efficient in terms of forwarding path as well as control plane.

Sure, but what I question is not the new solution but the lack of discussion on why using the existing specs was not considered good enough.


I think that my concern of clearly explaining the scenarios and motivations for this new spec could be addressed by splitting section 2.2 into a 2.2.1 describing the approach from 2.1 and its possible drawbacks, and a 2.2.2 having essentially the content of current section 2.2.

Here is a proposal:

2.2 Scenario 2: Leaf of Root site(s) per AC

   In these scenarii, a PE receives traffic from either Root OR Leaf
   sites (but not both) on a given Attachment Circuit (AC) of an EVI. In
   other words, an AC (ES or ES/VLAN) is either associated with Root(s)
   or Leaf(s) (but not both).

2.2.1 Scenario 2a: Leaf OR Root site(s) per AC, separate Leaf/Root MAC-VRFs

                     +---------+            +---------+
                     |   PE1   |            |   PE2   |
    +---+            |  +---+  |  +------+  |  +---+  |            +---+
    |CE1+-----ES1----+--+   |  |  |      |  |  |MAC+--+---ES2/AC1--+CE2|
    +---+    (Leaf)  |  |MAC|  |  | MPLS |  |  |VRF|  |   (Leaf)   +---+
                     |  |VRF|  |  |  /IP |  |  '---'  |
                     |  |   |  |  |      |  |  .---.  |
                     |  |   |  |  |      |  |  |MAC|  |            +---+
                     |  |   |  |  |      |  |  |VRF+--+---ES2/AC2--+CE3|
                     |  +---+  |  +------+  |  +---+  |   (Root)   +---+
                     +---------+            +---------+

   Figure 2: Scenario 2a

   In this scenario, the RT constraint procedures described in section 2.1 could
   also be used. The feasibility and efficiency of this approach depends on
   platforms specifics.

   This approach will lead to duplication of a large proportion of MAC addresses on
   PEs having both Leaf and Root sites, and is hence considered less suitable for
   deployment contexts where the vast majority of PEs are likely to ultimately
   have both Leaf and Root sites attached to them.

2.2.2 Scenario 2b: Leaf OR Root site(s) per AC, single MAC-VRF

                     +---------+            +---------+
                     |   PE1   |            |   PE2   |
    +---+            |  +---+  |  +------+  |  +---+  |            +---+
    |CE1+-----ES1----+--+   |  |  |      |  |  |   +--+---ES2/AC1--+CE2|
    +---+    (Leaf)  |  |MAC|  |  | MPLS |  |  |MAC|  |   (Leaf)   +---+
                     |  |VRF|  |  |  /IP |  |  |VRF|  |
                     |  |   |  |  |      |  |  |   |  |            +---+
                     |  |   |  |  |      |  |  |   +--+---ES2/AC2--+CE3|
                     |  +---+  |  +------+  |  +---+  |   (Root)   +---+
                     +---------+            +---------+

   Figure 2: Scenario 2b

   This scenario will alleviate keys drawbacks from Scenario 2a, in particular
   by avoiding duplication of MAC addresses on Leaf/Root PEs and avoiding the
   operational overhead of managing more than one RT.
   This approach comes at the expense of having routes for unneeded MAC addresses
   on Leaf-only PEs, and is hence considered less suitable for deployment contexts
   where the vast majority of PEs would remain Leaf-only.

   Unlike Scenario 1 and Scenario 2a, this scenario requires additional procedures
   provided in this document.
(And this last sentence should be added to section 2.3 as well)


For this scenario, if for a given
   EVI, the majority of PEs will eventually have both Leaf and Root
   sites attached, even though they may start as Root-only or Leaf-only
   PEs, then it is recommended to use a single RT per EVI and avoid
   additional configuration and operational overhead.

Why this recommendation ?
Even with a majority of PEs having both Leaves and Roots, there can remain (up to 49% of) PEs having only Leaves, which will uselessly have all routes to other Leaves.

So "it is recommended" above, deserves to be explained more, I think.

OK, I changed “majority” to “vast majority” :-)

My point was not to nit pick on "majority", but was that you should explain why you recommend that.
As the text currently reads, the cost of the recommendation can be identified: having useless routes on the fraction of PEs having only Leaves.
But the gain brought by the recommendation is not even mentioned, not to say explained.
Hence: why ?
(Why is it a useful tradeoff to have useless routes on some, even if only one, PE ?)

Changed the last sentence from:
"then it is recommended to use a single RT per EVI and avoid additional configuration and operational overhead.”
To
"then it is recommended to use a single RT per EVI and avoid additional configuration and operational overhead
at the expense of having unwanted MAC addresses on the Leaf PEs."

Ok. I adapted and incorporated this addition into my proposed text splitting 2.2 into a 2.2.1 and a 2.2.2.

Best,

-Thomas


--------------C32DDCF9198071689B8A4AD0-- From nobody Fri Dec 9 17:28:28 2016 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E44FC1295B6; Fri, 9 Dec 2016 17:28:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.417 X-Spam-Level: X-Spam-Status: No, score=-17.417 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ktSkfajZeIL; Fri, 9 Dec 2016 17:28:23 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72134129506; Fri, 9 Dec 2016 17:28:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=49369; q=dns/txt; s=iport; t=1481333303; x=1482542903; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=3D/ray/MpU9fTehZmhG4MLWvSBYKO/IqKZ6DFs59BGw=; b=ghhKlD4XegdABg6h1qhC7xqZl9okBUrPpm+QpQQoxP77ZrYSTZv7jrPJ Hvuu8BvGnEqpUKbt+BvaQZDKyr/MPOHVO3X5BS3+5RO+gtyyEQ6Gz+8ZX hfDfE7B1WLhs64WiA8YsTkETd4JojzAHC0EobK+AHg9Vl8tFHdVOMB5/W Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AUAQDQWEtY/4gNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgnM5CwEBAQEBH4FgB41ClxSVAoIKgkYBg1oCgWY/FAECAQEBAQE?= =?us-ascii?q?BAWIohGgBAQEEGlIFAQICAxACAQgRAwECIQEGBzIUCQgCBAENBRuIUK1gL4p1A?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEBHYsZhBlPhUEFmmsBiV6HQoFzhH+DSIYLjgu?= =?us-ascii?q?EDQEfN4EhhVlyh0qBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.33,325,1477958400"; d="scan'208,217";a="357480708" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 10 Dec 2016 01:28:21 +0000 Received: from XCH-RTP-017.cisco.com (xch-rtp-017.cisco.com [64.101.220.157]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id uBA1SLR5029966 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 10 Dec 2016 01:28:21 GMT Received: from xch-rtp-005.cisco.com (64.101.220.145) by XCH-RTP-017.cisco.com (64.101.220.157) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 9 Dec 2016 20:28:20 -0500 Received: from xch-rtp-005.cisco.com ([64.101.220.145]) by XCH-RTP-005.cisco.com ([64.101.220.145]) with mapi id 15.00.1210.000; Fri, 9 Dec 2016 20:28:20 -0500 From: "Ali Sajassi (sajassi)" To: Thomas Morin , "draft-ietf-bess-evpn-etree@ietf.org" , Loa Andersson , "George Swallow -T (swallow - MBO PARTNERS INC at Cisco)" , Eric Rosen , BESS Thread-Topic: shepherd review of draft-ietf-bess-evpn-etree Thread-Index: AQHSAgSQiVios9dTSUOmTfNWP8T6rqBlA4UAgAGT+oCASmTegIBKoSmAgAU1ewA= Date: Sat, 10 Dec 2016 01:28:20 +0000 Message-ID: References: <3323ddae-c96f-49a4-2dec-1bfc4ed857dc@orange.com> <6cb41698-b98b-ecbf-9e34-660771bd3fb8@orange.com> <0b846411-4526-c6d3-3ea4-87ebd90de953@orange.com> In-Reply-To: <0b846411-4526-c6d3-3ea4-87ebd90de953@orange.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.0.161029 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.19.76.53] Content-Type: multipart/alternative; boundary="_000_D46E097E1C5BCAsajassiciscocom_" MIME-Version: 1.0 Archived-At: Cc: Martin Vigoureux Subject: Re: [bess] shepherd review of draft-ietf-bess-evpn-etree X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Dec 2016 01:28:27 -0000 --_000_D46E097E1C5BCAsajassiciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Thomas, Your suggestion regarding multiple MAC-VRFs per EVI for E-TREE, impacts lot= more sections than just section 2.2 for which you suggested some texts. It= drastically impacts section 3.1 (known unicast traffic), and it also impa= cts section 3.2 (BUM traffic) and section 5.1. Furthermore, it creates a ne= w paradigm for EVPN that was never intended for because of creating two MAC= -VRFs (and two bridge tables) for the same VLAN. The WG LC was completed on= 3/29/16 and I am sure it is not your intention to have major changes to th= e doc at this stage where multiple vendors have already implemented the dra= ft. This draft talks about two kinds of traffic filtering: a) ingress filtering= for known unicast and b) egress filtering for BUM traffic. What you are su= ggesting is an alternate mechanism for ingress filtering. Although having m= ultiple VRFs (and forwarding tables) are fine for IP-VPNs because the unkno= wn traffic is always dropped, multiple VRFs for the same VLAN is not OK for= L2 traffic because of flooding of unknown traffic. That=92s why in section= 6 of RFC 7432, for all service interface types, the draft talks about a si= ngle MAC-VRF per EVI per PE and in case of VLAN-aware mode, multiple VLANs= per MAC-VRF but only a single bridge table per VLAN. In other words, the b= ottom line is that there can only be a single bridge table per VLAN in orde= r to avoid unnecessary flooding. When you have two MAC-VRFs per VLAN (one f= or root ACs and another for Leaf ACs), then you either need to duplicate lo= ts of MAC addresses between these two VRFs, or do lookup on both of these V= RFs. Either ways this is not a good option relative to keeping a single VRF= table for both root and leaf sites and just have a single-bit indication o= n whether a MAC is associated with root or leaf (as currently described app= roach in the draft). I Regards, Ali P.S., I included a bit more comment inline =85 From: Thomas Morin = > Organization: Orange Date: Tuesday, December 6, 2016 at 1:55 AM To: Cisco Employee >, "draft-ie= tf-bess-evpn-etree@ietf.org" >, Loa Andersson >, "George Swallow -T (swal= low - MBO PARTNERS INC at Cisco)" >, Eric Rosen >, BESS > Cc: Martin Vigoureux > Subject: Re: shepherd review of draft-ietf-bess-evpn-etree Hi Ali, Ali Sajassi (sajassi): Thanks again for your additional comments. Below, please find my comment re= solutions. Let me know please if there are any further comments. Answers below... EVI. The purpose of this topology constraint is to avoid having PEs with only Leaf sites importing and processing BGP MAC routes from each other. To support such topology constrain in EVPN, two BGP Route-Targets (RTs) are used for every EVPN Instance (EVI): one RT is associated with the Root sites and the other is associated with the Leaf sites. On a per EVI basis, every PE exports the single RT associated with its type of site(s). Furthermore, a PE with Root site(s) imports both Root and Leaf RTs, whereas a PE with Leaf site(s) only imports the Root RT. The text seems to imply that the above is sufficient to deliver the service= , but I fail to see what would prevent Leaf-to-Leaf traffic between Leaves = bound to the same MAC-VRF (ES2 and ES3 in firgure1). Shouldn't the text me= ntion the use of a split-horizon in Leaf MAC-VRFs ? Agree, nice catch!. I changed the first sentence from: "In such scenario, an EVPN PE implementation MAY provide E-TREE service usi= ng topology constraint among the PEs belonging to the same EVI." TO "In such scenario, topology constraint, provided by BGP Route Target (RT) i= mport/export policies among the PEs belonging to the same EVI, can be used = to restrict the communications among Leaf PEs." The sentence above does not address my question in fact, which was about co= mmunication between Leaf ACs (rather than about communication between Leaf = PEs) Let me restate here, more clearly: I fail to see what would prevent Leaf-t= o-Leaf traffic between **ACs** bound to the same MAC-VRF (ES2 and ES3 in fi= rgure1). Shouldn't the text mention the use of a split-horizon in Leaf MAC= -VRFs ? OK. I mentioned the use of split-horizon filtering explicitly for blocking = inter-Leaf communication within the same PE. "In such scenario, using tailored BGP Route Target (RT) import/export polic= ies among the PEs belonging to the same EVI, can be used to restrict the co= mmunications among Leaf PEs. To restrict the communications among leaf site= s connected to the same PE and belonging to the same EVI, split-horizon fi= ltering is used - i.e., the interfaces associated with Leaf sites are place= d in the same split-horizon group. " Mentioning this here is an improvement. Perhaps a reference is needed to explain what a split-horizon _group_ is th= ough, or simply rephrase to avoid the notion ? Proposal: "split-horizon is used to block traffic from one Leaf interface t= o another Leaf interface of a given E-TREE EVI". Ali> OK. Done. (assuming the previous point is resolved:) With this mechanism above, isn't it possible to have on a given PE, for a s= ingle E-TREE EVI, both Leaves and Roots, as long as distinct MAC-VRFs are u= sed (one for Leaves and one for Roots) ? (it seems to me that the assymet= ric import/export RT would do what is needed to build an E-TREE, we would j= ust have a particular case where a Leaf MAC-VRF and a Root MAC-VRF for a gi= ven E-TREE end up on a single PE) That=92s not possible because per definition of an EVI, there is only a sin= gle MAC-VRF per EVI for a PE. Where can I read such a definition ? (the Terminology section in RFC7432 do= es not say that, unless I'm missing something). And that seems a completely arbitrary restriction. (just thinking that a given PE device can be split in two logical devices s= how that it can work) Section 6 of RFC7432 where it gives definitions for different service inter= face types, it specifies the relationship between MAC-VRF and VLAN (bridge = table) and how many MAC-VRF (and bridge tables) can be per EVI. This section of RFC7434 discusses many different things for the different v= ariants. Can you provide a specific pointer about "how many MAC-VRFs can be per EVI"= ? Ali> Section 6 of RFC7432 spells out the relationship between EVI, MAC-VRF,= and bridge tables for all service interfaces very clearly. In all service = interfaces, the RFC says there is one MAC-VRF per EVI on a given PE. Now, i= f the service interface is =93vlan-aware=94, then there are several bridge = tables for that single MAC-VRF =96 ie, one bridge table per VLAN. In all se= rvice interfaces, you can ONLY have one bridge table per VLAN. In bridging world, there can only be a single bridge table per VLAN in a de= vice. I still don't find here anything that would preclude having, on a given PE,= for a given E-TREE EVI, one Leaves MAC-VRF and one Roots MAC-VRF: can't th= ese two MAC-VRFs use different internal VLANs (with translation if the exte= rnal VLANs are constrained). Ali> Lets assume we are using vlan-based service and thus there is only a = single bridge table per MAC-VRF, then what you are suggesting is two use tw= o MAC-VRFs (two bridge tables) for the same EVI (same VLAN). This results i= n some duplications of MAC addresses and would only work if flooding is dis= abled (more on this later). Besides, I don=92t understand what good does it do to have two MAC-VRFs on = the same PE (one for Leafs and another for Roots) Well, the "what is good for" is pretty simple: it means you can have, just = by tailoring the import/export policies like in 2.1, something as useful as= the scenario in 2.2. There can only be a single bridge table per VLAN. Now even if you add some = kind of logic to form two logical PEs in single physical PE, you end up rep= licating all the MAC addresses associated with the root sites in two bridge= tables. Your point above certainly does not sound to me as "it can't be done": some= may think that the above is an acceptable cost, some others may find ways = to make this "replication" with a low overhead, on some platforms the cost = may be negligible, etc. because Leafs and Roots need to talk to each other and thus we want them to= be in the same MAC-VRF. The fact that Leafs and Roots need to talk to each other does not mean that= they *have* to be in the same MAC-VRF, you can rely on the local MPLS data= plane inside the PE to carry the traffic between Roots and Leaves can be pa= ssed between a Leaf MAC-VRF and a Root MAC-VRF (and you can possibly implem= ent a shortcut not involving MPLS encap/decap). Anything is possible but at what cost. You know, for cost it is not always obvious to reach conclusions that are t= rue for all implementations and all targets. The current proposal is very efficient in terms of forwarding path as well = as control plane. Sure, but what I question is not the new solution but the lack of discussio= n on why using the existing specs was not considered good enough. I think that my concern of clearly explaining the scenarios and motivations= for this new spec could be addressed by splitting section 2.2 into a 2.2.1= describing the approach from 2.1 and its possible drawbacks, and a 2.2.2 h= aving essentially the content of current section 2.2. Here is a proposal: 2.2 Scenario 2: Leaf of Root site(s) per AC In these scenarii, a PE receives traffic from either Root OR Leaf sites (but not both) on a given Attachment Circuit (AC) of an EVI. In other words, an AC (ES or ES/VLAN) is either associated with Root(s) or Leaf(s) (but not both). 2.2.1 Scenario 2a: Leaf OR Root site(s) per AC, separate Leaf/Root MAC-VRFs +---------+ +---------+ | PE1 | | PE2 | +---+ | +---+ | +------+ | +---+ | +---+ |CE1+-----ES1----+--+ | | | | | |MAC+--+---ES2/AC1--+CE2| +---+ (Leaf) | |MAC| | | MPLS | | |VRF| | (Leaf) +---+ | |VRF| | | /IP | | '---' | | | | | | | | .---. | | | | | | | | |MAC| | +---+ | | | | | | | |VRF+--+---ES2/AC2--+CE3| | +---+ | +------+ | +---+ | (Root) +---+ +---------+ +---------+ Figure 2: Scenario 2a In this scenario, the RT constraint procedures described in section 2.1 = could also be used. The feasibility and efficiency of this approach depends on platforms specifics. This approach will lead to duplication of a large proportion of MAC addr= esses on PEs having both Leaf and Root sites, and is hence considered less suitab= le for deployment contexts where the vast majority of PEs are likely to ultimat= ely have both Leaf and Root sites attached to them. 2.2.2 Scenario 2b: Leaf OR Root site(s) per AC, single MAC-VRF +---------+ +---------+ | PE1 | | PE2 | +---+ | +---+ | +------+ | +---+ | +---+ |CE1+-----ES1----+--+ | | | | | | +--+---ES2/AC1--+CE2| +---+ (Leaf) | |MAC| | | MPLS | | |MAC| | (Leaf) +---+ | |VRF| | | /IP | | |VRF| | | | | | | | | | | | +---+ | | | | | | | | +--+---ES2/AC2--+CE3| | +---+ | +------+ | +---+ | (Root) +---+ +---------+ +---------+ Figure 2: Scenario 2b This scenario will alleviate keys drawbacks from Scenario 2a, in particu= lar by avoiding duplication of MAC addresses on Leaf/Root PEs and avoiding t= he operational overhead of managing more than one RT. This approach comes at the expense of having routes for unneeded MAC add= resses on Leaf-only PEs, and is hence considered less suitable for deployment c= ontexts where the vast majority of PEs would remain Leaf-only. Unlike Scenario= 1 and Scenario 2a, this scenario requires additional procedures provided in this document. (And this last sentence should be added to section 2.3 as well) For this scenario, if for a given EVI, the majority of PEs will eventually have both Leaf and Root sites attached, even though they may start as Root-only or Leaf-only PEs, then it is recommended to use a single RT per EVI and avoid additional configuration and operational overhead. Why this recommendation ? Even with a majority of PEs having both Leaves and Roots, there can remain = (up to 49% of) PEs having only Leaves, which will uselessly have all routes= to other Leaves. So "it is recommended" above, deserves to be explained more, I think. OK, I changed =93majority=94 to =93vast majority=94 :-) My point was not to nit pick on "majority", but was that you should explain= why you recommend that. As the text currently reads, the cost of the recommendation can be identifi= ed: having useless routes on the fraction of PEs having only Leaves. But the gain brought by the recommendation is not even mentioned, not to sa= y explained. Hence: why ? (Why is it a useful tradeoff to have useless routes on some, even if only o= ne, PE ?) Changed the last sentence from: "then it is recommended to use a single RT per EVI and avoid additional con= figuration and operational overhead.=94 To "then it is recommended to use a single RT per EVI and avoid additional con= figuration and operational overhead at the expense of having unwanted MAC addresses on the Leaf PEs." Ok. I adapted and incorporated this addition into my proposed text splittin= g 2.2 into a 2.2.1 and a 2.2.2. Best, -Thomas --_000_D46E097E1C5BCAsajassiciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <57E274477853D74EA27B3E8C2671F9FE@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi Thomas,

Your suggestion regarding multiple MAC-VRFs per EVI for E-TREE, impact= s lot more sections than just section 2.2 for which you suggested some text= s. It drastically  impacts section 3.1 (known unicast traffic), and it= also impacts section 3.2 (BUM traffic) and section 5.1. Furthermore, it creates a new paradigm for EVPN that was = never intended for because of creating two MAC-VRFs (and two bridge tables)= for the same VLAN. The WG LC was completed on 3/29/16 and I am sure it is = not your intention to have major changes to the doc at this stage where multiple vendors have already imple= mented the draft. 

This draft talks about two kinds of traffic filtering: a) ingress filt= ering for known unicast and b) egress filtering for BUM traffic. What you a= re suggesting is an alternate mechanism for ingress filtering. Although hav= ing multiple VRFs (and forwarding tables) are fine for IP-VPNs because the unknown traffic is always dropped= , multiple VRFs for the same VLAN is not OK for L2 traffic because of flood= ing of unknown traffic. That=92s why in section 6 of RFC 7432, for all serv= ice interface types, the draft talks about a single MAC-VRF per EVI per PE and in case of VLAN-aware mode, &nbs= p;multiple VLANs per MAC-VRF but only a single bridge table per VLAN. In ot= her words, the bottom line is that there can only be a single bridge table = per VLAN in order to avoid unnecessary flooding. When you have two MAC-VRFs per VLAN (one for root ACs and anothe= r for Leaf ACs), then you either need to duplicate lots of MAC addresses be= tween these two VRFs, or do lookup on both of these VRFs. Either ways this = is not a good option relative to keeping a single VRF table for both root and leaf sites and just have a si= ngle-bit indication on whether a MAC is associated with root or leaf (as cu= rrently described approach in the draft).  I

Regards,
Ali 

P.S., I included a bit more comment inline =85


From: Thomas Morin <thomas.morin@orange.com>
Organization: Orange
Date: Tuesday, December 6, 2016 at = 1:55 AM
To: Cisco Employee <sajassi@cisco.com>, "draft-ietf-bess-evpn-etree@ietf.org" <draft-i= etf-bess-evpn-etree@ietf.org>, Loa Andersson <loa@pi.nu>, "Ge= orge Swallow -T (swallow - MBO PARTNERS INC at Cisco)" <swallow@cisco.com>, Eric Rosen <erosen@juniper.net>, BESS <bess@ietf.org>
Cc: Martin Vigoureux <martin.vigoureux@nokia.com>
Subject: Re: shepherd review of dra= ft-ietf-bess-evpn-etree

Hi Ali,

Ali Sajassi (sajassi):
Thanks again= for your additional comments. Below, please find my comment resolutions. L= et me know please if there are any further comments.

Answers below...


=
   EVI. The purpose of this topology constraint is to avoid havin= g PEs
   with only  Leaf sites importing and processing BGP MAC ro= utes from
   each other. To support such topology constrain in EVPN, two BG= P
   Route-Targets (RTs) are used for every EVPN Instance (EVI): on= e RT is
   associated with the Root sites and the other is associated wit= h the
   Leaf sites. On a per EVI basis, every PE exports the single RT=
   associated with its type of site(s). Furthermore, a PE with Ro= ot
   site(s) imports both Root and Leaf RTs, whereas a PE with Leaf=
   site(s) only imports the Root RT.

The text seems to imply that the above is sufficient to deliver the service= , but I fail to see what would prevent Leaf-to-Leaf traffic between Leaves = bound to the same MAC-VRF (ES2 and ES3 in firgure1).  Shouldn't the te= xt mention the use of a split-horizon in Leaf MAC-VRFs ?

Agree, nice catch= !. I changed the first sentence from:
"In suc= h scenario, an EVPN PE implementation MAY provide E-TREE service using topology constr= aint among the PEs belonging to the same EVI."
TO
"In such scenario, topology constraint, provid= ed by BGP Route Target (RT) import/export policies among the PEs belonging = to the same EVI, can be used to restrict the communications among Leaf PEs.= "

The sentence above does not address my qu= estion in fact, which was about communication between Leaf ACs (rather than= about communication between Leaf PEs)
Let me restate here, more clearly:  = I fail to see what would prevent Leaf-t= o-Leaf traffic between **ACs** bound to the same MAC-VRF (ES2 and ES3 in firgure1).  Shouldn= 't the text mention the use of a split-horizon in Leaf MAC-VRFs ?
OK. I mentioned the use of split-horizon filte= ring explicitly for blocking inter-Leaf communication within the same PE.

"In such scenario, using tailored BGP Route Ta= rget (RT) import/export policies among the PEs belonging to the same EVI, c= an be used to restrict the communications among Leaf PEs. To restrict the c= ommunications among leaf sites connected to the same PE  and belonging to the same EVI, split-horizon filterin= g is used - i.e., the interfaces associated with Leaf sites are placed in t= he same split-horizon group. "


Mentioning this here is an improvement.
Perhaps a reference is needed to explain what a split-horizon _group_ is th= ough, or simply rephrase to avoid the notion ?

Proposal: "split-horizon is used to block traffic from one Leaf interf= ace to another Leaf interface of a given E-TREE EVI".

Ali> OK. Done.


(assuming the previous point is resolved:)

With this mechanism above, isn't it possible to have on a given PE, for a s= ingle E-TREE EVI, both Leaves and Roots, as long as distinct MAC-VRFs are u= sed (one for Leaves and one for Roots) ?   (it seems to me that t= he assymetric import/export RT would do what is needed to build an E-TREE, we would just have a particular case where a= Leaf MAC-VRF and a Root MAC-VRF for a given E-TREE end up on a single PE)<= /p>


That=92s not possible because per definition of an = EVI, there is only a single MAC-VRF per EVI for a PE.

Where can I read such a definition ? (the= Terminology section in RFC7432 does not say that, unless I'm missing somet= hing).
And that seems a completely arbitrary res= triction.
(just thinking that a given PE device can= be split in two logical devices show that it can work)

Section 6 of= RFC7432 where it gives definitions for different service interface types, = it specifies the relationship between MAC-VRF and VLAN (bridge table) and h= ow many MAC-VRF (and bridge tables) can be per EVI.

This section of RFC7434 discusses many different things for the different v= ariants.
Can you provide a specific pointer about "how many MAC-VRFs can be per= EVI" ?

Ali> Section 6 of RFC7432 spel= ls out the relationship between EVI, MAC-VRF, and bridge tables for all ser= vice interfaces very clearly. In all service interfaces, the RFC says there= is one MAC-VRF per EVI on a given PE. Now, if the service interface is =93vlan-aware=94, then there are several = bridge tables for that single MAC-VRF =96 ie, one bridge table per VLAN. In= all service interfaces, you can ONLY have one bridge table per VLAN.


In bridging world, there can only b= e a single bridge table per VLAN in a device.

I still don't find here anything that would preclude having, on a given PE,= for a given E-TREE EVI, one Leaves MAC-VRF and one Roots MAC-VRF: can't th= ese two MAC-VRFs use different internal VLANs (with translation if the exte= rnal VLANs are constrained).

Ali>  Lets assume we are using vlan-based service and thus there is= only a single bridge table per MAC-VRF, then what you are suggesting is tw= o use two MAC-VRFs (two bridge tables) for the same EVI (same VLAN). This r= esults in some duplications of MAC addresses and would only work if flooding is disabled (more on this later). 

Besides, I don=92t understand what good does i= t do to have two MAC-VRFs on the same PE (one for Leafs and another for Roo= ts)

Well, the "what is good for" is= pretty simple: it means you can have, just by tailoring the import/export = policies like in 2.1, something as useful as the scenario in 2.2.

There can only be a single bridg= e table per VLAN. Now even if you add some kind of logic to form two logical PEs in single physical PE, you end up replicating all the MAC addresses associ= ated with the root sites in two bridge tables.

Your point above certainly does not sound to me as "it can't be done&q= uot;: some may think that the above is an acceptable cost, some others may = find ways to make this "replication" with a low overhead, on some= platforms the cost may be negligible, etc.




because Leafs and Roots need to talk to each other = and thus we want them to be in the same MAC-VRF.

The f= act that Leafs and Roots need to talk to each other does not mean that they= *have* to be in the same MAC-VRF, you can rely on the local MPLS dataplane inside the PE to carry the traffic between Roots = and Leaves can be passed between a Leaf MAC-VRF and a Root MAC-VRF (and you= can possibly implement a shortcut not involving MPLS encap/decap).<= br>
Anything is possible but at what cos= t.

You know, for cost it is not always obvious to reach conclusions that are t= rue for all implementations and all targets.

The current proposal is= very efficient in terms of forwarding path as well as control plane.

Sure, but what I question is not the new solution but the lack of discussio= n on why using the existing specs was not considered good enough.


I think that my concern of clearly explaining the scenarios and motivations= for this new spec could be addressed by splitting section 2.2 into a 2.2.1= describing the approach from 2.1 and its possible drawbacks, and a 2.2.2 h= aving essentially the content of current section 2.2.

Here is a proposal:

2.2 Scenario 2: Leaf of Root site(s= ) per AC

   In these scenarii, a P= E receives traffic from either Root OR Leaf
   sites (but not both) o= n a given Attachment Circuit (AC) of an EVI. In
   other words, an AC (ES= or ES/VLAN) is either associated with Root(s)
   or Leaf(s) (but not bo= th).

2.2.1 Scenario 2a: Leaf OR Root sit= e(s) per AC, separate Leaf/Root MAC-VRFs

      = ;            &n= bsp;  +---------+       &nb= sp;    +---------+
      = ;            &n= bsp;  |   PE1   |     &nb= sp;      |   PE2   |
    +---+&nb= sp;           |  = 3;---+  |  +------+  |  +---+ = |            +-= --+
    |CE1+-----ES= 1----+--+   |  |  |    &nbs= p; |  |  |MAC+--+---ES2/AC1--+CE2|
    +---+&nb= sp;   (Leaf)  |  |MAC|  |  | MPLS |  |&n= bsp; |VRF|  |   (Leaf)   +---+
      = ;            &n= bsp;  |  |VRF|  |  |  /IP |  |  '---'&nb= sp; |
      = ;            &n= bsp;  |  |   |  |  |    &= nbsp; |  |  .---.  |=
      = ;            &n= bsp;  |  |   |  |  |    &= nbsp; |  |  |MAC|  |      &nbs= p;     +---+
      = ;            &n= bsp;  |  |   |  |  |    &= nbsp; |  |  |VRF+--+---ES2/AC2--+CE3|
      = ;            &n= bsp;  |  +---+  |  +------+  |&nbs= p; +---+  |   (Root)   +---+<= tt style=3D"color: rgb(0, 0, 0);">
      = ;            &n= bsp;  +---------+       &nb= sp;    +---------+

   Figure 2: Scenario 2a<= /tt>

   In this scenario, the = RT constraint procedures described in section 2.1 could
   also be used. The feas= ibility and efficiency of this approach depends on
   platforms specifics.

   This approach will lea= d to duplication of a large proportion o= f MAC addresses on
   PEs having both Leaf and Root sites, and is hence considered l= ess suitable for
   deployment contexts where the vast majority of PEs are likely = to ultimately
   have both Leaf and Roo= t sites attached to them.

2.2.2 Scenario 2b: Leaf OR Root sit= e(s) per AC, single MAC-VRF

    &n= bsp;            = ;    +---------+      =       +---------+
      = ;            &n= bsp;  |   PE1   |     &nb= sp;      |   PE2   |
    +---+&nb= sp;           |  = 3;---+  |  +------+  |  +---+ = |            +-= --+
    |CE1+-----ES= 1----+--+   |  |  |    &nbs= p; |  |  |   +--+---ES2/AC1--+CE2|
    +---+&nb= sp;   (Leaf)  |  |MAC|  |  | MPLS |  |&n= bsp; |MAC|  |   (Leaf)   +---+
      = ;            &n= bsp;  |  |VRF|  |  |  /IP |  |  |VRF|&nb= sp; |
      = ;            &n= bsp;  |  |   |  |  |    &= nbsp; |  |  |   |  |     =        +---+
      = ;            &n= bsp;  |  |   |  |  |    &= nbsp; |  |  |   +--+---ES2/AC2--+CE3|<= tt style=3D"color: rgb(0, 0, 0);">
      = ;            &n= bsp;  |  +---+  |  +------+  |&nbs= p; +---+  |   (Root)   +---+<= tt style=3D"color: rgb(0, 0, 0);">
      = ;            &n= bsp;  +---------+       &nb= sp;    +---------+

   Figure 2: Scenario 2b<= /tt>

   This scenario will all= eviate keys drawbacks from Scenario 2a, in particular
   by avoiding duplicatio= n of MAC addresses on Leaf/Root PEs and avoiding the
   operational overhead o= f managing more than one RT.
   This approach comes at the expense of having routes for unneeded MAC addresse=
s
   on Leaf-only PEs, and is =
hence considered less suitable for deployment contexts
   where the vast majority of PEs would remain Leaf-only.   U=
nlike Scenario 1 and Scenario 2a, this scenario requires additional procedu=
res
   provided in this document.
(And this last sentence should be added to section 2.3 as well)


For this scenario, if for a given
   EVI, the majority of PEs will eventually have both Leaf and Ro= ot
   sites attached, even though they may start as Root-only or Lea= f-only
   PEs, then it is recommended to use a single RT per EVI and avo= id
   additional configuration and operational overhead.

Why this recommendation ?
Even with a majority of PEs having both Leaves and Roots, there can remain = (up to 49% of) PEs having only Leaves, which will uselessly have all routes= to other Leaves.

So "it is recommended" above, deserves to be explained more, I th= ink.

OK, I changed =93majority=94 to =93vast m= ajority=94 :-)

My po= int was not to nit pick on "majority", but was that you should ex= plain why you recommend that.
As th= e text currently reads, the cost of the recommendation can be identified: h= aving useless routes on the fraction of PEs having only Leaves.
But t= he gain brought by the recommendation is not even mentioned, not to say exp= lained.
Hence= : why ?
(Why = is it a useful tradeoff to have useless routes on some, even if only one, P= E ?)

Changed the last sentence from:
"then it is recommended to use a single R= T per EVI and avoid additional configuration and operational overhead.=94
To
"then it is recommended to use a single R= T per EVI and avoid additional configuration and operational overhead
at the expense of having unwanted MAC addresses on = the Leaf PEs."

Ok. I adapted and incorporated this addition into my proposed text splittin= g 2.2 into a 2.2.1 and a 2.2.2.

Best,

-Thomas


 --_000_D46E097E1C5BCAsajassiciscocom_-- From nobody Mon Dec 12 06:48:32 2016 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26DE6129C2F; Mon, 12 Dec 2016 06:48:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.429 X-Spam-Level: X-Spam-Status: No, score=-6.429 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.896, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MtOWz25k5dfU; Mon, 12 Dec 2016 06:48:27 -0800 (PST) Received: from r-mail2.rd.orange.com (r-mail2.rd.orange.com [217.108.152.42]) by ietfa.amsl.com (Postfix) with ESMTP id 8A992129C37; Mon, 12 Dec 2016 06:48:22 -0800 (PST) Received: from r-mail2.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id E438B5D8A98; Mon, 12 Dec 2016 15:48:20 +0100 (CET) Received: from FTRDCH01.rd.francetelecom.fr (unknown [10.194.32.11]) by r-mail2.rd.orange.com (Postfix) with ESMTP id D59EC5D8994; Mon, 12 Dec 2016 15:48:20 +0100 (CET) Received: from [10.193.71.12] (10.193.71.12) by FTRDCH01.rd.francetelecom.fr (10.194.32.11) with Microsoft SMTP Server id 14.3.301.0; Mon, 12 Dec 2016 15:48:20 +0100 To: "Ali Sajassi (sajassi)" , "draft-ietf-bess-evpn-etree@ietf.org" , Loa Andersson , "George Swallow -T (swallow - MBO PARTNERS INC at Cisco)" , Eric Rosen , BESS References: <3323ddae-c96f-49a4-2dec-1bfc4ed857dc@orange.com> <6cb41698-b98b-ecbf-9e34-660771bd3fb8@orange.com> <0b846411-4526-c6d3-3ea4-87ebd90de953@orange.com> From: Thomas Morin Organization: Orange Message-ID: <62a4bc51-b9de-4a80-a843-bfa356bc23ea@orange.com> Date: Mon, 12 Dec 2016 15:48:20 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------B4CD8494471ED830E24567A0" Archived-At: Cc: Martin Vigoureux Subject: Re: [bess] shepherd review of draft-ietf-bess-evpn-etree X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Dec 2016 14:48:30 -0000 --------------B4CD8494471ED830E24567A0 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit Hi Ali, 2016-12-10, Ali Sajassi (sajassi): > Your suggestion regarding multiple MAC-VRFs per EVI for E-TREE, > impacts lot more sections than just section 2.2 for which you > suggested some texts. It drastically impacts section 3.1 (known > unicast traffic), and it also impacts section 3.2 (BUM traffic) and > section 5.1. Can you detail why ? The understanding that leads me to this suggestion is that the 2-RT+split-horizon scenario in 2.1, then applied to Root/Leaf PE in a 2.2.1 would not require new procotol procedures nor changes in the text that as I understand provides procedures for 2.2(.2) and 2.3. > Furthermore, it creates a new paradigm for EVPN that was never > intended for because of creating two MAC-VRFs (and two bridge tables) > for the same VLAN. The " created a new paradigm that was never intended for" is a not generally valid, or sufficiently detailed, argument: if it was, then you might go as far as challenging the whole E-Tree spec on the same kind grounds (and many other new things). So here is where it seems we have a gap to bridge: I still don't understand what in RFC7432 describes an intention of "not supporting two MAC-VRFs for the same VLAN". > The WG LC was completed on 3/29/16 and I am sure it is not your > intention to have major changes to the doc at this stage where > multiple vendors have already implemented the draft. As you know, there are different stages at which people do reviews on a doc after WGLC, an which may lead doc editors to introduce significant --editorial or technical-- changes in a document. Sometimes that leads to documents going back to the working group. However my root intention as doc shepherd, of course, is not to propose a major change, but merely to able to answer the standard question of the shepherd review -- on the reviews done, on document readiness, and on the document quality -- in a way as positive and sincere as possible. In particular questions (3) (4) and (6). > This draft talks about two kinds of traffic filtering: a) ingress > filtering for known unicast and b) egress filtering for BUM traffic. > What you are suggesting is an alternate mechanism for ingress filtering. (well I'm not suggesting the mechanism itself --which section 2.1 already does-- but simply to document that it can still apply without the constraint of avoiding the presence of a Root MAC-VRF and a Leaf MAC-VRF on a same PE) > Although having multiple VRFs (and forwarding tables) are fine for > IP-VPNs because the unknown traffic is always dropped, multiple VRFs > for the same VLAN is not OK for L2 traffic because of flooding of > unknown traffic. That’s why in section 6 of RFC 7432, for all service > interface types, the draft talks about a single MAC-VRF per EVI per PE > and in case of VLAN-aware mode, multiple VLANs per MAC-VRF but only a > single bridge table per VLAN. In other words, the bottom line is that > there can only be a single bridge table per VLAN in order to avoid > unnecessary flooding. > When you have two MAC-VRFs per VLAN (one for root ACs and another for > Leaf ACs), then you either need to duplicate lots of MAC addresses > between these two VRFs, or do lookup on both of these VRFs. Either > ways this is not a good option relative to keeping a single VRF table > for both root and leaf sites and just have a single-bit indication on > whether a MAC is associated with root or leaf (as currently described > approach in the draft). I In the above, it seems you agree that it can work, and you are able to offer reasons why it is not the preferred option, then why not just document that it can work and provides these reasons as the motivations that lead to proposing a new specs ? (it seems you have an unfinished last sentence: "I [...]" ) > >>> >>> (assuming the previous point is resolved:) >>> >>> With this mechanism above, isn't it possible to have on a given PE, >>> for a single E-TREE EVI, both Leaves and Roots, as long as distinct >>> MAC-VRFs are used (one for Leaves and one for Roots) ? (it seems >>> to me that the assymetric import/export RT would do what is needed >>> to build an E-TREE, we would just have a particular case where a >>> Leaf MAC-VRF and a Root MAC-VRF for a given E-TREE end up on a >>> single PE) >>> >>> >>> That’s not possible because per definition of an EVI, there is only >>> a single MAC-VRF per EVI for a PE. >> >> Where can I read such a definition ? (the Terminology section in >> RFC7432 does not say that, unless I'm missing something). >> And that seems a completely arbitrary restriction. >> (just thinking that a given PE device can be split in two logical >> devices show that it can work) >> >> Section 6 of RFC7432 where it gives definitions for different service >> interface types, it specifies the relationship between MAC-VRF and >> VLAN (bridge table) and how many MAC-VRF (and bridge tables) can be >> per EVI. > > This section of RFC7434 discusses many different things for the > different variants. > Can you provide a specific pointer about "how many MAC-VRFs can be per > EVI" ? > > Ali> Section 6 of RFC7432 spells out the relationship between EVI, > MAC-VRF, and bridge tables for all service interfaces very clearly. > In all service interfaces, the RFC says there is one MAC-VRF per EVI > on a given PE. > Now, if the service interface is “vlan-aware”, then there are several > bridge tables for that single MAC-VRF – ie, one bridge table per VLAN. > In all service interfaces, you can ONLY have one bridge table per VLAN. This answer is everything but a specific pointer. If Section 6 of RFC7432 says all this very clearly, I guess it should be possible to extract quotes about "there is one MAC-VRF per EVI on a given PE", right ? > >> In bridging world, there can only be a single bridge table per VLAN >> in a device. > > I still don't find here anything that would preclude having, on a > given PE, for a given E-TREE EVI, one Leaves MAC-VRF and one Roots > MAC-VRF: can't these two MAC-VRFs use different internal VLANs (with > translation if the external VLANs are constrained). > > Ali> Lets assume we are using vlan-based service and thus there is > only a single bridge table per MAC-VRF, then what you are suggesting > is two use two MAC-VRFs (two bridge tables) for the same EVI (same > VLAN). This results in some duplications of MAC addresses and would > only work if flooding is disabled (more on this later). "results in some duplications of MAC" is perhaps a drawback, but nothing like "just does not work" ? "would only work if flooding is disabled": why ? (you wrote "(more on this later)" but I couldn't identify anything recent from you in the rest of the email below) From an helicopter view, I can't see what fundamentally would become problematic between "two MAC-VRFs on two distinct PEs" and the same "two MAC-VRFs on a same PEs", at worse it is as efficient or as inefficient as having them on separate PEs (think logical router without anykind of dataplane optimisation), and we can't exclude that the PE could have local implementation details to do better than that. >> >>> Besides, I don’t understand what good does it do to have two >>> MAC-VRFs on the same PE (one for Leafs and another for Roots) >> >> Well, the "what is good for" is pretty simple: it means you can have, >> just by tailoring the import/export policies like in 2.1, something >> as useful as the scenario in 2.2. >> >> There can only be a single bridge table per VLAN. Now even if you add >> some kind of logic to form two logical PEs in single physical PE, you >> end up replicating all the MAC addresses associated with the root >> sites in two bridge tables. > > Your point above certainly does not sound to me as "it can't be done": > some may think that the above is an acceptable cost, some others may > find ways to make this "replication" with a low overhead, on some > platforms the cost may be negligible, etc. > > >> >> >>> because Leafs and Roots need to talk to each other and thus we want >>> them to be in the same MAC-VRF. >> >> The fact that Leafs and Roots need to talk to each other does not >> mean that they *have* to be in the same MAC-VRF, you can rely on the >> local MPLS dataplane inside the PE to carry the traffic between Roots >> and Leaves can be passed between a Leaf MAC-VRF and a Root MAC-VRF >> (and you can possibly implement a shortcut not involving MPLS >> encap/decap). >> >> Anything is possible but at what cost. > > You know, for cost it is not always obvious to reach conclusions that > are true for all implementations and all targets. > >> The current proposal is very efficient in terms of forwarding path as >> well as control plane. > > Sure, but what I question is not the new solution but the lack of > discussion on why using the existing specs was not considered good enough. > > > I think that my concern of clearly explaining the scenarios and > motivations for this new spec could be addressed by splitting section > 2.2 into a 2.2.1 describing the approach from 2.1 and its possible > drawbacks, and a 2.2.2 having essentially the content of current > section 2.2. > > Here is a proposal: > > 2.2 Scenario 2: Leaf of Root site(s) per AC > > In these scenarii, a PE receives traffic from either Root OR Leaf > sites (but not both) on a given Attachment Circuit (AC) of an EVI. In > other words, an AC (ES or ES/VLAN) is either associated with Root(s) > or Leaf(s) (but not both). > > 2.2.1 Scenario 2a: Leaf OR Root site(s) per AC, separate Leaf/Root > MAC-VRFs > > +---------+ +---------+ > | PE1 | | PE2 | > +---+ | +---+ | +------+ | +---+ | +---+ > |CE1+-----ES1----+--+ | | | | | |MAC+--+---ES2/AC1--+CE2| > +---+ (Leaf) | |MAC| | | MPLS | | |VRF| | (Leaf) +---+ > | |VRF| | | /IP | | '---' | > | | | | | | | .---. | > | | | | | | | |MAC| | +---+ > | | | | | | | |VRF+--+---ES2/AC2--+CE3| > | +---+ | +------+ | +---+ | (Root) +---+ > +---------+ +---------+ > > Figure 2: Scenario 2a > > In this scenario, the RT constraint procedures described in section > 2.1 could > also be used. The feasibility and efficiency of this approach > depends on > platforms specifics. > > This approach will lead toduplication of a large proportion of MAC > addresseson > PEs having both Leaf and Root sites, and is hence considered less > suitable for > deployment contexts where the vast majority of PEs are likely to > ultimately > have both Leaf and Root sites attached to them. > > 2.2.2 Scenario 2b: Leaf OR Root site(s) per AC, single MAC-VRF > > +---------+ +---------+ > | PE1 | | PE2 | > +---+ | +---+ | +------+ | +---+ | +---+ > |CE1+-----ES1----+--+ | | | | | | +--+---ES2/AC1--+CE2| > +---+ (Leaf) | |MAC| | | MPLS | | |MAC| | (Leaf) +---+ > | |VRF| | | /IP | | |VRF| | > | | | | | | | | | | +---+ > | | | | | | | | +--+---ES2/AC2--+CE3| > | +---+ | +------+ | +---+ | (Root) +---+ > +---------+ +---------+ > > Figure 2: Scenario 2b > > This scenario will alleviate keys drawbacks from Scenario 2a, in > particular > by avoiding duplication of MAC addresses on Leaf/Root PEs and > avoiding the > operational overhead of managing more than one RT. > This approach comes at the expense of having routes for unneeded > MAC addresses on Leaf-only PEs, and is hence considered less suitable > for deployment contexts where the vast majority of PEs would remain > Leaf-only. Unlike Scenario 1 and Scenario 2a, this scenario requires additional procedures > provided in this document. > > > (And this last sentence should be added to section 2.3 as well) > >> >>>> For this scenario, if for a given >>>> EVI, the majority of PEs will eventually have both Leaf and Root >>>> sites attached, even though they may start as Root-only or Leaf-only >>>> PEs, then it is recommended to use a single RT per EVI and avoid >>>> additional configuration and operational overhead. >>> >>> Why this recommendation ? >>> Even with a majority of PEs having both Leaves and Roots, there can >>> remain (up to 49% of) PEs having only Leaves, which will uselessly >>> have all routes to other Leaves. >>> >>> So "it is recommended" above, deserves to be explained more, I think. >>> >>> OK, I changed “majority” to “vast majority” :-) >> >> My point was not to nit pick on "majority", but was that you should >> explain why you recommend that. >> As the text currently reads, the cost of the recommendation can be >> identified: having useless routes on the fraction of PEs having only >> Leaves. >> But the gain brought by the recommendation is not even mentioned, not >> to say explained. >> Hence: why ? >> (Why is it a useful tradeoff to have useless routes on some, even if >> only one, PE ?) >> >> Changed the last sentence from: >> "then it is recommended to use a single RT per EVI and avoid >> additional configuration and operational overhead.” >> To >> "then it is recommended to use a single RT per EVI and avoid >> additional configuration and operational overhead >> at the expense of having unwanted MAC addresses on the Leaf PEs." > > Ok. I adapted and incorporated this addition into my proposed text > splitting 2.2 into a 2.2.1 and a 2.2.2. > > Best, > > -Thomas > > --------------B4CD8494471ED830E24567A0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 8bit
Hi Ali,

2016-12-10, Ali Sajassi (sajassi):
Your suggestion regarding multiple MAC-VRFs per EVI for E-TREE, impacts lot more sections than just section 2.2 for which you suggested some texts. It drastically  impacts section 3.1 (known unicast traffic), and it also impacts section 3.2 (BUM traffic) and section 5.1.

Can you detail why ?
The understanding that leads me to this suggestion is that the 2-RT+split-horizon scenario in 2.1, then applied to Root/Leaf PE in a 2.2.1 would not require new procotol procedures nor changes in the text that as I understand provides procedures for 2.2(.2) and 2.3.

Furthermore, it creates a new paradigm for EVPN that was never intended for because of creating two MAC-VRFs (and two bridge tables) for the same VLAN.

The "<new thing> created a new paradigm that <RFX xyz> was never intended for" is a not generally valid, or sufficiently detailed, argument: if it was, then you might go as far as challenging the whole E-Tree spec on the same kind grounds (and many other new things).

So here is where it seems we have a gap to bridge: I still don't understand what in RFC7432 describes an intention of "not supporting two MAC-VRFs for the same VLAN".

The WG LC was completed on 3/29/16 and I am sure it is not your intention to have major changes to the doc at this stage where multiple vendors have already implemented the draft.

As you know, there are different stages at which people do reviews on a doc after WGLC, an which may lead doc editors to introduce significant --editorial or technical-- changes in a document. Sometimes that leads to documents going back to the working group.

However my root intention as doc shepherd, of course, is not to propose a major change, but merely to able to answer the standard question of the shepherd review -- on the reviews done, on document readiness, and on the document quality -- in a way as positive and sincere as possible. In particular questions (3) (4) and (6).


This draft talks about two kinds of traffic filtering: a) ingress filtering for known unicast and b) egress filtering for BUM traffic. What you are suggesting is an alternate mechanism for ingress filtering.

(well I'm not suggesting the mechanism itself --which section 2.1 already does-- but simply to document that it can still apply without the constraint of avoiding the presence of a Root MAC-VRF and a Leaf MAC-VRF on a same PE)

Although having multiple VRFs (and forwarding tables) are fine for IP-VPNs because the unknown traffic is always dropped, multiple VRFs for the same VLAN is not OK for L2 traffic because of flooding of unknown traffic. That’s why in section 6 of RFC 7432, for all service interface types, the draft talks about a single MAC-VRF per EVI per PE and in case of VLAN-aware mode,  multiple VLANs per MAC-VRF but only a single bridge table per VLAN. In other words, the bottom line is that there can only be a single bridge table per VLAN in order to avoid unnecessary flooding.



When you have two MAC-VRFs per VLAN (one for root ACs and another for Leaf ACs), then you either need to duplicate lots of MAC addresses between these two VRFs, or do lookup on both of these VRFs. Either ways this is not a good option relative to keeping a single VRF table for both root and leaf sites and just have a single-bit indication on whether a MAC is associated with root or leaf (as currently described approach in the draft).  I


In the above, it seems you agree that it can work, and you are able to offer reasons why it is not the preferred option, then why not just document that it can work and provides these reasons as the motivations that lead to proposing a new specs ?

(it seems you have an unfinished last sentence: "I [...]" )


(assuming the previous point is resolved:)

With this mechanism above, isn't it possible to have on a given PE, for a single E-TREE EVI, both Leaves and Roots, as long as distinct MAC-VRFs are used (one for Leaves and one for Roots) ?   (it seems to me that the assymetric import/export RT would do what is needed to build an E-TREE, we would just have a particular case where a Leaf MAC-VRF and a Root MAC-VRF for a given E-TREE end up on a single PE)

That’s not possible because per definition of an EVI, there is only a single MAC-VRF per EVI for a PE.

Where can I read such a definition ? (the Terminology section in RFC7432 does not say that, unless I'm missing something).
And that seems a completely arbitrary restriction.
(just thinking that a given PE device can be split in two logical devices show that it can work)

Section 6 of RFC7432 where it gives definitions for different service interface types, it specifies the relationship between MAC-VRF and VLAN (bridge table) and how many MAC-VRF (and bridge tables) can be per EVI.

This section of RFC7434 discusses many different things for the different variants.
Can you provide a specific pointer about "how many MAC-VRFs can be per EVI" ?

Ali> Section 6 of RFC7432 spells out the relationship between EVI, MAC-VRF, and bridge tables for all service interfaces very clearly.
In all service interfaces, the RFC says there is one MAC-VRF per EVI on a given PE.
Now, if the service interface is “vlan-aware”, then there are several bridge tables for that single MAC-VRF – ie, one bridge table per VLAN. In all service interfaces, you can ONLY have one bridge table per VLAN.

This answer is everything but a specific pointer.
If Section 6 of RFC7432 says all this very clearly, I guess it should be possible to extract quotes about "there is one MAC-VRF per EVI on a given PE", right ?

In bridging world, there can only be a single bridge table per VLAN in a device.

I still don't find here anything that would preclude having, on a given PE, for a given E-TREE EVI, one Leaves MAC-VRF and one Roots MAC-VRF: can't these two MAC-VRFs use different internal VLANs (with translation if the external VLANs are constrained).

Ali>  Lets assume we are using vlan-based service and thus there is only a single bridge table per MAC-VRF, then what you are suggesting is two use two MAC-VRFs (two bridge tables) for the same EVI (same VLAN). This results in some duplications of MAC addresses and would only work if flooding is disabled (more on this later).

"results in some duplications of MAC" is perhaps a drawback, but nothing like "just does not work" ?

"would only work if flooding is disabled": why ?  (you wrote "(more on this later)" but I couldn't identify anything recent from you in the rest of the email below)


From an helicopter view, I can't see what fundamentally would become problematic between "two MAC-VRFs on two distinct PEs" and the same "two MAC-VRFs on a same PEs", at worse it is as efficient or as inefficient as having them on separate PEs (think logical router without anykind of dataplane optimisation), and we can't exclude that the PE could have local implementation details to do better than that.



Besides, I don’t understand what good does it do to have two MAC-VRFs on the same PE (one for Leafs and another for Roots)

Well, the "what is good for" is pretty simple: it means you can have, just by tailoring the import/export policies like in 2.1, something as useful as the scenario in 2.2.

There can only be a single bridge table per VLAN. Now even if you add some kind of logic to form two logical PEs in single physical PE, you end up replicating all the MAC addresses associated with the root sites in two bridge tables.

Your point above certainly does not sound to me as "it can't be done": some may think that the above is an acceptable cost, some others may find ways to make this "replication" with a low overhead, on some platforms the cost may be negligible, etc.




because Leafs and Roots need to talk to each other and thus we want them to be in the same MAC-VRF.

The fact that Leafs and Roots need to talk to each other does not mean that they *have* to be in the same MAC-VRF, you can rely on the local MPLS dataplane inside the PE to carry the traffic between Roots and Leaves can be passed between a Leaf MAC-VRF and a Root MAC-VRF (and you can possibly implement a shortcut not involving MPLS encap/decap).

Anything is possible but at what cost.

You know, for cost it is not always obvious to reach conclusions that are true for all implementations and all targets.

The current proposal is very efficient in terms of forwarding path as well as control plane.

Sure, but what I question is not the new solution but the lack of discussion on why using the existing specs was not considered good enough.


I think that my concern of clearly explaining the scenarios and motivations for this new spec could be addressed by splitting section 2.2 into a 2.2.1 describing the approach from 2.1 and its possible drawbacks, and a 2.2.2 having essentially the content of current section 2.2.

Here is a proposal:

2.2 Scenario 2: Leaf of Root site(s) per AC

   In these scenarii, a PE receives traffic from either Root OR Leaf
   sites (but not both) on a given Attachment Circuit (AC) of an EVI. In
   other words, an AC (ES or ES/VLAN) is either associated with Root(s)
   or Leaf(s) (but not both).

2.2.1 Scenario 2a: Leaf OR Root site(s) per AC, separate Leaf/Root MAC-VRFs

                     +---------+            +---------+
                     |   PE1   |            |   PE2   |
    +---+            |  +---+  |  +------+  |  +---+  |            +---+
    |CE1+-----ES1----+--+   |  |  |      |  |  |MAC+--+---ES2/AC1--+CE2|
    +---+    (Leaf)  |  |MAC|  |  | MPLS |  |  |VRF|  |   (Leaf)   +---+
                     |  |VRF|  |  |  /IP |  |  '---'  |
                     |  |   |  |  |      |  |  .---.  |
                     |  |   |  |  |      |  |  |MAC|  |            +---+
                     |  |   |  |  |      |  |  |VRF+--+---ES2/AC2--+CE3|
                     |  +---+  |  +------+  |  +---+  |   (Root)   +---+
                     +---------+            +---------+

   Figure 2: Scenario 2a

   In this scenario, the RT constraint procedures described in section 2.1 could
   also be used. The feasibility and efficiency of this approach depends on
   platforms specifics.

   This approach will lead to duplication of a large proportion of MAC addresses on
   PEs having both Leaf and Root sites, and is hence considered less suitable for
   deployment contexts where the vast majority of PEs are likely to ultimately
   have both Leaf and Root sites attached to them.

2.2.2 Scenario 2b: Leaf OR Root site(s) per AC, single MAC-VRF

                     +---------+            +---------+
                     |   PE1   |            |   PE2   |
    +---+            |  +---+  |  +------+  |  +---+  |            +---+
    |CE1+-----ES1----+--+   |  |  |      |  |  |   +--+---ES2/AC1--+CE2|
    +---+    (Leaf)  |  |MAC|  |  | MPLS |  |  |MAC|  |   (Leaf)   +---+
                     |  |VRF|  |  |  /IP |  |  |VRF|  |
                     |  |   |  |  |      |  |  |   |  |            +---+
                     |  |   |  |  |      |  |  |   +--+---ES2/AC2--+CE3|
                     |  +---+  |  +------+  |  +---+  |   (Root)   +---+
                     +---------+            +---------+

   Figure 2: Scenario 2b

   This scenario will alleviate keys drawbacks from Scenario 2a, in particular
   by avoiding duplication of MAC addresses on Leaf/Root PEs and avoiding the
   operational overhead of managing more than one RT.
   This approach comes at the expense of having routes for unneeded MAC addresses
   on Leaf-only PEs, and is hence considered less suitable for deployment contexts
   where the vast majority of PEs would remain Leaf-only.   Unlike Scenario 1 and Scenario 2a, this scenario requires additional procedures
   provided in this document.
(And this last sentence should be added to section 2.3 as well)


For this scenario, if for a given
   EVI, the majority of PEs will eventually have both Leaf and Root
   sites attached, even though they may start as Root-only or Leaf-only
   PEs, then it is recommended to use a single RT per EVI and avoid
   additional configuration and operational overhead.

Why this recommendation ?
Even with a majority of PEs having both Leaves and Roots, there can remain (up to 49% of) PEs having only Leaves, which will uselessly have all routes to other Leaves.

So "it is recommended" above, deserves to be explained more, I think.

OK, I changed “majority” to “vast majority” :-)

My point was not to nit pick on "majority", but was that you should explain why you recommend that.
As the text currently reads, the cost of the recommendation can be identified: having useless routes on the fraction of PEs having only Leaves.
But the gain brought by the recommendation is not even mentioned, not to say explained.
Hence: why ?
(Why is it a useful tradeoff to have useless routes on some, even if only one, PE ?)

Changed the last sentence from:
"then it is recommended to use a single RT per EVI and avoid additional configuration and operational overhead.”
To
"then it is recommended to use a single RT per EVI and avoid additional configuration and operational overhead
at the expense of having unwanted MAC addresses on the Leaf PEs."

Ok. I adapted and incorporated this addition into my proposed text splitting 2.2 into a 2.2.1 and a 2.2.2.

Best,

-Thomas


--------------B4CD8494471ED830E24567A0-- From nobody Mon Dec 12 12:59:08 2016 Return-Path: X-Original-To: bess@ietf.org Delivered-To: bess@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 254721294E8; Mon, 12 Dec 2016 12:59:07 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.39.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148157634714.22503.16016238504964948421.idtracker@ietfa.amsl.com> Date: Mon, 12 Dec 2016 12:59:07 -0800 Archived-At: Cc: bess@ietf.org Subject: [bess] I-D Action: draft-ietf-bess-mvpn-expl-track-01.txt X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.17 List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Dec 2016 20:59:07 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the BGP Enabled ServiceS of the IETF. Title : Explicit Tracking with Wild Card Routes in Multicast VPN Authors : Andrew Dolganow Jayant Kotalwar Eric C. Rosen Zhaohui Zhang Filename : draft-ietf-bess-mvpn-expl-track-01.txt Pages : 15 Date : 2016-12-12 Abstract: The MVPN specifications provide procedures to allow a multicast ingress node to invoke "explicit tracking" for a multicast flow or set of flows, thus learning the egress nodes for that flow or set of flows. However, the specifications are not completely clear about how the explicit tracking procedures work in certain scenarios. This document provides the necessary clarifications. It also specifies a new, optimized explicit tracking procedure. This new procedure allows an ingress node, by sending a single message, to request explicit tracking of each of a set of flows, where the set of flows is specified using a wildcard mechanism. This document updates RFC6625. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-expl-track/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-bess-mvpn-expl-track-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-mvpn-expl-track-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Dec 13 11:56:41 2016 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45E9F1294B8; Tue, 13 Dec 2016 11:56:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.417 X-Spam-Level: X-Spam-Status: No, score=-17.417 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5yfOzGw6Mu4P; Tue, 13 Dec 2016 11:56:35 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 728DC129431; Tue, 13 Dec 2016 11:56:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=55562; q=dns/txt; s=iport; t=1481658995; x=1482868595; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=TdtVmWEKWiyVkKJhxRIrUhHBf7as5q3gyalDrPa1b7Q=; b=Bu/gNcw+2uektMXDEeuLLB/jwmST3EQKQM+fbvSstj40emozDfS5FgVp KQwiTmMrBN7c4tpsIkpVyNypD88JwQuHHPmZVf9kDX/WVqiQes/860ok9 px710mkUaVQVk9PMwMd/BcTysgYE79rSK/U6jbL0VeT5o032Tn5uXA7Hy k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AVAQAoUlBY/4sNJK1TChkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJzOQsBAQEBAR+BYAeNQ5cZlQaCCYJGAYNaAoF9PxQBAgEBAQE?= =?us-ascii?q?BAQFiKIRoAQEBBBpSBQEBAQIDEAIBCBEDAQIhAQYHMhQJCAIEAQ0FG4hQrUkvi?= =?us-ascii?q?mUBAQEBAQEBAQEBAQEBAQEBAQEBAQEdihGBCIQZAQYLATyFQQWaawGJYYdJgXS?= =?us-ascii?q?FAYNIhguOEoQOAR83Yz6DeBeBXXKGP4EhgQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.33,342,1477958400"; d="scan'208,217";a="360455375" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 13 Dec 2016 19:56:34 +0000 Received: from XCH-RTP-019.cisco.com (xch-rtp-019.cisco.com [64.101.220.159]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id uBDJuXFf007654 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 13 Dec 2016 19:56:33 GMT Received: from xch-rtp-005.cisco.com (64.101.220.145) by XCH-RTP-019.cisco.com (64.101.220.159) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 13 Dec 2016 14:56:32 -0500 Received: from xch-rtp-005.cisco.com ([64.101.220.145]) by XCH-RTP-005.cisco.com ([64.101.220.145]) with mapi id 15.00.1210.000; Tue, 13 Dec 2016 14:56:32 -0500 From: "Ali Sajassi (sajassi)" To: Thomas Morin , "draft-ietf-bess-evpn-etree@ietf.org" , Loa Andersson , "George Swallow -T (swallow - MBO PARTNERS INC at Cisco)" , Eric Rosen , BESS Thread-Topic: shepherd review of draft-ietf-bess-evpn-etree Thread-Index: AQHSAgSQiVios9dTSUOmTfNWP8T6rqBlA4UAgAGT+oCASmTegIBKoSmAgAU1ewCABIpWAIABYlAA Date: Tue, 13 Dec 2016 19:56:32 +0000 Message-ID: References: <3323ddae-c96f-49a4-2dec-1bfc4ed857dc@orange.com> <6cb41698-b98b-ecbf-9e34-660771bd3fb8@orange.com> <0b846411-4526-c6d3-3ea4-87ebd90de953@orange.com> <62a4bc51-b9de-4a80-a843-bfa356bc23ea@orange.com> In-Reply-To: <62a4bc51-b9de-4a80-a843-bfa356bc23ea@orange.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.0.161029 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.128.224.205] Content-Type: multipart/alternative; boundary="_000_D47571E11C6CE2sajassiciscocom_" MIME-Version: 1.0 Archived-At: Cc: Martin Vigoureux Subject: Re: [bess] shepherd review of draft-ietf-bess-evpn-etree X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Dec 2016 19:56:39 -0000 --_000_D47571E11C6CE2sajassiciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Thomas, Please refer to my comments inline. From: Thomas Morin = > Organization: Orange Date: Monday, December 12, 2016 at 6:48 AM To: Cisco Employee >, "draft-ie= tf-bess-evpn-etree@ietf.org" >, Loa Andersson >, "George Swallow -T (swal= low - MBO PARTNERS INC at Cisco)" >, Eric Rosen >, BESS > Cc: Martin Vigoureux > Subject: Re: shepherd review of draft-ietf-bess-evpn-etree Hi Ali, 2016-12-10, Ali Sajassi (sajassi): Your suggestion regarding multiple MAC-VRFs per EVI for E-TREE, impacts lot= more sections than just section 2.2 for which you suggested some texts. It= drastically impacts section 3.1 (known unicast traffic), and it also impa= cts section 3.2 (BUM traffic) and section 5.1. Can you detail why ? The understanding that leads me to this suggestion is that the 2-RT+split-h= orizon scenario in 2.1, then applied to Root/Leaf PE in a 2.2.1 would not r= equire new procotol procedures nor changes in the text that as I understand= provides procedures for 2.2(.2) and 2.3. The reason that impacts more sections than just sec. 2, is that the propose= d 2.2.1 would be an alternative option for section 3.1. In section 3.1, the= root/leaf indication for MAC addresses are done via flag-bit defined in se= ction 5.1 and it only uses a single MAC-VRF (single bridge table per VLAN) = per RFC 7432. If we go with two MAC-VRFs (e.g., two bridge tables) per VLAN= , then that is an alternative way of doing the same thing described in sect= ion 3.1. This alternative way has big ramifications on the platform as it r= equires duplicating MACs and managing multiple bridge tables per VLAN. Maybe what you really want is to allow for scenario 2.2 to operate with two= RTs which has the benefits of both 2.2.1 and 2.2.2 and non of the drawback= s. So, maybe we can clarify the current text to make sure that this comes o= ut clearly =96 ie, a PE can have single MAC=96VRF can have multiple RTs. Furthermore, it creates a new paradigm for EVPN that was never intended for= because of creating two MAC-VRFs (and two bridge tables) for the same VLAN= . The " created a new paradigm that was never intended f= or" is a not generally valid, or sufficiently detailed, argument: if it was= , then you might go as far as challenging the whole E-Tree spec on the same= kind grounds (and many other new things). So here is where it seems we have a gap to bridge: I still don't understand= what in RFC7432 describes an intention of "not supporting two MAC-VRFs for= the same VLAN". I tried to explain the relationship between EVI, MAC-VRF, bridge table, and= VLAN in my previous email per RFC 7432. However, lets park this discussion= for time being as I think it is secondary. I think you agree that if we have a single solution that has all the benefi= ts of your proposed 2.2.1 and 2.2.2 and none of the drawbacks, it is much m= ore preferable with having two solutions each with its own advantages and d= raw backs, right? If so, then existing text in 2.2 was intended to convey t= hat. However, we can clarify it further =96 e.g, make it clear that for PE = with root & leaf in the same EVI, we can use a single MAC-VRF with two RTs = (one for leaf and another for root). The WG LC was completed on 3/29/16 and I am sure it is not your intention t= o have major changes to the doc at this stage where multiple vendors have a= lready implemented the draft. As you know, there are different stages at which people do reviews on a doc= after WGLC, an which may lead doc editors to introduce significant --edito= rial or technical-- changes in a document. Sometimes that leads to document= s going back to the working group. However my root intention as doc shepherd, of course, is not to propose a m= ajor change, but merely to able to answer the standard question of the shep= herd review -- on the reviews done, on document readiness, and on the docum= ent quality -- in a way as positive and sincere as possible. In particular = questions (3) (4) and (6). So, hopefully the answers to these three questions are now clear. I believe= your main concern is to ensure that we can apply two-RT approach of sec. 2= .1 to sec. 2.2 (and we can still do and still have a single MAC-VRF) This draft talks about two kinds of traffic filtering: a) ingress filtering= for known unicast and b) egress filtering for BUM traffic. What you are su= ggesting is an alternate mechanism for ingress filtering. (well I'm not suggesting the mechanism itself --which section 2.1 already d= oes-- but simply to document that it can still apply without the constraint= of avoiding the presence of a Root MAC-VRF and a Leaf MAC-VRF on a same PE= ) Although having multiple VRFs (and forwarding tables) are fine for IP-VPNs = because the unknown traffic is always dropped, multiple VRFs for the same V= LAN is not OK for L2 traffic because of flooding of unknown traffic. That= =92s why in section 6 of RFC 7432, for all service interface types, the dra= ft talks about a single MAC-VRF per EVI per PE and in case of VLAN-aware mo= de, multiple VLANs per MAC-VRF but only a single bridge table per VLAN. In= other words, the bottom line is that there can only be a single bridge tab= le per VLAN in order to avoid unnecessary flooding. When you have two MAC-VRFs per VLAN (one for root ACs and another for Leaf = ACs), then you either need to duplicate lots of MAC addresses between these= two VRFs, or do lookup on both of these VRFs. Either ways this is not a go= od option relative to keeping a single VRF table for both root and leaf sit= es and just have a single-bit indication on whether a MAC is associated wit= h root or leaf (as currently described approach in the draft). I In the above, it seems you agree that it can work, and you are able to offe= r reasons why it is not the preferred option, then why not just document th= at it can work and provides these reasons as the motivations that lead to p= roposing a new specs ? Sure, I can do that. This way, it would help future readers as to why we ha= ve chosen one approach versus the other. I am sure lot of people with IP-VP= N background like yourself will have the same question. Cheers, Ali (it seems you have an unfinished last sentence: "I [...]" ) (assuming the previous point is resolved:) With this mechanism above, isn't it possible to have on a given PE, for a s= ingle E-TREE EVI, both Leaves and Roots, as long as distinct MAC-VRFs are u= sed (one for Leaves and one for Roots) ? (it seems to me that the assymet= ric import/export RT would do what is needed to build an E-TREE, we would j= ust have a particular case where a Leaf MAC-VRF and a Root MAC-VRF for a gi= ven E-TREE end up on a single PE) That=92s not possible because per definition of an EVI, there is only a sin= gle MAC-VRF per EVI for a PE. Where can I read such a definition ? (the Terminology section in RFC7432 do= es not say that, unless I'm missing something). And that seems a completely arbitrary restriction. (just thinking that a given PE device can be split in two logical devices s= how that it can work) Section 6 of RFC7432 where it gives definitions for different service inter= face types, it specifies the relationship between MAC-VRF and VLAN (bridge = table) and how many MAC-VRF (and bridge tables) can be per EVI. This section of RFC7434 discusses many different things for the different v= ariants. Can you provide a specific pointer about "how many MAC-VRFs can be per EVI"= ? Ali> Section 6 of RFC7432 spells out the relationship between EVI, MAC-VRF,= and bridge tables for all service interfaces very clearly. In all service interfaces, the RFC says there is one MAC-VRF per EVI on a g= iven PE. Now, if the service interface is =93vlan-aware=94, then there are several b= ridge tables for that single MAC-VRF =96 ie, one bridge table per VLAN. In = all service interfaces, you can ONLY have one bridge table per VLAN. This answer is everything but a specific pointer. If Section 6 of RFC7432 says all this very clearly, I guess it should be po= ssible to extract quotes about "there is one MAC-VRF per EVI on a given PE"= , right ? In bridging world, there can only be a single bridge table per VLAN in a de= vice. I still don't find here anything that would preclude having, on a given PE,= for a given E-TREE EVI, one Leaves MAC-VRF and one Roots MAC-VRF: can't th= ese two MAC-VRFs use different internal VLANs (with translation if the exte= rnal VLANs are constrained). Ali> Lets assume we are using vlan-based service and thus there is only a = single bridge table per MAC-VRF, then what you are suggesting is two use tw= o MAC-VRFs (two bridge tables) for the same EVI (same VLAN). This results i= n some duplications of MAC addresses and would only work if flooding is dis= abled (more on this later). "results in some duplications of MAC" is perhaps a drawback, but nothing li= ke "just does not work" ? "would only work if flooding is disabled": why ? (you wrote "(more on this= later)" but I couldn't identify anything recent from you in the rest of th= e email below) >From an helicopter view, I can't see what fundamentally would become proble= matic between "two MAC-VRFs on two distinct PEs" and the same "two MAC-VRFs= on a same PEs", at worse it is as efficient or as inefficient as having th= em on separate PEs (think logical router without anykind of dataplane optim= isation), and we can't exclude that the PE could have local implementation = details to do better than that. Besides, I don=92t understand what good does it do to have two MAC-VRFs on = the same PE (one for Leafs and another for Roots) Well, the "what is good for" is pretty simple: it means you can have, just = by tailoring the import/export policies like in 2.1, something as useful as= the scenario in 2.2. There can only be a single bridge table per VLAN. Now even if you add some = kind of logic to form two logical PEs in single physical PE, you end up rep= licating all the MAC addresses associated with the root sites in two bridge= tables. Your point above certainly does not sound to me as "it can't be done": some= may think that the above is an acceptable cost, some others may find ways = to make this "replication" with a low overhead, on some platforms the cost = may be negligible, etc. because Leafs and Roots need to talk to each other and thus we want them to= be in the same MAC-VRF. The fact that Leafs and Roots need to talk to each other does not mean that= they *have* to be in the same MAC-VRF, you can rely on the local MPLS data= plane inside the PE to carry the traffic between Roots and Leaves can be pa= ssed between a Leaf MAC-VRF and a Root MAC-VRF (and you can possibly implem= ent a shortcut not involving MPLS encap/decap). Anything is possible but at what cost. You know, for cost it is not always obvious to reach conclusions that are t= rue for all implementations and all targets. The current proposal is very efficient in terms of forwarding path as well = as control plane. Sure, but what I question is not the new solution but the lack of discussio= n on why using the existing specs was not considered good enough. I think that my concern of clearly explaining the scenarios and motivations= for this new spec could be addressed by splitting section 2.2 into a 2.2.1= describing the approach from 2.1 and its possible drawbacks, and a 2.2.2 h= aving essentially the content of current section 2.2. Here is a proposal: 2.2 Scenario 2: Leaf of Root site(s) per AC In these scenarii, a PE receives traffic from either Root OR Leaf sites (but not both) on a given Attachment Circuit (AC) of an EVI. In other words, an AC (ES or ES/VLAN) is either associated with Root(s) or Leaf(s) (but not both). 2.2.1 Scenario 2a: Leaf OR Root site(s) per AC, separate Leaf/Root MAC-VRFs +---------+ +---------+ | PE1 | | PE2 | +---+ | +---+ | +------+ | +---+ | +---+ |CE1+-----ES1----+--+ | | | | | |MAC+--+---ES2/AC1--+CE2| +---+ (Leaf) | |MAC| | | MPLS | | |VRF| | (Leaf) +---+ | |VRF| | | /IP | | '---' | | | | | | | | .---. | | | | | | | | |MAC| | +---+ | | | | | | | |VRF+--+---ES2/AC2--+CE3| | +---+ | +------+ | +---+ | (Root) +---+ +---------+ +---------+ Figure 2: Scenario 2a In this scenario, the RT constraint procedures described in section 2.1 = could also be used. The feasibility and efficiency of this approach depends on platforms specifics. This approach will lead toduplication of a large proportion of MAC addre= sses on PEs having both Leaf and Root sites, and is hence considered less suitab= le for deployment contexts where the vast majority of PEs are likely to ultimat= ely have both Leaf and Root sites attached to them. 2.2.2 Scenario 2b: Leaf OR Root site(s) per AC, single MAC-VRF +---------+ +---------+ | PE1 | | PE2 | +---+ | +---+ | +------+ | +---+ | +---+ |CE1+-----ES1----+--+ | | | | | | +--+---ES2/AC1--+CE2| +---+ (Leaf) | |MAC| | | MPLS | | |MAC| | (Leaf) +---+ | |VRF| | | /IP | | |VRF| | | | | | | | | | | | +---+ | | | | | | | | +--+---ES2/AC2--+CE3| | +---+ | +------+ | +---+ | (Root) +---+ +---------+ +---------+ Figure 2: Scenario 2b This scenario will alleviate keys drawbacks from Scenario 2a, in particu= lar by avoiding duplication of MAC addresses on Leaf/Root PEs and avoiding t= he operational overhead of managing more than one RT. This approach comes at the expense of having routes for unneeded MAC add= resses on Leaf-only PEs, and is hence considered less suitable for deployment c= ontexts where the vast majority of PEs would remain Leaf-only. Unlike Scenario= 1 and Scenario 2a, this scenario requires additional procedures provided in this document. (And this last sentence should be added to section 2.3 as well) For this scenario, if for a given EVI, the majority of PEs will eventually have both Leaf and Root sites attached, even though they may start as Root-only or Leaf-only PEs, then it is recommended to use a single RT per EVI and avoid additional configuration and operational overhead. Why this recommendation ? Even with a majority of PEs having both Leaves and Roots, there can remain = (up to 49% of) PEs having only Leaves, which will uselessly have all routes= to other Leaves. So "it is recommended" above, deserves to be explained more, I think. OK, I changed =93majority=94 to =93vast majority=94 :-) My point was not to nit pick on "majority", but was that you should explain= why you recommend that. As the text currently reads, the cost of the recommendation can be identifi= ed: having useless routes on the fraction of PEs having only Leaves. But the gain brought by the recommendation is not even mentioned, not to sa= y explained. Hence: why ? (Why is it a useful tradeoff to have useless routes on some, even if only o= ne, PE ?) Changed the last sentence from: "then it is recommended to use a single RT per EVI and avoid additional con= figuration and operational overhead.=94 To "then it is recommended to use a single RT per EVI and avoid additional con= figuration and operational overhead at the expense of having unwanted MAC addresses on the Leaf PEs." Ok. I adapted and incorporated this addition into my proposed text splittin= g 2.2 into a 2.2.1 and a 2.2.2. Best, -Thomas --_000_D47571E11C6CE2sajassiciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <0C1796BC7B7A9348B4BE79F7471CD634@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi Thomas,

Please refer to my comments inline.

From: Thomas Morin <thomas.morin@orange.com>
Organization: Orange
Date: Monday, December 12, 2016 at = 6:48 AM
To: Cisco Employee <sajassi@cisco.com>, "draft-ietf-bess-evpn-etree@ietf.org" <draft-i= etf-bess-evpn-etree@ietf.org>, Loa Andersson <loa@pi.nu>, "Ge= orge Swallow -T (swallow - MBO PARTNERS INC at Cisco)" <swallow@cisco.com>, Eric Rosen <erosen@juniper.net>, BESS <bess@ietf.org>
Cc: Martin Vigoureux <martin.vigoureux@nokia.com>
Subject: Re: shepherd review of dra= ft-ietf-bess-evpn-etree

Hi Ali,

2016-12-10, Ali Sajassi (sajassi):
Your suggestion regarding multiple MAC-VRFs per EVI for E-TREE, impact= s lot more sections than just section 2.2 for which you suggested some text= s. It drastically  impacts section 3.1 (known unicast traffic), and it= also impacts section 3.2 (BUM traffic) and section 5.1.

Can you detail why ?
The understanding that leads me to this suggestion is that the 2-RT+spl= it-horizon scenario in 2.1, then applied to Root/Leaf PE in a 2.2.1 would n= ot require new procotol procedures nor changes in the text that as I unders= tand provides procedures for 2.2(.2) and 2.3.

The reason t= hat impacts more sections than just sec. 2, is that the proposed 2.2.1 woul= d be an alternative option for section 3.1. In section 3.1, the root/leaf i= ndication for MAC addresses are done via flag-bit defined in section 5.1 and it only uses a single MAC-VRF (sin= gle bridge table per VLAN) per RFC 7432. If we go with two MAC-VRFs (e.g., = two bridge tables) per VLAN, then that is an alternative way of doing = the same thing described in section 3.1. This alternative way has big ramifications on the platform as it requires = duplicating MACs and managing multiple bridge tables per VLAN. 

Maybe what you really want is to allow for sce= nario 2.2 to operate with two RTs which has the benefits of both 2.2.1 and = 2.2.2 and non of the drawbacks. So, maybe we can clarify the current text t= o make sure that this comes out clearly =96 ie, a PE can have single MAC=96VRF can have multiple RTs.

Furthermore, it creates a new paradigm for EVPN that was never intende= d for because of creating two MAC-VRFs (and two bridge tables) for the same= VLAN.

The "<new thing> created a new paradigm that <RFX xyz> was= never intended for" is a not generally valid, or sufficiently detaile= d, argument: if it was, then you might go as far as challenging the whole E= -Tree spec on the same kind grounds (and many other new things).

So here is where it seems we have a gap to bridge: I still don't understand= what in RFC7432 describes an intention of "not supporting two MAC-VRF= s for the same VLAN".

I tried to explain the relationship between EV= I, MAC-VRF, bridge table, and VLAN in my previous email per RFC 7432. = However, lets park this discussion for time being as I think it is sec= ondary.

I think you agree that if we have a single sol= ution that has all the benefits of your proposed 2.2.1 and 2.2.2 and none o= f the drawbacks, it is much more preferable with having two solutions each = with its own advantages and draw backs, right? If so, then existing text in 2.2 was intended to convey that. Howev= er, we can clarify it further =96 e.g, make it clear that for PE = with root & leaf in the same EVI, we can use a single MAC-VRF with= two RTs (one for leaf and another for root).

The WG LC was completed on 3/29/16 and I am sure it is not your intent= ion to have major changes to the doc at this stage where multiple vendors h= ave already implemented the draft.

As you know, there are different stages at which people do reviews on a doc= after WGLC, an which may lead doc editors to introduce significant --edito= rial or technical-- changes in a document. Sometimes that leads to document= s going back to the working group.

However my root intention as doc shepherd, of course, is not to propose a m= ajor change, but merely to able to answer the standard question of the shep= herd review -- on the reviews done, on document readiness, and on the docum= ent quality -- in a way as positive and sincere as possible. In particular questions (3) (4) and (6).

So, hopefully the answers to these three quest= ions are now clear. I believe your main concern is to ensure that= we can apply two-RT approach of sec. 2.1  to sec. 2.2 (and we can sti= ll do and still have a single MAC-VRF) 


This draft talks about two kinds of traffic filtering: a) ingress filt= ering for known unicast and b) egress filtering for BUM traffic. What you a= re suggesting is an alternate mechanism for ingress filtering.

(well I'm not suggesting the mechanism itself --which section 2.1 already d= oes-- but simply to document that it can still apply without the constraint= of avoiding the presence of a Root MAC-VRF and a Leaf MAC-VRF on a same PE= )

Although having multiple VRFs (and forwarding tables) are fine for IP-= VPNs because the unknown traffic is always dropped, multiple VRFs for the s= ame VLAN is not OK for L2 traffic because of flooding of unknown traffic. T= hat=92s why in section 6 of RFC 7432, for all service interface types, the draft talks about a single MAC-VRF pe= r EVI per PE and in case of VLAN-aware mode,  multiple VLANs per MAC-V= RF but only a single bridge table per VLAN. In other words, the bottom line= is that there can only be a single bridge table per VLAN in order to avoid unnecessary flooding.



When you have two MAC-VRFs per VLAN (one for root ACs and another for = Leaf ACs), then you either need to duplicate lots of MAC addresses between = these two VRFs, or do lookup on both of these VRFs. Either ways this is not= a good option relative to keeping a single VRF table for both root and leaf sites and just have a single-bit= indication on whether a MAC is associated with root or leaf (as currently = described approach in the draft).  I


In the above, it seems you agree that it can work, and you are able to offe= r reasons why it is not the preferred option, then why not just document th= at it can work and provides these reasons as the motivations that lead to p= roposing a new specs ?

Sure, I can do that. This way, it would h= elp future readers as to why we have chosen one approach versus the other.&= nbsp;I am sure lot of people with IP-VPN background like yourself will have= the same question.

Cheers,
Ali


(it seems you have an unfinished last sentence: "I [...]" )


=


(assuming the previous point is resolved:)

With this mechanism above, isn't it possible to have on a given PE, for a s= ingle E-TREE EVI, both Leaves and Roots, as long as distinct MAC-VRFs are u= sed (one for Leaves and one for Roots) ?   (it seems to me that t= he assymetric import/export RT would do what is needed to build an E-TREE, we would just have a particular case where a= Leaf MAC-VRF and a Root MAC-VRF for a given E-TREE end up on a single PE)<= /p>


That=92s not possible because per definition of an = EVI, there is only a single MAC-VRF per EVI for a PE.

Where can I read such a definition ? (the= Terminology section in RFC7432 does not say that, unless I'm missing somet= hing).
And that seems a completely arbitrary res= triction.
(just thinking that a given PE device can= be split in two logical devices show that it can work)

Section 6 of= RFC7432 where it gives definitions for different service interface types, = it specifies the relationship between MAC-VRF and VLAN (bridge table) and h= ow many MAC-VRF (and bridge tables) can be per EVI.

This section of RFC7434 discusses many different things for the different v= ariants.
Can you provide a specific pointer about "how many MAC-VRFs can be per= EVI" ?

Ali> Section 6 of RFC7432 spel= ls out the relationship between EVI, MAC-VRF, and bridge tables for all ser= vice interfaces very clearly.
=
In all service interfaces, the RF= C says there is one MAC-VRF per EVI on a given PE.
=
Now, if the service interface is = =93vlan-aware=94, then there are several bridge tables for that single MAC-= VRF =96 ie, one bridge table per VLAN. In all service interfaces, you can O= NLY have one bridge table per VLAN.

This answer is everything but a specific pointer.
If Section 6 of RFC7432 says all this very clearly, I guess it should be po= ssible to extract quotes about "there is one MAC-VRF per EVI on a given PE", right ?


=

In bridging world, there can only b= e a single bridge table per VLAN in a device.

I still don't find here anything that would preclude having, on a given PE,= for a given E-TREE EVI, one Leaves MAC-VRF and one Roots MAC-VRF: can't th= ese two MAC-VRFs use different internal VLANs (with translation if the exte= rnal VLANs are constrained).

Ali>  Lets assume we are using vlan-based service and thus there is= only a single bridge table per MAC-VRF, then what you are suggesting is tw= o use two MAC-VRFs (two bridge tables) for the same EVI (same VLAN). This r= esults in some duplications of MAC addresses and would only work if flooding is disabled (more on this later).

"results in some duplications of MAC" is perhaps a drawback, but = nothing like "just does not work" ?

"would only work if flooding is disabled": why ?  (you wrote= "(more on this later)" but I couldn't identify anything recent f= rom you in the rest of the email below)


>From an helicopter view, I can't see what fundamentally would become proble= matic between "two MAC-VRFs on two distinct PEs" and the same &qu= ot;two MAC-VRFs on a same PEs", at worse it is as efficient or as inef= ficient as having them on separate PEs (think logical router without anykind of dataplane optimisation), and we can't exclude th= at the PE could have local implementation details to do better than that.

=

Besides, I don=92t understand what good does i= t do to have two MAC-VRFs on the same PE (one for Leafs and another for Roo= ts)

Well, the "what is good for" is= pretty simple: it means you can have, just by tailoring the import/export = policies like in 2.1, something as useful as the scenario in 2.2.

There can only be a single bridg= e table per VLAN. Now even if you add some kind of logic to form two logical PEs in single physical PE, you end up replicating all the MAC addresses associ= ated with the root sites in two bridge tables.

Your point above certainly does not sound to me as "it can't be done&q= uot;: some may think that the above is an acceptable cost, some others may = find ways to make this "replication" with a low overhead, on some= platforms the cost may be negligible, etc.




because Leafs and Roots need to talk to each other = and thus we want them to be in the same MAC-VRF.

The fact that Leafs and Roots need to talk to each other does= not mean that they *have* to be in the same MAC-VRF, you can rely on the local MPLS dataplane inside the PE to carry the traffic betwee= n Roots and Leaves can be passed between a Leaf MAC-VRF and a Root MAC-VRF = (and you can possibly implement a shortcut not involving MPLS encap/decap).=

Anything is possi= ble but at what cost.

You know, for cost it is not always obvious to reach conclusions that are t= rue for all implementations and all targets.

The current propo= sal is very efficient in terms of forwarding path as well as control plane.=

Sure, but what I question is not the new solution but the lack of discussio= n on why using the existing specs was not considered good enough.


I think that my concern of clearly explaining the scenarios and motivations= for this new spec could be addressed by splitting section 2.2 into a 2.2.1= describing the approach from 2.1 and its possible drawbacks, and a 2.2.2 h= aving essentially the content of current section 2.2.

Here is a proposal:

2.2 Scenario 2: Leaf of Root site(s= ) per AC

   In these scenarii, a P= E receives traffic from either Root OR Leaf
   sites (but not both) o= n a given Attachment Circuit (AC) of an EVI. In
   other words, an AC (ES= or ES/VLAN) is either associated with Root(s)
   or Leaf(s) (but not bo= th).

2.2.1 Scenario 2a: Leaf OR Root sit= e(s) per AC, separate Leaf/Root MAC-VRFs

      = ;            &n= bsp;  +---------+       &nb= sp;    +---------+
      = ;            &n= bsp;  |   PE1   |     &nb= sp;      |   PE2   |
    +---+&nb= sp;           |  = 3;---+  |  +------+  |  +---+ = |            +-= --+
    |CE1+-----ES= 1----+--+   |  |  |    &nbs= p; |  |  |MAC+--+---ES2/AC1--+CE2|
    +---+&nb= sp;   (Leaf)  |  |MAC|  |  | MPLS |  |&n= bsp; |VRF|  |   (Leaf)   +---+
      = ;            &n= bsp;  |  |VRF|  |  |  /IP |  |  '---'&nb= sp; |
      = ;            &n= bsp;  |  |   |  |  |    &= nbsp; |  |  .---.  |
      = ;            &n= bsp;  |  |   |  |  |    &= nbsp; |  |  |MAC|  |      &nbs= p;     +---+
      = ;            &n= bsp;  |  |   |  |  |    &= nbsp; |  |  |VRF+--+---ES2/AC2--+CE3|
      = ;            &n= bsp;  |  +---+  |  +------+  |&nbs= p; +---+  |   (Root)   +---+<= tt style=3D"color: rgb(0, 0, 0);">
      = ;            &n= bsp;  +---------+       &nb= sp;    +---------+

   Figure 2: Scenario 2a<= /tt>

   In this scenario, the = RT constraint procedures described in section 2.1 could
   also be used. The feas= ibility and efficiency of this approach depends on
   platforms specifics.

   This approach will lea= d toduplication of a large proportion of MAC addresses on
   PEs having both Leaf and Root sites, and is hence considered l= ess suitable for
   deployment contexts where the vast majority of PEs are likely = to ultimately
   have both Leaf and Roo= t sites attached to them.

2.2.2 Scenario 2b: Leaf OR Root sit= e(s) per AC, single MAC-VRF

      = ;            &n= bsp;  +---------+       &nb= sp;    +---------+
      = ;            &n= bsp;  |   PE1   |     &nb= sp;      |   PE2   |
    +---+&nb= sp;           |  = 3;---+  |  +------+  |  +---+ = |            +-= --+
    |CE1+-----ES= 1----+--+   |  |  |    &nbs= p; |  |  |   +--+---ES2/AC1--+CE2|
    +---+&nb= sp;   (Leaf)  |  |MAC|  |  | MPLS |  |&n= bsp; |MAC|  |   (Leaf)   +---+
      = ;            &n= bsp;  |  |VRF|  |  |  /IP |  |  |VRF|&nb= sp; |
      = ;            &n= bsp;  |  |   |  |  |    &= nbsp; |  |  |   |  |     =        +---+
      = ;            &n= bsp;  |  |   |  |  |    &= nbsp; |  |  |   +--+---ES2/AC2--+CE3|<= tt style=3D"color: rgb(0, 0, 0);">
      = ;            &n= bsp;  |  +---+  |  +------+  |&nbs= p; +---+  |   (Root)   +---+<= tt style=3D"color: rgb(0, 0, 0);">
      = ;            &n= bsp;  +---------+       &nb= sp;    +---------+

   Figure 2: Scenario 2b<= /tt>

   This scenario will all= eviate keys drawbacks from Scenario 2a, in particular
   by avoiding duplicatio= n of MAC addresses on Leaf/Root PEs and avoiding the
   operational overhead of managing more than one RT.
   This approach comes at the expense of having routes for unneeded MAC addresse=
s
   on Leaf-only PEs, and is =
hence considered less suitable for deployment contexts
   where the vast majority of PEs would remain Leaf-only.   Unlike Sce=
nario 1 and Scenario 2a, this scenario requires additional procedures
   provided in this document.
(And this last sentence should be added to section 2.3 as well)


For this scenario, if for a given
   EVI, the majority of PEs will eventually have both Leaf and Ro= ot
   sites attached, even though they may start as Root-only or Lea= f-only
   PEs, then it is recommended to use a single RT per EVI and avo= id
   additional configuration and operational overhead.

Why this recommendation ?
Even with a majority of PEs having both Leaves and Roots, there can remain = (up to 49% of) PEs having only Leaves, which will uselessly have all routes= to other Leaves.

So "it is recommended" above, deserves to be explained more, I th= ink.

OK, I changed =93majority=94 to =93vast m= ajority=94 :-)

My point was not to nit pick on "majority", but was= that you should explain why you recommend that.
As the text currently reads, the cost of the recommendation c= an be identified: having useless routes on the fraction of PEs having only Leaves.
But the gain brought by the recommendation is not even mentio= ned, not to say explained.
Hence: why ?
(Why is it a useful tradeoff to have useless routes on some, = even if only one, PE ?)

Changed the last sentence from:
"then it is recommended to use a single R= T per EVI and avoid additional configuration and operational overhead.=94
To
"then it is recommended to use a single R= T per EVI and avoid additional configuration and operational overhead
at the expense of having unwanted MAC addresses on = the Leaf PEs."

Ok. I adapted and incorporated this addition into my proposed text splittin= g 2.2 into a 2.2.1 and a 2.2.2.

Best,

-Thomas



 --_000_D47571E11C6CE2sajassiciscocom_-- From nobody Tue Dec 13 12:03:05 2016 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D6621293EC for ; Tue, 13 Dec 2016 12:03:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.417 X-Spam-Level: X-Spam-Status: No, score=-17.417 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6lv6sQleYfAm for ; Tue, 13 Dec 2016 12:03:00 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D76451293D6 for ; Tue, 13 Dec 2016 12:02:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=55984; q=dns/txt; s=iport; t=1481659379; x=1482868979; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=AFtJQVRP0A0nASr4pRankZ9XF3v5RQ6ymXCo66j9aPU=; b=f1lETVdmrInZ7Dfv6LuWrefcjrjjlc6Qi+vaC39CSkBkKlFq4n84hQR6 ZDxpfaJuxanbscLnpLrfdYrKIntvfnxZna8JGibt2zlezO/wgoCAJOw+c oZnIgj8D09xzWan4eiK0upK5Rz4Rf2s1Woz61i7xpFLRTx9iOYfFv+UJW s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AVAQCeUlBY/5hdJa1TChkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJzOQsBAQEBAR+BYAeNQ5cZlQaCCYJGAYNaAoF9PxQBAgEBAQE?= =?us-ascii?q?BAQFiKIRoAQEBBBpSBQEBAQIDEAIBCBEDAQIhAQYHMhQJCAIEAQ0FG4hQrUovi?= =?us-ascii?q?mUBAQEBAQEBAQEBAQEBAQEBAQEBAQEdihGBCIQZAQYLATyFQQWaawGJYYdJgXS?= =?us-ascii?q?FAYNIhguOEoQOAR83Yz6DeBeBXXKGP4EhgQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.33,342,1477958400"; d="scan'208,217";a="359693001" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Dec 2016 20:02:58 +0000 Received: from XCH-RTP-017.cisco.com (xch-rtp-017.cisco.com [64.101.220.157]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id uBDK2v8T008136 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 13 Dec 2016 20:02:57 GMT Received: from xch-rtp-005.cisco.com (64.101.220.145) by XCH-RTP-017.cisco.com (64.101.220.157) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 13 Dec 2016 15:02:56 -0500 Received: from xch-rtp-005.cisco.com ([64.101.220.145]) by XCH-RTP-005.cisco.com ([64.101.220.145]) with mapi id 15.00.1210.000; Tue, 13 Dec 2016 15:02:56 -0500 From: "Ali Sajassi (sajassi)" To: Thomas Morin , Loa Andersson , "George Swallow -T (swallow - MBO PARTNERS INC at Cisco)" , "Eric Rosen" , BESS Thread-Topic: shepherd review of draft-ietf-bess-evpn-etree Thread-Index: AQHSAgSQiVios9dTSUOmTfNWP8T6rqBlA4UAgAGT+oCASmTegIBKoSmAgAU1ewCABIpWAIABYlAAgAABy4A= Date: Tue, 13 Dec 2016 20:02:56 +0000 Message-ID: References: <3323ddae-c96f-49a4-2dec-1bfc4ed857dc@orange.com> <6cb41698-b98b-ecbf-9e34-660771bd3fb8@orange.com> <0b846411-4526-c6d3-3ea4-87ebd90de953@orange.com> <62a4bc51-b9de-4a80-a843-bfa356bc23ea@orange.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.7.0.161029 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.128.224.205] Content-Type: multipart/alternative; boundary="_000_D47593851C6F23sajassiciscocom_" MIME-Version: 1.0 Archived-At: Cc: Martin Vigoureux Subject: Re: [bess] shepherd review of draft-ietf-bess-evpn-etree X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Dec 2016 20:03:04 -0000 --_000_D47593851C6F23sajassiciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable 2nd try. As my 1st response got truncated for some reason. Hi Thomas, Please refer to my comments inline. From: Thomas Morin = > Organization: Orange Date: Monday, December 12, 2016 at 6:48 AM To: Cisco Employee >, "draft-ie= tf-bess-evpn-etree@ietf.org" >, Loa Andersson >, "George Swallow -T (swal= low - MBO PARTNERS INC at Cisco)" >, Eric Rosen >, BESS > Cc: Martin Vigoureux > Subject: Re: shepherd review of draft-ietf-bess-evpn-etree Hi Ali, 2016-12-10, Ali Sajassi (sajassi): Your suggestion regarding multiple MAC-VRFs per EVI for E-TREE, impacts lot= more sections than just section 2.2 for which you suggested some texts. It= drastically impacts section 3.1 (known unicast traffic), and it also impa= cts section 3.2 (BUM traffic) and section 5.1. Can you detail why ? The understanding that leads me to this suggestion is that the 2-RT+split-h= orizon scenario in 2.1, then applied to Root/Leaf PE in a 2.2.1 would not r= equire new procotol procedures nor changes in the text that as I understand= provides procedures for 2.2(.2) and 2.3. The reason that impacts more sections than just sec. 2, is that the propose= d 2.2.1 would be an alternative option for section 3.1. In section 3.1, the= root/leaf indication for MAC addresses are done via flag-bit defined in se= ction 5.1 and it only uses a single MAC-VRF (single bridge table per VLAN) = per RFC 7432. If we go with two MAC-VRFs (e.g., two bridge tables) per VLAN= , then that is an alternative way of doing the same thing described in sect= ion 3.1. This alternative way has big ramifications on the platform as it r= equires duplicating MACs and managing multiple bridge tables per VLAN. Maybe what you really want is to allow for scenario 2.2 to operate with two= RTs which has the benefits of both 2.2.1 and 2.2.2 and non of the drawback= s. So, maybe we can clarify the current text to make sure that this comes o= ut clearly =96 ie, a PE can have single MAC=96VRF can have multiple RTs. Furthermore, it creates a new paradigm for EVPN that was never intended for= because of creating two MAC-VRFs (and two bridge tables) for the same VLAN= . The " created a new paradigm that was never intended f= or" is a not generally valid, or sufficiently detailed, argument: if it was= , then you might go as far as challenging the whole E-Tree spec on the same= kind grounds (and many other new things). So here is where it seems we have a gap to bridge: I still don't understand= what in RFC7432 describes an intention of "not supporting two MAC-VRFs for= the same VLAN". I tried to explain the relationship between EVI, MAC-VRF, bridge table, and= VLAN in my previous email per RFC 7432. However, lets park this discussion= for time being as I think it is secondary. I think you agree that if we have a single solution that has all the benefi= ts of your proposed 2.2.1 and 2.2.2 and none of the drawbacks, it is much m= ore preferable with having two solutions each with its own advantages and d= raw backs, right? If so, then existing text in 2.2 was intended to convey t= hat. However, we can clarify it further =96 e.g, make it clear that for PE = with root & leaf in the same EVI, we can use a single MAC-VRF with two RTs = (one for leaf and another for root). The WG LC was completed on 3/29/16 and I am sure it is not your intention t= o have major changes to the doc at this stage where multiple vendors have a= lready implemented the draft. As you know, there are different stages at which people do reviews on a doc= after WGLC, an which may lead doc editors to introduce significant --edito= rial or technical-- changes in a document. Sometimes that leads to document= s going back to the working group. However my root intention as doc shepherd, of course, is not to propose a m= ajor change, but merely to able to answer the standard question of the shep= herd review -- on the reviews done, on document readiness, and on the docum= ent quality -- in a way as positive and sincere as possible. In particular = questions (3) (4) and (6). So, hopefully the answers to these three questions are now clear. I believe= your main concern is to ensure that we can apply two-RT approach of sec. 2= .1 to sec. 2.2 (and we can still do and still have a single MAC-VRF) This draft talks about two kinds of traffic filtering: a) ingress filtering= for known unicast and b) egress filtering for BUM traffic. What you are su= ggesting is an alternate mechanism for ingress filtering. (well I'm not suggesting the mechanism itself --which section 2.1 already d= oes-- but simply to document that it can still apply without the constraint= of avoiding the presence of a Root MAC-VRF and a Leaf MAC-VRF on a same PE= ) Although having multiple VRFs (and forwarding tables) are fine for IP-VPNs = because the unknown traffic is always dropped, multiple VRFs for the same V= LAN is not OK for L2 traffic because of flooding of unknown traffic. That= =92s why in section 6 of RFC 7432, for all service interface types, the dra= ft talks about a single MAC-VRF per EVI per PE and in case of VLAN-aware mo= de, multiple VLANs per MAC-VRF but only a single bridge table per VLAN. In= other words, the bottom line is that there can only be a single bridge tab= le per VLAN in order to avoid unnecessary flooding. When you have two MAC-VRFs per VLAN (one for root ACs and another for Leaf = ACs), then you either need to duplicate lots of MAC addresses between these= two VRFs, or do lookup on both of these VRFs. Either ways this is not a go= od option relative to keeping a single VRF table for both root and leaf sit= es and just have a single-bit indication on whether a MAC is associated wit= h root or leaf (as currently described approach in the draft). I In the above, it seems you agree that it can work, and you are able to offe= r reasons why it is not the preferred option, then why not just document th= at it can work and provides these reasons as the motivations that lead to p= roposing a new specs ? Sure, I can do that. This way, it would help future readers as to why we ha= ve chosen one approach versus the other. I am sure lot of people with IP-VP= N background like yourself will have the same question. Cheers, Ali (it seems you have an unfinished last sentence: "I [...]" ) (assuming the previous point is resolved:) With this mechanism above, isn't it possible to have on a given PE, for a s= ingle E-TREE EVI, both Leaves and Roots, as long as distinct MAC-VRFs are u= sed (one for Leaves and one for Roots) ? (it seems to me that the assymet= ric import/export RT would do what is needed to build an E-TREE, we would j= ust have a particular case where a Leaf MAC-VRF and a Root MAC-VRF for a gi= ven E-TREE end up on a single PE) That=92s not possible because per definition of an EVI, there is only a sin= gle MAC-VRF per EVI for a PE. Where can I read such a definition ? (the Terminology section in RFC7432 do= es not say that, unless I'm missing something). And that seems a completely arbitrary restriction. (just thinking that a given PE device can be split in two logical devices s= how that it can work) Section 6 of RFC7432 where it gives definitions for different service inter= face types, it specifies the relationship between MAC-VRF and VLAN (bridge = table) and how many MAC-VRF (and bridge tables) can be per EVI. This section of RFC7434 discusses many different things for the different v= ariants. Can you provide a specific pointer about "how many MAC-VRFs can be per EVI"= ? Ali> Section 6 of RFC7432 spells out the relationship between EVI, MAC-VRF,= and bridge tables for all service interfaces very clearly. In all service interfaces, the RFC says there is one MAC-VRF per EVI on a g= iven PE. Now, if the service interface is =93vlan-aware=94, then there are several b= ridge tables for that single MAC-VRF =96 ie, one bridge table per VLAN. In = all service interfaces, you can ONLY have one bridge table per VLAN. This answer is everything but a specific pointer. If Section 6 of RFC7432 says all this very clearly, I guess it should be po= ssible to extract quotes about "there is one MAC-VRF per EVI on a given PE"= , right ? In bridging world, there can only be a single bridge table per VLAN in a de= vice. I still don't find here anything that would preclude having, on a given PE,= for a given E-TREE EVI, one Leaves MAC-VRF and one Roots MAC-VRF: can't th= ese two MAC-VRFs use different internal VLANs (with translation if the exte= rnal VLANs are constrained). Ali> Lets assume we are using vlan-based service and thus there is only a = single bridge table per MAC-VRF, then what you are suggesting is two use tw= o MAC-VRFs (two bridge tables) for the same EVI (same VLAN). This results i= n some duplications of MAC addresses and would only work if flooding is dis= abled (more on this later). "results in some duplications of MAC" is perhaps a drawback, but nothing li= ke "just does not work" ? "would only work if flooding is disabled": why ? (you wrote "(more on this= later)" but I couldn't identify anything recent from you in the rest of th= e email below) >From an helicopter view, I can't see what fundamentally would become proble= matic between "two MAC-VRFs on two distinct PEs" and the same "two MAC-VRFs= on a same PEs", at worse it is as efficient or as inefficient as having th= em on separate PEs (think logical router without anykind of dataplane optim= isation), and we can't exclude that the PE could have local implementation = details to do better than that. Besides, I don=92t understand what good does it do to have two MAC-VRFs on = the same PE (one for Leafs and another for Roots) Well, the "what is good for" is pretty simple: it means you can have, just = by tailoring the import/export policies like in 2.1, something as useful as= the scenario in 2.2. There can only be a single bridge table per VLAN. Now even if you add some = kind of logic to form two logical PEs in single physical PE, you end up rep= licating all the MAC addresses associated with the root sites in two bridge= tables. Your point above certainly does not sound to me as "it can't be done": some= may think that the above is an acceptable cost, some others may find ways = to make this "replication" with a low overhead, on some platforms the cost = may be negligible, etc. because Leafs and Roots need to talk to each other and thus we want them to= be in the same MAC-VRF. The fact that Leafs and Roots need to talk to each other does not mean that= they *have* to be in the same MAC-VRF, you can rely on the local MPLS data= plane inside the PE to carry the traffic between Roots and Leaves can be pa= ssed between a Leaf MAC-VRF and a Root MAC-VRF (and you can possibly implem= ent a shortcut not involving MPLS encap/decap). Anything is possible but at what cost. You know, for cost it is not always obvious to reach conclusions that are t= rue for all implementations and all targets. The current proposal is very efficient in terms of forwarding path as well = as control plane. Sure, but what I question is not the new solution but the lack of discussio= n on why using the existing specs was not considered good enough. I think that my concern of clearly explaining the scenarios and motivations= for this new spec could be addressed by splitting section 2.2 into a 2.2.1= describing the approach from 2.1 and its possible drawbacks, and a 2.2.2 h= aving essentially the content of current section 2.2. Here is a proposal: 2.2 Scenario 2: Leaf of Root site(s) per AC In these scenarii, a PE receives traffic from either Root OR Leaf sites (but not both) on a given Attachment Circuit (AC) of an EVI. In other words, an AC (ES or ES/VLAN) is either associated with Root(s) or Leaf(s) (but not both). 2.2.1 Scenario 2a: Leaf OR Root site(s) per AC, separate Leaf/Root MAC-VRFs +---------+ +---------+ | PE1 | | PE2 | +---+ | +---+ | +------+ | +---+ | +---+ |CE1+-----ES1----+--+ | | | | | |MAC+--+---ES2/AC1--+CE2| +---+ (Leaf) | |MAC| | | MPLS | | |VRF| | (Leaf) +---+ | |VRF| | | /IP | | '---' | | | | | | | | .---. | | | | | | | | |MAC| | +---+ | | | | | | | |VRF+--+---ES2/AC2--+CE3| | +---+ | +------+ | +---+ | (Root) +---+ +---------+ +---------+ Figure 2: Scenario 2a In this scenario, the RT constraint procedures described in section 2.1 = could also be used. The feasibility and efficiency of this approach depends on platforms specifics. This approach will lead toduplication of a large proportion of MAC addre= sses on PEs having both Leaf and Root sites, and is hence considered less suitab= le for deployment contexts where the vast majority of PEs are likely to ultimat= ely have both Leaf and Root sites attached to them. 2.2.2 Scenario 2b: Leaf OR Root site(s) per AC, single MAC-VRF +---------+ +---------+ | PE1 | | PE2 | +---+ | +---+ | +------+ | +---+ | +---+ |CE1+-----ES1----+--+ | | | | | | +--+---ES2/AC1--+CE2| +---+ (Leaf) | |MAC| | | MPLS | | |MAC| | (Leaf) +---+ | |VRF| | | /IP | | |VRF| | | | | | | | | | | | +---+ | | | | | | | | +--+---ES2/AC2--+CE3| | +---+ | +------+ | +---+ | (Root) +---+ +---------+ +---------+ Figure 2: Scenario 2b This scenario will alleviate keys drawbacks from Scenario 2a, in particu= lar by avoiding duplication of MAC addresses on Leaf/Root PEs and avoiding t= he operational overhead of managing more than one RT. This approach comes at the expense of having routes for unneeded MAC add= resses on Leaf-only PEs, and is hence considered less suitable for deployment c= ontexts where the vast majority of PEs would remain Leaf-only. Unlike Scenario= 1 and Scenario 2a, this scenario requires additional procedures provided in this document. (And this last sentence should be added to section 2.3 as well) For this scenario, if for a given EVI, the majority of PEs will eventually have both Leaf and Root sites attached, even though they may start as Root-only or Leaf-only PEs, then it is recommended to use a single RT per EVI and avoid additional configuration and operational overhead. Why this recommendation ? Even with a majority of PEs having both Leaves and Roots, there can remain = (up to 49% of) PEs having only Leaves, which will uselessly have all routes= to other Leaves. So "it is recommended" above, deserves to be explained more, I think. OK, I changed =93majority=94 to =93vast majority=94 :-) My point was not to nit pick on "majority", but was that you should explain= why you recommend that. As the text currently reads, the cost of the recommendation can be identifi= ed: having useless routes on the fraction of PEs having only Leaves. But the gain brought by the recommendation is not even mentioned, not to sa= y explained. Hence: why ? (Why is it a useful tradeoff to have useless routes on some, even if only o= ne, PE ?) Changed the last sentence from: "then it is recommended to use a single RT per EVI and avoid additional con= figuration and operational overhead.=94 To "then it is recommended to use a single RT per EVI and avoid additional con= figuration and operational overhead at the expense of having unwanted MAC addresses on the Leaf PEs." Ok. I adapted and incorporated this addition into my proposed text splittin= g 2.2 into a 2.2.1 and a 2.2.2. Best, -Thomas --_000_D47593851C6F23sajassiciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <0583C23FF3B1564481C52A1BA10B8499@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
2nd try. As my 1st response got truncated for some reason.


Hi Thomas,

Please refer to my comments inline.

From: Thomas Morin <thomas.morin@orange.com>
Organization: Orange
Date: Monday, December 12, 2016 at = 6:48 AM
To: Cisco Employee <sajassi@cisco.com>, "draft-ietf-bess-evpn-etree@ietf.org" <draft-i= etf-bess-evpn-etree@ietf.org>, Loa Andersson <loa@pi.nu>, "Ge= orge Swallow -T (swallow - MBO PARTNERS INC at Cisco)" <swallow@cisco.com>, Eric Rosen <erosen@juniper.net>, BESS <bess@ietf.org>
Cc: Martin Vigoureux <martin.vigoureux@nokia.com>
Subject: Re: shepherd review of dra= ft-ietf-bess-evpn-etree

Hi Ali,

2016-12-10, Ali Sajassi (sajassi):
Your suggestion regarding multiple MAC-VRFs per EVI for E-TREE, impact= s lot more sections than just section 2.2 for which you suggested some text= s. It drastically  impacts section 3.1 (known unicast traffic), and it= also impacts section 3.2 (BUM traffic) and section 5.1.

Can you detail why ?
The understanding that leads me to this suggestion is that the 2-RT+spl= it-horizon scenario in 2.1, then applied to Root/Leaf PE in a 2.2.1 would n= ot require new procotol procedures nor changes in the text that as I unders= tand provides procedures for 2.2(.2) and 2.3.

The reason t= hat impacts more sections than just sec. 2, is that the proposed 2.2.1 woul= d be an alternative option for section 3.1. In section 3.1, the root/leaf i= ndication for MAC addresses are done via flag-bit defined in section 5.1 and it only uses a single MAC-VRF (sin= gle bridge table per VLAN) per RFC 7432. If we go with two MAC-VRFs (e.g., = two bridge tables) per VLAN, then that is an alternative way of doing = the same thing described in section 3.1. This alternative way has big ramifications on the platform as it requires = duplicating MACs and managing multiple bridge tables per VLAN. 

Maybe what you really want is to allow for sce= nario 2.2 to operate with two RTs which has the benefits of both 2.2.1 and = 2.2.2 and non of the drawbacks. So, maybe we can clarify the current text t= o make sure that this comes out clearly =96 ie, a PE can have single MAC=96VRF can have multiple RTs.

Furthermore, it creates a new paradigm for EVPN that was never intende= d for because of creating two MAC-VRFs (and two bridge tables) for the same= VLAN.

The "<new thing> created a new paradigm that <RFX xyz> was= never intended for" is a not generally valid, or sufficiently detaile= d, argument: if it was, then you might go as far as challenging the whole E= -Tree spec on the same kind grounds (and many other new things).

So here is where it seems we have a gap to bridge: I still don't understand= what in RFC7432 describes an intention of "not supporting two MAC-VRF= s for the same VLAN".

I tried to explain the relationship between EV= I, MAC-VRF, bridge table, and VLAN in my previous email per RFC 7432. = However, lets park this discussion for time being as I think it is sec= ondary.

I think you agree that if we have a single sol= ution that has all the benefits of your proposed 2.2.1 and 2.2.2 and none o= f the drawbacks, it is much more preferable with having two solutions each = with its own advantages and draw backs, right? If so, then existing text in 2.2 was intended to convey that. Howev= er, we can clarify it further =96 e.g, make it clear that for PE = with root & leaf in the same EVI, we can use a single MAC-VRF with= two RTs (one for leaf and another for root).

The WG LC was completed on 3/29/16 and I am sure it is not your intent= ion to have major changes to the doc at this stage where multiple vendors h= ave already implemented the draft.

As you know, there are different stages at which people do reviews on a doc= after WGLC, an which may lead doc editors to introduce significant --edito= rial or technical-- changes in a document. Sometimes that leads to document= s going back to the working group.

However my root intention as doc shepherd, of course, is not to propose a m= ajor change, but merely to able to answer the standard question of the shep= herd review -- on the reviews done, on document readiness, and on the docum= ent quality -- in a way as positive and sincere as possible. In particular questions (3) (4) and (6).

So, hopefully the answers to these three quest= ions are now clear. I believe your main concern is to ensure that= we can apply two-RT approach of sec. 2.1  to sec. 2.2 (and we can sti= ll do and still have a single MAC-VRF) 


This draft talks about two kinds of traffic filtering: a) ingress filt= ering for known unicast and b) egress filtering for BUM traffic. What you a= re suggesting is an alternate mechanism for ingress filtering.

(well I'm not suggesting the mechanism itself --which section 2.1 already d= oes-- but simply to document that it can still apply without the constraint= of avoiding the presence of a Root MAC-VRF and a Leaf MAC-VRF on a same PE= )

Although having multiple VRFs (and forwarding tables) are fine for IP-= VPNs because the unknown traffic is always dropped, multiple VRFs for the s= ame VLAN is not OK for L2 traffic because of flooding of unknown traffic. T= hat=92s why in section 6 of RFC 7432, for all service interface types, the draft talks about a single MAC-VRF pe= r EVI per PE and in case of VLAN-aware mode,  multiple VLANs per MAC-V= RF but only a single bridge table per VLAN. In other words, the bottom line= is that there can only be a single bridge table per VLAN in order to avoid unnecessary flooding.



When you have two MAC-VRFs per VLAN (one for root ACs and another for = Leaf ACs), then you either need to duplicate lots of MAC addresses between = these two VRFs, or do lookup on both of these VRFs. Either ways this is not= a good option relative to keeping a single VRF table for both root and leaf sites and just have a single-bit= indication on whether a MAC is associated with root or leaf (as currently = described approach in the draft).  I


In the above, it seems you agree that it can work, and you are able to offe= r reasons why it is not the preferred option, then why not just document th= at it can work and provides these reasons as the motivations that lead to p= roposing a new specs ?

Sure, I can do that. This way, it would h= elp future readers as to why we have chosen one approach versus the other.&= nbsp;I am sure lot of people with IP-VPN background like yourself will have= the same question.

Cheers,
Ali


(it seems you have an unfinished last sentence: "I [...]" )


=


(assuming the previous point is resolved:)

With this mechanism above, isn't it possible to have on a given PE, for a s= ingle E-TREE EVI, both Leaves and Roots, as long as distinct MAC-VRFs are u= sed (one for Leaves and one for Roots) ?   (it seems to me that t= he assymetric import/export RT would do what is needed to build an E-TREE, we would just have a particular case where a= Leaf MAC-VRF and a Root MAC-VRF for a given E-TREE end up on a single PE)<= /p>


That=92s not possible because per definition of an = EVI, there is only a single MAC-VRF per EVI for a PE.

Where can I read such a definition ? (the= Terminology section in RFC7432 does not say that, unless I'm missing somet= hing).
And that seems a completely arbitrary res= triction.
(just thinking that a given PE device can= be split in two logical devices show that it can work)

Section 6 of= RFC7432 where it gives definitions for different service interface types, = it specifies the relationship between MAC-VRF and VLAN (bridge table) and h= ow many MAC-VRF (and bridge tables) can be per EVI.

This section of RFC7434 discusses many different things for the different v= ariants.
Can you provide a specific pointer about "how many MAC-VRFs can be per= EVI" ?

Ali> Section 6 of RFC7432 spel= ls out the relationship between EVI, MAC-VRF, and bridge tables for all ser= vice interfaces very clearly.
=
In all service interfaces, the RF= C says there is one MAC-VRF per EVI on a given PE.
=
Now, if the service interface is = =93vlan-aware=94, then there are several bridge tables for that single MAC-= VRF =96 ie, one bridge table per VLAN. In all service interfaces, you can O= NLY have one bridge table per VLAN.

This answer is everything but a specific pointer.
If Section 6 of RFC7432 says all this very clearly, I guess it should be po= ssible to extract quotes about "there is one MAC-VRF per EVI on a given PE", right ?


=

In bridging world, there can only b= e a single bridge table per VLAN in a device.

I still don't find here anything that would preclude having, on a given PE,= for a given E-TREE EVI, one Leaves MAC-VRF and one Roots MAC-VRF: can't th= ese two MAC-VRFs use different internal VLANs (with translation if the exte= rnal VLANs are constrained).

Ali>  Lets assume we are using vlan-based service and thus there is= only a single bridge table per MAC-VRF, then what you are suggesting is tw= o use two MAC-VRFs (two bridge tables) for the same EVI (same VLAN). This r= esults in some duplications of MAC addresses and would only work if flooding is disabled (more on this later).

"results in some duplications of MAC" is perhaps a drawback, but = nothing like "just does not work" ?

"would only work if flooding is disabled": why ?  (you wrote= "(more on this later)" but I couldn't identify anything recent f= rom you in the rest of the email below)


>From an helicopter view, I can't see what fundamentally would become proble= matic between "two MAC-VRFs on two distinct PEs" and the same &qu= ot;two MAC-VRFs on a same PEs", at worse it is as efficient or as inef= ficient as having them on separate PEs (think logical router without anykind of dataplane optimisation), and we can't exclude th= at the PE could have local implementation details to do better than that.

=

Besides, I don=92t understand what good does i= t do to have two MAC-VRFs on the same PE (one for Leafs and another for Roo= ts)

Well, the "what is good for" is= pretty simple: it means you can have, just by tailoring the import/export = policies like in 2.1, something as useful as the scenario in 2.2.

There can only be a single bridg= e table per VLAN. Now even if you add some kind of logic to form two logical PEs in single physical PE, you end up replicating all the MAC addresses associ= ated with the root sites in two bridge tables.

Your point above certainly does not sound to me as "it can't be done&q= uot;: some may think that the above is an acceptable cost, some others may = find ways to make this "replication" with a low overhead, on some= platforms the cost may be negligible, etc.




because Leafs and Roots need to talk to each other = and thus we want them to be in the same MAC-VRF.

The fact that Leafs and Roots need to talk to each other does= not mean that they *have* to be in the same MAC-VRF, you can rely on the local MPLS dataplane inside the PE to carry the traffic betwee= n Roots and Leaves can be passed between a Leaf MAC-VRF and a Root MAC-VRF = (and you can possibly implement a shortcut not involving MPLS encap/decap).=

Anything is possi= ble but at what cost.

You know, for cost it is not always obvious to reach conclusions that are t= rue for all implementations and all targets.

The current propo= sal is very efficient in terms of forwarding path as well as control plane.=

Sure, but what I question is not the new solution but the lack of discussio= n on why using the existing specs was not considered good enough.


I think that my concern of clearly explaining the scenarios and motivations= for this new spec could be addressed by splitting section 2.2 into a 2.2.1= describing the approach from 2.1 and its possible drawbacks, and a 2.2.2 h= aving essentially the content of current section 2.2.

Here is a proposal:

2.2 Scenario 2: Leaf of Root site(s= ) per AC

   In these scenarii, a P= E receives traffic from either Root OR Leaf
   sites (but not both) o= n a given Attachment Circuit (AC) of an EVI. In
   other words, an AC (ES= or ES/VLAN) is either associated with Root(s)
   or Leaf(s) (but not bo= th).

2.2.1 Scenario 2a: Leaf OR Root sit= e(s) per AC, separate Leaf/Root MAC-VRFs

      = ;            &n= bsp;  +---------+       &nb= sp;    +---------+
      = ;            &n= bsp;  |   PE1   |     &nb= sp;      |   PE2   |
    +---+&nb= sp;           |  = 3;---+  |  +------+  |  +---+ = |            +-= --+
    |CE1+-----ES= 1----+--+   |  |  |    &nbs= p; |  |  |MAC+--+---ES2/AC1--+CE2|
    +---+&nb= sp;   (Leaf)  |  |MAC|  |  | MPLS |  |&n= bsp; |VRF|  |   (Leaf)   +---+
      = ;            &n= bsp;  |  |VRF|  |  |  /IP |  |  '---'&nb= sp; |
      = ;            &n= bsp;  |  |   |  |  |    &= nbsp; |  |  .---.  |
      = ;            &n= bsp;  |  |   |  |  |    &= nbsp; |  |  |MAC|  |      &nbs= p;     +---+
      = ;            &n= bsp;  |  |   |  |  |    &= nbsp; |  |  |VRF+--+---ES2/AC2--+CE3|
      = ;            &n= bsp;  |  +---+  |  +------+  |&nbs= p; +---+  |   (Root)   +---+<= tt style=3D"color: rgb(0, 0, 0);">
      = ;            &n= bsp;  +---------+       &nb= sp;    +---------+

   Figure 2: Scenario 2a<= /tt>

   In this scenario, the = RT constraint procedures described in section 2.1 could
   also be used. The feas= ibility and efficiency of this approach depends on
   platforms specifics.

   This approach will lea= d toduplication of a large proportion of MAC addresses on
   PEs having both Leaf and Root sites, and is hence considered l= ess suitable for
   deployment contexts where the vast majority of PEs are likely = to ultimately
   have both Leaf and Roo= t sites attached to them.

2.2.2 Scenario 2b: Leaf OR Root sit= e(s) per AC, single MAC-VRF

      = ;            &n= bsp;  +---------+       &nb= sp;    +---------+
      = ;            &n= bsp;  |   PE1   |     &nb= sp;      |   PE2   |
    +---+&nb= sp;           |  = 3;---+  |  +------+  |  +---+ = |            +-= --+
    |CE1+-----ES= 1----+--+   |  |  |    &nbs= p; |  |  |   +--+---ES2/AC1--+CE2|
    +---+&nb= sp;   (Leaf)  |  |MAC|  |  | MPLS |  |&n= bsp; |MAC|  |   (Leaf)   +---+
      = ;            &n= bsp;  |  |VRF|  |  |  /IP |  |  |VRF|&nb= sp; |
      = ;            &n= bsp;  |  |   |  |  |    &= nbsp; |  |  |   |  |     =        +---+
      = ;            &n= bsp;  |  |   |  |  |    &= nbsp; |  |  |   +--+---ES2/AC2--+CE3|<= tt style=3D"color: rgb(0, 0, 0);">
      = ;            &n= bsp;  |  +---+  |  +------+  |&nbs= p; +---+  |   (Root)   +---+<= tt style=3D"color: rgb(0, 0, 0);">
      = ;            &n= bsp;  +---------+       &nb= sp;    +---------+

   Figure 2: Scenario 2b<= /tt>

   This scenario will all= eviate keys drawbacks from Scenario 2a, in particular
   by avoiding duplicatio= n of MAC addresses on Leaf/Root PEs and avoiding the
   operational overhead of managing more than one RT.
   This approach comes at the expense of having routes for unneeded MAC addresse=
s
   on Leaf-only PEs, and is =
hence considered less suitable for deployment contexts
   where the vast majority of PEs would remain Leaf-only.   Unlike Sce=
nario 1 and Scenario 2a, this scenario requires additional procedures
   provided in this document.
(And this last sentence should be added to section 2.3 as well)


For this scenario, if for a given
   EVI, the majority of PEs will eventually have both Leaf and Ro= ot
   sites attached, even though they may start as Root-only or Lea= f-only
   PEs, then it is recommended to use a single RT per EVI and avo= id
   additional configuration and operational overhead.

Why this recommendation ?
Even with a majority of PEs having both Leaves and Roots, there can remain = (up to 49% of) PEs having only Leaves, which will uselessly have all routes= to other Leaves.

So "it is recommended" above, deserves to be explained more, I th= ink.

OK, I changed =93majority=94 to =93vast m= ajority=94 :-)

My point was not to nit pick on "majority", but was= that you should explain why you recommend that.
As the text currently reads, the cost of the recommendation c= an be identified: having useless routes on the fraction of PEs having only Leaves.
But the gain brought by the recommendation is not even mentio= ned, not to say explained.
Hence: why ?
(Why is it a useful tradeoff to have useless routes on some, = even if only one, PE ?)

Changed the last sentence from:
"then it is recommended to use a single R= T per EVI and avoid additional configuration and operational overhead.=94
To
"then it is recommended to use a single R= T per EVI and avoid additional configuration and operational overhead
at the expense of having unwanted MAC addresses on = the Leaf PEs."

Ok. I adapted and incorporated this addition into my proposed text splittin= g 2.2 into a 2.2.1 and a 2.2.2.

Best,

-Thomas



 --_000_D47593851C6F23sajassiciscocom_-- From nobody Wed Dec 14 08:21:12 2016 Return-Path: X-Original-To: bess@ietf.org Delivered-To: bess@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 21312129E96; Wed, 14 Dec 2016 08:21:06 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.39.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148173246612.16876.1023254166262890742.idtracker@ietfa.amsl.com> Date: Wed, 14 Dec 2016 08:21:06 -0800 Archived-At: Cc: bess@ietf.org Subject: [bess] I-D Action: draft-ietf-bess-evpn-bum-procedure-updates-01.txt X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.17 List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Dec 2016 16:21:06 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the BGP Enabled ServiceS of the IETF. Title : Updates on EVPN BUM Procedures Authors : Zhaohui Zhang Wen Lin Jorge Rabadan Keyur Patel Filename : draft-ietf-bess-evpn-bum-procedure-updates-01.txt Pages : 16 Date : 2016-12-14 Abstract: This document specifies procedure updates for broadcast, unknown unicast, and multicast (BUM) traffic in Ethernet VPNs (EVPN), including selective multicast, and provider tunnel segmentation. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-bum-procedure-updates/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-bess-evpn-bum-procedure-updates-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-evpn-bum-procedure-updates-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Dec 15 04:22:02 2016 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9904A129DB6 for ; Thu, 15 Dec 2016 04:22:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.129 X-Spam-Level: X-Spam-Status: No, score=-4.129 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-2.896, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3AEcAYS6lXM4 for ; Thu, 15 Dec 2016 04:21:56 -0800 (PST) Received: from p-mail1.rd.orange.com (p-mail1.rd.orange.com [161.106.1.2]) by ietfa.amsl.com (Postfix) with ESMTP id 9D2DD12A055 for ; Thu, 15 Dec 2016 04:12:34 -0800 (PST) Received: from p-mail1.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id DE49B7CC001; Thu, 15 Dec 2016 13:12:33 +0100 (CET) Received: from FTRDCH01.rd.francetelecom.fr (unknown [10.194.32.11]) by p-mail1.rd.orange.com (Postfix) with ESMTP id C4E00410242; Thu, 15 Dec 2016 13:12:33 +0100 (CET) Received: from [172.31.0.98] (10.193.116.12) by FTRDCH01.rd.francetelecom.fr (10.194.32.11) with Microsoft SMTP Server id 14.3.301.0; Thu, 15 Dec 2016 13:12:31 +0100 To: "Ali Sajassi (sajassi)" , Loa Andersson , "George Swallow -T (swallow - MBO PARTNERS INC at Cisco)" , Eric Rosen , BESS References: <3323ddae-c96f-49a4-2dec-1bfc4ed857dc@orange.com> <6cb41698-b98b-ecbf-9e34-660771bd3fb8@orange.com> <0b846411-4526-c6d3-3ea4-87ebd90de953@orange.com> <62a4bc51-b9de-4a80-a843-bfa356bc23ea@orange.com> From: Thomas Morin Organization: Orange Message-ID: <84953d59-4962-2b5d-1730-7ac1d0d9c982@orange.com> Date: Thu, 15 Dec 2016 13:12:30 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------69F6F479E6D209251AC45756" Archived-At: Cc: Martin Vigoureux Subject: Re: [bess] shepherd review of draft-ietf-bess-evpn-etree X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Dec 2016 12:22:01 -0000 --------------69F6F479E6D209251AC45756 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit Hi Ali, 2016-12-13, Ali Sajassi (sajassi): > > 2016-12-10, Ali Sajassi (sajassi): >> Your suggestion regarding multiple MAC-VRFs per EVI for E-TREE, >> impacts lot more sections than just section 2.2 for which you >> suggested some texts. It drastically impacts section 3.1 (known >> unicast traffic), and it also impacts section 3.2 (BUM traffic) and >> section 5.1. > > Can you detail why ? > The understanding that leads me to this suggestion is that the > 2-RT+split-horizon scenario in 2.1, then applied to Root/Leaf PE in a > 2.2.1 would not require new procotol procedures nor changes in the > text that as I understand provides procedures for 2.2(.2) and 2.3. > 2nd try. As my 1st response got truncated for some reason. > > The reason that impacts more sections than just sec. 2, is that the > proposed 2.2.1 would be an alternative option for section 3.1. In > section 3.1, the root/leaf indication for MAC addresses are done via > flag-bit defined in section 5.1 and it only uses a single MAC-VRF > (single bridge table per VLAN) per RFC 7432. If we go with two > MAC-VRFs (e.g., two bridge tables) per VLAN, then that is an > alternative way of doing the same thing described in section 3.1. This > alternative way has big ramifications on the platform as it requires > duplicating MACs and managing multiple bridge tables per VLAN. Since 2.1 and the proposed 2.2.1 do not require new protocol procedures (they only require split-horizon locally in Leaf MAC-VRFs), if you state clearly that the procedures in the document are here to address 2.2.2 and 2.3, then you don't need to modify the content of the document after section 2 (more exactly, you will need minor update like changing the current "This scheme applies to all scenarios described in section 2." in section 3 into "This scheme applies to scenarios described in 2.2.2 and 2.3". The "big ramifications" above are then not about section 3, but just the (platform specific-drawbacks) of 2.2.2 that we have already discussed and that can be covered in 2.2.2. > Maybe what you really want is to allow for scenario 2.2 to operate > with two RTs which has the benefits of both 2.2.1 and 2.2.2 and non of > the drawbacks. So, maybe we can clarify the current text to make sure > that this comes out clearly – ie, a PE can have single MAC–VRF can > have multiple RTs. You could mention that, but for me the key things is: - documenting the motivation for the new procedures - not arbitrarily /restrict/ 2.2.2 to one RT (but why not document identified drawbacks) > >> Furthermore, it creates a new paradigm for EVPN that was never >> intended for because of creating two MAC-VRFs (and two bridge tables) >> for the same VLAN. > > The " created a new paradigm that was never > intended for" is a not generally valid, or sufficiently detailed, > argument: if it was, then you might go as far as challenging the whole > E-Tree spec on the same kind grounds (and many other new things). > > So here is where it seems we have a gap to bridge: I still don't > understand what in RFC7432 describes an intention of "not supporting > two MAC-VRFs for the same VLAN". > > I tried to explain the relationship between EVI, MAC-VRF, bridge > table, and VLAN in my previous email per RFC 7432. However, lets park > this discussion for time being as I think it is secondary. Ok, feel free to revisit if you think that RFC7432 would preclude procedures that end up being described in this draft > I think you agree that if we have a single solution that has all the > benefits of your proposed 2.2.1 and 2.2.2 and none of the drawbacks, > it is much more preferable with having two solutions each with its own > advantages and draw backs, right? If so, then existing text in 2.2 was > intended to convey that. However, we can clarify it further – e.g, > make it clear that for PE with root & leaf in the same EVI, we can use > a single MAC-VRF with two RTs (one for leaf and another for root). As said above my key concern is having the document clearly spell out the motivation for new specs. If this implies documenting the fact that already existing procedure can be used, but have drawbacks, then so be it ; there would be no point in hiding that, right ? > >> The WG LC was completed on 3/29/16 and I am sure it is not your >> intention to have major changes to the doc at this stage where >> multiple vendors have already implemented the draft. > > As you know, there are different stages at which people do reviews on > a doc after WGLC, an which may lead doc editors to introduce > significant --editorial or technical-- changes in a document. > Sometimes that leads to documents going back to the working group. > > However my root intention as doc shepherd, of course, is not to > propose a major change, but merely to able to answer the standard > question of the shepherd review -- on the reviews done, on document > readiness, and on the document quality -- in a way as positive and > sincere as possible. In particular questions (3) (4) and (6). > > So, hopefully the answers to these three questions are now > clear. I believe your main concern is to ensure that we can apply > two-RT approach of sec. 2.1 to sec. 2.2 (and we can still do and > still have a single MAC-VRF) See above. > > >> This draft talks about two kinds of traffic filtering: a) ingress >> filtering for known unicast and b) egress filtering for BUM traffic. >> What you are suggesting is an alternate mechanism for ingress filtering. > > (well I'm not suggesting the mechanism itself --which section 2.1 > already does-- but simply to document that it can still apply without > the constraint of avoiding the presence of a Root MAC-VRF and a Leaf > MAC-VRF on a same PE) > >> Although having multiple VRFs (and forwarding tables) are fine for >> IP-VPNs because the unknown traffic is always dropped, multiple VRFs >> for the same VLAN is not OK for L2 traffic because of flooding of >> unknown traffic. That’s why in section 6 of RFC 7432, for all service >> interface types, the draft talks about a single MAC-VRF per EVI per >> PE and in case of VLAN-aware mode, multiple VLANs per MAC-VRF but >> only a single bridge table per VLAN. In other words, the bottom line >> is that there can only be a single bridge table per VLAN in order to >> avoid unnecessary flooding. > > > >> When you have two MAC-VRFs per VLAN (one for root ACs and another for >> Leaf ACs), then you either need to duplicate lots of MAC addresses >> between these two VRFs, or do lookup on both of these VRFs. Either >> ways this is not a good option relative to keeping a single VRF table >> for both root and leaf sites and just have a single-bit indication on >> whether a MAC is associated with root or leaf (as currently described >> approach in the draft). I > > > In the above, it seems you agree that it can work, and you are able to > offer reasons why it is not the preferred option, then why not just > document that it can work and provides these reasons as the > motivations that lead to proposing a new specs ? > > Sure, I can do that. [...] Ok. I'll be happy to review a new revision and hopefully post the shepherd review. Thanks, -Thomas > > (it seems you have an unfinished last sentence: "I [...]" ) > > >> >>>> >>>> (assuming the previous point is resolved:) >>>> >>>> With this mechanism above, isn't it possible to have on a given PE, >>>> for a single E-TREE EVI, both Leaves and Roots, as long as distinct >>>> MAC-VRFs are used (one for Leaves and one for Roots) ? (it seems >>>> to me that the assymetric import/export RT would do what is needed >>>> to build an E-TREE, we would just have a particular case where a >>>> Leaf MAC-VRF and a Root MAC-VRF for a given E-TREE end up on a >>>> single PE) >>>> >>>> >>>> That’s not possible because per definition of an EVI, there is only >>>> a single MAC-VRF per EVI for a PE. >>> >>> Where can I read such a definition ? (the Terminology section in >>> RFC7432 does not say that, unless I'm missing something). >>> And that seems a completely arbitrary restriction. >>> (just thinking that a given PE device can be split in two logical >>> devices show that it can work) >>> >>> Section 6 of RFC7432 where it gives definitions for different >>> service interface types, it specifies the relationship between >>> MAC-VRF and VLAN (bridge table) and how many MAC-VRF (and bridge >>> tables) can be per EVI. >> >> This section of RFC7434 discusses many different things for the >> different variants. >> Can you provide a specific pointer about "how many MAC-VRFs can be >> per EVI" ? >> >> Ali> Section 6 of RFC7432 spells out the relationship between EVI, >> MAC-VRF, and bridge tables for all service interfaces very clearly. >> In all service interfaces, the RFC says there is one MAC-VRF per EVI >> on a given PE. >> Now, if the service interface is “vlan-aware”, then there are several >> bridge tables for that single MAC-VRF – ie, one bridge table per >> VLAN. In all service interfaces, you can ONLY have one bridge table >> per VLAN. > > This answer is everything but a specific pointer. > If Section 6 of RFC7432 says all this very clearly, I guess it should > be possible to extract quotes about "there is one MAC-VRF per EVI on a > given PE", right ? > > >> >>> In bridging world, there can only be a single bridge table per VLAN >>> in a device. >> >> I still don't find here anything that would preclude having, on a >> given PE, for a given E-TREE EVI, one Leaves MAC-VRF and one Roots >> MAC-VRF: can't these two MAC-VRFs use different internal VLANs (with >> translation if the external VLANs are constrained). >> >> Ali> Lets assume we are using vlan-based service and thus there is >> only a single bridge table per MAC-VRF, then what you are suggesting >> is two use two MAC-VRFs (two bridge tables) for the same EVI (same >> VLAN). This results in some duplications of MAC addresses and would >> only work if flooding is disabled (more on this later). > > "results in some duplications of MAC" is perhaps a drawback, but > nothing like "just does not work" ? > > "would only work if flooding is disabled": why ? (you wrote "(more on > this later)" but I couldn't identify anything recent from you in the > rest of the email below) > > > From an helicopter view, I can't see what fundamentally would become > problematic between "two MAC-VRFs on two distinct PEs" and the same > "two MAC-VRFs on a same PEs", at worse it is as efficient or as > inefficient as having them on separate PEs (think logical router > without anykind of dataplane optimisation), and we can't exclude that > the PE could have local implementation details to do better than that. > > >>> >>>> Besides, I don’t understand what good does it do to have two >>>> MAC-VRFs on the same PE (one for Leafs and another for Roots) >>> >>> Well, the "what is good for" is pretty simple: it means you can >>> have, just by tailoring the import/export policies like in 2.1, >>> something as useful as the scenario in 2.2. >>> >>> There can only be a single bridge table per VLAN. Now even if you >>> add some kind of logic to form two logical PEs in single physical >>> PE, you end up replicating all the MAC addresses associated with the >>> root sites in two bridge tables. >> >> Your point above certainly does not sound to me as "it can't be >> done": some may think that the above is an acceptable cost, some >> others may find ways to make this "replication" with a low overhead, >> on some platforms the cost may be negligible, etc. >> >> >>> >>> >>>> because Leafs and Roots need to talk to each other and thus we want >>>> them to be in the same MAC-VRF. >>> >>> The fact that Leafs and Roots need to talk to each other does not >>> mean that they *have* to be in the same MAC-VRF, you can rely on the >>> local MPLS dataplane inside the PE to carry the traffic between >>> Roots and Leaves can be passed between a Leaf MAC-VRF and a Root >>> MAC-VRF (and you can possibly implement a shortcut not involving >>> MPLS encap/decap). >>> >>> Anything is possible but at what cost. >> >> You know, for cost it is not always obvious to reach conclusions that >> are true for all implementations and all targets. >> >>> The current proposal is very efficient in terms of forwarding path >>> as well as control plane. >> >> Sure, but what I question is not the new solution but the lack of >> discussion on why using the existing specs was not considered good >> enough. >> >> >> I think that my concern of clearly explaining the scenarios and >> motivations for this new spec could be addressed by splitting section >> 2.2 into a 2.2.1 describing the approach from 2.1 and its possible >> drawbacks, and a 2.2.2 having essentially the content of current >> section 2.2. >> >> Here is a proposal: >> >> 2.2 Scenario 2: Leaf of Root site(s) per AC >> >> In these scenarii, a PE receives traffic from either Root OR Leaf >> sites (but not both) on a given Attachment Circuit (AC) of an EVI. In >> other words, an AC (ES or ES/VLAN) is either associated with Root(s) >> or Leaf(s) (but not both). >> >> 2.2.1 Scenario 2a: Leaf OR Root site(s) per AC, separate Leaf/Root >> MAC-VRFs >> >> +---------+ +---------+ >> | PE1 | | PE2 | >> +---+ | +---+ | +------+ | +---+ | +---+ >> |CE1+-----ES1----+--+ | | | | | |MAC+--+---ES2/AC1--+CE2| >> +---+ (Leaf) | |MAC| | | MPLS | | |VRF| | (Leaf) +---+ >> | |VRF| | | /IP | | '---' | >> | | | | | | | .---. | >> | | | | | | | |MAC| | +---+ >> | | | | | | | |VRF+--+---ES2/AC2--+CE3| >> | +---+ | +------+ | +---+ | (Root) +---+ >> +---------+ +---------+ >> >> Figure 2: Scenario 2a >> >> In this scenario, the RT constraint procedures described in >> section 2.1 could >> also be used. The feasibility and efficiency of this approach >> depends on >> platforms specifics. >> >> This approach will lead toduplication of a large proportion of MAC >> addresseson >> PEs having both Leaf and Root sites, and is hence considered less >> suitable for >> deployment contexts where the vast majority of PEs are likely to >> ultimately >> have both Leaf and Root sites attached to them. >> >> 2.2.2 Scenario 2b: Leaf OR Root site(s) per AC, single MAC-VRF >> >> +---------+ +---------+ >> | PE1 | | PE2 | >> +---+ | +---+ | +------+ | +---+ | +---+ >> |CE1+-----ES1----+--+ | | | | | | +--+---ES2/AC1--+CE2| >> +---+ (Leaf) | |MAC| | | MPLS | | |MAC| | (Leaf) +---+ >> | |VRF| | | /IP | | |VRF| | >> | | | | | | | | | | +---+ >> | | | | | | | | +--+---ES2/AC2--+CE3| >> | +---+ | +------+ | +---+ | (Root) +---+ >> +---------+ +---------+ >> >> Figure 2: Scenario 2b >> >> This scenario will alleviate keys drawbacks from Scenario 2a, in >> particular >> by avoiding duplication of MAC addresses on Leaf/Root PEs and >> avoiding the >> operational overhead of managing more than one RT. >> This approach comes at the expense of having routes for unneeded >> MAC addresses on Leaf-only PEs, and is hence considered less suitable >> for deployment contexts where the vast majority of PEs would remain >> Leaf-only. Unlike Scenario 1 and Scenario 2a, this scenario requires additional procedures >> provided in this document. >> >> >> (And this last sentence should be added to section 2.3 as well) >> >>> >>>>> For this scenario, if for a given >>>>> EVI, the majority of PEs will eventually have both Leaf and Root >>>>> sites attached, even though they may start as Root-only or >>>>> Leaf-only >>>>> PEs, then it is recommended to use a single RT per EVI and avoid >>>>> additional configuration and operational overhead. >>>> >>>> Why this recommendation ? >>>> Even with a majority of PEs having both Leaves and Roots, there can >>>> remain (up to 49% of) PEs having only Leaves, which will uselessly >>>> have all routes to other Leaves. >>>> >>>> So "it is recommended" above, deserves to be explained more, I think. >>>> >>>> OK, I changed “majority” to “vast majority” :-) >>> >>> My point was not to nit pick on "majority", but was that you should >>> explain why you recommend that. >>> As the text currently reads, the cost of the recommendation can be >>> identified: having useless routes on the fraction of PEs having only >>> Leaves. >>> But the gain brought by the recommendation is not even mentioned, >>> not to say explained. >>> Hence: why ? >>> (Why is it a useful tradeoff to have useless routes on some, even if >>> only one, PE ?) >>> >>> Changed the last sentence from: >>> "then it is recommended to use a single RT per EVI and avoid >>> additional configuration and operational overhead.” >>> To >>> "then it is recommended to use a single RT per EVI and avoid >>> additional configuration and operational overhead >>> at the expense of having unwanted MAC addresses on the Leaf PEs." >> >> Ok. I adapted and incorporated this addition into my proposed text >> splitting 2.2 into a 2.2.1 and a 2.2.2. >> >> Best, >> >> -Thomas >> >> > --------------69F6F479E6D209251AC45756 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 8bit
Hi Ali,

2016-12-13, Ali Sajassi (sajassi):

2016-12-10, Ali Sajassi (sajassi):
Your suggestion regarding multiple MAC-VRFs per EVI for E-TREE, impacts lot more sections than just section 2.2 for which you suggested some texts. It drastically  impacts section 3.1 (known unicast traffic), and it also impacts section 3.2 (BUM traffic) and section 5.1.

Can you detail why ?
The understanding that leads me to this suggestion is that the 2-RT+split-horizon scenario in 2.1, then applied to Root/Leaf PE in a 2.2.1 would not require new procotol procedures nor changes in the text that as I understand provides procedures for 2.2(.2) and 2.3.
2nd try. As my 1st response got truncated for some reason.

The reason that impacts more sections than just sec. 2, is that the proposed 2.2.1 would be an alternative option for section 3.1. In section 3.1, the root/leaf indication for MAC addresses are done via flag-bit defined in section 5.1 and it only uses a single MAC-VRF (single bridge table per VLAN) per RFC 7432. If we go with two MAC-VRFs (e.g., two bridge tables) per VLAN, then that is an alternative way of doing the same thing described in section 3.1. This alternative way has big ramifications on the platform as it requires duplicating MACs and managing multiple bridge tables per VLAN.

Since 2.1 and the proposed 2.2.1 do not require new protocol procedures (they only require split-horizon locally in Leaf MAC-VRFs), if you state clearly that the procedures in the document are here to address 2.2.2 and 2.3, then you don't need to modify the content of the document after section 2  (more exactly, you will need minor update like changing the current "This scheme applies to all scenarios described in section 2." in section 3 into "This scheme applies to scenarios described in 2.2.2 and 2.3".
 
The "big ramifications" above are then not about section 3, but just the (platform specific-drawbacks) of 2.2.2 that we have already discussed and that can be covered in 2.2.2.

Maybe what you really want is to allow for scenario 2.2 to operate with two RTs which has the benefits of both 2.2.1 and 2.2.2 and non of the drawbacks. So, maybe we can clarify the current text to make sure that this comes out clearly – ie, a PE can have single MAC–VRF can have multiple RTs.

You could mention that, but for me the key things is:
- documenting the motivation for the new procedures
- not arbitrarily /restrict/ 2.2.2 to one RT (but why not document identified drawbacks)


Furthermore, it creates a new paradigm for EVPN that was never intended for because of creating two MAC-VRFs (and two bridge tables) for the same VLAN.

The "<new thing> created a new paradigm that <RFX xyz> was never intended for" is a not generally valid, or sufficiently detailed, argument: if it was, then you might go as far as challenging the whole E-Tree spec on the same kind grounds (and many other new things).

So here is where it seems we have a gap to bridge: I still don't understand what in RFC7432 describes an intention of "not supporting two MAC-VRFs for the same VLAN".

I tried to explain the relationship between EVI, MAC-VRF, bridge table, and VLAN in my previous email per RFC 7432. However, lets park this discussion for time being as I think it is secondary.

Ok, feel free to revisit if you think that RFC7432 would preclude procedures that end up being described in this draft

I think you agree that if we have a single solution that has all the benefits of your proposed 2.2.1 and 2.2.2 and none of the drawbacks, it is much more preferable with having two solutions each with its own advantages and draw backs, right? If so, then existing text in 2.2 was intended to convey that. However, we can clarify it further – e.g, make it clear that for PE with root & leaf in the same EVI, we can use a single MAC-VRF with two RTs (one for leaf and another for root).

As said above my key concern is having the document clearly spell out the motivation for new specs.
If this implies documenting the fact that already existing procedure can be used, but have drawbacks, then so be it ; there would be no point in hiding that, right ?



The WG LC was completed on 3/29/16 and I am sure it is not your intention to have major changes to the doc at this stage where multiple vendors have already implemented the draft.

As you know, there are different stages at which people do reviews on a doc after WGLC, an which may lead doc editors to introduce significant --editorial or technical-- changes in a document. Sometimes that leads to documents going back to the working group.

However my root intention as doc shepherd, of course, is not to propose a major change, but merely to able to answer the standard question of the shepherd review -- on the reviews done, on document readiness, and on the document quality -- in a way as positive and sincere as possible. In particular questions (3) (4) and (6).

So, hopefully the answers to these three questions are now clear. I believe your main concern is to ensure that we can apply two-RT approach of sec. 2.1  to sec. 2.2 (and we can still do and still have a single MAC-VRF)

See above.


This draft talks about two kinds of traffic filtering: a) ingress filtering for known unicast and b) egress filtering for BUM traffic. What you are suggesting is an alternate mechanism for ingress filtering.

(well I'm not suggesting the mechanism itself --which section 2.1 already does-- but simply to document that it can still apply without the constraint of avoiding the presence of a Root MAC-VRF and a Leaf MAC-VRF on a same PE)

Although having multiple VRFs (and forwarding tables) are fine for IP-VPNs because the unknown traffic is always dropped, multiple VRFs for the same VLAN is not OK for L2 traffic because of flooding of unknown traffic. That’s why in section 6 of RFC 7432, for all service interface types, the draft talks about a single MAC-VRF per EVI per PE and in case of VLAN-aware mode,  multiple VLANs per MAC-VRF but only a single bridge table per VLAN. In other words, the bottom line is that there can only be a single bridge table per VLAN in order to avoid unnecessary flooding.



When you have two MAC-VRFs per VLAN (one for root ACs and another for Leaf ACs), then you either need to duplicate lots of MAC addresses between these two VRFs, or do lookup on both of these VRFs. Either ways this is not a good option relative to keeping a single VRF table for both root and leaf sites and just have a single-bit indication on whether a MAC is associated with root or leaf (as currently described approach in the draft).  I


In the above, it seems you agree that it can work, and you are able to offer reasons why it is not the preferred option, then why not just document that it can work and provides these reasons as the motivations that lead to proposing a new specs ?

Sure, I can do that. [...]

Ok.
I'll be happy to review a new revision and hopefully post the shepherd review.

Thanks,

-Thomas



(it seems you have an unfinished last sentence: "I [...]" )


(assuming the previous point is resolved:)

With this mechanism above, isn't it possible to have on a given PE, for a single E-TREE EVI, both Leaves and Roots, as long as distinct MAC-VRFs are used (one for Leaves and one for Roots) ?   (it seems to me that the assymetric import/export RT would do what is needed to build an E-TREE, we would just have a particular case where a Leaf MAC-VRF and a Root MAC-VRF for a given E-TREE end up on a single PE)

That’s not possible because per definition of an EVI, there is only a single MAC-VRF per EVI for a PE.

Where can I read such a definition ? (the Terminology section in RFC7432 does not say that, unless I'm missing something).
And that seems a completely arbitrary restriction.
(just thinking that a given PE device can be split in two logical devices show that it can work)

Section 6 of RFC7432 where it gives definitions for different service interface types, it specifies the relationship between MAC-VRF and VLAN (bridge table) and how many MAC-VRF (and bridge tables) can be per EVI.

This section of RFC7434 discusses many different things for the different variants.
Can you provide a specific pointer about "how many MAC-VRFs can be per EVI" ?

Ali> Section 6 of RFC7432 spells out the relationship between EVI, MAC-VRF, and bridge tables for all service interfaces very clearly.
In all service interfaces, the RFC says there is one MAC-VRF per EVI on a given PE.
Now, if the service interface is “vlan-aware”, then there are several bridge tables for that single MAC-VRF – ie, one bridge table per VLAN. In all service interfaces, you can ONLY have one bridge table per VLAN.

This answer is everything but a specific pointer.
If Section 6 of RFC7432 says all this very clearly, I guess it should be possible to extract quotes about "there is one MAC-VRF per EVI on a given PE", right ?



In bridging world, there can only be a single bridge table per VLAN in a device.

I still don't find here anything that would preclude having, on a given PE, for a given E-TREE EVI, one Leaves MAC-VRF and one Roots MAC-VRF: can't these two MAC-VRFs use different internal VLANs (with translation if the external VLANs are constrained).

Ali>  Lets assume we are using vlan-based service and thus there is only a single bridge table per MAC-VRF, then what you are suggesting is two use two MAC-VRFs (two bridge tables) for the same EVI (same VLAN). This results in some duplications of MAC addresses and would only work if flooding is disabled (more on this later).

"results in some duplications of MAC" is perhaps a drawback, but nothing like "just does not work" ?

"would only work if flooding is disabled": why ?  (you wrote "(more on this later)" but I couldn't identify anything recent from you in the rest of the email below)


From an helicopter view, I can't see what fundamentally would become problematic between "two MAC-VRFs on two distinct PEs" and the same "two MAC-VRFs on a same PEs", at worse it is as efficient or as inefficient as having them on separate PEs (think logical router without anykind of dataplane optimisation), and we can't exclude that the PE could have local implementation details to do better than that.



Besides, I don’t understand what good does it do to have two MAC-VRFs on the same PE (one for Leafs and another for Roots)

Well, the "what is good for" is pretty simple: it means you can have, just by tailoring the import/export policies like in 2.1, something as useful as the scenario in 2.2.

There can only be a single bridge table per VLAN. Now even if you add some kind of logic to form two logical PEs in single physical PE, you end up replicating all the MAC addresses associated with the root sites in two bridge tables.

Your point above certainly does not sound to me as "it can't be done": some may think that the above is an acceptable cost, some others may find ways to make this "replication" with a low overhead, on some platforms the cost may be negligible, etc.




because Leafs and Roots need to talk to each other and thus we want them to be in the same MAC-VRF.

The fact that Leafs and Roots need to talk to each other does not mean that they *have* to be in the same MAC-VRF, you can rely on the local MPLS dataplane inside the PE to carry the traffic between Roots and Leaves can be passed between a Leaf MAC-VRF and a Root MAC-VRF (and you can possibly implement a shortcut not involving MPLS encap/decap).

Anything is possible but at what cost.

You know, for cost it is not always obvious to reach conclusions that are true for all implementations and all targets.

The current proposal is very efficient in terms of forwarding path as well as control plane.

Sure, but what I question is not the new solution but the lack of discussion on why using the existing specs was not considered good enough.


I think that my concern of clearly explaining the scenarios and motivations for this new spec could be addressed by splitting section 2.2 into a 2.2.1 describing the approach from 2.1 and its possible drawbacks, and a 2.2.2 having essentially the content of current section 2.2.

Here is a proposal:

2.2 Scenario 2: Leaf of Root site(s) per AC

   In these scenarii, a PE receives traffic from either Root OR Leaf
   sites (but not both) on a given Attachment Circuit (AC) of an EVI. In
   other words, an AC (ES or ES/VLAN) is either associated with Root(s)
   or Leaf(s) (but not both).

2.2.1 Scenario 2a: Leaf OR Root site(s) per AC, separate Leaf/Root MAC-VRFs

                     +---------+            +---------+
                     |   PE1   |            |   PE2   |
    +---+            |  +---+  |  +------+  |  +---+  |            +---+
    |CE1+-----ES1----+--+   |  |  |      |  |  |MAC+--+---ES2/AC1--+CE2|
    +---+    (Leaf)  |  |MAC|  |  | MPLS |  |  |VRF|  |   (Leaf)   +---+
                     |  |VRF|  |  |  /IP |  |  '---'  |
                     |  |   |  |  |      |  |  .---.  |
                     |  |   |  |  |      |  |  |MAC|  |            +---+
                     |  |   |  |  |      |  |  |VRF+--+---ES2/AC2--+CE3|
                     |  +---+  |  +------+  |  +---+  |   (Root)   +---+
                     +---------+            +---------+

   Figure 2: Scenario 2a

   In this scenario, the RT constraint procedures described in section 2.1 could
   also be used. The feasibility and efficiency of this approach depends on
   platforms specifics.

   This approach will lead toduplication of a large proportion of MAC addresses on
   PEs having both Leaf and Root sites, and is hence considered less suitable for
   deployment contexts where the vast majority of PEs are likely to ultimately
   have both Leaf and Root sites attached to them.

2.2.2 Scenario 2b: Leaf OR Root site(s) per AC, single MAC-VRF

                     +---------+            +---------+
                     |   PE1   |            |   PE2   |
    +---+            |  +---+  |  +------+  |  +---+  |            +---+
    |CE1+-----ES1----+--+   |  |  |      |  |  |   +--+---ES2/AC1--+CE2|
    +---+    (Leaf)  |  |MAC|  |  | MPLS |  |  |MAC|  |   (Leaf)   +---+
                     |  |VRF|  |  |  /IP |  |  |VRF|  |
                     |  |   |  |  |      |  |  |   |  |            +---+
                     |  |   |  |  |      |  |  |   +--+---ES2/AC2--+CE3|
                     |  +---+  |  +------+  |  +---+  |   (Root)   +---+
                     +---------+            +---------+

   Figure 2: Scenario 2b

   This scenario will alleviate keys drawbacks from Scenario 2a, in particular
   by avoiding duplication of MAC addresses on Leaf/Root PEs and avoiding the
   operational overhead of managing more than one RT.
   This approach comes at the expense of having routes for unneeded MAC addresses
   on Leaf-only PEs, and is hence considered less suitable for deployment contexts
   where the vast majority of PEs would remain Leaf-only.   Unlike Scenario 1 and Scenario 2a, this scenario requires additional procedures
   provided in this document.
(And this last sentence should be added to section 2.3 as well)


For this scenario, if for a given
   EVI, the majority of PEs will eventually have both Leaf and Root
   sites attached, even though they may start as Root-only or Leaf-only
   PEs, then it is recommended to use a single RT per EVI and avoid
   additional configuration and operational overhead.

Why this recommendation ?
Even with a majority of PEs having both Leaves and Roots, there can remain (up to 49% of) PEs having only Leaves, which will uselessly have all routes to other Leaves.

So "it is recommended" above, deserves to be explained more, I think.

OK, I changed “majority” to “vast majority” :-)

My point was not to nit pick on "majority", but was that you should explain why you recommend that.
As the text currently reads, the cost of the recommendation can be identified: having useless routes on the fraction of PEs having only Leaves.
But the gain brought by the recommendation is not even mentioned, not to say explained.
Hence: why ?
(Why is it a useful tradeoff to have useless routes on some, even if only one, PE ?)

Changed the last sentence from:
"then it is recommended to use a single RT per EVI and avoid additional configuration and operational overhead.”
To
"then it is recommended to use a single RT per EVI and avoid additional configuration and operational overhead
at the expense of having unwanted MAC addresses on the Leaf PEs."

Ok. I adapted and incorporated this addition into my proposed text splitting 2.2 into a 2.2.1 and a 2.2.2.

Best,

-Thomas


--------------69F6F479E6D209251AC45756-- From nobody Thu Dec 15 14:28:16 2016 Return-Path: X-Original-To: bess@ietf.org Delivered-To: bess@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 904AA12951E; Thu, 15 Dec 2016 14:27:58 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.40.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148184087858.24621.15224091402435799261.idtracker@ietfa.amsl.com> Date: Thu, 15 Dec 2016 14:27:58 -0800 Archived-At: Cc: bess@ietf.org Subject: [bess] I-D Action: draft-ietf-l3vpn-end-system-06.txt X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.17 List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Dec 2016 22:27:58 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the BGP Enabled ServiceS of the IETF. Title : BGP-Signaled End-System IP/VPNs Authors : Stuart Mackie Luyuan Fang Nischal Sheth Maria Napierala Nabil Bitar Filename : draft-ietf-l3vpn-end-system-06.txt Pages : 31 Date : 2016-12-15 Abstract: This document describes a solution in which the control plane protocol specified in BGP/MPLS IP VPNs is used and extended via the XMPP protocol to provide a Virtual Network service to end-systems (hosts). These end-systems may be used to provide network services or may host end-user applications. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-l3vpn-end-system/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-l3vpn-end-system-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-l3vpn-end-system-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Dec 18 19:01:57 2016 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B1C1129471 for ; Sun, 18 Dec 2016 19:01:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.621 X-Spam-Level: X-Spam-Status: No, score=-17.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3faiViueUr4S for ; Sun, 18 Dec 2016 19:01:51 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87B01129466 for ; Sun, 18 Dec 2016 19:01:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=70877; q=dns/txt; s=iport; t=1482116511; x=1483326111; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=SIGUMT6W+7kAeVq6QUrTgm9ovdkJox1ZPUXqkTePHpM=; b=dkTTrgiG5roqUKIiWk2MEXYKkzel235R61pG6Pt5lISsTdLAbKWM2wFQ qZadZQT+IMQ/2GGrK1nFe2LJ+3oaE2t58WfZ6Hui74OBXYOZh2F+5+vFF Km/WBtu0aBn3O4+W/Pj5QPfd7m7UmxXC8dyeuxDj9dc/gyMluIbJvPu9Y o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AVAQBPTFdY/40NJK1TChkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJzOQsBAQEBAR+BYAeNSJZXlQ6CCoJHAYNaAoIYPxQBAgEBAQE?= =?us-ascii?q?BAQFiKIRoAQEBBBIIAVEFAQEBAgMQAgEIEQMBAiEBBgcyFAkIAgQBDQUbB4hJn?= =?us-ascii?q?gMBkB4vilwBAQEBAQEBAQEBAQEBAQEBAQEBAQEdigeBCIQRAQYLATyFQQWVA4V?= =?us-ascii?q?tAYljh1CBdIUDg0qEXIEwh3CGKYQOAR83Y0KECByBXXKGLoEhgQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.33,372,1477958400"; d="scan'208,217";a="174487018" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 19 Dec 2016 03:01:49 +0000 Received: from XCH-RTP-017.cisco.com (xch-rtp-017.cisco.com [64.101.220.157]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id uBJ31nf7019855 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 19 Dec 2016 03:01:49 GMT Received: from xch-rtp-005.cisco.com (64.101.220.145) by XCH-RTP-017.cisco.com (64.101.220.157) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Sun, 18 Dec 2016 22:01:48 -0500 Received: from xch-rtp-005.cisco.com ([64.101.220.145]) by XCH-RTP-005.cisco.com ([64.101.220.145]) with mapi id 15.00.1210.000; Sun, 18 Dec 2016 22:01:48 -0500 From: "Ali Sajassi (sajassi)" To: Thomas Morin , Loa Andersson , "George Swallow -T (swallow - MBO PARTNERS INC at Cisco)" , "Eric Rosen" , BESS Thread-Topic: shepherd review of draft-ietf-bess-evpn-etree Thread-Index: AQHSAgSQiVios9dTSUOmTfNWP8T6rqBlA4UAgAGT+oCASmTegIBKoSmAgAU1ewCABIpWAIABYlAAgAABy4CAAydaAIAFHy2A Date: Mon, 19 Dec 2016 03:01:48 +0000 Message-ID: References: <3323ddae-c96f-49a4-2dec-1bfc4ed857dc@orange.com> <6cb41698-b98b-ecbf-9e34-660771bd3fb8@orange.com> <0b846411-4526-c6d3-3ea4-87ebd90de953@orange.com> <62a4bc51-b9de-4a80-a843-bfa356bc23ea@orange.com> <84953d59-4962-2b5d-1730-7ac1d0d9c982@orange.com> In-Reply-To: <84953d59-4962-2b5d-1730-7ac1d0d9c982@orange.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.0.161029 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.11.84] Content-Type: multipart/alternative; boundary="_000_D47964F61C70D0sajassiciscocom_" MIME-Version: 1.0 Archived-At: Cc: Martin Vigoureux Subject: Re: [bess] shepherd review of draft-ietf-bess-evpn-etree X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2016 03:01:56 -0000 --_000_D47964F61C70D0sajassiciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Thomas, I have modified section 2.2 (copied below) to elaborate why coloring approa= ch for Leaf/Root MAC addresses is used in this draft. Also, the use of sing= le RT for this scenario is mentioned just as =93MAY=94. Please review the t= ext below and let me know if you still have questions/comments: 2.2 Scenario 2: Leaf OR Root site(s) per AC In this scenario, a PE receives traffic from either Root OR Leaf sites (but not both) on a given Attachment Circuit (AC) of an EVI. In other words, an AC (ES or ES/VLAN) is either a Root AC or a Leaf AC (but not both). +---------+ +---------+ | PE1 | | PE2 | +---+ | +---+ | +------+ | +---+ | +---+ |CE1+-----ES1----+--+ | | | | | | +--+---ES2/AC1--+CE2| +---+ (Leaf) | |MAC| | | MPLS | | |MAC| | (Leaf) +---+ | |VRF| | | /IP | | |VRF| | | | | | | | | | | | +---+ | | | | | | | | +--+---ES2/AC2--+CE3| | +---+ | +------+ | +---+ | (Root) +---+ +---------+ +---------+ Figure 2: Scenario 2 In this scenario, just like the previous scenario (in section 2.1), two Route Targets (one for Root and another for Leaf) can be used. However, the difference is that on a PE with both Root and Leaf ACs, all remote MAC routes are imported and thus there needs to be a way to differentiate remote MAC routes associated with Leaf ACs versus the ones associated with Root ACs in order to apply the proper ingress filtering. In order to support such ingress filtering on the ingress PE with both Leaf and Root ACs, one the following two approaches can be used: A) Color MAC addresses with Leaf (or Root) color before distributing them in BGP to other PEs depending on whether it is learned on a Leaf AC (or a Root AC) B) Use two MAC-VRFs (two bridge tables per VLANs) - one for Root ACs and another for Leaf ACs. Maintaining two bridge tables per VLAN requires either two lookups be performed per MAC address in either direction in case of a miss, or duplicating many MAC addresses between the two bridge tables belonging to the same VLAN (same E-TREE instance). The duplication of MAC addresses are need for both locally learned and remotely learned MAC addresses. Locally learned MAC addresses from Leaf ACs need to be duplicated onto Root bridge table and locally learned MAC addresses from Root ACs need to be duplicated onto Leaf bridge table. Remotely learned MAC addresses from Root ACs need to be copied onto both Root and Leaf bridge tables. Neither double lookups nor MAC duplications are considered viable options; therefore, this draft recommends the use of MAC address coloring for this scenario as detailed in section 3.1. For this scenario, if for a given EVI, the vast majority of PEs will have both Leaf and Root sites attached, even though they may start as Root-only or Leaf-only PEs, then a single RT per EVI MAY be used in order to alleviate additional configuration overhead associated with using two RTs per EVI at the expense of having unwanted MAC addresses on the Leaf-only PEs. Regards, Ali From: Thomas Morin = > Organization: Orange Date: Thursday, December 15, 2016 at 4:12 AM To: Cisco Employee >, Loa Ander= sson >, "George Swallow -T (swallow - MBO PARTN= ERS INC at Cisco)" >, Eric Rose= n >, BESS > Cc: Martin Vigoureux > Subject: Re: shepherd review of draft-ietf-bess-evpn-etree Hi Ali, 2016-12-13, Ali Sajassi (sajassi): 2016-12-10, Ali Sajassi (sajassi): Your suggestion regarding multiple MAC-VRFs per EVI for E-TREE, impacts lot= more sections than just section 2.2 for which you suggested some texts. It= drastically impacts section 3.1 (known unicast traffic), and it also impa= cts section 3.2 (BUM traffic) and section 5.1. Can you detail why ? The understanding that leads me to this suggestion is that the 2-RT+split-h= orizon scenario in 2.1, then applied to Root/Leaf PE in a 2.2.1 would not r= equire new procotol procedures nor changes in the text that as I understand= provides procedures for 2.2(.2) and 2.3. 2nd try. As my 1st response got truncated for some reason. The reason that impacts more sections than just sec. 2, is that the propose= d 2.2.1 would be an alternative option for section 3.1. In section 3.1, the= root/leaf indication for MAC addresses are done via flag-bit defined in se= ction 5.1 and it only uses a single MAC-VRF (single bridge table per VLAN) = per RFC 7432. If we go with two MAC-VRFs (e.g., two bridge tables) per VLAN= , then that is an alternative way of doing the same thing described in sect= ion 3.1. This alternative way has big ramifications on the platform as it r= equires duplicating MACs and managing multiple bridge tables per VLAN. Since 2.1 and the proposed 2.2.1 do not require new protocol procedures (th= ey only require split-horizon locally in Leaf MAC-VRFs), if you state clear= ly that the procedures in the document are here to address 2.2.2 and 2.3, t= hen you don't need to modify the content of the document after section 2 (= more exactly, you will need minor update like changing the current "This sc= heme applies to all scenarios described in section 2." in section 3 into "T= his scheme applies to scenarios described in 2.2.2 and 2.3". The "big ramifications" above are then not about section 3, but just the (p= latform specific-drawbacks) of 2.2.2 that we have already discussed and tha= t can be covered in 2.2.2. Maybe what you really want is to allow for scenario 2.2 to operate with two= RTs which has the benefits of both 2.2.1 and 2.2.2 and non of the drawback= s. So, maybe we can clarify the current text to make sure that this comes o= ut clearly =96 ie, a PE can have single MAC=96VRF can have multiple RTs. You could mention that, but for me the key things is: - documenting the motivation for the new procedures - not arbitrarily /restrict/ 2.2.2 to one RT (but why not document identifi= ed drawbacks) Furthermore, it creates a new paradigm for EVPN that was never intended for= because of creating two MAC-VRFs (and two bridge tables) for the same VLAN= . The " created a new paradigm that was never intended f= or" is a not generally valid, or sufficiently detailed, argument: if it was= , then you might go as far as challenging the whole E-Tree spec on the same= kind grounds (and many other new things). So here is where it seems we have a gap to bridge: I still don't understand= what in RFC7432 describes an intention of "not supporting two MAC-VRFs for= the same VLAN". I tried to explain the relationship between EVI, MAC-VRF, bridge table, and= VLAN in my previous email per RFC 7432. However, lets park this discussion= for time being as I think it is secondary. Ok, feel free to revisit if you think that RFC7432 would preclude procedure= s that end up being described in this draft I think you agree that if we have a single solution that has all the benefi= ts of your proposed 2.2.1 and 2.2.2 and none of the drawbacks, it is much m= ore preferable with having two solutions each with its own advantages and d= raw backs, right? If so, then existing text in 2.2 was intended to convey t= hat. However, we can clarify it further =96 e.g, make it clear that for PE = with root & leaf in the same EVI, we can use a single MAC-VRF with two RTs = (one for leaf and another for root). As said above my key concern is having the document clearly spell out the m= otivation for new specs. If this implies documenting the fact that already existing procedure can be= used, but have drawbacks, then so be it ; there would be no point in hidin= g that, right ? The WG LC was completed on 3/29/16 and I am sure it is not your intention t= o have major changes to the doc at this stage where multiple vendors have a= lready implemented the draft. As you know, there are different stages at which people do reviews on a doc= after WGLC, an which may lead doc editors to introduce significant --edito= rial or technical-- changes in a document. Sometimes that leads to document= s going back to the working group. However my root intention as doc shepherd, of course, is not to propose a m= ajor change, but merely to able to answer the standard question of the shep= herd review -- on the reviews done, on document readiness, and on the docum= ent quality -- in a way as positive and sincere as possible. In particular = questions (3) (4) and (6). So, hopefully the answers to these three questions are now clear. I believe= your main concern is to ensure that we can apply two-RT approach of sec. 2= .1 to sec. 2.2 (and we can still do and still have a single MAC-VRF) See above. This draft talks about two kinds of traffic filtering: a) ingress filtering= for known unicast and b) egress filtering for BUM traffic. What you are su= ggesting is an alternate mechanism for ingress filtering. (well I'm not suggesting the mechanism itself --which section 2.1 already d= oes-- but simply to document that it can still apply without the constraint= of avoiding the presence of a Root MAC-VRF and a Leaf MAC-VRF on a same PE= ) Although having multiple VRFs (and forwarding tables) are fine for IP-VPNs = because the unknown traffic is always dropped, multiple VRFs for the same V= LAN is not OK for L2 traffic because of flooding of unknown traffic. That= =92s why in section 6 of RFC 7432, for all service interface types, the dra= ft talks about a single MAC-VRF per EVI per PE and in case of VLAN-aware mo= de, multiple VLANs per MAC-VRF but only a single bridge table per VLAN. In= other words, the bottom line is that there can only be a single bridge tab= le per VLAN in order to avoid unnecessary flooding. When you have two MAC-VRFs per VLAN (one for root ACs and another for Leaf = ACs), then you either need to duplicate lots of MAC addresses between these= two VRFs, or do lookup on both of these VRFs. Either ways this is not a go= od option relative to keeping a single VRF table for both root and leaf sit= es and just have a single-bit indication on whether a MAC is associated wit= h root or leaf (as currently described approach in the draft). I In the above, it seems you agree that it can work, and you are able to offe= r reasons why it is not the preferred option, then why not just document th= at it can work and provides these reasons as the motivations that lead to p= roposing a new specs ? Sure, I can do that. [...] Ok. I'll be happy to review a new revision and hopefully post the shepherd revi= ew. Thanks, -Thomas (it seems you have an unfinished last sentence: "I [...]" ) (assuming the previous point is resolved:) With this mechanism above, isn't it possible to have on a given PE, for a s= ingle E-TREE EVI, both Leaves and Roots, as long as distinct MAC-VRFs are u= sed (one for Leaves and one for Roots) ? (it seems to me that the assymet= ric import/export RT would do what is needed to build an E-TREE, we would j= ust have a particular case where a Leaf MAC-VRF and a Root MAC-VRF for a gi= ven E-TREE end up on a single PE) That=92s not possible because per definition of an EVI, there is only a sin= gle MAC-VRF per EVI for a PE. Where can I read such a definition ? (the Terminology section in RFC7432 do= es not say that, unless I'm missing something). And that seems a completely arbitrary restriction. (just thinking that a given PE device can be split in two logical devices s= how that it can work) Section 6 of RFC7432 where it gives definitions for different service inter= face types, it specifies the relationship between MAC-VRF and VLAN (bridge = table) and how many MAC-VRF (and bridge tables) can be per EVI. This section of RFC7434 discusses many different things for the different v= ariants. Can you provide a specific pointer about "how many MAC-VRFs can be per EVI"= ? Ali> Section 6 of RFC7432 spells out the relationship between EVI, MAC-VRF,= and bridge tables for all service interfaces very clearly. In all service interfaces, the RFC says there is one MAC-VRF per EVI on a g= iven PE. Now, if the service interface is =93vlan-aware=94, then there are several b= ridge tables for that single MAC-VRF =96 ie, one bridge table per VLAN. In = all service interfaces, you can ONLY have one bridge table per VLAN. This answer is everything but a specific pointer. If Section 6 of RFC7432 says all this very clearly, I guess it should be po= ssible to extract quotes about "there is one MAC-VRF per EVI on a given PE"= , right ? In bridging world, there can only be a single bridge table per VLAN in a de= vice. I still don't find here anything that would preclude having, on a given PE,= for a given E-TREE EVI, one Leaves MAC-VRF and one Roots MAC-VRF: can't th= ese two MAC-VRFs use different internal VLANs (with translation if the exte= rnal VLANs are constrained). Ali> Lets assume we are using vlan-based service and thus there is only a = single bridge table per MAC-VRF, then what you are suggesting is two use tw= o MAC-VRFs (two bridge tables) for the same EVI (same VLAN). This results i= n some duplications of MAC addresses and would only work if flooding is dis= abled (more on this later). "results in some duplications of MAC" is perhaps a drawback, but nothing li= ke "just does not work" ? "would only work if flooding is disabled": why ? (you wrote "(more on this= later)" but I couldn't identify anything recent from you in the rest of th= e email below) >From an helicopter view, I can't see what fundamentally would become proble= matic between "two MAC-VRFs on two distinct PEs" and the same "two MAC-VRFs= on a same PEs", at worse it is as efficient or as inefficient as having th= em on separate PEs (think logical router without anykind of dataplane optim= isation), and we can't exclude that the PE could have local implementation = details to do better than that. Besides, I don=92t understand what good does it do to have two MAC-VRFs on = the same PE (one for Leafs and another for Roots) Well, the "what is good for" is pretty simple: it means you can have, just = by tailoring the import/export policies like in 2.1, something as useful as= the scenario in 2.2. There can only be a single bridge table per VLAN. Now even if you add some = kind of logic to form two logical PEs in single physical PE, you end up rep= licating all the MAC addresses associated with the root sites in two bridge= tables. Your point above certainly does not sound to me as "it can't be done": some= may think that the above is an acceptable cost, some others may find ways = to make this "replication" with a low overhead, on some platforms the cost = may be negligible, etc. because Leafs and Roots need to talk to each other and thus we want them to= be in the same MAC-VRF. The fact that Leafs and Roots need to talk to each other does not mean that= they *have* to be in the same MAC-VRF, you can rely on the local MPLS data= plane inside the PE to carry the traffic between Roots and Leaves can be pa= ssed between a Leaf MAC-VRF and a Root MAC-VRF (and you can possibly implem= ent a shortcut not involving MPLS encap/decap). Anything is possible but at what cost. You know, for cost it is not always obvious to reach conclusions that are t= rue for all implementations and all targets. The current proposal is very efficient in terms of forwarding path as well = as control plane. Sure, but what I question is not the new solution but the lack of discussio= n on why using the existing specs was not considered good enough. I think that my concern of clearly explaining the scenarios and motivations= for this new spec could be addressed by splitting section 2.2 into a 2.2.1= describing the approach from 2.1 and its possible drawbacks, and a 2.2.2 h= aving essentially the content of current section 2.2. Here is a proposal: 2.2 Scenario 2: Leaf of Root site(s) per AC In these scenarii, a PE receives traffic from either Root OR Leaf sites (but not both) on a given Attachment Circuit (AC) of an EVI. In other words, an AC (ES or ES/VLAN) is either associated with Root(s) or Leaf(s) (but not both). 2.2.1 Scenario 2a: Leaf OR Root site(s) per AC, separate Leaf/Root MAC-VRFs +---------+ +---------+ | PE1 | | PE2 | +---+ | +---+ | +------+ | +---+ | +---+ |CE1+-----ES1----+--+ | | | | | |MAC+--+---ES2/AC1--+CE2| +---+ (Leaf) | |MAC| | | MPLS | | |VRF| | (Leaf) +---+ | |VRF| | | /IP | | '---' | | | | | | | | .---. | | | | | | | | |MAC| | +---+ | | | | | | | |VRF+--+---ES2/AC2--+CE3| | +---+ | +------+ | +---+ | (Root) +---+ +---------+ +---------+ Figure 2: Scenario 2a In this scenario, the RT constraint procedures described in section 2.1 = could also be used. The feasibility and efficiency of this approach depends on platforms specifics. This approach will lead toduplication of a large proportion of MAC addre= sses on PEs having both Leaf and Root sites, and is hence considered less suitab= le for deployment contexts where the vast majority of PEs are likely to ultimat= ely have both Leaf and Root sites attached to them. 2.2.2 Scenario 2b: Leaf OR Root site(s) per AC, single MAC-VRF +---------+ +---------+ | PE1 | | PE2 | +---+ | +---+ | +------+ | +---+ | +---+ |CE1+-----ES1----+--+ | | | | | | +--+---ES2/AC1--+CE2| +---+ (Leaf) | |MAC| | | MPLS | | |MAC| | (Leaf) +---+ | |VRF| | | /IP | | |VRF| | | | | | | | | | | | +---+ | | | | | | | | +--+---ES2/AC2--+CE3| | +---+ | +------+ | +---+ | (Root) +---+ +---------+ +---------+ Figure 2: Scenario 2b This scenario will alleviate keys drawbacks from Scenario 2a, in particu= lar by avoiding duplication of MAC addresses on Leaf/Root PEs and avoiding t= he operational overhead of managing more than one RT. This approach comes at the expense of having routes for unneeded MAC add= resses on Leaf-only PEs, and is hence considered less suitable for deployment c= ontexts where the vast majority of PEs would remain Leaf-only. Unlike Scenario= 1 and Scenario 2a, this scenario requires additional procedures provided in this document. (And this last sentence should be added to section 2.3 as well) For this scenario, if for a given EVI, the majority of PEs will eventually have both Leaf and Root sites attached, even though they may start as Root-only or Leaf-only PEs, then it is recommended to use a single RT per EVI and avoid additional configuration and operational overhead. Why this recommendation ? Even with a majority of PEs having both Leaves and Roots, there can remain = (up to 49% of) PEs having only Leaves, which will uselessly have all routes= to other Leaves. So "it is recommended" above, deserves to be explained more, I think. OK, I changed =93majority=94 to =93vast majority=94 :-) My point was not to nit pick on "majority", but was that you should explain= why you recommend that. As the text currently reads, the cost of the recommendation can be identifi= ed: having useless routes on the fraction of PEs having only Leaves. But the gain brought by the recommendation is not even mentioned, not to sa= y explained. Hence: why ? (Why is it a useful tradeoff to have useless routes on some, even if only o= ne, PE ?) Changed the last sentence from: "then it is recommended to use a single RT per EVI and avoid additional con= figuration and operational overhead.=94 To "then it is recommended to use a single RT per EVI and avoid additional con= figuration and operational overhead at the expense of having unwanted MAC addresses on the Leaf PEs." Ok. I adapted and incorporated this addition into my proposed text splittin= g 2.2 into a 2.2.1 and a 2.2.2. Best, -Thomas --_000_D47964F61C70D0sajassiciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <2A93DA49305D6349874162C8E255E825@emea.cisco.com> Content-Transfer-Encoding: quoted-printable

Hi Thomas,

I have modified section 2.2 (copied below) to elaborate why coloring a= pproach for Leaf/Root MAC addresses is used in this draft. Also, the use of= single RT for this scenario is mentioned just as =93MAY=94. Please review = the text below and let me know if you still have questions/comments:

2.2 Scenario 2: Leaf OR Root site(s) per AC

   In this scenario, a PE receives traffic from either Root = OR Leaf
   sites (but not both) on a given Attachment Circuit (AC) o= f an EVI. In
   other words, an AC (ES or ES/VLAN) is either a Root AC or= a Leaf AC
   (but not both). 


                    =  +---------+            +---= ------+
                    =  |   PE1   |            | &nbs= p; PE2   |
    +---+            |=  +---+  |  +------+  |  +---&= #43;  |            +---+
    |CE1+-----ES1----+--+   |  |  = ;|      |  |  |   +--+---ES2/AC1--= 3;CE2|
    +---+    (Leaf)  |  |MAC| &n= bsp;|  | MPLS |  |  |MAC|  |   (Leaf)   += ---+
                    =  |  |VRF|  |  |  /IP |  |  |VRF|  |=
                    =  |  |   |  |  |      |  | &nbs= p;|   |  |            +---+=
                    =  |  |   |  |  |      |  | &nbs= p;|   +--+---ES2/AC2--+CE3|
                    =  |  +---+  |  +------+  |  &#= 43;---+  |   (Root)   +---+
                    =  +---------+            +---= ------+

   Figure 2: Scenario 2

   In this scenario, just like the previous scenario (in sec= tion 2.1),
   two Route Targets (one for Root and another for Leaf) can= be used.
   However, the difference is that on a PE with both Root an= d Leaf ACs,
   all remote MAC routes are imported and thus there needs t= o be a way
   to differentiate remote MAC routes associated with Leaf A= Cs versus
   the ones associated with Root ACs in order to apply the p= roper
   ingress filtering. 

   In order to support such ingress filtering on the ingress= PE with
   both Leaf and Root ACs, one the following two approaches = can be used:

   A) Color MAC addresses with Leaf (or Root) color before d= istributing
   them in BGP to other PEs depending on whether it is learn= ed on a Leaf
   AC (or a Root AC)

   B) Use two MAC-VRFs (two bridge tables per VLANs) - one f= or Root ACs
   and another for Leaf ACs. 

   Maintaining two bridge tables per VLAN requires either tw= o lookups be
   performed per MAC address in either direction in case of = a miss, or
   duplicating many MAC addresses between the two bridge tab= les
   belonging to the same VLAN (same E-TREE instance). The du= plication of
   MAC addresses are need for both locally learned and remot= ely learned
   MAC addresses. Locally learned MAC addresses from Leaf AC= s need to be
   duplicated onto Root bridge table and locally learned MAC= addresses
   from Root ACs need to be duplicated onto Leaf bridge tabl= e. Remotely
   learned MAC addresses from Root ACs need to be copied ont= o both Root
   and Leaf bridge tables. Neither double lookups nor MAC du= plications
   are considered viable options; therefore, this draft reco= mmends the
   use of MAC address coloring for this scenario as detailed= in section
   3.1.    

   For this scenario, if for a given EVI, the vast majority = of PEs will
   have both Leaf and Root sites attached, even though they = may start as
   Root-only or Leaf-only PEs, then a single RT per EVI MAY = be used in
   order to alleviate  additional configuration overhea= d associated with
   using two RTs per EVI at the expense of having unwanted M= AC addresses
   on the Leaf-only PEs. 


Regards,
Ali


From: Thomas Morin <thomas.morin@orange.com>
Organization: Orange
Date: Thursday, December 15, 2016 a= t 4:12 AM
To: Cisco Employee <sajassi@cisco.com>, Loa Andersson <loa@pi.nu>, "George Swallow -T (swallow= - MBO PARTNERS INC at Cisco)" <swallow@cisco.com>, Eric Rosen <erosen@juniper.net>, BESS <bess@ietf.org>
Cc: Martin Vigoureux <martin.vigoureux@nokia.com>
Subject: Re: shepherd review of dra= ft-ietf-bess-evpn-etree

Hi Ali,

2016-12-13, Ali Sajassi (sajassi):

2016-12-10, Ali Sajassi (sajassi):
Your suggestion regarding multiple MAC-VRFs per EVI for E-TREE, impact= s lot more sections than just section 2.2 for which you suggested some text= s. It drastically  impacts section 3.1 (known unicast traffic), and it= also impacts section 3.2 (BUM traffic) and section 5.1.

Can you detail why ?
The understanding that leads me to this suggestion is that the 2-RT+spl= it-horizon scenario in 2.1, then applied to Root/Leaf PE in a 2.2.1 would n= ot require new procotol procedures nor changes in the text that as I unders= tand provides procedures for 2.2(.2) and 2.3.
2nd try. As my 1st response got truncated for some reason.

The reason t= hat impacts more sections than just sec. 2, is that the proposed 2.2.1 woul= d be an alternative option for section 3.1. In section 3.1, the root/leaf i= ndication for MAC addresses are done via flag-bit defined in section 5.1 and it only uses a single MAC-VRF (sin= gle bridge table per VLAN) per RFC 7432. If we go with two MAC-VRFs (e.g., = two bridge tables) per VLAN, then that is an alternative way of doing = the same thing described in section 3.1. This alternative way has big ramifications on the platform as it requires = duplicating MACs and managing multiple bridge tables per VLAN.

Since 2.1 and the proposed 2.2.1 do not require new protocol procedures (th= ey only require split-horizon locally in Leaf MAC-VRFs), if you state clear= ly that the procedures in the document are here to address 2.2.2 and 2.3, t= hen you don't need to modify the content of the document after section 2  (more exactly, you will need= minor update like changing the current "This scheme applies to all sc= enarios described in section 2." in section 3 into "This scheme a= pplies to scenarios described in 2.2.2 and 2.3".
 
The "big ramifications" above are then not about section 3, but j= ust the (platform specific-drawbacks) of 2.2.2 that we have already discuss= ed and that can be covered in 2.2.2.

=
Maybe what you really want is to allow for sce= nario 2.2 to operate with two RTs which has the benefits of both 2.2.1 and = 2.2.2 and non of the drawbacks. So, maybe we can clarify the current text t= o make sure that this comes out clearly =96 ie, a PE can have single MAC=96VRF can have multiple RTs.

You could mention that, but for me the key things is:
- documenting the motivation for the new procedures
- not arbitrarily /restrict/ 2.2.2 to one RT (but why not document identifi= ed drawbacks)

=

Furthermore, it creates a new paradigm for EVPN that was never intende= d for because of creating two MAC-VRFs (and two bridge tables) for the same= VLAN.

The "<new thing> created a new paradigm that <RFX xyz> was= never intended for" is a not generally valid, or sufficiently detaile= d, argument: if it was, then you might go as far as challenging the whole E= -Tree spec on the same kind grounds (and many other new things).

So here is where it seems we have a gap to bridge: I still don't understand= what in RFC7432 describes an intention of "not supporting two MAC-VRF= s for the same VLAN".

I tried to explain the relationship between EV= I, MAC-VRF, bridge table, and VLAN in my previous email per RFC 7432. = However, lets park this discussion for time being as I think it is sec= ondary.

Ok, feel free to revisit if you think that RFC7432 would preclude procedure= s that end up being described in this draft

=
I think you agree that if we have a single sol= ution that has all the benefits of your proposed 2.2.1 and 2.2.2 and none o= f the drawbacks, it is much more preferable with having two solutions each = with its own advantages and draw backs, right? If so, then existing text in 2.2 was intended to convey that. Howev= er, we can clarify it further =96 e.g, make it clear that for PE = with root & leaf in the same EVI, we can use a single MAC-VRF with= two RTs (one for leaf and another for root).

As said above my key concern is having the document clearly spell out the m= otivation for new specs.
If this implies documenting the fact that already existing procedure can be= used, but have drawbacks, then so be it ; there would be no point in hidin= g that, right ?


=

The WG LC was completed on 3/29/16 and I am sure it is not your intent= ion to have major changes to the doc at this stage where multiple vendors h= ave already implemented the draft.

As you know, there are different stages at which people do reviews on a doc= after WGLC, an which may lead doc editors to introduce significant --edito= rial or technical-- changes in a document. Sometimes that leads to document= s going back to the working group.

However my root intention as doc shepherd, of course, is not to propose a m= ajor change, but merely to able to answer the standard question of the shep= herd review -- on the reviews done, on document readiness, and on the docum= ent quality -- in a way as positive and sincere as possible. In particular questions (3) (4) and (6).

So, hopefully the answers to these three quest= ions are now clear. I believe your main concern is to ensure that= we can apply two-RT approach of sec. 2.1  to sec. 2.2 (and we can sti= ll do and still have a single MAC-VRF)

See above.
=


This draft talks about two kinds of traffic filtering: a) ingress filt= ering for known unicast and b) egress filtering for BUM traffic. What you a= re suggesting is an alternate mechanism for ingress filtering.

(well I'm not suggesting the mechanism itself --which section 2.1 already d= oes-- but simply to document that it can still apply without the constraint= of avoiding the presence of a Root MAC-VRF and a Leaf MAC-VRF on a same PE= )

Although having multiple VRFs (and forwarding tables) are fine for IP-= VPNs because the unknown traffic is always dropped, multiple VRFs for the s= ame VLAN is not OK for L2 traffic because of flooding of unknown traffic. T= hat=92s why in section 6 of RFC 7432, for all service interface types, the draft talks about a single MAC-VRF pe= r EVI per PE and in case of VLAN-aware mode,  multiple VLANs per MAC-V= RF but only a single bridge table per VLAN. In other words, the bottom line= is that there can only be a single bridge table per VLAN in order to avoid unnecessary flooding.



When you have two MAC-VRFs per VLAN (one for root ACs and another for = Leaf ACs), then you either need to duplicate lots of MAC addresses between = these two VRFs, or do lookup on both of these VRFs. Either ways this is not= a good option relative to keeping a single VRF table for both root and leaf sites and just have a single-bit= indication on whether a MAC is associated with root or leaf (as currently = described approach in the draft).  I


In the above, it seems you agree that it can work, and you are able to offe= r reasons why it is not the preferred option, then why not just document th= at it can work and provides these reasons as the motivations that lead to p= roposing a new specs ?

Sure, I can do that. [...]

Ok.
I'll be happy to review a new revision and hopefully post the shepherd revi= ew.

Thanks,

-Thomas


=

(it seems you have an unfinished last sentence: "I [...]" )


=


(assuming the previous point is resolved:)

With this mechanism above, isn't it possible to have on a given PE, for a s= ingle E-TREE EVI, both Leaves and Roots, as long as distinct MAC-VRFs are u= sed (one for Leaves and one for Roots) ?   (it seems to me that t= he assymetric import/export RT would do what is needed to build an E-TREE, we would just have a particular case where a= Leaf MAC-VRF and a Root MAC-VRF for a given E-TREE end up on a single PE)<= /p>


That=92s not possible because per definition of an = EVI, there is only a single MAC-VRF per EVI for a PE.

Where can I read such a definition ? (the= Terminology section in RFC7432 does not say that, unless I'm missing somet= hing).
And that seems a completely arbitrary res= triction.
(just thinking that a given PE device can= be split in two logical devices show that it can work)

Section 6 of= RFC7432 where it gives definitions for different service interface types, = it specifies the relationship between MAC-VRF and VLAN (bridge table) and h= ow many MAC-VRF (and bridge tables) can be per EVI.

This section of RFC7434 discusses many different things for the different v= ariants.
Can you provide a specific pointer about "how many MAC-VRFs can be per= EVI" ?

Ali> Section 6 of RFC7432 spel= ls out the relationship between EVI, MAC-VRF, and bridge tables for all ser= vice interfaces very clearly.
=
In all service interfaces, the RF= C says there is one MAC-VRF per EVI on a given PE.
=
Now, if the service interface is = =93vlan-aware=94, then there are several bridge tables for that single MAC-= VRF =96 ie, one bridge table per VLAN. In all service interfaces, you can O= NLY have one bridge table per VLAN.

This answer is everything but a specific pointer.
If Section 6 of RFC7432 says all this very clearly, I guess it should be po= ssible to extract quotes about "there is one MAC-VRF per EVI on a given PE&= quot;, right ?


=

In bridging world= , there can only be a single bridge table per VLAN in a device.

I still don't find here anything that would preclude having, on a given PE,= for a given E-TREE EVI, one Leaves MAC-VRF and one Roots MAC-VRF: can't th= ese two MAC-VRFs use different internal VLANs (with translation if the exte= rnal VLANs are constrained).

Ali>  Lets assume we are using vlan-based service and thus there is= only a single bridge table per MAC-VRF, then what you are suggesting is tw= o use two MAC-VRFs (two bridge tables) for the same EVI (same VLAN). This r= esults in some duplications of MAC addresses and would only work if flooding is disabled (more on this later).

"results in some duplications of MAC" is perhaps a drawback, but = nothing like "just does not work" ?

"would only work if flooding is disabled": why ?  (you wrote= "(more on this later)" but I couldn't identify anything recent f= rom you in the rest of the email below)


>From an helicopter view, I can't see what fundamentally would become proble= matic between "two MAC-VRFs on two distinct PEs" and the same &qu= ot;two MAC-VRFs on a same PEs", at worse it is as efficient or as inef= ficient as having them on separate PEs (think logical router without anykind of dataplane optimisation), and we can't exclude th= at the PE could have local implementation details to do better than that.

=

Besides, I don=92t understand what good does i= t do to have two MAC-VRFs on the same PE (one for Leafs and another for Roo= ts)

Well, the "what is good for" is= pretty simple: it means you can have, just by tailoring the import/export = policies like in 2.1, something as useful as the scenario in 2.2.

There can only be a single bridg= e table per VLAN. Now even if you add some kind of logic to form two logical PEs in single physical PE, you end up replicating all the MAC addresses associ= ated with the root sites in two bridge tables.

Your point above certainly does not sound to me as "it can't be done&q= uot;: some may think that the above is an acceptable cost, some others may = find ways to make this "replication" with a low overhead, on some= platforms the cost may be negligible, etc.




because Leafs and Roots need to talk to each other = and thus we want them to be in the same MAC-VRF.

The fact that Leafs and Roots need to talk to each other does not mean that they *have* to be in the same MAC-VRF, you can rely on the local MPLS= dataplane inside the PE to carry the traffic between Roots and Leaves can = be passed between a Leaf MAC-VRF and a Root MAC-VRF (and you can possibly i= mplement a shortcut not involving MPLS encap/decap).

Anything is possible but at what cost.

You know, for cost it is not always obvious to reach conclusions that are t= rue for all implementations and all targets.

The current proposal is very efficient in terms of forwarding path= as well as control plane.

Sure, but what I question is not the new solution but the lack of discussio= n on why using the existing specs was not considered good enough.


I think that my concern of clearly explaining the scenarios and motivations= for this new spec could be addressed by splitting section 2.2 into a 2.2.1= describing the approach from 2.1 and its possible drawbacks, and a 2.2.2 h= aving essentially the content of current section 2.2.

Here is a proposal:

2.2 Scenario 2: Leaf of Root site(s= ) per AC

   In these scenarii, a P= E receives traffic from either Root OR Leaf
   sites (but not both) o= n a given Attachment Circuit (AC) of an EVI. In
   other words, an AC (ES= or ES/VLAN) is either associated with Root(s)
   or Leaf(s) (but not bo= th).

2.2.1 Scenario 2a: Leaf OR Root sit= e(s) per AC, separate Leaf/Root MAC-VRFs

      = ;            &n= bsp;  +---------+       &nb= sp;    +---------+
      = ;            &n= bsp;  |   PE1   |     &nb= sp;      |   PE2   |
    +---+&nb= sp;           |  = 3;---+  |  +------+  |  +---+ = |            +-= --+
    |CE1+-----ES= 1----+--+   |  |  |    &nbs= p; |  |  |MAC+--+---ES2/AC1--+CE2|
    +---+&nb= sp;   (Leaf)  |  |MAC|  |  | MPLS |  |&n= bsp; |VRF|  |   (Leaf)   +---+
      = ;            &n= bsp;  |  |VRF|  |  |  /IP |  |  '---'&nb= sp; |
      = ;            &n= bsp;  |  |   |  |  |    &= nbsp; |  |  .---.  |=
      = ;            &n= bsp;  |  |   |  |  |    &= nbsp; |  |  |MAC|  |      &nbs= p;     +---+
      = ;            &n= bsp;  |  |   |  |  |    &= nbsp; |  |  |VRF+--+---ES2/AC2--+CE3|
      = ;            &n= bsp;  |  +---+  |  +------+  |&nbs= p; +---+  |   (Root)   +---+<= tt style=3D"color: rgb(0, 0, 0);">
      = ;            &n= bsp;  +---------+       &nb= sp;    +---------+

   Figure 2: Scenario 2a<= /tt>

   In this scenario, the = RT constraint procedures described in section 2.1 could
   also be used. The feas= ibility and efficiency of this approach depends on
   platforms specifics.

   This approach will lea= d toduplication of a large proportio= n of MAC addresses on
   PEs having both Leaf and Root sites, and is hence considered l= ess suitable for
   deployment contexts where the vast majority of PEs are likely = to ultimately
   have both Leaf and Roo= t sites attached to them.

2.2.2 Scenario 2b: Leaf OR Root sit= e(s) per AC, single MAC-VRF

      = ;            &n= bsp;  +---------+       &nb= sp;    +---------+
      = ;            &n= bsp;  |   PE1   |     &nb= sp;      |   PE2   |
    +---+&nb= sp;           |  = 3;---+  |  +------+  |  +---+ = |            +-= --+
    |CE1+-----ES= 1----+--+   |  |  |    &nbs= p; |  |  |   +--+---ES2/AC1--+CE2|
    +---+&nb= sp;   (Leaf)  |  |MAC|  |  | MPLS |  |&n= bsp; |MAC|  |   (Leaf)   +---+
      = ;            &n= bsp;  |  |VRF|  |  |  /IP |  |  |VRF|&nb= sp; |
      = ;            &n= bsp;  |  |   |  |  |    &= nbsp; |  |  |   |  |     =        +---+
      = ;            &n= bsp;  |  |   |  |  |    &= nbsp; |  |  |   +--+---ES2/AC2--+CE3|<= tt style=3D"color: rgb(0, 0, 0);">
      = ;            &n= bsp;  |  +---+  |  +------+  |&nbs= p; +---+  |   (Root)   +---+<= tt style=3D"color: rgb(0, 0, 0);">
      = ;            &n= bsp;  +---------+       &nb= sp;    +---------+

   Figure 2: Scenario 2b<= /tt>

   This scenario will all= eviate keys drawbacks from Scenario 2a, in particular
   by avoiding duplicatio= n of MAC addresses on Leaf/Root PEs and avoiding the
   operational overhead o= f managing more than one RT.
   This approach comes at the expense of having routes for unneeded MAC addresse=
s
   on Leaf-only PEs, and is =
hence considered less suitable for deployment contexts
   where the vast majority of PEs would remain Leaf-only.   Unlike Sce=
nario 1 and Scenario 2a, this scenario requires additional procedures
   provided in this document.
(And this last sentence should be added to section 2.3 as well)


For this scenario, if for a given
   EVI, the majority of PEs will eventually have both Leaf and Ro= ot
   sites attached, even though they may start as Root-only or Lea= f-only
   PEs, then it is recommended to use a single RT per EVI and avo= id
   additional configuration and operational overhead.

Why this recommendation ?
Even with a majority of PEs having both Leaves and Roots, there can remain = (up to 49% of) PEs having only Leaves, which will uselessly have all routes= to other Leaves.

So "it is recommended" above, deserves to be explained more, I th= ink.

OK, I changed =93majority=94 to =93vast m= ajority=94 :-)

My point was not to nit pick on "majority", but was that you = should explain why you recommend that.
As the text currently reads, the cost of the recommendation can be iden= tified: having useless routes on the fraction of PEs having only Leaves. But the gain brought by the recommendation is not even mentioned, not t= o say explained.
Hence: why ?
(Why is it a useful tradeoff to have useless routes on some, even if on= ly one, PE ?)

Changed the last sentence from:
"then it is recommended to use a single R= T per EVI and avoid additional configuration and operational overhead.=94
To
"then it is recommended to use a single R= T per EVI and avoid additional configuration and operational overhead
at the expense of having unwanted MAC addresses on = the Leaf PEs."

Ok. I adapted and incorporated this addition into my proposed text splittin= g 2.2 into a 2.2.1 and a 2.2.2.

Best,

-Thomas




 --_000_D47964F61C70D0sajassiciscocom_--