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

From: Christopher Morrow <[email-masked]>
Date: Wed, 23 Jun 2010 15:45:49 -0400

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 <[email-masked]> 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
>
>
>

---

From: IETF Secretariat <[email-masked]>
Date: Wed, 23 Jun 2010 12:31:56 -0700 (PDT)

The IETF Secretariat

---

From: Paul Francis <[email-masked]>
Date: Thu, 24 Jun 2010 09:49:45 +0200

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.

Thoughts?

PF

From:   Christopher Morrow <[email-masked]>
To:     [email-masked]
Cc:     [email-masked], [email-masked], [email-masked], 
[email-masked], [email-masked], [email-masked], 
[email-masked], [email-masked], [email-masked]
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,

-Chris

---

From: Christopher Morrow <[email-masked]>
Date: Thu, 24 Jun 2010 11:10:06 -0400

> 3.  Drop the auto-config draft, and continue forward with only the two

my feeling is if the autoconfig isn't necessary, and is encumbered how
about we live without it if possible :)
(w/participant hat)
-Chris

---

From: John Scudder <[email-masked]>
Date: Thu, 24 Jun 2010 08:25:43 -0700

> about we live without it if possible :)

My question on this is the same as always -- considering that the lack of a patent disclosure does NOT guarantee that a technology is unencumbered, what do we gain by penalizing technologies for which a disclosure has been filed?  In fact, from one point of view there is something to be preferred about a spec with an above-board RAND disclosure over a spec with no disclosure but that may be covered by some submarine patent held by a troll.  I see an argument in favor of preferring a positively-known-to-be-unencumbered technology, but AFAIK that is a completely hypothetical case.

(You would be wrong if you interpreted this as "John is happy with the state of patent law".  The above represents my view of reality-as-it-is.  My view of reality-as-I-wish-it-was is not particularly relevant, AFAICT.)

--John
  with my own individual contributor hat on, of course

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 24 Jun 2010 11:32:31 -0400

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.)

Yours,
Joel

Christopher Morrow wrote:
> _______________________________________________
> GROW mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/grow
>

---

From: Christopher Morrow <[email-masked]>
Date: Thu, 24 Jun 2010 11:41:55 -0400

On Thu, Jun 24, 2010 at 11:32 AM, Joel M. Halpern <[email-masked]> wrote:
> 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

some form of config management relative to VA, sure. I'm not sure that
some overlying protocol is called for, for the 12 routers out of 1200
that need this, in a hypothetical network. Just understanding: "route
to the left on these devices only" seems fine.

> 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.

that's fair, in the end I have no strong feeling about it. I was
proposing to skip it if we don't feel it's on the critical path.

> system error prone and sufficient expensive, in terms of operational cost,
> that it woudl cost more than it would save.)

sure, and as stated in meetings (and on-list I believe) VA, to me,
seems like a short term solution when there are no alternatives
available to an operator for upgrades. There are lots of folks that do
'va' today *(by hand and in a very gross fashion) for this very
reason. For example, one could look at the bgp customer config at
cogent as a form of VA...

(w/regular-person-hat)
-chris

>>>> 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
>>>>
>>>> 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
>>>>

---

From: Xu Xiaohu <[email-masked]>
Date: Fri, 25 Jun 2010 09:24:28 +0800

> -----邮件原件-----
> 发件人: [email-masked] [mailto:[email-masked]] 代表 Joel M.
> Halpern
> 发送时间: 2010年6月24日 23:33
> 收件人: Christopher Morrow
> 抄送: [email-masked]; [email-masked]
> 主题: Re: [GROW] IPR Disclosure: Huawei Technologies Co., Ltd's Statement
about
> IPR related to draft-ietf-grow-va-02
> 

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.
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
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
large volume of popular prefixes on all VA routers?

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).

In a word, I don't think the auto-config mechanism is optional and
dispensable.

Best wishes,
Xiaohu

---

From: Christopher Morrow <[email-masked]>
Date: Thu, 24 Jun 2010 21:55:49 -0400

> 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).

> 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...

> 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.

