Subject: [i2rs] 2 week WG adoption call for draft-dong-i2rs-l2-network-topology-01.txt

From: "Susan Hares" <[email-masked]>
Date: Mon, 6 Apr 2015 09:11:39 -0400

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-topology/

 <http://datatracker.ietf.org/doc/draft-clemm-i2rs-yang-l3-topo/> 

Sue Hares and Jeff Haas

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Mon, 6 Apr 2015 09:27:34 -0400

Is this currently in the charter or does the charter need to be extended 
to allow for non-RIB related topology models to be included in i2rs? As I recall,
this is why we didn't do any L1 topology for optical networks, which was
something one particular operator requested at the time but was pushed 
back based on that not being in the charter.  At the time, the message was
that we should only focus on l3 topology (i.e.: routing/RIB-related).

o The ability to extract information about topology from the network.  
Injection and creation of topology will not be considered as a work 
item. Such topology-related models will be based on a generic 
topology model to support multiple uses; the generic topology model 
should support topology extension for non-I2RS uses.
o Other use cases may be adopted by the working group only through 
rechartering.

- Yang Data Models consistent with the use cases. Such documents 
should include an information overview. The existing WG draft - 
draft-ietf-i2rs-rib-info-model - that is just an informational model 
can be completed or extended with the associated YANG data model.

> On Apr 6, 2015:9:11 AM, at 9:11 AM, Susan Hares <[email-masked]> 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-topology/ <http://datatracker.ietf.org/doc/draft-dong-i2rs-l2-network-topology/>
> _______________________________________________
> i2rs mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/i2rs <https://www.ietf.org/mailman/listinfo/i2rs>

---

From: "Susan Hares" <[email-masked]>
Date: Mon, 6 Apr 2015 09:45:53 -0400

Tom:

See the charter text from http://datatracker.ietf.org/wg/i2rs/charter/

o The ability to extract information about topology from the network.  Injection and creation of topology will not be considered as a work item. Such topology-related models will be based on a generic  topology model to support multiple uses; the generic topology model should support topology extension for non-I2RS uses.

The L2 draft is a Protocol independent an extension of the generic protocol-independent topology module at layer 2.  Please see  <http://datatracker.ietf.org/doc/draft-clemm-i2rs-yang-network-topo/> draft-clemm-i2rs-yang-network-topo-04 for details on generic model that points to multiple layers. 

The L3 and L2 drafts provide layers of the protocol-independent.  The L1 Topology draft and Service topology drafts need addition work to be aligned with the TEAS WG and other service topology WGs (L3SM, SFC, and SUPA BOF).  Drafts at the L1 layer and Service layer are still within the protocol independent topology. 

The WG Adoption calls (L3 topology and L2 topology) are based on this understanding of the I2RS charter

Sue  Hares

From: Thomas D. Nadeau [mailto:[email-masked]] 
Sent: Monday, April 06, 2015 9:28 AM
To: Susan Hares
Cc: [email-masked]; Dongjie (Jimmy)
Subject: Re: [i2rs] 2 week WG adoption call for draft-dong-i2rs-l2-network-topology-01.txt

 

 <http://datatracker.ietf.org/doc/draft-dong-i2rs-l2-network-topology/> http://datatracker.ietf.org/doc/draft-dong-i2rs-l2-network-topology/

Sue Hares and Jeff Haas

_______________________________________________
i2rs mailing list
 <mailto:[email-masked]> [email-masked]
 <https://www.ietf.org/mailman/listinfo/i2rs> https://www.ietf.org/mailman/listinfo/i2rs

---

From: "Fedyk, Don" <[email-masked]>
Date: Mon, 6 Apr 2015 15:09:13 +0000

Hi Sue

I agree. Recent L2 control planes have leverage common mechanisms such as routing as well as supporting learning. I think it helps to model based on the generic model with common terms at L2 and L3.

Cheers,
Don

From: i2rs [mailto:[email-masked]] On Behalf Of Susan Hares
Sent: Monday, April 06, 2015 9:46 AM
To: 'Thomas D. Nadeau'
Cc: [email-masked]; 'Alia Atlas'; 'Dongjie (Jimmy)'
Subject: Re: [i2rs] 2 week WG adoption call for draft-dong-i2rs-l2-network-topology-01.txt

