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

[Xu Xiaohu <[e-mail]>]

Chris,

> -----邮件原件-----
> 发件人: Christopher Morrow [mailto:[e-mail]]
> 发送时间: 2010年6月25日 9:56
> 收件人: Xu Xiaohu
> 抄送: Joel M. Halpern; [e-mail]; [e-mail]
> 主题: Re: [GROW] IPR Disclosure: Huawei Technologies Co., Ltd's Statement
about
> IPR related to draft-ietf-grow-va-02
> 
> 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'. 

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

> Layering on another protocol to manage
> this (with the surely unintended security problems that brings along
> with it) isn't really a win here.

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.

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

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.

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

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

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

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

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