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:
On Thu, Jun 24, 2010 at 3:49 AM, Paul Francis <[email protected]> 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 <[email protected]>
To: [email protected]
Cc: [email protected], [email protected], [email protected],
[email protected], [email protected], [email protected],
[email protected], [email protected], [email protected]
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 <[email protected]>
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
[email protected]
https://www.ietf.org/mailman/listinfo/grow
_______________________________________________
GROW mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/grow
