[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [libvirt] [PATCH] vepa: parsing for 802.1Qb{g|h} XML



* Stefan Berger (stefanb us ibm com) wrote:
> Daniel Veillard <veillard redhat com> wrote on 05/11/2010 06:07:58 AM:
> 
> 
> > 
> > On Mon, May 10, 2010 at 07:57:37PM -0400, Stefan Berger wrote:
> > > Below is David Alan's original patch with lots of changes. 
> > > 
> > > In particular, it now parses the following XML and stored the data
> > > internally. No sending of netlink messages has been implemented here.
> > > 
> > >    <interface type='direct'>
> > >       <source dev='static' mode='vepa'/>
> > >       <model type='virtio'/>
> > >       <vsi managerid='12' typeid='0x123456' typeidversion='1'
> > >            instanceid='fa9b7fff-b0a0-4893-8e0e-beef4ff18f8f' />
> > >       <filterref filter='clean-traffic'/>
> > >     </interface>
> > > 
> > >     <interface type='direct'>
> > >       <source dev='static' mode='vepa'/>
> > >       <model type='virtio'/>
> > >       <vsi profileid='my_profile'/>
> > >     </interface>
> > > 
> > > I'd suggest to use this patch as a base for sending out netlink
> > > messages.
> > > 
> > > Signed-off-by: Stefan Berger <stefanb us ibm com>
> > 
> >   I have 2 basic questions:
> > 
> >     - how can we be sure that if we apply this the XML interface won't
> >       need to change due to kernel interfaces, maybe Chris can confirm
> >       that the kernel is now stable enough that this should not affect
> >       the XML anymore
> 
> I have been trying to gather the parameters necessary to trigger the 
> slightly
> different setup protocols. I cannot be sure that this XML won't change at 
> the 
> moment but would also wait to have it checked in. However, the parser here
> works to the best of my current knowledge.
> The netlink messages that require these parameters drive the requirements 
> to the XML. So, I'd wait for the kernel implementation to become stable.
> 
> 
> >     - can I get some signoff from Cisco that there is agreement on this
> >       format and that will be sufficient for their need
> 
> I'd also like to have 100% re-assurance that the TWO pre-standards we are 
> dealing
> with here are not going change later on and cause changes affecting the 
> XML.

Honestly, the only way you'll get that is to wait until they are
standards (and even then there's possible changes, additions, etc).
The low-level TLVs and the protocol ladder diagrams are not under
substantial churn.  Names change regularly, but the notion of
preassociate/associate/deassociate and the basic id's for VDP payload
(database id, profile id, mac+vlan pairs, etc).

thanks,
-chris


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]