Tom:

The L2 draft is a Protocol independent an extension of the generic protocol-independent topology module at layer 2.  Please see draft-clemm-i2rs-yang-network-topo-04<http://datatracker.ietf.org/doc/draft-clemm-i2rs-yang-network-topo/> for details on generic model that points to multiple layers.

Sue  Hares

From: Thomas D. Nadeau [mailto:[email-masked]]
Sent: Monday, April 06, 2015 9:28 AM
To: Susan Hares
Cc: [email-masked]<mailto:[email-masked]>; Dongjie (Jimmy)
Subject: Re: [i2rs] 2 week WG adoption call for draft-dong-i2rs-l2-network-topology-01.txt

On Apr 6, 2015:9:11 AM, at 9:11 AM, Susan Hares <[email-masked]<mailto:[email-masked]>> wrote:

Sue Hares and Jeff Haas

_______________________________________________
i2rs mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/i2rs

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 6 Apr 2015 17:17:50 +0200

>  <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.

There are many other things I do not understand. Why is a chassis-id a
mac-address (and how relates this notion of a chassis to the physical
entity modeling work). How is this going to be implemented? Is the
idea that the information is extracted out of a briding process or do
protocols such as layer two discovery protocols like LLDP play a role
here? In short, I think this model needs some decent IEEE layer two
expertise - so does this really fall into the scope of I2RS?

/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/>

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Mon, 6 Apr 2015 15:31:57 -0400

> On Apr 6, 2015:11:17 AM, at 11:17 AM, Juergen Schoenwaelder <[email-masked]> wrote:
> 

	There has been indication at least, that the IEEE was going to 
embark on this work to reflect the L2/bridge MIB work that went on there.
But as you say, there has been no official liaison to the IETF on this.
Perhaps Dan (CC:ed) knows?

	--Tom

> [email-masked]

---

From: "Susan Hares" <[email-masked]>
Date: Mon, 6 Apr 2015 15:57:29 -0400

Tom:

I'll drop a note to official liaison for IEEE is a good idea, and other IEEE
members of 802.1 I know.  Thank you for that input. 

The I2RS L2 protocol topology is the protocol independent topology.  Just as
Alexander Clemm points out that the L3 topology may be a virtual composite
of either the static setting or a combination of the protocol specific
topologies, the L2 topology is a virtual composite of the lower L2
topologies.  

Sue Hares 

-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of Thomas D. Nadeau
Sent: Monday, April 06, 2015 3:32 PM
To: Juergen Schoenwaelder
Cc: [email-masked]; Romascanu, Dan (Dan); Susan Hares; Dongjie (Jimmy)
Subject: Re: [i2rs] 2 week WG adoption call for
draft-dong-i2rs-l2-network-topology-01.txt

> On Apr 6, 2015:11:17 AM, at 11:17 AM, Juergen Schoenwaelder
<[email-masked]> wrote:
>> 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:
>> 

	--Tom

---

From: Mahesh Jethanandani <[email-masked]>
Date: Mon, 6 Apr 2015 13:09:34 -0700

There is a PAR/CSD making its way through dot1Q to develop YANG models in
that committee. The first of those models is to develop the bridge model.

In addition to IEEE, I would think that the L2 topology work would be
better served in MEF where we are trying to develop service models for L2
services. As a editor of that project, I would love a contribution from the
authors and will support it there.

-- 
Mahesh Jethanandani
[email-masked]

---

From: "Susan Hares" <[email-masked]>
Date: Mon, 6 Apr 2015 16:37:43 -0400

Mahesh: 

Thank you for your input on the MEF L2 Service topologies. 

Just to be clear, the I2RS L2 Topology model is simply a virtual topology model as specified in the I2RS charter.  This virtual topology model provides a link between the Service layer, L3 layer, L2 layer, and the physical topology.  These virtual topologies provide a seamless protocol independent virtual topology that operators may utilize.  

The I2RS virtual topology is not the L2 Bridge configuration and operational status that 802.1 is developing. The I2RS L2 virtual topology needs to align with 802.1 Bridge and operational status work, but it does not provide the configuration and operational state.   

