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