[Xorp-hackers] VLAN support

[Kristian Larsson]

Pavlin Radoslavov wrote:
> <kristian at spritelink.net> wrote:
> 
>> On Thu, 13 Sep 2007 16:30:15 -0700, Pavlin Radoslavov <pavlin at icir.org>
>> wrote:
>>> Kristian Larsson <kristian at spritelink.net> wrote:
>>>
>>>> Hello everyone :)
>>>>
>>>> I've seen a few CVS commits recently relating to VLAN configuration. I
>>>> would like to know what the current status is of the interface naming
>>>> scheme. The current standard has been questioned on several occasions
>>>> and I would like to see that the project reaches some form of consensus
>>>> on this before just implementing things.
>>>>
>>>> I read through an old thread with the subject 'Some thoughts' which
>>>> Hasso started. What is your view on those ideas?
>>>>
>>>> Do you currently have in mind a naming scheme for VLAN and other
>>>> "sub-interfaces"?
>>> The VLAN changes are to the backend and they follow the existing
>>> interface/vif scheme: the VLAN is a vif to the parent interface.
>>> Nothing has been changed in the user front-end.
>> I understand that nothing has been changed so far, what I'm interested in
>> is if it will be.
>> And I'm not certain how VLANs fit in under the current naming scheme, since
>> it's not currently implemented...
>> Under linux a vlan interface by default is named <interface>.<vlan id> and
>> under FreeBSD a vlan is named vlan<sequence number>, where the sequence
>> number has no correlation to the vlan id. Is XORP supposed to somehow
>> follow this?
>> interface eth0 {
>>           vif eth0.123 {
>>           }
>> }
>> or on freebsd
>> interface fxp0 {
>>           vid vlan2 {
>>           }
>> }
>> ??
>> How do I know the tag which is used on FreeBSD?
>> Could you please provide a few examples of how it may look ? :)
> 
> No, until the implementation is completed :)

If you go ahead and implement, which of course is nothing I object to - 
I would love VLAN support in XORP, I think the discussion will be raised 
on how the naming scheme should look and there is a slight risk that 
someone will have to re-implement and change things due to that we reach 
concensus on some other solution than what is currently on roadmap.
I'm having difficult understanding just why you can't provide me with an 
example of what you have in mind? Is it a secret? ;)

  -K