I2RS L2 yang modules that would augment the L2 Bridge configuration and operational state for the I2RS interface are not in charter  The I2RS is not chartered to work on L2 Service topologies.  I also encourage authors to work with you for those MEF L2 Service topologies.  

In interest of rapid advancement of all yang work,  individuals may discuss/get advice for I2RS specific issues for L2 yang modules for these L2 Bridge or MEF L2 Service topologies.  It is great to see the yang work take off. 

Sue 

From: Mahesh Jethanandani [mailto:[email-masked]] 
Sent: Monday, April 06, 2015 4:10 PM
To: Susan Hares
Cc: Thomas D. Nadeau; Juergen Schoenwaelder; [email-masked]; Dongjie (Jimmy); Romascanu, Dan (Dan); Carl Moberg (camoberg)
Subject: Re: [i2rs] 2 week WG adoption call for draft-dong-i2rs-l2-network-topology-01.txt

There is a PAR/CSD making its way through dot1Q to develop YANG models in that committee. The first of those models is to develop the bridge model.

In addition to IEEE, I would think that the L2 topology work would be better served in MEF where we are trying to develop service models for L2 services. As a editor of that project, I would love a contribution from the authors and will support it there.

Tom:

Sue Hares

-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of Thomas D. Nadeau
Sent: Monday, April 06, 2015 3:32 PM
To: Juergen Schoenwaelder
Cc: [email-masked]; Romascanu, Dan (Dan); Susan Hares; Dongjie (Jimmy)
Subject: Re: [i2rs] 2 week WG adoption call for

        --Tom

> Phone: +49 421 200 3587 <tel:%2B49%20421%20200%203587>          Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103 <tel:%2B49%20421%20200%203103>          <http://www.jacobs-university.de/>
>

 

-- 

Mahesh Jethanandani

[email-masked]

---

From: "Shah, Himanshu" <[email-masked]>
Date: Mon, 6 Apr 2015 16:46:54 -0400

I agree with Tom. This work does not seem to applicable to I2RS WG.
At best, it is related to L2VPN WG, now, PALS and BESS.
And in addition, there are other SDOs that are working on this as well.
It would be difficult to unwind the overlap.

/himanshu

-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of Susan Hares
Sent: Monday, April 06, 2015 3:57 PM
To: 'Thomas D. Nadeau'; 'Juergen Schoenwaelder'
Cc: [email-masked]; 'Dongjie (Jimmy)'; 'Romascanu, Dan (Dan)'
Subject: Re: [i2rs] 2 week WG adoption call for draft-dong-i2rs-l2-network-topology-01.txt

Tom:

I'll drop a note to official liaison for IEEE is a good idea, and other IEEE members of 802.1 I know.  Thank you for that input. 

The I2RS L2 protocol topology is the protocol independent topology.  Just as Alexander Clemm points out that the L3 topology may be a virtual composite of either the static setting or a combination of the protocol specific topologies, the L2 topology is a virtual composite of the lower L2 topologies.  

Sue Hares 

-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of Thomas D. Nadeau
Sent: Monday, April 06, 2015 3:32 PM
To: Juergen Schoenwaelder
Cc: [email-masked]; Romascanu, Dan (Dan); Susan Hares; Dongjie (Jimmy)
Subject: Re: [i2rs] 2 week WG adoption call for draft-dong-i2rs-l2-network-topology-01.txt

> liaison interaction here.

	There has been indication at least, that the IEEE was going to embark on this work to reflect the L2/bridge MIB work that went on there.
But as you say, there has been no official liaison to the IETF on this.
Perhaps Dan (CC:ed) knows?

	--Tom

---

From: "Susan Hares" <[email-masked]>
Date: Mon, 6 Apr 2015 17:59:50 -0400

Himanshu: 

Just to make sure I understand your comment, you do not feel an I2RS WG
draft on topology should include a protocol independent virtual topology at
Layer 2.  I will bring this comment to the attention of the Routing AD in
charge of the I2RS work. 

The L2VPN, BESS, IEEE, PALS document are considered protocol specific
topologies - so these are not the same thing (according to Alia Atlas, AD).
The I2RS Working group is not charter to work on these protocol-specific
modules.  

