Re: [L3sm] New Version Notification for draft-wu-l3sm-rfc8049bis-02.txt

David Ball <daviball@cisco.com> Fri, 25 August 2017 10:53 UTC

Return-Path: <daviball@cisco.com>
X-Original-To: l3sm@ietfa.amsl.com
Delivered-To: l3sm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3F0C132B9F for <l3sm@ietfa.amsl.com>; Fri, 25 Aug 2017 03:53:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.489
X-Spam-Level:
X-Spam-Status: No, score=-14.489 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, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=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 6BeaxqzsG-zX for <l3sm@ietfa.amsl.com>; Fri, 25 Aug 2017 03:53:49 -0700 (PDT)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2E23132AA6 for <l3sm@ietf.org>; Fri, 25 Aug 2017 03:53:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=78182; q=dns/txt; s=iport; t=1503658427; x=1504868027; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=X2T7zyyDlo+qY4IytS7K7oAP6QacFkyouf3Kv2jjcio=; b=BOJMh9dvhKFaxc1hNlJQBP3cJEPefUiVn5IE5Ph/Xi/sFaKAMAwz26LB dlG+AxNrXJpIpatBciMnJT89z3FqPwGyPCUG9z5Z7u1JHb66wmfEs32Hx lipQwIchdL05FB4wRYSQrqoMCiZrgWB24PR+iFGxVYKqeYu037O/U+vJg E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CMAABnAKBZ/xbLJq1cGQEBAQEBAQEBAQEBBwEBAQEBgm+BT4EVjhR0kRR3lS4OggEDIQEKhRsChCwYAQIBAQEBAQEBayiFGAEBAQECAQEBGAEICjoHBAUCBQsJAg4KIAEGAwICJx8RBgEMBgIBAReKDggQkAGdZoInJ4MuiAsBAQEBAQEBAQEBAQEBAQEBAQEBAQEdgyqDT4FjK4JINIMmgRMVEUyCXYJhBYoKhxWPP4dWjHCCElqFCoNZhxeJcoNViHAfOIENMiEIHBUfKoUYBReBZgI/NgGHS4FFfAEBAQ
X-IronPort-AV: E=Sophos;i="5.41,425,1498521600"; d="scan'208,217";a="654182661"
Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 Aug 2017 10:53:42 +0000
Received: from [10.63.23.84] (dhcp-ensft1-uk-vla370-10-63-23-84.cisco.com [10.63.23.84]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v7PArfJC025133; Fri, 25 Aug 2017 10:53:42 GMT
To: Qin Wu <bill.wu@huawei.com>, "l3sm@ietf.org" <l3sm@ietf.org>
Cc: Stephane Litkowski <stephane.litkowski@orange.com>, Kenichi Ogaki <ke-oogaki@kddi.com>, "adrian@olddog.co.uk" <adrian@olddog.co.uk>
References: <B8F9A780D330094D99AF023C5877DABA9AA5D7A2@nkgeml513-mbx.china.huawei.com> <c76328ad-b71e-b2a3-92a4-b02beac2be7d@cisco.com> <B8F9A780D330094D99AF023C5877DABA9AAB78D5@nkgeml513-mbx.china.huawei.com> <e3289dda-b54f-6001-d4df-4ad6f43cbc91@cisco.com> <B8F9A780D330094D99AF023C5877DABA9AACC436@nkgeml513-mbx.china.huawei.com> <6acab373-d50e-674e-1f8a-b95363ae7e4b@cisco.com> <B8F9A780D330094D99AF023C5877DABA9AAD04B2@nkgeml513-mbx.china.huawei.com>
From: David Ball <daviball@cisco.com>
Message-ID: <bbb82618-18c6-70d1-9a3d-a4cade93535f@cisco.com>
Date: Fri, 25 Aug 2017 11:53:41 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <B8F9A780D330094D99AF023C5877DABA9AAD04B2@nkgeml513-mbx.china.huawei.com>
Content-Type: multipart/alternative; boundary="------------1490E7E15CA658A37CFC6956"
Content-Language: en-GB
Archived-At: <https://mailarchive.ietf.org/arch/msg/l3sm/cVWgkPlYW5bHacCeRoLvbUEAVEI>
Subject: Re: [L3sm] New Version Notification for draft-wu-l3sm-rfc8049bis-02.txt
X-BeenThere: l3sm@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: L3VPN Service YANG Model discussion group <l3sm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/l3sm>, <mailto:l3sm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/l3sm/>
List-Post: <mailto:l3sm@ietf.org>
List-Help: <mailto:l3sm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/l3sm>, <mailto:l3sm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 25 Aug 2017 10:53:55 -0000

Thanks - a couple more comments inline with [DB3]:


On 25/08/2017 07:18, Qin Wu wrote:
>
> *发件人:*L3sm [mailto:l3sm-bounces@ietf.org] *代表 *David Ball
> *发送时间:*2017年8月24日17:52
> *收件人:*Qin Wu; l3sm@ietf.org
> *抄送:*Stephane Litkowski; Kenichi Ogaki; adrian@olddog.co.uk
> *主题:*Re: [L3sm] New Version Notification for 
> draft-wu-l3sm-rfc8049bis-02.txt
>
> Thanks - more inline with [DB2]:
>
> On 24/08/2017 04:26, Qin Wu wrote:
>
>     Thank David for follow up comments. See my reply inline below
>     marked with [Qin-1].
>
>     *发件人:*David Ball [mailto:daviball@cisco.com]
>     *发送时间:*2017年8月23日20:22
>     *收件人:*Qin Wu; l3sm@ietf.org <mailto:l3sm@ietf.org>
>     *抄送:*Stephane Litkowski; Kenichi Ogaki; adrian@olddog.co.uk
>     <mailto:adrian@olddog.co.uk>
>     *主题:*Re: [L3sm] New Version Notification for
>     draft-wu-l3sm-rfc8049bis-02.txt
>
>     Thanks Qin, I think most of the comments are being addressed. 
>     Some responses below, I've snipped out the ones where we have
>     agreement.
>
>     On 21/08/2017 07:47, Qin Wu wrote:
>
>         > 2. In section 6.3, I think we can add a statement like: "Multiple
>         locations can be associated
>
>         >     with a single site, but a particular location cannot be associated
>         with more than one site."
>
>         >   (Personally I don't see the need for this restriction, but
>         this sentence is based on the
>
>         >     previous discussion).
>
>         We will not be making this change (which seems consistent with
>         your view). A location is a description of a physical
>         location, while a site is part of a service (i.e., a CE).
>         There is no reason to prohibit a service having two co-located
>         CEs. And, of course, two different services could have sites
>         at a single location.
>
>
>     [DB]
>     Ok - in that case, for clarity, can we make the opposite
>     statement: "Multiple locations can be associated with a single
>     site; similarly, a particular location can be associated with more
>     than one site."
>
>
>     [Qin-1]:The statement we like to put is: Each site is associated
>     with one location or more locations.
>
>
> [DB2] I think we already say that; but it is the converse I would like 
> to add, i.e. each location can have one or more sites.
>
> [Qin-2]:I think the text MUST be consistent with the model. In the 
> model, the site and location are organized as:
>
> One site can have one or more location. Not the other way around, in 
> the text, we can see multi-location site is one typical example that 
> is discussed in the draft.
>
> “
>
> +--rw sites
>
> +--rw site* [site-id]
>
> +--rw site-id         svc-id
>
> +--rw requested-site-start?  yang:date-and-time
>
> +--rw requested-site-stop?   yang:date-and-time
>
> +--rw locations
>
> | +--rw location* [location-id]
>
> ”
>
> Considering consistency and clarity, I think we should use statement I 
> mentioned above previously.
>

[DB3]
Ok, but I think that's just a phrasing issue.  Would you be happier 
adding "Two or more sites can be associated with the same location, by 
referencing the same location ID"?

> [Note: I came to the conclusion above based on the previous discussion 
> about SubVPN, where you said site-network-accesses in different sites 
> couldn't share physical components because different sites would be 
> associated with different locations.  If multiple sites are allowed to 
> be associated with the same location, then they could also share some 
> physical components, right?]
>
> [Qin]: Sure, you can use " same-bearer" attribute to express that 
> constraint the relationship between source site-network-access and 
> target site-network-access.
>
>
>
>
> > 9. In section 6.12.2.2, the second paragraph needs to be updated (or
>
> >     deleted?) now that you have added the "direction" leaf.
>
> We don't believe there is anything actually incorrect about the 
> current text.
>
>
> [DB]
> Ok, in that case I don't understand it. :)  Suppose there is a 
> provider-managed connection with a qos-profile, and the direction in 
> the qos profile is set to Site-to-WAN.  The second paragraph says: 
> "the provider should ensure scheduling according to the requested 
> policy in both traffic directions", but the description of the 
> direction says: "used to specify the direction which qos profile is 
> applied to".  Since the direction is Site-to-WAN in this example, this 
> means the profile would only be applied in that direction, not in both 
> directions.  That seems to contradict the previous text that says it 
> should be applied in both directions?
>
>
> [Qin-1]: I see your point. I think in case of provider-managed or 
> co-managed connection, QoS profile are applied to both direction based 
> on the second paragraph of section 6.12.2.2, that means the parameter 
> “direction” is set to “both”.
>
> In case of customer-managed connection, QoS profile is applied to the 
> direction from SP network to the customer site, that means the 
> parameter “direction” should be set to “WAN-to-Site”.
>
> That’ why we think there is actually incorrect about the current text. 
> Note that “direction” is just optional parameter in this model.
>
> On the other hand, if we want to enhance the current text, we might 
> consider:
>
> 1.allow direction at network access level to override the parameter in 
> the site level.
>
> 2.Use “direction” condition to replace “provider-managed, co-managed, 
> customer-managed” condition in the text and allow more flexibility to 
> apply QoS profile to appropriate traffic direction.
>
> But I like to talk to the design team for this first.
>
>
> [DB2] Ok - option 2 would be my preference but lets see what others think.
>
> [Qin-2]:ok, I have asked design team to express on the list if they 
> have different opinion.
>
>
>
> > 12. The value carried in the svc-mtu leaf is now described more 
> clearly, but its intended
>
> >     use is still unclear, at least to me.  Would something like the following be 
> correct?  If
>
> >     not, what is the correct expression of how to interpret this leaf?
>
> >    "For a given VPN service, the service provider may discard (or for IPv4, may fragment)
>
> >     packets that are longer than the smallest svc-mtu across all 
> site-network-accesses for
>
> >     all sites in the VPN."
>
> We think that SPs are used to the concept of link MTU. svc-mtu 
> modifies the link MTU for the site-access links within the scope of a 
> particular service. We think that an SP will know exactly how to 
> handle packets that exceed MTU values
>
>
> [DB]
> Ok, so the intent is that this is just local to the 
> site-network-access.  I.e. we could say: "Packets transmitted over the 
> site-network-access that are longer than the svc-mtu may be discarded 
> (or for IPv4, fragmented)."
>
> [Qin-1]: I would prefer to leave this up to SP to determine how to 
> deal with MTU exceeding, we can not limited only to discard or 
> fragmented, does this make sense?
>
>
> [DB2] Yes - that is why I said "may be discarded" instead of "must be 
> discarded".  With my suggested text, it is still up to SP to determine 
> how to handle it, but we are providing some warning for the customer.
>
> [Qin-2]:I still feel this model is just a service model which is not 
> directly code implemented on the network device to control the network 
> operation. I am reluctant to add this lower layer constraint to the 
> service parameter in the service model. SP may instruct the management 
> system to provision the network device with appropriate policy.
>

[DB3] I completely agree; my point is to provide some information to the 
customer about how the service might behave if they request a particular 
value for the MTU.


     David


> > 13. In the new filters container, there is a list of filters indexed by type (ipv4, 
> ipv6,
>
> >     lan-tag, or vpn-policy-filter-type).  Each filter contains a leaf-list of IPv4 
> prefixes,
>
> >     a leaf-list of ipv6 prefixes and a leaf-list of lan-tags.  Is the intent that the 
> contents
>
> >     of the filter matches the type?  There is nothing to enforce that currently 
> - should
>
> >     there be a "when" statement for each leaf-list, to restrict it to only the case
>
> >     where the type is appropriate (e.g. the ipv4-lan-prefix leaf-list would have
>
> >     "when ../type = ipv4")?
>
> >     I don't really understand what this new filter list achieves over having a single
>
> >     filter that could contain a mix of ipv4 prefixes, ipv6 prefixes and lan-tags.  What's
>
> >     the advantage of 3 filters each containing a single type over one filter 
> containing
>
> >     all three types?
>
> RFC 8049 allowed multiple filters of any one type, but not a mix of 
> filters of different types. That's now fixed.
>
>
> [DB]
> Right, I was comparing to the previous version of 8049bis rather than 
> to RFC8049 (which I agree did not allow a mix of prefixes and LAN tags).
>
>
> [Qin-1]With the old version of RFC8049, you still can have a mix of 
> prefixes and LAN tags, with two entries instead of single entry
>
> “
>
>       <entries>
>
>        <id>ENTRY1</id>
>
>        <filter>
>
>         <lan-tag>LAN1</lan-tag>
>
>        </filter>
>
>        <vpn>
>
>         <vpn-id>VPN2</vpn-id>
>
> <site-role>hub-role</site-role>
>
>        </vpn>
>
>       </entries>
>
>       <entries>
>
>        <id>ENTRY2</id>
>
>        <filter>
>
> <ipv4-lan-prefix>LAN2</ipv4-lan-prefix>
>
>        </filter>
>
>        <vpn>
>
>         <vpn-id>VPN2</vpn-id>
>
> <site-role>any-to-any-role</site-role>
>
>        </vpn>
>
>       </entries>
>
> ”
>
>
> With the new version, you could have data like this:
>
> <filters>
>   <filter>
>     <type>lan</type>
> <ipv4-lan-prefix>10.0.0.0/24</ipv4-lan-prefix> // IPv4 prefix 
> specified even though type is lan
>   </filter>
>   <filter>
>     <type>ipv4</type>
> <ipv6-lan-prefix>10::0/64</ipv6-lan-prefix> // IPv6 prefix and lan tag 
> specified even though type is ipv4
>     <lan-tag>foo</lan-tag>
>   </filter>
> </filters>
>
> [Qin-1]: This can be easily fixed by add when statement, e.g.,
>
> when "derived-from-or-self(../type, 'l3vpn-svc:ipv4')" {
>
>          description
>
>          "Only applies when vpn policy filter is ipv4-lan-prefix.";
>
>         }
>
>
> [DB2] Yes, adding 'when' statements would also work.
>
> [Qin-2]: Thanks.
>
>
> I think the aim could be achieved with a single filter that contains 
> leaf-lists for IPv4, Ipv6 and lan tags, i.e.:
>
> container filter {
>   leaf-list ipv4-lan-prefix { type inet:ipv4-prefix; }
>   leaf-list ipv6-lan-prefix { type inet:ipv6-prefix; }
>   leaf-list lan-tag { type string; }
> }
>
> This allows full flexibility, i.e. a filter can have zero or more IPv4 
> prefixes, zero or more IPv6 prefixes and zero or more LAN tags.
>
> [Qin]: Similar to our design team's proposal in the new version, but 
> ipv4 and ipv6 and lan-tag are not of the same type. put them in the 
> same container seems weird,J.
>
> Our proposal follow similar construct proposed for " routing-protocol" 
> list in this model.
>
> > 15. For the site-network-access connection addressing, ip-connection/ipv4/address-
>
> >   allocation-type is optional with no default, but 
> ip-connection/ipv6/address-allocation-
>
> >    type has a default defined (static-addressing).  This means it's impossible to 
> have a
>
> >   site-network-access that only uses IPv4 addressing.  I think the 
> default should be
>
> >    deleted in the IPv6 case, so that an IPv4-only site-network-access could be
>
> >    represented by simply not setting the IPv6 address-allocation-type.
>
> Good catch, to get consistent with original RFC8049, I would propose 
> to add the default for ipv4-only site-network-access as well.
>
> Note that we use "feature" for both ipv4 case and ipv6 case.
>
>
> [DB]
> Using "feature" doesn't solve the problem, since that turns IPv4 or 
> IPv6 on or off for every service.  However, the SP might have some 
> IPv4-only services and some IPv6-only services.  So, they need to 
> advertise both features, but they also need a way to not specify an 
> IPv6 connection address for the IPv4-only services, and to not specify 
> an IPv4 connection address for the IPv6-only services.
> So, I believe the best solution is to delete the default for the 
> address-allocation-type in both cases.
>
> [Qin-1]: I am fine to delete both default values, but
>
> RFC7950 section 7.6.1 said:
>
> "
>
> Note that if the leaf or any of its ancestors has a "when" condition
>
> or "if-feature" expression that evaluates to "false", then the
>
> default value is not in use.
>
> "
>
> To my understanding, if the server doesn’t support one feature or 
> advertise one feature, the default value will not in use.
>
> If the server advertise both features, it doesn’t say default value 
> for each feature MUST be specified.
>
> So if both features can be supported, is there any reason we only 
> specify only IPv6 connection or IPv4 connection?
>
>
> [DB2] The difference is that features apply across the whole server - 
> if the ipv4 feature is disabled, then the server cannot support IPv4 
> at all, and there can be *no* services with IPv4.  However, the case I 
> was describing is different - in this case, there are some services 
> that support IPv4 and some that do not.  For example, the SP might 
> offer an IPv4 product, and IPv6 product and a dual-stack product, 
> where the dual-stack product is more expensive.  So some customers 
> might choose IPv4-only or IPv6-only - or a particular customer might 
> choose a mix of ipv4-only and ipv6-only services.  This is why I think 
> the default should be deleted in both cases.
>
> [Qin-2]:Sounds reasonable to me, I will delete default if there is no 
> one against it.
>     David
>
>
>
>
>     David
>
>
>
>
> Thanks for your time and effort.
>
> Qin
>
> On 09/08/2017 11:40, Qin Wu wrote:
>
>     Here is the update to draft-wu-l3sm-rfc8049bis-02 based on
>     additional discussion on the list.
>
>     https://www.ietf.org/internet-drafts/draft-wu-l3sm-rfc8049bis-02.txt
>
>     Thank David for additional comments. Thank Design team to help
>     address these comments.
>
>     The main changes include:
>
>     1.Clarify the rational of the model in the section 5 based on
>     David's comment.
>
>     2.Add multi-filter and multi-VPN per entry support for VPN policy.
>
>     3.Modify description for svc-input-bandwidth leaf and svc-output-
>
>     Bandwidth leaf to address inconsistency issue with the text in
>     section 6.12.1.
>
>     4. Add text to clarify the way to achieve Per-VPN QoS policy.
>
>     5. Remove address-scope-type since there is no common
>     understanding on this.
>
>     6. Modify the description of autonomous-system under container “BGP”to address David's comment on AS.
>
>     Regarding provider address and mask to the model for the DHCP and
>     DHCP relay cases, talking with design team members,
>
>     We believe these parameters are the one requested by Customer to
>     Provider and therefore we keep it in the model.
>
>     Regarding Number of BGP sessions, eBGP multihop between loopbacks
>     and other similar issue, The design team agreed that it is not
>
>     reasonable to enumerate all the cases this models doesn't support.
>     The current text has been clear about this.
>
>     We believe that we have address all the comments. Thanks!
>
>     -Qin
>
>     -----邮件原件-----
>
>     发件人: internet-drafts@ietf.org <mailto:internet-drafts@ietf.org>
>     [mailto:internet-drafts@ietf.org]
>
>     发送时间: 2017年8月9日18:20
>
>     收件人: Qin Wu; Luis Tomotaki; Kenichi Ogaki; Stephane Litkowski
>
>     主题: New Version Notification for draft-wu-l3sm-rfc8049bis-02.txt
>
>     A new version of I-D, draft-wu-l3sm-rfc8049bis-02.txt has been
>     successfully submitted by Qin Wu and posted to the IETF repository.
>
>     Name:            draft-wu-l3sm-rfc8049bis
>
>     Revision: 02
>
>     Title:           YANG Data Model for L3VPN Service Delivery
>
>     Document date:   2017-08-09
>
>     Group:           Individual Submission
>
>     Pages:           181
>
>     URL:
>     https://www.ietf.org/internet-drafts/draft-wu-l3sm-rfc8049bis-02.txt
>
>     Status: https://datatracker.ietf.org/doc/draft-wu-l3sm-rfc8049bis/
>
>     Htmlized: https://tools.ietf.org/html/draft-wu-l3sm-rfc8049bis-02
>
>     Htmlized:
>     https://datatracker.ietf.org/doc/html/draft-wu-l3sm-rfc8049bis-02
>
>     Diff: https://www.ietf.org/rfcdiff?url2=draft-wu-l3sm-rfc8049bis-02
>
>     Abstract:
>
>        This document defines a YANG data model that can be used for
>
>        communication between customers and network operators and to
>     deliver
>
>        a Layer 3 provider-provisioned VPN service.  This document is
>     limited
>
>        to BGP PE-based VPNs as described in RFCs 4026, 4110, and
>     4364.  This
>
>        model is intended to be instantiated at the management system to
>
>        deliver the overall service.  It is not a configuration model to be
>
>        used directly on network elements.  This model provides an
>     abstracted
>
>        view of the Layer 3 IP VPN service configuration components. 
>     It will
>
>        be up to the management system to take this model as input and use
>
>        specific configuration models to configure the different network
>
>        elements to deliver the service.  How the configuration of network
>
>        elements is done is out of scope for this document.
>
>        If approved, this document obsoletes RFC 8049.  The changes are a
>
>        series of small fixes to the YANG module, and some
>     clarifications to
>
>        the text.
>
>     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.
>
>     The IETF Secretariat
>
>     _______________________________________________
>
>     L3sm mailing list
>
>     L3sm@ietf.org <mailto:L3sm@ietf.org>
>
>     https://www.ietf.org/mailman/listinfo/l3sm
>
>
>
>
>
> -- 
> David Ball
> <daviball@cisco.com> <mailto:daviball@cisco.com>
>
>
>
>
> -- 
> David Ball
> <daviball@cisco.com> <mailto:daviball@cisco.com>
>
>
>
> -- 
> David Ball
> <daviball@cisco.com> <mailto:daviball@cisco.com>

-- 
David Ball
<daviball@cisco.com>