> On Apr 7, 2015:1:56 PM, at 1:56 PM, Andy Bierman <[email protected]> wrote:
>
> On Tue, Apr 7, 2015 at 7:17 AM, Thomas D. Nadeau
> <[email protected]> wrote:
>>
>>> On Apr 7, 2015:9:39 AM, at 9:39 AM, Susan Hares <[email protected]> wrote:
>>>
>>>
>>> Juergen:
>>>
>>> This is good feedback on the L2 topology versus interface module.
>>>
>>> Stating "taking out all objects that are interface specific" is a bit broad,
>>> but in principle specifics that belong to interfaces should be in the
>>> interfaces module. The L2 specification is part of a virtual topology that
>>> reflects interfaces, links, nodes, and terminating points. There will be
>>> some references to the virtual principles. Some things chassis-id imply a
>>> shared group resources (interfaces in a chassis) which creates a shared risk
>>> group. The virtual topology needs to indicate which interfaces are within a
>>> shared risk group. As Jie has mentioned, he will take into account your
>>> comments in the next revision of the draft.
>>
>> I agree with Juergen on the interfaces point. I also want to remind
>> folks
>> that the chassis-related stuff are being broken off and put into the
>> effort to build the Entity-MIB Yang Model. There is a design team that
>> I kicked off in NETMOD to do this work. Jimmy is part of that DT and
>> should be able to sync up with that effort.
>>
>
> Hi,
>
> The design team met for several hours in Dallas.
> I will be producing an initial draft based on those discussions.
> I will send meeting notes to the WG mailing list first.
Fantastic and thanks!
> We most focused on how to adapt the existing ENTITY MIB modules,
> not on missing data that I2RS needs beyond the adapted MIB modules.
That is cool. We can add that as we iterate.
--Tom
>
>
>> --Tom
>
> Andy
>
>>
>>
>>> I have already spoken to some IEEE people about who to talk to about the
>>> LLDP yang modules. It appears the appropriate group is the 802.1 working
>>> group, and I will send a note to the chair today.
>>>
>>> Sue
>>>
>>> -----Original Message-----
>>> From: i2rs [mailto:[email protected]] On Behalf Of Juergen Schoenwaelder
>>> Sent: Tuesday, April 07, 2015 5:45 AM
>>> To: Dongjie (Jimmy)
>>> Cc: [email protected]; Susan Hares
>>> Subject: Re: [i2rs] 2 week WG adoption call for
>>> draft-dong-i2rs-l2-network-topology-01.txt
>>>
>>> On Tue, Apr 07, 2015 at 09:36:18AM +0000, Dongjie (Jimmy) wrote:
>>>> Hi Juergen,
>>>>
>>>> Thanks for your comments on this L2 topology model. Please see some
>>> replies inline.
>>>>
>>>>> -----Original Message-----
>>>>> From: Juergen Schoenwaelder
>>>>> [mailto:[email protected]]
>>>>> Sent: Monday, April 06, 2015 11:18 PM
>>>>> To: Susan Hares
>>>>> Cc: [email protected]; Dongjie (Jimmy)
>>>>> Subject: Re: [i2rs] 2 week WG adoption call for
>>>>> draft-dong-i2rs-l2-network-topology-01.txt
>>>>>
>>>>> On Mon, Apr 06, 2015 at 09:11:39AM -0400, Susan Hares wrote:
>>>>>> This begins a 2 week adoption call for
>>>>>> draft-dong-i2rs-l2-network-topology-01.
>>>>>>
>>>>>> Please indicate in your comments "support" or "no support" and
>>>>>> discuss how this draft will allow I2RS client-agent pairs to query
>>>>>> information about L2 topology. The draft can be found at:
>>>>>>
>>>>>> http://datatracker.ietf.org/doc/draft-dong-i2rs-l2-network-topolog
>>>>>> y/
>>>>>>
>>>>>> <http://datatracker.ietf.org/doc/draft-clemm-i2rs-yang-l3-topo/>
>>>>>
>>>>> I wonder how this will interwork with any possible IEEE work.
>>>>> Bridges and VLANs had been modeled as MIBs back in a day but we
>>>>> meanwhile transferred work all over to IEEE. I think there should be
>>> some IEEE liaison interaction here.
>>>>>
>>>>> I also wonder to what extend this data model is repeating things
>>>>> that are already in the interfaces abstraction we have. There is no
>>>>> mention of RFC 7223 yet there is overlap.
>>>>
>>>> As a topology model, the L2 topology model is focusing on the overview of
>>> connectivity between the network entities from layer-2's perspective, thus
>>> the detailed config and operational information of interfaces will not be
>>> covered in this model, only those which are used as the identifiers of nodes
>>> and termination-points are included. We will take a look at whether the
>>> interface model should be referenced here.
>>>>
>>>
>>> Are you saying you will take out all objects that are interface specific? I
>>> think there should be text explaining the relationship to the
>>> ietf-interfaces model and extensions of it.
>>>
>>>> The chassis-id here has the same meaning as it is in LLDP. Currently its
>>> type is set to mac-address as one common implementation. This could be
>>> updated with a more generic type.
>>>
>>> Well, it is simply under specified what it is. And there is the model of
>>> physical entities where a chassis has a specific meaning. Anyway, there
>>> needs to be more relationship sections explaining all this. But at this
>>> point, many things are simply too vague to understand what they mean and it
>>> is unclear where the information would come from.
>>>
>>> /js
>>>
>>> --
>>> Juergen Schoenwaelder Jacobs University Bremen gGmbH
>>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
>>> Fax: +49 421 200 3103 <http://www.jacobs-university.de/>
>>>
>>> _______________________________________________
>>> i2rs mailing list
>>> [email protected]
>>> https://www.ietf.org/mailman/listinfo/i2rs
>>>
>>> _______________________________________________
>>> i2rs mailing list
>>> [email protected]
>>> https://www.ietf.org/mailman/listinfo/i2rs
>>>
>>
>> _______________________________________________
>> i2rs mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/i2rs
>
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