I do agree that TEAS and I2RS carefully need to work through on the Traffic
Engineering topologies and logical topologies.  I am monitoring the design
teams so that we coordinate this portion of the TEAS/I2RS work. 

Sue 

-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of Shah, Himanshu
Sent: Monday, April 06, 2015 4:47 PM
To: Susan Hares; 'Thomas D. Nadeau'; 'Juergen Schoenwaelder'
Cc: [email-masked]; 'Romascanu, Dan (Dan)'; 'Dongjie (Jimmy)'
Subject: Re: [i2rs] 2 week WG adoption call for

/himanshu

-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of Susan Hares
Sent: Monday, April 06, 2015 3:57 PM
To: 'Thomas D. Nadeau'; 'Juergen Schoenwaelder'
Cc: [email-masked]; 'Dongjie (Jimmy)'; 'Romascanu, Dan (Dan)'
Subject: Re: [i2rs] 2 week WG adoption call for

Tom:

Sue Hares 

-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of Thomas D. Nadeau
Sent: Monday, April 06, 2015 3:32 PM
To: Juergen Schoenwaelder
Cc: [email-masked]; Romascanu, Dan (Dan); Susan Hares; Dongjie (Jimmy)
Subject: Re: [i2rs] 2 week WG adoption call for

	--Tom

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 7 Apr 2015 09:30:19 +0200

> topologies, the L2 topology is a virtual composite of the lower L2

Why is a "virtual composite of the lower L2 topologies", needed to
achieve the goals of I2RS?

Since IEEE 802 networks are reasonably common technology, I think a
"virtual composite of the lower L2 topology" should make sure it
represents IEEE 802 topologies well.

/js

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Tue, 7 Apr 2015 09:36:18 +0000

Hi Juergen, 

Thanks for your comments on this L2 topology model. Please see some replies inline.

> From: Juergen Schoenwaelder [mailto:[email-masked]]
> Sent: Monday, April 06, 2015 11:18 PM
> To: Susan Hares
> > 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:
> >
> 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. 

> mac-address (and how relates this notion of a chassis to the physical entity
> modeling work). How is this going to be implemented? Is the idea that the
> information is extracted out of a briding process or do protocols such as layer
> two discovery protocols like LLDP play a role here? In short, I think this model
> needs some decent IEEE layer two expertise - so does this really fall into the
> scope of I2RS?

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.

The information can be extracted from bridging process, LLDP or other sources. This topology model just use the collected information to specify the topology of the layer-2 network, no matter where such information comes from.

As Sue replied, liaison to IEEE is a good idea. While we need to keep in mind that this L2 topology model will not reflect too much details of different L2 technologies. This is similar to the relationship between the L3 topology model and the L3 protocol specific models.

Best regards,
Jie

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 7 Apr 2015 11:44:36 +0200

> 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…

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

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Tue, 7 Apr 2015 10:00:41 +0000

Hi Himanshu,

Thanks for your comments. 

Regarding the relationship between the L2 topology model and L2VPN model, currently this draft treats L2VPN as one approach of building particular connectivity in a L2 topology, and part or all of a L2 topology can also be established using other l2 technologies, e.g. Ethernet, TRILL, L2 overlay etc. Thus in my view the L2VPN model and this L2 topology model are complementary work. Of course we would like to discuss and coordinate with the L2VPN model design team in details of the model.

As for other SDOs working on this, could you provide more information so that we could see whether they are also complementary or there is some overlap? Thanks.

Best regards,
Jie

> From: Shah, Himanshu [mailto:[email-masked]]
> Sent: Tuesday, April 07, 2015 4:47 AM
> Cc: [email-masked]; Dongjie (Jimmy); 'Romascanu, Dan (Dan)'
> Subject: RE: [i2rs] 2 week WG adoption call for
> Alexander Clemm points out that the L3 topology may be a virtual composite of
> either the static setting or a combination of the protocol specific topologies,
> the L2 topology is a virtual composite of the lower L2 topologies.
> 
> Sue Hares
> 
> 	There has been indication at least, that the IEEE was going to embark on
> this work to reflect the L2/bridge MIB work that went on there.

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 7 Apr 2015 09:39:08 -0400

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 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-masked]] On Behalf Of Juergen Schoenwaelder
Sent: Tuesday, April 07, 2015 5:45 AM
To: Dongjie (Jimmy)
Cc: [email-masked]; Susan Hares
Subject: Re: [i2rs] 2 week WG adoption call for

