Re: [GROW] IPR Disclosure: Huawei Technologies Co., Ltd's Statement about IPR related to draft-ietf-grow-va-02

[Robert Raszuk <[e-mail]>]

Folks,

I (as both individual contributor as well as co-author of VA draft)
fully agree with Chris that if needed simple use of BGP communities can
be applied within given domain to carry any form of local policy across
iBGP mesh - that applies to both prefix groups/lists and popular
prefixes using VA terminology.

Reinventing the wheel with some other tool other then those which
already have been successfully used for years makes no sense to me.

With this in mind I am completely not clear what such IPR filing could
be about. Are we discussing IPR of carrying local policy by BGP
communities ? That I am afraid has a decent prior art to 2007 filing.

Many thx,
R.


> 2010/6/24 Xu Xiaohu<[e-mail]>:
>>
>>
>>> -----邮件原件-----
>>> 发件人: [e-mail] [mailto:[e-mail]] 代表 Joel M.
>>> Halpern
>>> 发送时间: 2010年6月24日 23:33
>>> 收件人: Christopher Morrow
>>> 抄送: [e-mail]; [e-mail]
>>> 主题: Re: [GROW] IPR Disclosure: Huawei Technologies Co., Ltd's Statement
>> about
>>> IPR related to draft-ietf-grow-va-02
>>>
>>> While autoconfig is not "necessary" in order to have a working VA
>>> system, I think it (some form of autoconfig) is necessary in order to
>>> have a deployable and operable VA system.  Given that GROW is supposed
>>> to be focussed on operability, I am not at all sure we should drop
>>> autoconfig.
>>>
>>> {For context, the many concern I heard expressed at the early grow
>>> presentations was concern that the complexity of configuration made the
>>> system error prone and sufficient expensive, in terms of operational
>>> cost, that it woudl cost more than it would save.)
>>
>> I fully agree with Joel's concern. When you consider a real operational VA
>> system, you would have to consider how to make the configuration task as
>> easy as possible. For the purpose of experiment, the VP-list tool is enough.
> 
> my point about cogent, swisscom and other networks is that they
> already do VA (after a fashion) and they already have management of
> this configuration 'solved'. Layering on another protocol to manage
> this (with the surely unintended security problems that brings along
> with it) isn't really a win here.
> 
> Folks that run large MPLS enabled networks already have a system to
> distribute lsp configs (or use LDP for this), adding some config
> standards for prefix-list management and bgp policy isn't super hard.
> In fact, you already do this today in any decent sized network for
> connected routes, aggregates, customer/peer/etc, local community
> attachment... Certainly the first bit of "gee, we have routes without
> full routes, should the route left or right for this?" is "hard" (or
> at least takes a few moments of thought), but ongoing it's really not
> very hard to figure out (or shouldn't be).
> 
>> However, for a product network, is it acceptable for the network operators
>> to configure/maintain the identical VP-list on all VA routers? Besides, to
> 
> they do today for things as I mentioned above:
> aggregate routes
> static redistribution
> connected route redistribution
> 'customer' routes vs 'peer' routes
> localizing communities
> etc...
> 
>> alleviate the heavy traffic pressure on the APRs, those popular prefixes for
>> high-volume traffic should be installed into FIB by all BGP routers as
>> normal. Is it acceptable for the network operators to configure/maintain the
> 
> 'some prefixes will want as optimal pathing through the network as possible'
>   or
> 'some prefixes will pay for better service'
>   or
> 'some prefixes can not tolerate the added stretch imposed by VA'
> 
> this isn't really all that different than tweaking bgp
> communities/policy today "Hey, hauling this /24 from SFO to LAX just
> to send it to ATT and SantaClara is dumb, why don't we just localpref
> it up here in SantaClara and hand it to ATT there?"
> 
>> large volume of popular prefixes on all VA routers?
> 
> this happens today, see previous examples.
> 
>> With the auto-configure mechanism defined in the current VA-auto draft, the
>> network operator just need to configure the VP-range and the pop-prefix-list
>> on those local ASBRs which are connected to its peer ASes and transit ASes,
>> and those ASBRs in turn will classify the e-BGP learnt routes into two types
>> according to the configured VP-range and the pop-prefix-list:
>> can-be-suppressed and can-not-be-suppressed, and attach the "can-suppress"
>> tag to those can-be-suppressed prefixes when adverting them to their iBGP
>> peers which, in turn, just need to selectively install the received routes
>> according the "can-suppress" tag of the routes and their own roles (i.e.,.
>> ARP or non-APR).
> 
> you have successfully described 'bgp communities' and 'prefix
> lists'... we do this today, it's really not a burden.
> 
>>
>> In a word, I don't think the auto-config mechanism is optional and
>> dispensable.
> 
> sure... I'm just saying that as a network operator today I'm not clear
> that I see how I need anything at all to implement VA. The proof of
> this is that Cogent, Swisscom, VZB and many other folks already do it
> without any 'autoconfig'.
> 
> Again though, I'm just one guy, if the rest of the GROW participants
> think this is critical or interesting or worth investing in, then by
> all means we ought to soldier on.
> 
> <regular-guy-hat>
> -chris
> 
>> Best wishes,
>> Xiaohu
>>
>>> Yours,
>>> Joel
>>>
>>> Christopher Morrow wrote:
>>>> On Thu, Jun 24, 2010 at 3:49 AM, Paul Francis<[e-mail]>
>> wrote:
>>>>> As it was, I was about to ask the list if folks thought VA could move
>>>>> towards an informational RFC, or if folks felt that more implementation
>>>>> experience were needed.  Currently we have a linux/quagga
>> implementation
>>>>> that does not include MPLS tunneling.  I'm not sure the status of the
>>>>> Huawei implementation, but it is not to the point where it can be
>> tested
>>>>> against the linux implementation.  In any event, VA doesn't require
>>>>> wire-protocol changes, and I can well imagine that only once folks
>> start
>>>>> trying to deploy it will we really learn what configurations work best
>> (at
>>>>> which point we can document that).  In other words, even if we did have
>> a
>>>>> couple working implementations, there would be much more to learn from
>>>>> real deployments.
>>>>>
>>>>> I wasn't aware of the IPR.  According to the statement, it covers
>>>>> technology in draft-ietf-grow-va-auto-01.  This covers a way to
>> simplify
>>>>> configuration of the so-called VP-list.  This approach is not mentioned
>> in
>>>>> either of the main drafts (draft-ietf-grow-va-02 or
>>>>> draft-ietf-grow-simple-va-00).  My personal feeling is that this
>> approach
>>>>> is not very critical to the operation of VA, but lacking experience I
>>>>> could certainly be wrong.  In fact, if you look at the 00 draft of
>>>>> auto-config, you'll see that there was a second method proposed for
>>>>> auto-config which has pros and cons relative to Huawei's approach.
>> This
>>>>> was dropped from the 01 version primarily so as to keep things
>> simple...I
>>>>> don't think any of the non-Huawei authors felt strongly about these
>>>>> approaches one way or the other.
>>>>>
>>>>> Bottom line, I don't think this IPR should impinge moving the two main
>>>>> drafts forward---first because it is optional, and second because there
>>>>> are alternatives.  There are a couple ways we could move forward:
>>>>>
>>>>> 1.  Stick with the set of drafts we have now (the two main drafts, and
>> the
>>>>> optional auto-config draft with the IPR).
>>>>> 2.  Revive the second auto-config method so as to have a published
>>>>> non-encumbered option (probably as a separate draft so that it is clear
>>>>> what is and is not encumbered).
>>>>> 3.  Drop the auto-config draft, and continue forward with only the two
>>>>> main drafts.
>>>>
>>>> my feeling is if the autoconfig isn't necessary, and is encumbered how
>>>> about we live without it if possible :)
>>>> (w/participant hat)
>>>> -Chris
>>>>
>>>>> Thoughts?
>>>>>
>>>>> PF
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> From:   Christopher Morrow<[e-mail]>
>>>>> To:     [e-mail]
>>>>> Cc:     [e-mail], [e-mail], [e-mail],
>>>>> [e-mail], [e-mail], [e-mail],
>>>>> [e-mail], [e-mail], [e-mail]
>>>>> Date:   06/23/2010 09:46 PM
>>>>> Subject:        Re: IPR Disclosure: Huawei Technologies Co.,Ltd's
>>>>> Statement about IPR     related to draft-ietf-grow-va-02
>>>>>
>>>>>
>>>>>
>>>>> Grow-folk,
>>>>> we should probably decide whether this is a blocking issue for VA
>>>>> progression or not... I believe the ietf stance is that IPR claims are
>>>>> fine, if there aren't other non-encumbered options available.
>>>>>
>>>>> -Chris
>>>>>
>>>>> On Wed, Jun 23, 2010 at 3:31 PM, IETF Secretariat<[e-mail]>
>>>>> wrote:
>>>>>> Dear Lixia Zhang, Robert Raszuk, Xiaohu Xu, Dan Jen, Hitesh Ballani,
>>>>> Paul Francis:
>>>>>> An IPR disclosure that pertains to your Internet-Draft entitled "FIB
>>>>> Suppression
>>>>>> with Virtual Aggregation" (draft-ietf-grow-va) was submitted to the
>> IETF
>>>>>> Secretariat on 2010-06-23 and has been posted on the "IETF Page of
>>>>> Intellectual
>>>>>> Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1341/).
>>>>> The title
>>>>>> of the IPR disclosure is "Huawei Technologies Co.,Ltd's Statement
>> about
>>>>> IPR
>>>>>> related to draft-ietf-grow-va-02."
>>>>>>
>>>>>> The IETF Secretariat
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>> _______________________________________________
>>>> GROW mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/grow
>>>>
>>> _______________________________________________
>>> GROW mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/grow
>>
>>
> _______________________________________________
> GROW mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/grow