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