On Tue, Apr 07, 2015 at 09:36:18AM +0000, Dongjie (Jimmy) wrote:
> > From: Juergen Schoenwaelder 
> > [mailto:[email-masked]]
> > 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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 7 Apr 2015 15:46:59 +0200

> comments in the next revision of the draft.

Susan,

multiple overlapping objects marked config true I believe are asking
for trouble. Read-only is a different story but when it comes to
config true objects, I am rather concerned about multiple knobs to
change the same underlying resource without a clear specification how
conflicts are resolved (or whether access control can be bypassed
through such repeated objects).

So let me revise my statement to "taking out all config true objects
that are interface specific".

/js

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 7 Apr 2015 09:55:47 -0400

Juergen: 

Your concern about "multiple overlapping objects marked config true" is
reasonable, but the virtual topology is within the ephemeral I2RS state.  If
L2 changes state, then the ephemeral state is being changed (config true,
ephemeral true) 

The ephemeral I2RS state is a topic which deserves a substantial amount of
discussion on the list.  I will begin another topic on the mail list by
tomorrow  (I want to review all netconf/netmod and mail list discussions
before I start).  However, all the I2RS topology drafts assume the ephemeral
state.  I hope this helps the future part of this discussion. 

Sue 

-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of Juergen Schoenwaelder
Sent: Tuesday, April 07, 2015 9:47 AM
To: Susan Hares
Cc: 'Dongjie (Jimmy)'; [email-masked]
Subject: Re: [i2rs] 2 week WG adoption call for

On Tue, Apr 07, 2015 at 09:39:08AM -0400, Susan Hares wrote:
> 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.

Susan,

multiple overlapping objects marked config true I believe are asking for
trouble. Read-only is a different story but when it comes to config true
objects, I am rather concerned about multiple knobs to change the same
underlying resource without a clear specification how conflicts are resolved
(or whether access control can be bypassed through such repeated objects).

So let me revise my statement to "taking out all config true objects that
are interface specific".

/js

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Tue, 7 Apr 2015 10:17:26 -0400

> On Apr 7, 2015:9:39 AM, at 9:39 AM, Susan Hares <[email-masked]> wrote:
> 
> 
> Juergen: 
> 

	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.

	--Tom

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 7 Apr 2015 10:27:36 -0400

Tom:

Thank you for reminding people of the Entity-MIB Yang Model.  

Sue 

-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of Thomas D. Nadeau
Sent: Tuesday, April 07, 2015 10:17 AM
To: Susan Hares
Cc: Dongjie (Jimmy); Juergen Schoenwaelder; [email-masked]
Subject: Re: [i2rs] 2 week WG adoption call for

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.

	--Tom

> 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
> 
> 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.
>> 
> 
> 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
> 
> --

---

From: Andy Bierman <[email-masked]>
Date: Tue, 7 Apr 2015 10:56:51 -0700

> 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.

We most focused on how to adapt the existing ENTITY MIB modules,
not on missing data that I2RS needs beyond the adapted MIB modules.

>         --Tom

Andy

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Tue, 7 Apr 2015 15:23:20 -0400

> On Apr 7, 2015:1:56 PM, at 1:56 PM, Andy Bierman <[email-masked]> wrote:
> 

	Fantastic and thanks! 

> not on missing data that I2RS needs beyond the adapted MIB modules.

	That is cool. We can add that as we iterate. 

	--Tom

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Wed, 8 Apr 2015 01:55:48 +0000

Hi Tom,

> Sent: Tuesday, April 07, 2015 10:17 PM
> To: Susan Hares
> Cc: Juergen Schoenwaelder; Dongjie (Jimmy); [email-masked]
> 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.
> 
> 	--Tom

Agree that the chassis-related stuff needs to be specified in the entity-mib yang model, and the identifiers used in the topology drafts will sync up with that model.

-Jie