> according the "can-suppress" tag of the routes and their own roles (i.e.,.

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

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

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 25 Jun 2010 13:26:21 +0200

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<[email-masked]>:
>>
>>
>>> -----邮件原件-----
>>>> On Thu, Jun 24, 2010 at 3:49 AM, Paul Francis<[email-masked]>
>> wrote:
>>>>> From:   Christopher Morrow<[email-masked]>
>>>>> To:     [email-masked]
>>>>> On Wed, Jun 23, 2010 at 3:31 PM, IETF Secretariat<[email-masked]>
>>>>> wrote:

---

From: Xu Xiaohu <[email-masked]>
Date: Sat, 26 Jun 2010 09:25:40 +0800

Chris,

> -----邮件原件-----
> 发件人: Christopher Morrow [mailto:[email-masked]]
> 发送时间: 2010年6月25日 9:56
> 收件人: Xu Xiaohu
> 抄送: Joel M. Halpern; [email-masked]; [email-masked]
about
> this configuration 'solved'. 

I'm glad hearing that some ISPs have deployed VA (after a fashion) to
suppress FIB.

> Layering on another protocol to manage

Sure, that's why we just use the BGP community, rather than a new path
attribute or a totally new protocol to carry the "can-suppress" tag.

> standards for prefix-list management and bgp policy isn't super hard.

I agree that isn't super hard. One can choose either to synchronize the
policy configuration (e.g., prefix-list for policy) among all the BGP peers
of the same domain and make these BGP peers in turn perform the path
selection according to the synchronized policy configuration, or to
configure the policy on the limited number of BGP peers and make these BGP
peers to mark the e-BGP learnt routes with the local preference or some
other path attribute, thus the other BGP peers receiving the marked routes
could directly make the route selection according to the marks. There are
similar choices for QoS process, for example, One can choose to
synchronization the QoS policy configuration among all involved routers and
make each of them to perform QoS remark and CAR independently, or to
configure the QoS policy just at the border routers which will perform QoS
remarks and make the following routers to perform QoS CAR according to the
QoS marks.

> 'some prefixes can not tolerate the added stretch imposed by VA'

Yes. That's the intention of the popular prefix defined in VA docs.

> lists'... we do this today, it's really not a burden.

Yes, after using the BGP community to carry the "can-suppress" tag, the
configuration for VA becomes much easy and isn't a burden any more.
Especially when the operator has deployed APRs whose VPs have covered the
whole DFZ address blocks, just one VP-range entry of 0/0 is enough and it is
only needed to be configured on the local ASBRs which are connected to peer
ASes and transit ASes. Besides, VP merge and VP split operations don't
require any change to the VP-range configuration. I believe the amount of
these ASBRs is much smaller than that of the ASBRs which are connected to
customer ASes for most ISP networks, not mentioning the other non-ASBR BGP
peers. 

Best wishes,
Xiaohu

> >> >> 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
> >> >> configuration of the so-called VP-list.  This approach is not
mentioned
> > in
> >> >> 1.  Stick with the set of drafts we have now (the two main drafts,
and
> > the
> >> >>> Property Rights Disclosures"
> (https://datatracker.ietf.org/ipr/1341/).
> >> >> The title

---

From: Xu Xiaohu <[email-masked]>
Date: Sat, 26 Jun 2010 09:26:29 +0800

Robert,

> -----邮件原件-----
> 发件人: [email-masked] [mailto:[email-masked]] 代表 Robert
> Raszuk
> 发送时间: 2010年6月25日 19:26
> 收件人: [email-masked]
about

> already have been successfully used for years makes no sense to me.

Agree. Actually the auto-configuration mechanism defined in va-auto draft
DOES use the BGP community to carry the "can-suppress" tag which determines
whether or not the prefix should be suppressed. Hence, we are not
reinventing the wheel, and that is why the draft is just informational,
rather than standard track.

Best wishes,
Xiaohu

> >> alleviate the heavy traffic pressure on the APRs, those popular
prefixes
> for
> >> normal. Is it acceptable for the network operators to
configure/maintain
best
have
mentioned
and

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 26 Jun 2010 10:48:17 +0200

Xu,

I am not talking about the draft. I am asking about the patent ?

if you are using BGP communities to carry policy information what is in
there which is novel and which requires IPR ?

Thx,
R.

---

From: Xu Xiaohu <[email-masked]>
Date: Sat, 26 Jun 2010 17:20:34 +0800

> -----邮件原件-----
> 发件人: Robert Raszuk [mailto:[email-masked]]
> 发送时间: 2010年6月26日 16:48
> 收件人: Xu Xiaohu
> 抄送: [email-masked]
about
> there which is novel and which requires IPR ?

The key part of this IPR is to make a BGP router to selectively FIB-install
BGP routes according to their BGP community values, together with its own
role (i.e., APR or non-APR for a given prefix).

Best wishes,
Xiaohu