Re: [i2rs] 'network type' placement and RFC8345

[Susan Hares]

Tom: 

This issue is one that I debated with the TEAS group since there are two
options: with teas (length is required) and without teas (length is extra). 

Deborah suggested that CCAMP was the expert. The original authors wanted it
to go to TEAS and CCAMP.   TEAS felt CCAMP and WSON should go under the
TE-Topology.   Since TEAS has control over a great deal of these drafts, the
TEAS won. 

This is not a clear logical reason but perhaps the TEAS people will provide
you with their reasoning. 

The reason I backed off on forcing specific instruction into RFC8345 is that
the debates were still in full discussion mode.   I had hoped we would come
back and add detail later. 

Sue 

-Original Message-
From: i2rs [mailto:i2rs-boun...@ietf.org] On Behalf Of tom petch
Sent: Friday, September 25, 2020 11:58 AM
To: Susan Hares; 'Qin Wu'
Cc: i2rs@ietf.org
Subject: Re: [i2rs] 'network type' placement and RFC8345

From: Susan Hares 
Sent: 25 September 2020 14:10

Tom:

The tree structure in RFC8345 provides links between types at different
layers (service layer, net-layer 3, Layer2, Layer 1).

The choice of whether CCAMP is layer 1 or layer 1-2 is a choice of the IETF
standardizing the group.  Deborah is correct to send you to that group.

Can you provide a little detail on why you thing "CCAMP got it wrong"?


Sue

What I was referring to was placing the definition of the network type for
WSON, for flexi-grid,  for otn-topo, for optical impairment  under
te-topology so that te-topology  becomes a top level node in the tree of
network node like layer 1 or layer 2.  Were WSON under layer 1 or layer 1-2
I would not question it but it seems inconsistent to me to treat te-topology
like layer 1 etc.  To me, that is looking at the classification of network
type in a different dimension to layers, perhaps on the basis of YANG
imports.

I have read and re-read RFC8345 and as I have said, I find it clear that a
presence container must be defined but do not see the guidance as to what
goes under what, apart from OSPF and layer 3.  

A minor consequence is that all the references in the YANG when statements
have an extra element - that is 101 when statements in wson-yang. Longer
term I think we might find a different usage for the tree structure of
network type although I do not see anything in particular at the moment and
having a cluster under te-toplogy might thwart that usage (or of course it
could be spot on:-).

I e-mailed TEAS as the owners of te-topology to see if they saw themselves
as a top level node but have yet to get a reply.  I e-mailed yourself and
I2RS to see if anyone had any more to say about RFC8345, what the thinking
was about the tree structure and how it might be used.

If I got an answer, then my thinking was to raise it as part of IETF Last
Call for wson-yang to see what others thought.  If TEAS or I2RS had strong
views then I would see CCAMP as being likely to fall in with them.

Tom Petch

Sue


-Original Message-
From: tom petch [mailto:ie...@btconnect.com]
Sent: Friday, September 25, 2020 6:31 AM
To: Qin Wu; Sue Hares
Cc: 'i2rs@ietf.org'
Subject: Re: [i2rs] 'network type' placement and RFC8345

From: Qin Wu 
Sent: 24 September 2020 13:17

-邮件原件-
发件人: tom petch [mailto:ie...@btconnect.com]
发送时间: 2020年9月24日 16:45

From: Qin Wu 
Sent: 24 September 2020 03:22

Hi, Tom:
Layer2, Layer 3, TE are all base modules which other modules can extend
from.
I am not sure we have Layer 1 base module, WSON and flexi-grid, if my
understanding is correct, are TE technology specific and WSON and flexi-grid
module can be seem as extension to TE module or a module derived from TE
module Therefore we could follow OSPF example defined in the L3 topology
module or L3 TE module defined in draft-ietf-teas-yang-l3-te-topo-08.


Qin

I think that you are missing the point.
RFC8345 sets up a registry, a namespace, and gives rules about how it should
be used.  The use of a YANG presence container is clearly specified.
What I find unclear in RFC8345 is the intent about tree structure it
describes, what is the criterion for placing e.g. network type 802.3
alongside or below one of the existing network type.
How the different network type YANG modules relate with respect to YANG
import and augment is a different and irrelevant question IMHO.
My thinking is that CCAMP have got it wrong and that their network types
should be alongside existing types, that there is nothing in RFC8345 to
suggest that they should be subordinate to anything else.
Since they are presence containers I see nothing in YANG that would make a
tree structure anything other than more complicated with a longer path to
reference them bringing no benefit.

Tom Petch

"
   module: ietf-l3-te-topology
 augment /nw:networks/nw:network/nw:network-types
   /l3t:l3-unicast-topology:
   +--rw l3-te!
"
"
   module example-ospf-topology
   augment
"/nw:networks/nw:network/nw:network-types/l3t:l3-unica

Re: [i2rs] 'network type' placement and RFC8345

[Susan Hares]

Tom:

The tree structure in RFC8345 provides links between types at different
layers (service layer, net-layer 3, Layer2, Layer 1). 

The choice of whether CCAMP is layer 1 or layer 1-2 is a choice of the IETF
standardizing the group.  Deborah is correct to send you to that group. 

Can you provide a little detail on why you thing "CCAMP got it wrong"?  

Sue 

 
-Original Message-
From: tom petch [mailto:ie...@btconnect.com] 
Sent: Friday, September 25, 2020 6:31 AM
To: Qin Wu; Sue Hares
Cc: 'i2rs@ietf.org'
Subject: Re: [i2rs] 'network type' placement and RFC8345

From: Qin Wu 
Sent: 24 September 2020 13:17

-邮件原件-
发件人: tom petch [mailto:ie...@btconnect.com]
发送时间: 2020年9月24日 16:45

From: Qin Wu 
Sent: 24 September 2020 03:22

Hi, Tom:
Layer2, Layer 3, TE are all base modules which other modules can extend
from.
I am not sure we have Layer 1 base module, WSON and flexi-grid, if my
understanding is correct, are TE technology specific and WSON and flexi-grid
module can be seem as extension to TE module or a module derived from TE
module Therefore we could follow OSPF example defined in the L3 topology
module or L3 TE module defined in draft-ietf-teas-yang-l3-te-topo-08.


Qin

I think that you are missing the point.
RFC8345 sets up a registry, a namespace, and gives rules about how it should
be used.  The use of a YANG presence container is clearly specified.
What I find unclear in RFC8345 is the intent about tree structure it
describes, what is the criterion for placing e.g. network type 802.3
alongside or below one of the existing network type.
How the different network type YANG modules relate with respect to YANG
import and augment is a different and irrelevant question IMHO.
My thinking is that CCAMP have got it wrong and that their network types
should be alongside existing types, that there is nothing in RFC8345 to
suggest that they should be subordinate to anything else.
Since they are presence containers I see nothing in YANG that would make a
tree structure anything other than more complicated with a longer path to
reference them bringing no benefit.

Tom Petch

"
   module: ietf-l3-te-topology
 augment /nw:networks/nw:network/nw:network-types
   /l3t:l3-unicast-topology:
   +--rw l3-te!
"
"
   module example-ospf-topology
   augment
"/nw:networks/nw:network/nw:network-types/l3t:l3-unicast-topology"
   +--rw ospf!
"
I might be wrong if a generic layer 1 can be defined without adding
dependency to TE technology. But at least layer 1 type or layer 0 type are
common building block that can be reused.

In addition, base model, in my opinion doesn't need to limit to layer 1,
layer 2, layer 3, service layer, TE layer this angle, we may classify
network topology from other angle, e.g., classify network topology into UNI
topology and NNI topology, One relevant model is UNI topology model that is
proposed in the opsawg
https://tools.ietf.org/html/draft-ogondio-opsawg-uni-topology-01
such models are also base model which other modules can derive from.

For network type, if we can define it as identity, it may be another design
option.
But comparing with presence container design, I think the only difference is
one is explicit way, the other is implicit way.


Qin
My starting point is RFC8345 which for me creates this 'registry' of network
type and lays down the ground rules.  It says that a presence container must
be defined.  Why not identity, as with routing protocols, I do not know.  It
suggests a tree structure and is generally keen on a layered network as in
layer 1, layer 2, layer 3, application-related layers and so on which is
fine until you get to sub-IP.

But, network layering has nothing to do with YANG modules, with imports,
cross-references, dependencies and so on so the fact that the wson module
augments te-topo seems an irrelevance where the tree structure of layers is
concerned.  There are lots of augments to te-topo and they could be any
layer.

[Qin]: we can have ietf-l3-te-topology module augment to layer 3, but we
don't have l3 specific module augment to te module, see
draft-ietf-teas-yang-l3-te-topo-08.
I will not see ietf-te-topology-packet as l3 specific module augment to te
module. But may be a little bit fuzzy.
For ccamp modules which are classified into layer 0,layer1 and married with
te technology, I feel nature they augment from te module, but not other
layer module. That's my impression. But I might be wrong.

RFC8345 says a lot but I do not understand what it is saying when it comes
to adding a network type beyond what it says about presence container.  What
is the point of the tree structure therein?
[Qin]: The question is whether there are any layer0, layer 2 modules without
marriage with TE technology?

 Is it something we want or need to embody in YANG so that we can do
something fancy as we can elsewhere with base identity and derivations
therefrom as with routing protocols?

I do not know so my inclination is to say that the 

Re: [i2rs] Robert Wilton's No Objection on draft-ietf-i2rs-yang-l2-network-topology-18: (with COMMENT)

[Susan Hares]

Rob and other IESG members: 

Should we wait for an IEEE official position or can we continue with 
standardization?  I think the informal review will be the most substantive. 

Sue Hares

-Original Message-
From: Robert Wilton via Datatracker [mailto:nore...@ietf.org] 
Sent: Thursday, September 17, 2020 12:51 PM
To: The IESG
Cc: draft-ietf-i2rs-yang-l2-network-topol...@ietf.org; i2rs-cha...@ietf.org; 
i2rs@ietf.org
Subject: Robert Wilton's No Objection on 
draft-ietf-i2rs-yang-l2-network-topology-18: (with COMMENT)

Robert Wilton has entered the following ballot position for
draft-ietf-i2rs-yang-l2-network-topology-18: No Objection

When responding, please keep the subject line intact and reply to all email 
addresses included in the To and CC lines. (Feel free to cut this introductory 
paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-l2-network-topology/



--
COMMENT:
--

Clearing discuss held for IEEE review:

The IEEE Yangsters (members of the IEEE YANG experts) who reviewed and 
contributed review comments to this draft are comfortable with version -18. 
Note, that these represent informal reviews of individuals and do not represent 
a formal IEEE consensus position."

Regards,
Rob

Mostly minor/editorial comments  (###) on the YANG model, but I do think that 
it would be helpful for these to be discussed and addressed as appropriate:

4.  Layer 2 Topology YANG Module

 import ietf-inet-types {
   prefix inet;
   reference
 "Section 4 of RFC 6991";
 }
 import ietf-yang-types {
   prefix yang;
   reference
 "Section 3 of RFC 6991";
 }

###
These references should probably both just be: "RFC 6991: Common YANG Data 
Types"

 revision 2020-06-29 {
   description
 "Initial revision";
   reference
 "RFC : A YANG Data Model for Layer 2 Network
Topologies";
 }

###
I would reorder these sections to be (which will solve the forward reference 
issue mentioned by Ben):
   feature-stmt
   identity-stmt
   typedef-stmt

I'm surprised that pyang didn't flag this.

 /*
  * Typedefs
  */

 typedef vni {
   type uint32 {
 range "0..16777215";
   }
   description
 "VXLAN Network Identifier or VXLAN Segment ID.
  It allows up to 16 M VXLAN segments to coexist
  within the same administrative domain.

  The use of value '0' is implementation-specific.";
   reference
 "RFC 7348: Virtual eXtensible Local Area  Network (VXLAN):
A Framework for Overlaying Virtualized Layer 2
Networks over Layer 3 Networks";
 }

 typedef l2-flag-type {
   type identityref {
 base flag-identity;
   }
   description
 "Base type for L2 flags. One example of L2 flag
  type is trill which represents trill topology
  type.";
 }

###
This isn't really a base type.  Given where this flag is used, would this be 
better as an "network-flag-type", with a description more similar to the ones 
below?

 typedef node-flag-type {
   type identityref {
 base flag-identity;
   }
   description
 "Node flag attributes. The physical node can be
  one example of node flag attribute.";
 }

 typedef link-flag-type {
   type identityref {
 base flag-identity;
   }
   description
 "Link flag attributes. One example of link flag
  attribute is the pseudowire.";
 }

###
Should there be identities defined for l2-flag, node-flag and link-flag that 
derive from flag-identity?  That would them make these three typedefs reference 
different things rather than all referencing the same base flags.

 typedef l2-network-event-type {
   type enumeration {
 enum add {
   value 0;
   description
 "A Layer 2 node or link or termination-point
  has been added.";
 }
 enum remove {
   value 1;
   description
 "A Layer 2 node or link or termination-point
  has been removed.";
 }
 enum update {
   value 2;
   description
 "A Layer 2 node or link or termination-point
  has been updated.";
 }
   }
   description
 "Layer 2 network event type for notifications.";
 }

###
Since these are events, I would suggest renaming these "add" -> "addition", 
"remove" -> "removal", "update"

 typedef neg-mode {
   type enumeration {
 enum full-duplex {
  

[i2rs] Feedback from

[Susan Hares]

What is the feedback from IEEE for the I2rs Layer 2 model? 

 

Cheerily, Susan Hares 

___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

Re: [i2rs] EXTERNAL: RE: Mail regarding draft-ietf-i2rs-yang-l2-network-topology

[Susan Hares]

Stephen: 

 

I’m sure Qin will also provide you answers to your questions regarding your 
questions about specific implementation details on the L2 models.  

 

However, as the shepherd and co-chair of I2RS – let me provide a bit of 
high-level background.  The use cases were data that provide the ideas that the 
WG gathered on what the WC could do.

 

The I2RS movement forward was stymied by the length of time it took to move the 
NETCONF/NETMOD working groups toward the  NMDA architecture (2018/2019).  Many 
of the Topology models were implemented by open daylight as of 2014 and most of 
the I2RS models were adopted by 2015.  This slowness in the basic topology 
caused the WG to be put in hiatus by AD in 2015 (Alia Atlas) and our 
instructions were to finish our current models without additional 
functionality.IETF has a mantra of running code. 

 

The L3 models because the base for TEAS work, L2SM, and L3SM concepts.   The 
SLRG issues at layer 3 were concepts that have been picked up by the TEAS at 
layer 3.   RFC8776 defines SLRG data types in preparation for 
draft-ietf-teas-yang-te-topo-22.txt  which has been approved for publication.   
Please see the te-link-info-attributes container in 
draft-teas-yang-te-topo-22.txt for the SLRG objects. 

 

The layer 2 work awaited implementation models and work from IEEE 802.1 for 
802.1Q updates.  As the Yang models which currently are available which seem to 
relate are:  ieee-dot1q-bridge-yang.txt, ieee802-dotq-tpmr.yang.txt, and 
ieee-dot1x.yang.txt.   These models release in 2018 seems to have implementers 
going.  

(Recall IETF looks for implementation of models to verify the NM/OPS). 
Implementations were completed for the L2 topology model in 2018-2019.   

 

The L2 topology model is a virtual data model for NM/OPS aligned with IETF 
focus on NM/OPS using Yang models.  (See Open Daylight for implementations 
using topology models).   IETF topology models differ from IEEE models in that 
we seek interoperability based on common use.  As such, we may be modeling 
things (such as the sys-management-mac) which are common industry practices 
beyond the IEEE models.  My question to IEEE-IETF interface committee asked 
about common practices for the system management interface which were not 
standardizes (as far as I could tell) in the IEEE 802.1 Yang models. 

 

A great deal of Yang work was completed for the IEEE 802.1Q work.  It seems 
appropriate that the virtual topology work for IETF NM/OPS would be aligned 
with the IEEE 802.1Q part for TSN  (time sensitive networking).  

It may be appropriate for I2RS to pick up the L2 topology work again.  

 

One other document that may be of interest to you is the 

 draft-ietf-netmod-sub-intf-vlan-model-07 

  that create a sub-interface. 

 

If you know of additional IEEE yang models that we should have considered, 
please send email to the I2rs WG. 

 

I have answered your specific question below.  Qin will add more details. 

 

Sue 

 

From: i2rs [mailto:i2rs-boun...@ietf.org] On Behalf Of Stephen Cheng
Sent: Tuesday, July 14, 2020 12:06 AM
To: Qin Wu; i2rs@ietf.org; draft-ietf-i2rs-yang-l2-network-topol...@ietf.org
Cc: Dongjie (Jimmy)
Subject: Re: [i2rs] EXTERNAL: RE: Mail regarding 
draft-ietf-i2rs-yang-l2-network-topology

 

Further to last email, I am going through the use cases defined in 
https://tools.ietf.org/pdf/draft-ietf-i2rs-usecase-reqs-summary-03.pdf, to 
determine the topology use cases related to Layer 2 topology. This document is 
referred to in your draft in section 1 “Further use cases where the data model 
can be applied are described in [I2RS-UR].”

 

If you  think these are useful documents, I can work to send this document 
through the IETF publication process.  These were interim documents to help the 
WG. 

 

Topo-REQ-03 (IC): Topology Manager should be able to collect and keep current 
topology information for multiple layers of the network: Transport, Ethernet 
and IP/MPLS, as well as information for multiple Layer 3 IGP areas and multiple 
Autonomous Systems (ASes). This information must contain cross-layer unerlying 
Shared Risk Link Groups (SRLG) within transport or Ethernet layers. (from 
section 3.2)

[SC] Is SRLG supported in draft-ietf-i2rs-yang-l2-network-topology?

 

Yes – The intent of the L2 network model is to align with appropriate IEEE 
models, draft-teas-yang-te-topo-22.txt, and 
draft-ietf-netmod-sub-intf-vlan-model-07 

 .  Qin, his co-authors and I would like to receive any comments regarding the 
alignment.  We have decided to release the L2 topology document based on the 
current state of implementations.  If you feel we should include additional 
work for SLRG, it could be put in an augmentation model.  

 

VT-TDM-REQ6 (IC): The topology model should allow association between 

Re: [i2rs] Robert Wilton's Discuss on draft-ietf-i2rs-yang-l2-network-topology-14: (with DISCUSS and COMMENT)

[Susan Hares]

Rob:

Thank you for raising the process discussion regarding IEEE-IETF
coordination.   Qin, his co-authors, and I desire to have a model which uses
the best common practices of the IEEE and IETF. 

Qin and his co-authors will work through all the specific description
changes below and the auto-neg description in his responses.  We were
pointed to draft-ietf-netmod-sub-intf-vlan-model and worked to adjust to
this model.  Specific suggestions for changes would be helpful at this
point. 

I have the following two higher level questions as the shepherd/co-chair: 

1) This document was repeated reviewed by the Yang doctors prior to
submission.   

We were pointed to draft-ietf-netmod-sub-intf-vlan-model and worked to
adjust to this model.

What happened in the process of Yang model review that caused you to have so
many comments at the last moment?   Where did we miss the clues that there
were problems in the email from the Yang doctors? 

2) Policy questions regarding IEEE and IETF focus on QinQ versus VLAN 

I have one question for you and the rest of the IESG.  The IEEE terminology
for QinQ versus VLAN does not always match the industry use.   IETF has
always maintained running code for operational networks is the most
important factor.  IEEE has maintained consistency of their own terminology
was most important.  These differences cause the switches two have both
terminologies.  How should we support both? 

Susan Hares 

-Original Message-
From: i2rs [mailto:i2rs-boun...@ietf.org] On Behalf Of Robert Wilton via
Datatracker
Sent: Thursday, July 9, 2020 8:13 AM
To: The IESG
Cc: draft-ietf-i2rs-yang-l2-network-topol...@ietf.org; i2rs@ietf.org;
i2rs-cha...@ietf.org
Subject: [i2rs] Robert Wilton's Discuss on
draft-ietf-i2rs-yang-l2-network-topology-14: (with DISCUSS and COMMENT)

Robert Wilton has entered the following ballot position for
draft-ietf-i2rs-yang-l2-network-topology-14: Discuss

When responding, please keep the subject line intact and reply to all email
addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-l2-network-topology/



--
DISCUSS:
--

I support Magnus's discuss regarding IEEE 802.1Q WG review.

I also feel that the YANG model could benefit from another editorial pass:
 - In many places the descriptions are very terse, and references are
missing.
 - The way that auto-neg is defined doesn't really match the 802.3
specification, probably splitting it into two separate leaves (one for
whether  auto-neg is on/off, and separate one for the duplex setting would
be better).
 - The use of terminology for VLAN vs QinQ might not be acceptable to IEEE. 
 Finding names that are more closely aligned with the terms in 802.1Q may be
helpful (although if I understand it correctly, 802.1Q bridges don't
directly  expose double VLAN tags).  Possibly some of the
terminology/description from  draft-ietf-netmod-sub-intf-vlan-model (which
has been reviewed by IEEE 802.1Q
 WG) may be helpful here.


--
COMMENT:
--

Mostly minor/editorial comments  (###) on the YANG model, but I do think
that it would be helpful for these to be discussed and addressed as
appropriate:

4.  Layer 2 Topology YANG Module

 import ietf-inet-types {
   prefix inet;
   reference
 "Section 4 of RFC 6991";
 }
 import ietf-yang-types {
   prefix yang;
   reference
 "Section 3 of RFC 6991";
 }

###
These references should probably both just be: "RFC 6991: Common YANG Data
Types"

 revision 2020-06-29 {
   description
 "Initial revision";
   reference
 "RFC : A YANG Data Model for Layer 2 Network
Topologies";
 }

###
I would reorder these sections to be (which will solve the forward reference
issue mentioned by Ben):
   feature-stmt
   identity-stmt
   typedef-stmt

I'm surprised that pyang didn't flag this.

 /*
  * Typedefs
  */

 typedef vni {
   type uint32 {
 range "0..16777215";
   }
   description
 "VXLAN Network Identifier or VXLAN Segment ID.
  It allows up to 16 M VXLAN segments to coexist
  within the same administrative domain.

  The use of value '0' is implementation-specific.";
   reference
 "RFC 7348: Virtual eXtensible Local Area  Network (VXLAN):
A Framework for Overla

Re: [i2rs] Magnus Westerlund's Discuss on draft-ietf-i2rs-yang-l2-network-topology-14: (with DISCUSS)

[Susan Hares]

Magnus: 

Thank you for raising this process discuss.  

The authors and I strong desire the I2RS model to be a NM management model that 
imports the appropriate things from IEEE. 

I have two points you should add to your process discuss: 

1) Where did the coordination instructions change for the WG chair? 

In the midst of the discussion within the IESG would you please consider how to 
provide better instructions for the lowly chair and authors on this topic.   In 
the past, the IESG sent information to IEEE-IETF.(I was scribe during the 
first meeting of the IETF-IESG over the TRILL issue).   I was the TRILL chair 
for the last years of the TRILL WGs life.   I have participated in the IEEE 
802.1 and IETF during the TRILL issue when we were trying to resolve a common 
management for TRILL between IEEE and IETF.   During that time, it was 
important that a few focused voices discussed issues regarding TRILL.  It would 
help me to understand when this transitioned to chairs being able to send 
requests to the IEEE-IETF coordination list.  

We also asked for numerous reviews by Yang Doctors who were knowledgeable 
regarding IETF.  I delayed publication request several times until it appeared 
all issues were resolved.   This "sudden" surprise is indeed amazing since the 
L2 is 5 years old.  It is older than the 8021Qcp-2018 official models.   


2) Why are I2RS topology models are not seen as Network Management by the IEEE. 

These are virtual topology models used by open source platforms for management. 
 (E.g. Open Daylight). 

Sue  

-Original Message-
From: Magnus Westerlund via Datatracker [mailto:nore...@ietf.org] 
Sent: Thursday, July 9, 2020 7:44 AM
To: The IESG
Cc: draft-ietf-i2rs-yang-l2-network-topol...@ietf.org; i2rs-cha...@ietf.org; 
i2rs@ietf.org
Subject: Magnus Westerlund's Discuss on 
draft-ietf-i2rs-yang-l2-network-topology-14: (with DISCUSS)

Magnus Westerlund has entered the following ballot position for
draft-ietf-i2rs-yang-l2-network-topology-14: Discuss

When responding, please keep the subject line intact and reply to all email 
addresses included in the To and CC lines. (Feel free to cut this introductory 
paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-l2-network-topology/



--
DISCUSS:
--

This is a process discuss.

There apparently have been a failure to coordinate this with IEEE per 
discussion on the IETF-IEEE mailing list.

Glenn Parsons requested that this was deferred to give IEEE time to review it 
at their plenary next week. I think this time should be given before approving 
this document.






___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

Re: [i2rs] Éric Vyncke's No Objection on draft-ietf-i2rs-yang-l2-network-topology-14: (with COMMENT)

[Susan Hares]

Eric and Martin: 

I have received email back from Glenn Parsons regarding the sys-mac-address - 
who is in charge of the IEEE Yang modules for TSN PAR (time sensitive network). 

The email started with a rant regarding the lack of coordination over this 
model occurring at the last minute, and 
a request to delay final review of this model until the july 20th IEEE 802.1 
meeting.   Since the first WG publication of 
draft-ietf-i2rs-yang-l2-network-topology-00.txt  in 2015 predates the IEEE 
802.1 Yang models for the bridge, it seems any coordination for the last 5 
years regarding this model has gone to /dev/null.  

In order to keep harmonious working between IEEE 802.1 and IETF for this I2RS 
model,  it may be necessary for this review and delay to occur.   Qin, his 
co-authors, and I have repeatedly tried to make sure this coordination has 
occurred.  We have received "acks" from internal IETF sources that were 
supposedly knowledgeable. 

I recommend that you and Martin communicate with Glenn Parsons in order to 
foster a good review.  Since the virtual models of I2RS for IETF NM are not 
well understood in the IESG,  you may need my help or members of the I2RS WG to 
help explain the basic concept of the I2RS Virtual models.  

By the way, Glenn did not provide any new data on the sys-mac-address concept.  

Sue 

-Original Message-
From: Eric Vyncke (evyncke) [mailto:evyn...@cisco.com] 
Sent: Thursday, July 9, 2020 4:33 AM
To: Qin Wu; Susan Hares; 'Eric Vyncke (evyncke)'; 'The IESG'
Cc: draft-ietf-i2rs-yang-l2-network-topol...@ietf.org; i2rs@ietf.org; 
i2rs-cha...@ietf.org
Subject: Re: [i2rs] Éric Vyncke's No Objection on 
draft-ietf-i2rs-yang-l2-network-topology-14: (with COMMENT)

Qin,

Honestly, I do not mind too much about "system-mac-address" (and the LLDP was 
just an example) but per symmetry with other leaves, adding a 
'management-mac-address' could be useful. But, again, I do not mind too much.

About the link rate... whether it is Sigfox or other data link does not really 
mater but I keep wondering why not having a minimum lower than 10 kbps is such 
a problem for the authors/WG... Why not simply augment the number of decimals 
on this leaf ? It is a decimal64 and by looking at RFC 6020 section 9.3.4 is 
seems that even using 3 decimals for Mbps (or simply using rate in kbps) will 
not limit the upper rate. 

In short, I am still really puzzled why this lower bound on rate is in the 
model.

-éric



-Original Message-
From: iesg  on behalf of Qin Wu 
Date: Thursday, 9 July 2020 at 08:40
To: Susan Hares , "'Eric Vyncke (evyncke)'" 
, 'The IESG' 
Cc: "draft-ietf-i2rs-yang-l2-network-topol...@ietf.org" 
, "i2rs@ietf.org" 
, "i2rs-cha...@ietf.org" 
Subject: RE: [i2rs]  Éric Vyncke's No Objection on 
draft-ietf-i2rs-yang-l2-network-topology-14: (with COMMENT)

Hi, Eric：
Sorry for late reply, your question on wireless is difficult to me,:-)
Regarding Key editorial additions:
Sure, we should replace CRC with RCS and fix inconsistency on L2 vs Layer 2.
Regarding key technical changes:
I think system-mac-address will be used for sending LLDP frames, we don't 
need another management MAC address, maybe we use different terminology to talk 
about the same thing.
As for speeds for IoT and wireless,
I am using figure 1 in draft-ietf-lpwan-schc-over-sigfox as an example, I 
still believe we should not model the link between Device and Sigfox BS (RG) in 
the Layer 2 network topology, bear in mind, L2 topo focuses network side 
topology.
see reference 
https://www.ietf.org/id/draft-ietf-lpwan-schc-over-sigfox-02.txt
Do you think the link speed of wired line between Sigfox BS and Sigfox 
network should be less than 10 kbps? No?
Anyway if the wireless can benefit from L2 topology, I hope it could take 
augmentation approach.

-Qin
-邮件原件-
发件人: Susan Hares [mailto:sha...@ndzh.com] 
发送时间: 2020年7月7日 22:20
收件人: 'Eric Vyncke (evyncke)' ; Qin Wu 
; 'The IESG' 
抄送: draft-ietf-i2rs-yang-l2-network-topol...@ietf.org; i2rs@ietf.org; 
i2rs-cha...@ietf.org
主题: RE: [i2rs] Éric Vyncke's No Objection on 
draft-ietf-i2rs-yang-l2-network-topology-14: (with COMMENT)

Eric: 

Another round of comments are below.   

As to the  IEEE review, this goes through the IETF-IEEE liaison. I'm 
happy to have this yang model reviewed by the IEEE liaison is in 2020.   Qin's 
review occurred late 2019.  I'm unclear who the 2020 liaison is from IETF to 
IEEE.  Asking specifically about the Ethernet is useful.  Martin/Alvaro/Deborah 
may know who to ask. 

FCS is a more generic term.  I'm sure that Qin will agree to utilize this 
term. 
Qin response may come in 2-3 hours. 

More comments below to your questions.   [Sue2] indicates the next round of 
answers. 

Key editorial additions: 
1) FCS replacing CRC
2) Inconsistent use of L2 versus 

Re: [i2rs] Benjamin Kaduk's No Objection on draft-ietf-i2rs-yang-l2-network-topology-14: (with COMMENT)

[Susan Hares]

Ben: 

Following up on my earlier mail regarding the investigation comments: 

1)  System management MAC port - 

The 802.1Q-2018 is the latest full specification 

https://1.ieee802.org/yang-modules/
http://ieee802.org/1/files/public/YANGs/ieee802-dot1q-bridge.yang - provides
the yang modules

in this module there is a container Bridge with the bridge configuration.
In this container there is a MAC address, but I do not find a clear
specification of system-mac or the management mac.  I will ask the IEEE-IETF
liaison group to provide me with the appropriate specification to validate
the current and future handling of system macs. 

It may be an vendor specific augmentation to the IEEE model.  If so, these
additions would still be needed by the L2 topology model which is looking to
have an interoperable L2 view of the network. 

2) "other state" in the termination point 

The states of the termination port of "in  use", "blocking",  "down", and
"others" concepts 802.1Q Yang models to a simplistic view of the port.  

The concepts of "other" as a mentioned below come from anticipation in 2016
of work for time sensitive network (TSN) task group.  The TSN work could
cause the port as a logical termination point to have something besides "in
use", "block frames", and "down".  Therefore, we added a state "other" to
allow the model to indicate one of the other concepts.   

The TSN specifications that lead us to this conclusion are the following:
P802F (yang module for Ether Types),  802.1Qcw (yang data models for
schedule traffic, frame preemption, and per-stream filtering/policing),
802.1Qdj (configuration enhancements for TSN),  802.1ABcu (LLDP Yang Data
model), and 802.1CBcv (Frame Replication and Elimination) model

In the future after the Yang models of the IEEE for TSN are specified and
approved, a revision of this I2RS model could specify a simplification of
the TSN functioning into 1 or more specific states.   


Summary: 
Item 1 - management-address  for process that is 

leaf-list management-address {
   type inet:ip-address;
   description
 "System management address.";
 }
 leaf sys-mac-address {
   type yang:mac-address;
   description
 "System MAC address.";
 }

I'm still trying to correlate this with the Bridge model in 802.1Q or 


Item 2 - completed research and "other" is placeholder for Time sensitive
network (TSN) work in 802.1. 
This correlates to detnet work. 

Cheerily, Sue 

-Original Message-
From: Susan Hares [mailto:sha...@ndzh.com] 
Sent: Wednesday, July 8, 2020 11:14 AM
To: 'Benjamin Kaduk'; 'The IESG'
Cc: draft-ietf-i2rs-yang-l2-network-topol...@ietf.org; i2rs@ietf.org;
i2rs-cha...@ietf.org
Subject: RE: [i2rs] Benjamin Kaduk's No Objection on
draft-ietf-i2rs-yang-l2-network-topology-14: (with COMMENT)

Benjamin: 

I'm sorry I missed this email until today.I do not think Qin has
answered your questions.   

Issues we believe are settled
==
1) VXLAN - value of zero.
   We believe Yang Doctors have indicated our method is correct. 
   Rob Wilton is the best judge among IESG for this issue. 

2) Network topology models and links - please see RFC 8345 

Issues which need investigation with IEEE/IETF liaison and industry use
===
1) System management  IP address -  We believe that a single system
management is the correct basic functionality. 
  
Additional system management ports would be an augmentation of a model by a
vendor.  If this does not match the current hardware technology, the authors
can change to indicate a list of multiple system management ports.
Advice is needed from switch vendors on the basic.   I have sent a request
to the yang doctors.   Rob Wilton can provide feedback for the IESG if I
do not get Yang Doctors response quickly. 

2) What "others" states might be added in the future?
  
 802.1 has been adding some other states to ports for ACTIVE-ACTIVE
fail-over and for highly deterministic L2 paths for video (~IETF detnet).
I need to check when these "other states" have been defined by IEEE 802.1,
and when these new "other" states might be deployed in new switch devices.
If the new states are in devices, we will need to add them to this model
following the 802.1 definitions.   As a shepherd, I had not check upon
these in the last 2 years.  I have concern about putting  these states in
a model unless we have implementations that will use these states.   The
normal way to add these states is with an augmentation for the model.   

Good catch - I should have re-examined the IEEE work and current technology
in the last few weeks. 

3) Normative and informative choices - Authors will abide by IESG and IEEE
recommendations The authors will abide by IES

Re: [i2rs] [yang-doctors] draft-ietf-i2rs-yang-l2-network-topology

[Susan Hares]

Reshad: 

 

Ah.. thank you for clarifying the questions.   

 

The IP addresses are treated as attributes for the port node.  My understanding 
is that these attributes help store information if the yang model is used 
stand-alone without the network layer model.  Of course, smart implementations 
will internally validate these values. 

 

Sue   

 

From: Reshad Rahman (rrahman) [mailto:rrah...@cisco.com] 
Sent: Wednesday, July 8, 2020 12:20 PM
To: Susan Hares; yang-doct...@ietf.org; i2rs@ietf.org
Cc: martin.vigour...@nokia.com; 'Benjamin Kaduk'
Subject: Re: [yang-doctors] draft-ietf-i2rs-yang-l2-network-topology

 

Thanks Sue. I wasn’t questioning the need for multiple IP addresses, I just 
found it odd to have IP address(es) in an L2 grouping.

 

Regards,

Reshad.

 

From: Susan Hares 
Date: Wednesday, July 8, 2020 at 12:16 PM
To: "Reshad Rahman (rrahman)" , "yang-doct...@ietf.org" 
, "i2rs@ietf.org" 
Cc: "martin.vigour...@nokia.com" , 'Benjamin Kaduk' 

Subject: RE: [yang-doctors] draft-ietf-i2rs-yang-l2-network-topology

 

Reshad: 

 

Juregen indicates my questions are not for IETF but for IEEE, and that multiple 
system-macs may be implemented as a list.   

 

I’m looking at the IEEE  yang model for 802-1Qcp (2018 update to IEEE 802.1Q), 
but you can get the pre-release draft at (only editorial nits are missing) at: 

 

http://www.ieee802.org/1/files/private/cp-drafts/d2/802-1Qcp-d2-2.pdf

 

The reason there are multiple IP addresses is that the single LAN can have 
multiple IP addresses assigned to it.   

In may routers/switches the single MAC port will have multiple virtual ports.  
(cisco started this concept in the 1990s). 

 

Thanks for the help! 

 

Sue 

 

From: Reshad Rahman (rrahman) [mailto:rrah...@cisco.com] 
Sent: Wednesday, July 8, 2020 12:09 PM
To: Susan Hares; yang-doct...@ietf.org; i2rs@ietf.org
Cc: martin.vigour...@nokia.com; 'Benjamin Kaduk'
Subject: Re: [yang-doctors] draft-ietf-i2rs-yang-l2-network-topology

 

Hi,

 

I was referring to management-address leaf-list in the same grouping (see 
below).

 

I don’t have the expertise to answer your questions below, maybe some YDs do.

 

Regards,

Reshad.

 

 grouping l2-node-attributes {

   description

 "L2 node attributes";

   container l2-node-attributes {

 description

   "Contains L2 node attributes.";



 leaf-list management-address {

   type inet:ip-address;

   description

 "System management address.";

 }

 leaf sys-mac-address {

   type yang:mac-address;

   description

     "System MAC address.";

 }

 

 

From: Susan Hares 
Date: Wednesday, July 8, 2020 at 11:48 AM
To: "Reshad Rahman (rrahman)" , "yang-doct...@ietf.org" 
, "i2rs@ietf.org" 
Cc: "martin.vigour...@nokia.com" , 'Benjamin Kaduk' 

Subject: RE: [yang-doctors] draft-ietf-i2rs-yang-l2-network-topology

 

Reshad: 

 

Thank you for quick response.   However, I’m confused.   Where do you see the 
IP address in the Yang snippet I sent?  It is a MAC Address (type 
yang:mac-address)?  If the system port allows IP, it will respond to the ARP 
request with the appropriate IP/MAC match in an ARP reply.   

 

In real implementations I2rs implementers examined, 

*   L2 port with mgmt-mac-address seems to be used to only send LLDP 
packets, 
*   L2 port with sys-mac-address seems to be used for management using 
TCP/IP.  

 

If we swap the names, it did not work with the initial implementers of the yang 
model.  The  I2RS Topology models are used for operational management of 
switches and routers as logical units. 

 

Also, your response does not seem to match my questions: 

 

1) Is this the normal assumption for yang models? 

2) If not, what is the normal assumption on system mac addresses? 

3) Am I correct that switches with more than 1 system MAC will augment their 
basic yang model with the second system MAC Address? 

 

I’m sorry to bother you but this document is being reviewed by the IESG  
tomorrow (Thursday) and 

I am the shepherd.  I do not know how to answer some of the yang related 
questions regarding multiple system ports to exchange management configuration 
on.  

 

I had thought that netconf/restconf would be exchanged over the same ports so 
the yang doctors would know what the normal custom should be. 

 

Thanks again! 

 

Sue  

 

 

 

 

 

 

 

 

From: Reshad Rahman (rrahman) [mailto:rrah...@cisco.com] 
Sent: Wednesday, July 8, 2020 11:27 AM
To: Susan Hares; yang-doct...@ietf.org; i2rs@ietf.org
Cc: martin.vigour...@nokia.com; 'Benjamin Kaduk'
Subject: Re: [yang-doctors] draft-ietf-i2rs-yang-l2-network-topology

 

Hi,

 

So sys-mac-address is supposed to be the MAC address of the mgmt port, i.e. the 
device would respond to an ARP request for management-address

Re: [i2rs] [yang-doctors] draft-ietf-i2rs-yang-l2-network-topology

[Susan Hares]

Reshad: 

 

Juregen indicates my questions are not for IETF but for IEEE, and that multiple 
system-macs may be implemented as a list.   

 

I’m looking at the IEEE  yang model for 802-1Qcp (2018 update to IEEE 802.1Q), 
but you can get the pre-release draft at (only editorial nits are missing) at: 

 

http://www.ieee802.org/1/files/private/cp-drafts/d2/802-1Qcp-d2-2.pdf

 

The reason there are multiple IP addresses is that the single LAN can have 
multiple IP addresses assigned to it.   

In may routers/switches the single MAC port will have multiple virtual ports.  
(cisco started this concept in the 1990s). 

 

Thanks for the help! 

 

Sue 

 

From: Reshad Rahman (rrahman) [mailto:rrah...@cisco.com] 
Sent: Wednesday, July 8, 2020 12:09 PM
To: Susan Hares; yang-doct...@ietf.org; i2rs@ietf.org
Cc: martin.vigour...@nokia.com; 'Benjamin Kaduk'
Subject: Re: [yang-doctors] draft-ietf-i2rs-yang-l2-network-topology

 

Hi,

 

I was referring to management-address leaf-list in the same grouping (see 
below).

 

I don’t have the expertise to answer your questions below, maybe some YDs do.

 

Regards,

Reshad.

 

 grouping l2-node-attributes {

   description

 "L2 node attributes";

   container l2-node-attributes {

 description

   "Contains L2 node attributes.";



 leaf-list management-address {

   type inet:ip-address;

   description

 "System management address.";

 }

 leaf sys-mac-address {

   type yang:mac-address;

   description

 "System MAC address.";

 }

 

 

From: Susan Hares 
Date: Wednesday, July 8, 2020 at 11:48 AM
To: "Reshad Rahman (rrahman)" , "yang-doct...@ietf.org" 
, "i2rs@ietf.org" 
Cc: "martin.vigour...@nokia.com" , 'Benjamin Kaduk' 

Subject: RE: [yang-doctors] draft-ietf-i2rs-yang-l2-network-topology

 

Reshad: 

 

Thank you for quick response.   However, I’m confused.   Where do you see the 
IP address in the Yang snippet I sent?  It is a MAC Address (type 
yang:mac-address)?  If the system port allows IP, it will respond to the ARP 
request with the appropriate IP/MAC match in an ARP reply.   

 

In real implementations I2rs implementers examined, 

*   L2 port with mgmt-mac-address seems to be used to only send LLDP 
packets, 
*   L2 port with sys-mac-address seems to be used for management using 
TCP/IP.  

 

If we swap the names, it did not work with the initial implementers of the yang 
model.  The  I2RS Topology models are used for operational management of 
switches and routers as logical units. 

 

Also, your response does not seem to match my questions: 

 

1) Is this the normal assumption for yang models? 

2) If not, what is the normal assumption on system mac addresses? 

3) Am I correct that switches with more than 1 system MAC will augment their 
basic yang model with the second system MAC Address? 

 

I’m sorry to bother you but this document is being reviewed by the IESG  
tomorrow (Thursday) and 

I am the shepherd.  I do not know how to answer some of the yang related 
questions regarding multiple system ports to exchange management configuration 
on.  

 

I had thought that netconf/restconf would be exchanged over the same ports so 
the yang doctors would know what the normal custom should be. 

 

Thanks again! 

 

Sue  

 

 

 

 

 

 

 

 

From: Reshad Rahman (rrahman) [mailto:rrah...@cisco.com] 
Sent: Wednesday, July 8, 2020 11:27 AM
To: Susan Hares; yang-doct...@ietf.org; i2rs@ietf.org
Cc: martin.vigour...@nokia.com; 'Benjamin Kaduk'
Subject: Re: [yang-doctors] draft-ietf-i2rs-yang-l2-network-topology

 

Hi,

 

So sys-mac-address is supposed to be the MAC address of the mgmt port, i.e. the 
device would respond to an ARP request for management-address with 
sys-mac-address? I think use of term system might be a bit misleading if that’s 
the case, mgmt-mac-address might be better.

 

Also, it is odd to have an IP address in an L2 grouping.

 

Disclaimer: not familiar with that draft at all, just took a look at the L2 
grouping.

 

Regards,

Reshad.

 

From: yang-doctors  on behalf of Susan Hares 

Date: Wednesday, July 8, 2020 at 11:12 AM
To: "yang-doct...@ietf.org" , "i2rs@ietf.org" 

Cc: "martin.vigour...@nokia.com" , 'Benjamin Kaduk' 

Subject: [yang-doctors] draft-ietf-i2rs-yang-l2-network-topology

 

The following question was asked by Ben Kaduk during IESG review of the 
following document: 

 

https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-l2-network-topology/

 

 grouping l2-node-attributes {

 [...]

 leaf sys-mac-address {

   type yang:mac-address;

   description

 "System MAC address.";

 }

 

If there are more than 1 system mac address in a switch, how would this model 
handle it. 

 

My understan

Re: [i2rs] [yang-doctors] draft-ietf-i2rs-yang-l2-network-topology

[Susan Hares]

Juergen:

This is the answer I expected, but I needed to ask. 

Thank you, Susan Hares 

-Original Message-
From: Juergen Schoenwaelder [mailto:j.schoenwael...@jacobs-university.de] 
Sent: Wednesday, July 8, 2020 12:03 PM
To: Susan Hares
Cc: 'Reshad Rahman (rrahman)'; yang-doct...@ietf.org; i2rs@ietf.org;
martin.vigour...@nokia.com; 'Benjamin Kaduk'
Subject: Re: [yang-doctors] draft-ietf-i2rs-yang-l2-network-topology

On Wed, Jul 08, 2020 at 11:47:45AM -0400, Susan Hares wrote:
> 
> 1) Is this the normal assumption for yang models?

This is a question for IEEE bridge experts, not yang doctors.
 
> 2) If not, what is the normal assumption on system mac addresses?

This is a question for IEEE bridge experts, not yang doctors.
 
> 3) Am I correct that switches with more than 1 system MAC will augment
their basic yang model with the second system MAC Address? 
>

It depends on the implementor. If you have more than one address, than you
likely add a *list of addresses instead of a second and then a third and so
fourth.

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 <https://www.jacobs-university.de/>

___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

Re: [i2rs] Éric Vyncke's No Objection on draft-ietf-i2rs-yang-l2-network-topology-14: (with COMMENT)

[Susan Hares]

Alvaro: 

 

Thank you for the pointer to the coordination team. 

 

Sue 

 

From: i2rs [mailto:i2rs-boun...@ietf.org] On Behalf Of Alvaro Retana
Sent: Tuesday, July 7, 2020 4:20 PM
To: Susan Hares; Eric Vyncke (evyncke); Qin Wu; The IESG
Cc: draft-ietf-i2rs-yang-l2-network-topol...@ietf.org; i2rs@ietf.org; 
i2rs-cha...@ietf.org
Subject: Re: [i2rs] Éric Vyncke's No Objection on 
draft-ietf-i2rs-yang-l2-network-topology-14: (with COMMENT)

 

Hi!

 

I don’t think that a formal review is needed from the IEEE.  Sending an FYI 
e-mail to ieee-ietf-co...@ietf.org should be enough — letting the team know the 
current state of the document.

 

Thanks!

 

Alvaro.

 

On July 7, 2020 at 10:20:14 AM, Susan Hares (sha...@ndzh.com) wrote:

As to the IEEE review, this goes through the IETF-IEEE liaison. I'm happy to 
have this yang model reviewed by the IEEE liaison is in 2020. Qin's review 
occurred late 2019. I'm unclear who the 2020 liaison is from IETF to IEEE. 
Asking specifically about the Ethernet is useful. Martin/Alvaro/Deborah may 
know who to ask. 

___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

Re: [i2rs] [yang-doctors] draft-ietf-i2rs-yang-l2-network-topology

[Susan Hares]

Reshad: 

 

Thank you for quick response.   However, I’m confused.   Where do you see the 
IP address in the Yang snippet I sent?  It is a MAC Address (type 
yang:mac-address)?  If the system port allows IP, it will respond to the ARP 
request with the appropriate IP/MAC match in an ARP reply.   

 

In real implementations I2rs implementers examined, 

· L2 port with mgmt-mac-address seems to be used to only send LLDP 
packets, 

· L2 port with sys-mac-address seems to be used for management using 
TCP/IP.  

 

If we swap the names, it did not work with the initial implementers of the yang 
model.  The  I2RS Topology models are used for operational management of 
switches and routers as logical units. 

 

Also, your response does not seem to match my questions: 

 

1) Is this the normal assumption for yang models? 

2) If not, what is the normal assumption on system mac addresses? 

3) Am I correct that switches with more than 1 system MAC will augment their 
basic yang model with the second system MAC Address? 

 

I’m sorry to bother you but this document is being reviewed by the IESG  
tomorrow (Thursday) and 

I am the shepherd.  I do not know how to answer some of the yang related 
questions regarding multiple system ports to exchange management configuration 
on.  

 

I had thought that netconf/restconf would be exchanged over the same ports so 
the yang doctors would know what the normal custom should be. 

 

Thanks again! 

 

Sue  

 

 

 

 

 

 

 

 

From: Reshad Rahman (rrahman) [mailto:rrah...@cisco.com] 
Sent: Wednesday, July 8, 2020 11:27 AM
To: Susan Hares; yang-doct...@ietf.org; i2rs@ietf.org
Cc: martin.vigour...@nokia.com; 'Benjamin Kaduk'
Subject: Re: [yang-doctors] draft-ietf-i2rs-yang-l2-network-topology

 

Hi,

 

So sys-mac-address is supposed to be the MAC address of the mgmt port, i.e. the 
device would respond to an ARP request for management-address with 
sys-mac-address? I think use of term system might be a bit misleading if that’s 
the case, mgmt-mac-address might be better.

 

Also, it is odd to have an IP address in an L2 grouping.

 

Disclaimer: not familiar with that draft at all, just took a look at the L2 
grouping.

 

Regards,

Reshad.

 

From: yang-doctors  on behalf of Susan Hares 

Date: Wednesday, July 8, 2020 at 11:12 AM
To: "yang-doct...@ietf.org" , "i2rs@ietf.org" 

Cc: "martin.vigour...@nokia.com" , 'Benjamin Kaduk' 

Subject: [yang-doctors] draft-ietf-i2rs-yang-l2-network-topology

 

The following question was asked by Ben Kaduk during IESG review of the 
following document: 

 

https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-l2-network-topology/

 

 grouping l2-node-attributes {

 [...]

 leaf sys-mac-address {

   type yang:mac-address;

   description

 "System MAC address.";

 }

 

If there are more than 1 system mac address in a switch, how would this model 
handle it. 

 

My understanding is that most switches have 1 system mac address for network 
management.  Therefore, the L2 topology model supports one. 

 

Question for Yang Doctors: 

 

1) Is this the normal assumption for yang models? 

2) If not, what is the normal assumption on system mac addresses? 

 

3) Am I correct that switches with more than 1 system MAC will augment their 
basic yang model with the second system MAC Address. 

 

Thank you, Susan Hares 

___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

Re: [i2rs] Benjamin Kaduk's No Objection on draft-ietf-i2rs-yang-l2-network-topology-14: (with COMMENT)

[Susan Hares]

Benjamin: 

I'm sorry I missed this email until today.I do not think Qin has
answered your questions.   

Issues we believe are settled
== 
1) VXLAN - value of zero.
   We believe Yang Doctors have indicated our method is correct. 
   Rob Wilton is the best judge among IESG for this issue. 

2) Network topology models and links - please see RFC 8345 

Issues which need investigation with IEEE/IETF liaison and industry use
===
1) System management  IP address -  We believe that a single system
management is the correct basic functionality. 
  
Additional system management ports would be an augmentation of a model by a
vendor.  If this does not match the current hardware technology, the authors
can change to indicate a list of multiple system management ports.  Advice
is needed from switch vendors on the basic.   I have sent a request to the
yang doctors.   Rob Wilton can provide feedback for the IESG if I do not get
Yang Doctors response quickly. 

2) What "others" states might be added in the future?
  
 802.1 has been adding some other states to ports for ACTIVE-ACTIVE
fail-over and for highly deterministic L2 paths for video (~IETF detnet).
I need to check when these "other states" have been defined by IEEE 802.1,
and when these new "other" states might be deployed in new switch devices.
If the new states are in devices, we will need to add them to this model
following the 802.1 definitions.   As a shepherd, I had not check upon these
in the last 2 years.  I have concern about putting  these states in a model
unless we have implementations that will use these states.   The normal way
to add these states is with an augmentation for the model.   

Good catch - I should have re-examined the IEEE work and current technology
in the last few weeks. 

3) Normative and informative choices - Authors will abide by IESG and IEEE
recommendations 
The authors will abide by IESG and IEEE recommendations for the status of
RFCs.  The following should be discussed by IESG and the IEEE

  a) Normative --> informative   RFC3688 and RFC7951 
  b) Informative--> normative: [IEEE802.1Qcp], RFC7348
  
Issues which need editorial changes:  (Qin SHOULD change/add] 

1) QinQ definitions

The svlan-id and cvlan-id can should augment the structures with longer
descriptions.  These descriptions should point to the IEEE longer
descriptions.   This change will need to be validated by yang doctors and
IETF-IEEE liaison person. 

2) change of text in security sections 
[(a) "intended" to "intended" datastore and b) NETCONF access control model
to NACM)]

Thanks for catching the nits in the security text.  

Thank you for your careful and thoughtful review, 
 Susan Hares 

-Original Message-
From: i2rs [mailto:i2rs-boun...@ietf.org] On Behalf Of Benjamin Kaduk via
Datatracker
Sent: Monday, July 6, 2020 9:35 PM
To: The IESG
Cc: draft-ietf-i2rs-yang-l2-network-topol...@ietf.org; i2rs@ietf.org;
i2rs-cha...@ietf.org
Subject: [i2rs] Benjamin Kaduk's No Objection on
draft-ietf-i2rs-yang-l2-network-topology-14: (with COMMENT)

Benjamin Kaduk has entered the following ballot position for
draft-ietf-i2rs-yang-l2-network-topology-14: No Objection

When responding, please keep the subject line intact and reply to all email
addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-l2-network-topology/



--
COMMENT:
--

Why is the "management-address" for a l2-node an IP address?  Does that
exclude any potential use of this data model for non-IP networks?

Section 3

   o  Links in the "ietf-network-topology" module are augmented as well
  with a set of Layer 2 parameters, allowing to associate a link
  with a name, a set of Layer 2 link attributes, and flags.

Interesting that names for links were not part of the core network-topology
module.  Are there any potential issues if other ntework types also specify
a link name and there is disagreement between them?

[Sue:  The links were part of the core network topology 

>From RFC 8345: 

   module: ietf-network-topology
 augment /nw:networks/nw:network:
   +--rw link* [link-id]
  +--rw link-idlink-id
  +--rw source
  |  +--rw source-node?   -> ../../../nw:node/node-id
  |  +--rw source-tp? leafref
  +--rw destination
  |  +--rw dest-node?   -> ../../../nw:node/node-id
  |  +--rw dest-tp? leafr

Re: [i2rs] Éric Vyncke's No Objection on draft-ietf-i2rs-yang-l2-network-topology-14: (with COMMENT)

[Susan Hares]

Eric: 

Another round of comments are below.   

As to the  IEEE review, this goes through the IETF-IEEE liaison. I'm happy 
to have this yang model reviewed by the IEEE liaison is in 2020.   Qin's review 
occurred late 2019.  I'm unclear who the 2020 liaison is from IETF to IEEE.  
Asking specifically about the Ethernet is useful.  Martin/Alvaro/Deborah may 
know who to ask. 

FCS is a more generic term.  I'm sure that Qin will agree to utilize this term. 
Qin response may come in 2-3 hours. 

More comments below to your questions.   [Sue2] indicates the next round of 
answers. 

Key editorial additions: 
1) FCS replacing CRC 
2) Inconsistent use of L2 versus Layer 2. 

Key technical changes: 
1) management-mac-address - used for sending LLDP frames. 
2) Speeds for IoT and the Wireless - could we get an expert from Internet on 
IoT directorate, and 
Any suggestions on 802.11 person?  
I have managed a team that wrote code for early 802.11 code in L2 switches, but 
I have not done that since 2010.   If you do not have a key person, Qin or 
Donald Eastlake or other 802.11 people can help me. 

Thanks for going through the model carefully. 

Susan Hares 

-Original Message-
From: i2rs [mailto:i2rs-boun...@ietf.org] On Behalf Of Eric Vyncke (evyncke)
Sent: Tuesday, July 7, 2020 8:39 AM
To: Qin Wu; Susan Hares; 'The IESG'
Cc: draft-ietf-i2rs-yang-l2-network-topol...@ietf.org; i2rs@ietf.org; 
i2rs-cha...@ietf.org
Subject: Re: [i2rs] Éric Vyncke's No Objection on 
draft-ietf-i2rs-yang-l2-network-topology-14: (with COMMENT)

Hello Qin

Long time not talked ☹

Satisfied to read that IEEE has reviewed the document as this was a major 
concern of mine. If IEEE reviewers do not mind about using the old 'ethernet' 
word rather than 'ieee802', then I can only respect your and their choice.

About the Ethernet frame length, your suggested text is improved but you may 
want to also specify for IEEE 802.11 whether the 'frame control' and other 
fields are also counted. I know, L2 is a pain __ Also (and my bad), please use 
FCS rather than CRC.

About the rate, AFAIK, SigFox is below 1 kbps and LoRa is just a little faster. 
So, why not covering those rates ? Except if there is another limitation that I 
am not aware of

Sincerely hope it helps

-éric


-Original Message-
From: Qin Wu 
Date: Tuesday, 7 July 2020 at 14:22
To: Eric Vyncke , Susan Hares , 'The IESG' 

Cc: "draft-ietf-i2rs-yang-l2-network-topol...@ietf.org" 
, "i2rs@ietf.org" 
, "i2rs-cha...@ietf.org" 
Subject: RE: [i2rs] Éric Vyncke's No Objection on 
draft-ietf-i2rs-yang-l2-network-topology-14: (with COMMENT)

Hi, Eric:
Thanks Sue for helping clarification. See followup comments inline below.
-邮件原件-
发件人: Eric Vyncke (evyncke) [mailto:evyn...@cisco.com] 
发送时间: 2020年7月7日 15:36
收件人: Susan Hares ; 'The IESG' 
抄送: draft-ietf-i2rs-yang-l2-network-topol...@ietf.org; i2rs@ietf.org; 
i2rs-cha...@ietf.org
主题: Re: [i2rs] Éric Vyncke's No Objection on 
draft-ietf-i2rs-yang-l2-network-topology-14: (with COMMENT)

Hello Sue,

Thank you for your reply; no surprise, you take your document shepherd role 
seriously.

About the YANG validations, I was indeed suspecting something about the 
tool itself rather with the document: thank you for clearing my concerns. Your 
statement obviously clears my semi DISCUSS.

Please find below some more comments prefixed with EV> (mainly about IEEE 
and indeed my lack of knowledge about the IETF topology model)

All the best,

-éric

-Original Message-
From: Susan Hares 
Date: Monday, 6 July 2020 at 22:40
To: Eric Vyncke , 'The IESG' 
Cc: "draft-ietf-i2rs-yang-l2-network-topol...@ietf.org" 
, "i2rs@ietf.org" 
, "i2rs-cha...@ietf.org" 
Subject: RE: [i2rs] Éric Vyncke's No Objection on 
draft-ietf-i2rs-yang-l2-network-topology-14: (with COMMENT)

Eric: 

 

Thank you for being concerned about the errors reported by the tools.  
These errors have been growing with each revision of the yang tools kit without 
any change to the Yang.  

Yang doctors have OKed the draft.  We have asked the Yang Doctors to 
address this issue and the ADs.It is hard to fix ghost bugs.   The authors 
will fix anything that is a real bug rather than a ghost bug. 

Other comments are below. 
 I will answer quickly because Authors are in China.   They may correct 
me - as it is there document. 


Sue 

-Original Message-
From: i2rs [mailto:i2rs-boun...@ietf.org] On Behalf Of Éric Vyncke via 
Datatracker
Sent: Friday, July 3, 2020 6:21 AM
To: The IESG
Cc: draft-ietf-i2rs-yang-l2-network-topol...@ietf.org; i2rs@ietf.org; 
i2rs-cha...@ietf.org
Subject: [i2rs] Éric Vyncke's No Objection on 
draft-ietf-i2rs-yang-l2-network-topology-14: (with COMMENT)

Éric Vyncke has entered

Re: [i2rs] Éric Vyncke's No Objection on draft-ietf-i2rs-yang-l2-network-topology-14: (with COMMENT)

[Susan Hares]

Eric: 

 

Thank you for being concerned about the errors reported by the tools.  These 
errors have been growing with each revision of the yang tools kit without any 
change to the Yang.  

Yang doctors have OKed the draft.  We have asked the Yang Doctors to address 
this issue and the ADs.It is hard to fix ghost bugs.   The authors will fix 
anything that is a real bug rather than a ghost bug. 

Other comments are below. 
 I will answer quickly because Authors are in China.   They may correct me - as 
it is there document. 


Sue 

-Original Message-
From: i2rs [mailto:i2rs-boun...@ietf.org] On Behalf Of Éric Vyncke via 
Datatracker
Sent: Friday, July 3, 2020 6:21 AM
To: The IESG
Cc: draft-ietf-i2rs-yang-l2-network-topol...@ietf.org; i2rs@ietf.org; 
i2rs-cha...@ietf.org
Subject: [i2rs] Éric Vyncke's No Objection on 
draft-ietf-i2rs-yang-l2-network-topology-14: (with COMMENT)

Éric Vyncke has entered the following ballot position for
draft-ietf-i2rs-yang-l2-network-topology-14: No Objection

When responding, please keep the subject line intact and reply to all email 
addresses included in the To and CC lines. (Feel free to cut this introductory 
paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-l2-network-topology/



--
COMMENT:
--

Thank you for the work put into this document.

Please find below a couple on non-blocking COMMENTs (and I would appreciate a 
reply to each of my COMMENTs because for some of them I was close to ballot a 
DISCUSS).

I hope that this helps to improve the document,

Regards,

-éric

== DISCUSS ==

== COMMENTS ==

Generic: is there a reason why the YANG validation results in 19 errors and 4 
warnings? Sue Harres (the shepherd) mentions in her write-up that 9 errors are 
linked to missing IEEE but what about the 10 remaining errors ?

Has there been a review by IEEE of this YANG model? While the shepherd is 
extensive and detailed, there is no mention of a coordination with IEEE.

-- Section 3 --

  "The Layer 2 (L2) network topology YANG module is designed to be
   generic and applicable to Layer 2 networks built with different L2
   technologies."
Is this statement correct? What about LoraWAN, Sigfox, and other LP-WAN 
technologies? Or technologies that may be using different MTU sizes on each 
direction? or having more parameters than this (such as being NBMA that should 
be captured).

[Sue:   It is generic abstract representation just like the network topology is 
a generic abstract representation. 
Abstract models can be augmented with specific details.  See TEAS augmentation 
of the abstract network topology model.   As a chair, I delayed this model 
until it was implemented on a set of topologies.  

If we can get proposals from running code or people plan running code for yang 
models,  I will glad work on augmentations for any of these topologies.  The 
only caveat is if my AD agrees to this work. 

Should "sys-mac-address? " rather be "management-mac-address? "

[Sue: My understanding from building switches is that the sys-mac-address may 
be different than the 
management-mac-address.   The system processor may have a different chip that 
the management processor. 
Therefore, based on the plan implementations - I would have to object to a 
change. 


I must admit that I am not familiar with the ietf-topology YANG model, so, the 
following COMMENTs can be plain wrong :-( ... It is unclear to me the 
difference between 'node' and 'termination-point'. If not defined in the 
ietf-topology, then please define before first use (I had to read the YANG 
module to understand).


[Sue:  This shows a misunderstand of the base topology model.  May I politely 
suggest that I will cover this offline with you or that you discuss this with 
Alvaro or Martin or Rob Wilton [NM/OPS]?  ]

Why is 'ethernet' used rather than 'ieee802', notably to cover IEEE 802.11 ?
[Sue: The  IEEE 802.1 is now linking multiple IEEE 802.11 segments using IEEE 
802.11 segments.  Donald Eastlake was a part of that process in 802.11 
specification.In my limited understanding, it is correct to use ieee802 as 
ieee802.1 is provides the linkage.   

The use of the term Ethernet was vetted by several discussions regarding the 
802.1 models this links to.   If the IEEE and the IETF suggest something else  
(in their harmonization of this model between groups), the authors will change 
to.  We've put in the draft what all parties agreed to (i2rs participants and 
IETF yang experts with IEEE knowledge) suggested.   If you have a concrete 
alternate proposal the same groups agree to, we will adjust.  We've been trying 
to do the best to 

Re: [i2rs] [Last-Call] Secdir last call review of draft-ietf-i2rs-yang-l2-network-topology-13

[Susan Hares]

Juergen: 

Good catch.   Thanks. 

sue

-Original Message-
From: Juergen Schoenwaelder [mailto:j.schoenwael...@jacobs-university.de] 
Sent: Friday, June 26, 2020 9:12 AM
To: Susan Hares
Cc: 'Christian Huitema'; 'Qin Wu'; sec...@ietf.org; i2rs@ietf.org; 
draft-ietf-i2rs-yang-l2-network-topology@ietf.org; last-c...@ietf.org
Subject: Re: [i2rs] [Last-Call] Secdir last call review of 
draft-ietf-i2rs-yang-l2-network-topology-13

But please s/agents/clients/ .

/js

On Fri, Jun 26, 2020 at 08:36:23AM -0400, Susan Hares wrote:
> Qin and Christian: 
> 
> This addition words for me. 
> 
> Sue
> 
> -Original Message-
> From: Christian Huitema [mailto:huit...@huitema.net]
> Sent: Friday, June 26, 2020 12:05 AM
> To: Susan Hares; 'Qin Wu'; sec...@ietf.org
> Cc: i2rs@ietf.org; 
> draft-ietf-i2rs-yang-l2-network-topology@ietf.org; 
> last-c...@ietf.org
> Subject: Re: [Last-Call] [i2rs] Secdir last call review of 
> draft-ietf-i2rs-yang-l2-network-topology-13
> 
> How about adding something like this:
> 
> Privacy Considerations
> 
> The Yang model for layer 2 topology exposes privacy sensitive information, 
> for example the MAC addresses of devices. Unrestricted use of such 
> information can lead to privacy violations. For example, listing MAC 
> addresses in a network allows monitoring of devices and their movements. 
> Location information can be derived from MAC addresses of network devices, 
> bypassing protection of location information by the Operating System.
> 
> Deployments should mitigate this privacy concerns by limiting access to the 
> layer 2 topology information. Access to the information should be restricted 
> to a minimal list of authorized agents, and should require proper 
> authentication of these agents.
> 
> -- Christian Huitema
> 
> On 6/25/2020 7:00 AM, Susan Hares wrote:
> > Qin and Christian: 
> >
> > Thank you for your prompt attention to the privacy issue.  
> > I'm sure Christian will respond in a bit - since he might be in PDT 
> > time-zone. 
> >
> > Once you have a solution you both like, we should validate the 
> > privacy changes to the security considerations section with the 
> > Yang-doctors, OPS-ADs, and Security-ADs.
> >
> > Martin's watching this thread so I'm sure he'll help us out as well. 
> >
> > Sue
> >
> > -Original Message-
> > From: i2rs [mailto:i2rs-boun...@ietf.org] On Behalf Of Qin Wu
> > Sent: Thursday, June 25, 2020 9:25 AM
> > To: Susan Hares; 'Christian Huitema'; sec...@ietf.org
> > Cc: i2rs@ietf.org;
> > draft-ietf-i2rs-yang-l2-network-topology@ietf.org;
> > last-c...@ietf.org
> > Subject: Re: [i2rs] Secdir last call review of
> > draft-ietf-i2rs-yang-l2-network-topology-13
> >
> > Sue and Christian:
> > I have responded to Christian on privacy issue, my proposal is to add MAC 
> > address as another data node vulnerability example in our original security 
> > consideration section.
> > But If Christian or security directorate has recommending text, we authors 
> > are happy to accept it.
> >
> > -Qin
> > -邮件原件-
> > 发件人: Susan Hares [mailto:sha...@ndzh.com]
> > 发送时间: 2020年6月25日 21:04
> > 收件人: 'Christian Huitema' ; sec...@ietf.org
> > 抄送: draft-ietf-i2rs-yang-l2-network-topology@ietf.org;
> > i2rs@ietf.org; last-c...@ietf.org
> > 主题: RE: Secdir last call review of
> > draft-ietf-i2rs-yang-l2-network-topology-13
> >
> > Christian:
> >
> > Thank you for catching the privacy issues.  
> >
> > I've got a few questions to help the authors scope this change: 
> >
> > 1) Since this is common to all L2 Topologies, can you or the security 
> > directorate recommend some text that might be appropriate? 
> >If you have recommended text, has this text been reviewed by OPS-DIR and 
> > Yang doctors? 
> >
> > 2) Will it be a problem If we write privacy considerations on IEEE 
> > specifications? 
> > 3) Do we need to consider the range of deployments of L2 (home, 
> > enterprise,  public PBB service, national PBB service, Data centers)
> >
> >
> > Thank you,  Sue
> >
> >
> > -Original Message-
> > From: Christian Huitema via Datatracker [mailto:nore...@ietf.org]
> > Sent: Thursday, June 25, 2020 1:01 AM
> > To: sec...@ietf.org
> > Cc: draft-ietf-i2rs-yang-l2-network-topology@ietf.org;
> > i2rs@ietf.org; last-c...@ietf.org
> > Subject: Secdir last call review of
> > draft-ietf-i2rs-yang-l2-network-topology-13
> >
> > Reviewer: Christian Huitema
> > Review result: Has Issues
>

Re: [i2rs] [Last-Call] Secdir last call review of draft-ietf-i2rs-yang-l2-network-topology-13

[Susan Hares]

Qin and Christian: 

This addition words for me. 

Sue 

-Original Message-
From: Christian Huitema [mailto:huit...@huitema.net] 
Sent: Friday, June 26, 2020 12:05 AM
To: Susan Hares; 'Qin Wu'; sec...@ietf.org
Cc: i2rs@ietf.org; draft-ietf-i2rs-yang-l2-network-topology@ietf.org; 
last-c...@ietf.org
Subject: Re: [Last-Call] [i2rs] Secdir last call review of 
draft-ietf-i2rs-yang-l2-network-topology-13

How about adding something like this:

Privacy Considerations

The Yang model for layer 2 topology exposes privacy sensitive information, for 
example the MAC addresses of devices. Unrestricted use of such information can 
lead to privacy violations. For example, listing MAC addresses in a network 
allows monitoring of devices and their movements. Location information can be 
derived from MAC addresses of network devices, bypassing protection of location 
information by the Operating System.

Deployments should mitigate this privacy concerns by limiting access to the 
layer 2 topology information. Access to the information should be restricted to 
a minimal list of authorized agents, and should require proper authentication 
of these agents.

-- Christian Huitema

On 6/25/2020 7:00 AM, Susan Hares wrote:
> Qin and Christian: 
>
> Thank you for your prompt attention to the privacy issue.  
> I'm sure Christian will respond in a bit - since he might be in PDT 
> time-zone. 
>
> Once you have a solution you both like, we should validate the privacy 
> changes to the security considerations section with the Yang-doctors, 
> OPS-ADs, and Security-ADs.
>
> Martin's watching this thread so I'm sure he'll help us out as well. 
>
> Sue
>
> -Original Message-
> From: i2rs [mailto:i2rs-boun...@ietf.org] On Behalf Of Qin Wu
> Sent: Thursday, June 25, 2020 9:25 AM
> To: Susan Hares; 'Christian Huitema'; sec...@ietf.org
> Cc: i2rs@ietf.org; 
> draft-ietf-i2rs-yang-l2-network-topology@ietf.org; 
> last-c...@ietf.org
> Subject: Re: [i2rs] Secdir last call review of 
> draft-ietf-i2rs-yang-l2-network-topology-13
>
> Sue and Christian:
> I have responded to Christian on privacy issue, my proposal is to add MAC 
> address as another data node vulnerability example in our original security 
> consideration section.
> But If Christian or security directorate has recommending text, we authors 
> are happy to accept it.
>
> -Qin
> -邮件原件-
> 发件人: Susan Hares [mailto:sha...@ndzh.com]
> 发送时间: 2020年6月25日 21:04
> 收件人: 'Christian Huitema' ; sec...@ietf.org
> 抄送: draft-ietf-i2rs-yang-l2-network-topology@ietf.org; 
> i2rs@ietf.org; last-c...@ietf.org
> 主题: RE: Secdir last call review of 
> draft-ietf-i2rs-yang-l2-network-topology-13
>
> Christian:
>
> Thank you for catching the privacy issues.  
>
> I've got a few questions to help the authors scope this change: 
>
> 1) Since this is common to all L2 Topologies, can you or the security 
> directorate recommend some text that might be appropriate? 
>If you have recommended text, has this text been reviewed by OPS-DIR and 
> Yang doctors? 
>
> 2) Will it be a problem If we write privacy considerations on IEEE 
> specifications? 
> 3) Do we need to consider the range of deployments of L2 (home, 
> enterprise,  public PBB service, national PBB service, Data centers)
>
>
> Thank you,  Sue
>
>
> -Original Message-
> From: Christian Huitema via Datatracker [mailto:nore...@ietf.org]
> Sent: Thursday, June 25, 2020 1:01 AM
> To: sec...@ietf.org
> Cc: draft-ietf-i2rs-yang-l2-network-topology@ietf.org; 
> i2rs@ietf.org; last-c...@ietf.org
> Subject: Secdir last call review of 
> draft-ietf-i2rs-yang-l2-network-topology-13
>
> Reviewer: Christian Huitema
> Review result: Has Issues
>
> I have reviewed this document as part of the security directorate's ongoing 
> effort to review all IETF documents being processed by the IESG.  These 
> comments were written with the intent of improving security requirements and 
> considerations in IETF drafts.  Comments not addressed in last call may be 
> included in AD reviews during the IESG review.  Document editors and WG 
> chairs should treat these comments just like any other last call comments.
>
> This document describes a Yang model for representing Link Layer topologies.
> Representing such topologies is obviously useful for managing network.
> The security section is focused on securing the usage of this information for 
> network management, but does not address potential privacy issues.
>
> The security considerations explain correctly how altering the link layer 
> information could enable attacks against the network. The proposed remedy is 
> access control, implemented using either SSH or TLS. This is fine, although 
> the dis

Re: [i2rs] Secdir last call review of draft-ietf-i2rs-yang-l2-network-topology-13

[Susan Hares]

Christian:

Thank you for catching the privacy issues.  

I've got a few questions to help the authors scope this change: 

1) Since this is common to all L2 Topologies, can you or the security 
directorate recommend some text that might be appropriate? 
   If you have recommended text, has this text been reviewed by OPS-DIR and 
Yang doctors? 

2) Will it be a problem If we write privacy considerations on IEEE 
specifications? 
3) Do we need to consider the range of deployments of L2
(home, enterprise,  public PBB service, national PBB service, Data centers)


Thank you,  Sue 


-Original Message-
From: Christian Huitema via Datatracker [mailto:nore...@ietf.org] 
Sent: Thursday, June 25, 2020 1:01 AM
To: sec...@ietf.org
Cc: draft-ietf-i2rs-yang-l2-network-topology@ietf.org; i2rs@ietf.org; 
last-c...@ietf.org
Subject: Secdir last call review of draft-ietf-i2rs-yang-l2-network-topology-13

Reviewer: Christian Huitema
Review result: Has Issues

I have reviewed this document as part of the security directorate's ongoing 
effort to review all IETF documents being processed by the IESG.  These 
comments were written with the intent of improving security requirements and 
considerations in IETF drafts.  Comments not addressed in last call may be 
included in AD reviews during the IESG review.  Document editors and WG chairs 
should treat these comments just like any other last call comments.

This document describes a Yang model for representing Link Layer topologies.
Representing such topologies is obviously useful for managing network.
The security section is focused on securing the usage of this information for 
network management, but does not address potential privacy issues.

The security considerations explain correctly how altering the link layer 
information could enable attacks against the network. The proposed remedy is 
access control, implemented using either SSH or TLS. This is fine, although the 
discussion of TLS authorisation is a bit short. By default, TLS verifies the 
identity of the server but not that of the client. RFC8040 section 2.5 
specifies that "a RESTCONF server SHOULD require authentication based on TLS 
client certificates. I assume that's the intent, but it might be useful to say 
so.

On the other hand, the security considerations do not describe privacy issues, 
and I find that problematic. The proposed information model lists a number of 
sensitive data, such as for example the MAC addresses of devices.
This information can be misused. For example, applications could assess device 
location fetching the MAC addresses of local gateways. Third parties could 
access link local information to gather identities of devices accessing a 
particular network. Such information is often protected by privacy API in the 
Operating System, but accessing the Yang module over the network might allow 
applications to bypass these controls.

Client authentication alone does not necessarily protect against these privacy 
leaks. A classic configuration error would limit write access to authorized 
users, but to allow read-only access to most users. This kind of error would 
allow privacy leaks. Given the sensitive nature of MAC addresses and other 
identifiers, it is useful to warn against such errors.





___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

Re: [i2rs] RtgDir review: draft-ietf-i2rs-yang-l2-network-topology-13.txt

[Susan Hares]

Med: 

I did report the issue in the write-up, and the Tools people said they were 
working on it. 

Sue 

-Original Message-
From: mohamed.boucad...@orange.com [mailto:mohamed.boucad...@orange.com] 
Sent: Wednesday, June 24, 2020 2:14 PM
To: Stig Venaas; 
Cc: rtg-...@ietf.org; draft-ietf-i2rs-yang-l2-network-topology@ietf.org; 
i2rs@ietf.org
Subject: RE: RtgDir review: draft-ietf-i2rs-yang-l2-network-topology-13.txt

Hi Stig, 

Thank you for the review. These nits will be fixed in the next iteration. 

As per this comment: 

"There may be some minor model issues, tracker says: Yang Validation 9 errors, 
2 warnings." 

Actually, this is an issue of the IETF datatracker that only populates in 
IETF-defined modules. In particular, IEEE-related modules are not populated in 
as revealed by the error message:

==
ietf-l2-topol...@2019-10-15.yang:31: error: module "ieee802-dot1q-types" not 
found in search path ==

Unless I'm mistaken, Sue has reported this issue in the write-up. Will look 
further on the warnings, though. 

Cheers,
Med

> -Message d'origine-
> De : Stig Venaas [mailto:s...@venaas.com] Envoyé : mercredi 24 juin 
> 2020 19:07 À :  Cc : rtg-...@ietf.org; 
> draft-ietf-i2rs-yang-l2-network- topology@ietf.org; i2rs@ietf.org 
> Objet : RtgDir review: draft-ietf-i2rs-yang-l2-network-topology-13.txt
> 
> Hello,
> 
> I have been selected as the Routing Directorate reviewer for this 
> draft. The Routing Directorate seeks to review all routing or 
> routing-related drafts as they pass through IETF last call and IESG 
> review, and sometimes on special request. The purpose of the review is 
> to provide assistance to the Routing ADs. For more information about 
> the Routing Directorate, please see 
> http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir
> 
> Although these comments are primarily for the use of the Routing ADs, 
> it would be helpful if you could consider them along with any other 
> IETF Last Call comments that you receive, and strive to resolve them 
> through discussion or by updating the draft.
> 
> Document: draft-ietf-i2rs-yang-l2-network-topology-13.txt
> Reviewer: Stig Venaas
> Review Date: 2020-06-24
> IETF LC End Date: 2020-06-25
> Intended Status: Standards Track
> 
> Summary:
> This document is basically ready for publication, but has nits that 
> should be considered prior to publication.
> 
> Comments:
> The document is well written and easy to read. I only found some minor 
> nits that should be taken care of.
> 
> Major Issues:
> No major issues found.
> 
> Minor Issues:
> No minor issues found.
> 
> Nits:
> 
> The idnits tool found some nits; regarding references in particular.
> 
> There may be some minor model issues, tracker says: Yang Validation 9 
> errors, 2 warnings.
> 
> The abstract is rather short, I think it would be worth going into a 
> little more detail.
> 
> In Introduction “A sample example” should maybe just be “An example”?
> 
> For grouping l2-network-type, shouldn’t “indicates” be capitalized?
>   presence "indicates L2 Network";
> 
> For leaf maximum-frame-size, missing space before PPP
>   if L2 frame is other type (e.g.,PPP), the L2
> 
> For l2-termination-point-type, leaf tag, should say “is supported”
>   "Defines whether lag is support or not.";
> 
> In the security considerations, should be “defines”
>   The Layer 2 topology module define
> 
> In Appendix A, should say “represents”.
>   implementations, a corresponding companion module is defined that
>   represent the operational state of layer 2 network topologies.  
> The
> 
> Regards,
> Stig

_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites 
ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez 
le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les 
messages electroniques etant susceptibles d'alteration, Orange decline toute 
responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law; they should not be distributed, used 
or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.


___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

[i2rs] draft-ietf-i2rs-yang-l2-network-topology

[Susan Hares]

Martin: 

 

It has been 42 days since I submitted the following draft for IESG
publication 

 

https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-l2-network-topology/

 

When do you think you will review this document?   Are there any  issues? 

 

It appears my private messages are encountering your spam filter so I will
be sending all future messages to a group blast. 

 

Thank you, 

 

Susan Hares 

___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

[i2rs] Publication has been requested for draft-ietf-i2rs-yang-l2-network-topology-13

[Susan Hares via Datatracker]

Susan Hares has requested publication of 
draft-ietf-i2rs-yang-l2-network-topology-13 as Proposed Standard on behalf of 
the I2RS working group.

Please verify the document's state at 
https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-l2-network-topology/


___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

Re: [i2rs] draft-ietf-i2rs-yang-l2-network-topology-12

[Susan Hares]

Tom.  

Thank you for the input on the normative.   

Sue 

-Original Message-
From: i2rs [mailto:i2rs-boun...@ietf.org] On Behalf Of tom petch
Sent: Wednesday, March 11, 2020 1:29 PM
To: Susan Hares; i2rs@ietf.org
Cc: 'Martin Vigoureux'
Subject: Re: [i2rs] draft-ietf-i2rs-yang-l2-network-topology-12

From: i2rs  on behalf of Susan Hares

Sent: 09 March 2020 18:36

Qin, Jie, Med, and Anders:

With the implementation experience described on the
I2rs@ietf.org<mailto:I2rs@ietf.org> list in terms of implementation
questions, we have reach the maturity to send this to the IESG.

We need 3 things:

1)  Anders Liu's IPR statement - If you have email with his statement, send
it to the I2rs@ietf.org<mailto:I2rs@ietf.org> list.
2) errors resolved in the yang compilation -

I need the errors resolved or a reason why the errors are occurring in the
build.

3) Nits need to be fixed


Sue,
I like the reference to IEEE 802.1Qcp but suspect It should be Normative
given its usage within the model, (but then something gnaws at the back of
my mind about different rules for non-IETF references, but I cannot find
where that came up:-(

tom petch








As soon as you finish these three items, I will be glad to push the button
to send it to Martin.

I've copied Martin on this email so he knows this long-awaited draft is
finally coming.

Cheerily, Susan hares

___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

Re: [i2rs] Mail regarding draft-ietf-i2rs-yang-l2-network-topology

[Susan Hares]

Samier: 

 

If it is an example, it is just an example in the standards document.If it 
is an augment to a standard model,  it must be in the many body of the standard 
document. 

 

I would suggest you create an augment model and put it in another document.   
For OSPF, ISIS, and BGP, the topology models will need to go to the WGs for 
these protocols. 

 

For LLDP,  there is not a specific WG – so I2RS or another may be useful to 
provide the first review.   If you wish to go this way, I will ask Martin if 
where he feels you will get the best review of the LLDP work.I will let you 
know what he says. 

 

Susan Hares 

 

From: SAMIER BARGUIL GIRALDO [mailto:samier.barguilgiraldo@telefonica.com] 
Sent: Tuesday, March 10, 2020 11:48 AM
To: Qin Wu; Susan Hares; draft-ietf-i2rs-yang-l2-network-topol...@ietf.org; 
i2rs@ietf.org
Cc: Oscar González de Dios; Dongjie (Jimmy); Cristian Felipe Rosero Carvajal 
(COMMS-EGM)
Subject: RE: [i2rs] Mail regarding draft-ietf-i2rs-yang-l2-network-topology

 

HI Qin / Sue,

 

I have one conceptual doubt that maybe you can help me to clarify. If we put 
the LLDP model as an example It is part of the standard? If not we have a gap 
because we expect to request the standard support to our network providers. 

 

In that case, we can fill this GAP proposing a new standard based on the 
definitions you have already done for L2 and L3 topologies. We were thinking a 
generic multi-purpose topology model to support for example:

*   LLDP
*   OSPF
*   ISIS
*   BGP

What do you think about tis?

 

Regards,

 

Samier Barguil
Transport & IP Networks | GCTIO - Technology | CIT Centro Integrado de 
Transporte |

Móvil +57 3017026430

Móvil +34 665416074

E-mail samier.barguilgiraldo@telefonica.com

E-mail samier.barg...@wipro.com

 

  _  

De: Qin Wu 
Enviado: lunes, 9 de marzo de 2020 22:59
Para: Susan Hares ; SAMIER BARGUIL GIRALDO 
; 
draft-ietf-i2rs-yang-l2-network-topol...@ietf.org 
; i2rs@ietf.org 

Cc: Oscar González de Dios ; Dongjie 
(Jimmy) ; Cristian Felipe Rosero Carvajal (COMMS-EGM) 

Asunto: RE: [i2rs] Mail regarding draft-ietf-i2rs-yang-l2-network-topology 

 

Thanks Sue to advance this work,

Samier, let me know if you want to add LLDP topo model in the appendix, which 
is augmented from L2 topo model, similar to OSPF topology example is defined in 
the Appendix B of RFC8346.

If we reach agreement on this (whether not needed or add an example in the 
appendix), I think we are ready to go.

 

-Qin

发件人: Susan Hares [mailto:sha...@ndzh.com] 
发送时间: 2020年3月10日 1:29
收件人: Qin Wu ; 'SAMIER BARGUIL GIRALDO' 
; 
draft-ietf-i2rs-yang-l2-network-topol...@ietf.org; i2rs@ietf.org
抄送: 'Oscar González de Dios' ; Dongjie 
(Jimmy) ; 'Cristian Felipe Rosero Carvajal (COMMS-EGM)' 

主题: RE: [i2rs] Mail regarding draft-ietf-i2rs-yang-l2-network-topology

 

Qin and Samier:

 

I’m excited to see that L2 Data model is being implemented.  

 

If it turns out that the L2 topology model needs to be augmented with 
additional LLDP topology drafts,  then I suggest you simply write an 
augmentation for the L2 model.I will be glad to support you and work with 
on the LLDP.With this in mind, I will close the shepherd’s report and send 
this long overdue RFC to the IESG.If the I2RS WG closes, then the 

 

On the BGP-LS information,  I suggest sending a note to IDR to determine if 
anyone has collected LLDP information across domains.   If you wish, I can (as 
co-chair of IDR) send that information for you. 

 

Susan Hares

 

From: i2rs [mailto:i2rs-boun...@ietf.org] On Behalf Of Qin Wu
Sent: Monday, February 10, 2020 1:12 AM
To: SAMIER BARGUIL GIRALDO; draft-ietf-i2rs-yang-l2-network-topol...@ietf.org; 
i2rs@ietf.org
Cc: Oscar González de Dios; Dongjie (Jimmy); Cristian Felipe Rosero Carvajal 
(COMMS-EGM)
Subject: Re: [i2rs] Mail regarding draft-ietf-i2rs-yang-l2-network-topology

 

SAMIER:

Come back for this comment, I think similar to L3 Topology, L2 network topology 
model is independent of layer 2 protocol type, e.g., LLDP. But Layer 2 topology 
model can be augmented with addition definitions for LLDP topology type.

One OSPF topology example is defined in the Appendix B of RFC8346. LLDP 
topology model can be defined in the same way.

 

Regarding your question, I think H-SDN-C should have boundary node information 
from its inventory model collected by each IP controller and it is the job of 
H-SDN-C to be responsible for topology stitching in different domains, 

 there are many protocols that can be used to expose topology from IP 
controller to H-SDN-C, e.g., BGP-LS routing protocol.  We haven’t seen LLDP can 
be used to collect cross inter-domain neighbourhood,e.g.,peer IP controller.

 

-Qin

发件人: SAMIER BARGUIL GIRALDO [mailto:samier.barguilgiraldo@telefonica.com] 
发送时间: 2020年1月23日 22:27
收件人: Qin Wu ; 
draft-ietf-i2rs-yang-l2-network-topol...@ietf.org; i2rs@ietf.org
抄送: Oscar González de Dios ; Cristian 
Felipe Ro

[i2rs] draft-ietf-i2rs-yang-l2-network-topology-12

[Susan Hares]

Qin, Jie, Med, and Anders: 

 

 

With the implementation experience described on the I2rs@ietf.org list in
terms of implementation questions, we have reach the maturity to send this
to the IESG. 

 

We need 3 things: 

 

1)  Anders Liu's IPR statement - If you have email with his statement, send
it to the I2rs@ietf.org list. 

2) errors resolved in the yang compilation - 

 

I need the errors resolved or a reason why the errors are occurring in the
build. 

 

3) Nits need to be fixed 

 

As soon as you finish these three items, I will be glad to push the button
to send it to Martin.  

 

I've copied Martin on this email so he knows this long-awaited draft is
finally coming. 

 

Cheerily, Susan hares 

___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

Re: [i2rs] Mail regarding draft-ietf-i2rs-yang-l2-network-topology

[Susan Hares]

Qin and Samier:

 

I’m excited to see that L2 Data model is being implemented.  

 

If it turns out that the L2 topology model needs to be augmented with 
additional LLDP topology drafts,  then I suggest you simply write an 
augmentation for the L2 model.I will be glad to support you and work with 
on the LLDP.With this in mind, I will close the shepherd’s report and send 
this long overdue RFC to the IESG.If the I2RS WG closes, then the 

 

On the BGP-LS information,  I suggest sending a note to IDR to determine if 
anyone has collected LLDP information across domains.   If you wish, I can (as 
co-chair of IDR) send that information for you. 

 

Susan Hares

 

From: i2rs [mailto:i2rs-boun...@ietf.org] On Behalf Of Qin Wu
Sent: Monday, February 10, 2020 1:12 AM
To: SAMIER BARGUIL GIRALDO; draft-ietf-i2rs-yang-l2-network-topol...@ietf.org; 
i2rs@ietf.org
Cc: Oscar González de Dios; Dongjie (Jimmy); Cristian Felipe Rosero Carvajal 
(COMMS-EGM)
Subject: Re: [i2rs] Mail regarding draft-ietf-i2rs-yang-l2-network-topology

 

SAMIER:

Come back for this comment, I think similar to L3 Topology, L2 network topology 
model is independent of layer 2 protocol type, e.g., LLDP. But Layer 2 topology 
model can be augmented with addition definitions for LLDP topology type.

One OSPF topology example is defined in the Appendix B of RFC8346. LLDP 
topology model can be defined in the same way.

 

Regarding your question, I think H-SDN-C should have boundary node information 
from its inventory model collected by each IP controller and it is the job of 
H-SDN-C to be responsible for topology stitching in different domains, 

 there are many protocols that can be used to expose topology from IP 
controller to H-SDN-C, e.g., BGP-LS routing protocol.  We haven’t seen LLDP can 
be used to collect cross inter-domain neighbourhood,e.g.,peer IP controller.

 

-Qin

发件人: SAMIER BARGUIL GIRALDO [mailto:samier.barguilgiraldo@telefonica.com] 
发送时间: 2020年1月23日 22:27
收件人: Qin Wu ; 
draft-ietf-i2rs-yang-l2-network-topol...@ietf.org; i2rs@ietf.org
抄送: Oscar González de Dios ; Cristian 
Felipe Rosero Carvajal (COMMS-EGM) ; Dongjie 
(Jimmy) 
主题: RE: Mail regarding draft-ietf-i2rs-yang-l2-network-topology

 

Hi Qin, 

 

I hade made a mistake. I was trying to say LLDP neighbour. A

 

I will try to explain it again to avoid confusions.  As your mentioned the LLDP 
can be enabled in the network and create the L2 Links (this is our intention). 
However, We have not seen in the model the way to express this inter-domain 
neighbourhood, for example:

 



In this network scenario:

*   Each domain controller will expose a L2 Topology
*   IP Controller-1 have not in its node DB the Node B
*   IP Controller-2 have not in its node DB the Node A

How the H-SDNc can join the two L2-topo (each from a controller) to generate 
the common view? It is possible with this model?

 

Regards,

--

Samier Barguil
Transport & IP Networks | GCTIO - Technology | CIT Centro Integrado de 
Transporte |

Móvil +57 3017026430

Móvil +34 665416074

E-mail samier.barguilgiraldo@telefonica.com

E-mail samier.barg...@wipro.com

 

  _  

De: Qin Wu 
Enviado: miércoles, 22 de enero de 2020 20:44
Para: SAMIER BARGUIL GIRALDO ; 
draft-ietf-i2rs-yang-l2-network-topol...@ietf.org 
; i2rs@ietf.org 

Cc: Oscar González de Dios ; Cristian 
Felipe Rosero Carvajal (COMMS-EGM) ; Dongjie 
(Jimmy) 
Asunto: RE: Mail regarding draft-ietf-i2rs-yang-l2-network-topology 

 

Hi, Samier:

L2 topo is used to describe neighbor relationship and can be collected by LLDP 
or any other Layer 2 protocol, are you sure LDP protocol should be part of L2 
topo model? If there is a use case for LDP, L2 topo model could be augmented in 
the separate model to support such use case.

BTW, L2 topo has completed WGLC. The token is in the document shepherd’s hand.

 

-Qin

发件人: SAMIER BARGUIL GIRALDO [mailto:samier.barguilgiraldo@telefonica.com] 
发送时间: 2020年1月21日 0:36
收件人: draft-ietf-i2rs-yang-l2-network-topol...@ietf.org; i2rs@ietf.org
抄送: Oscar González de Dios ; Cristian 
Felipe Rosero Carvajal (COMMS-EGM) 
主题: Mail regarding draft-ietf-i2rs-yang-l2-network-topology

 

Hello authors,

 

We have been using your model to describe our L2 Topology in a single domain IP 
scenario. During the last month we have been exporting this topology to a 
centralized entity in order to build a multi-domain (two IP domain controllers) 
L2-Topology. However, In order to build this end-to-end L2 view of our networks 
we were expecting to use the LDP neighbour relationship, however in the 
draft-ietf-i2rs-yang-l2-network-topology there is not such possibility.  

 

Do you have any plan to include this information in the model? If not how do 
you expect a centralized entity (Network Orchestator) can build an end-to-end 
L2 view of the network if the L2 Topo is reported by two domain controllers? 

 

Thanks in advance for your answer. 

 

Regards, 

Samier Bar

[i2rs] WG LC on draft-ietf-i2rs-yang-l2-network-topology-11.txt - use of IEEE 802.1Qcp-2018 in document -AD and WGChair/shepherd feedback - Comment period until 9/20/2019

[Susan Hares]

Tom and Qin: 

 

I've received input from the Routing AD (Martin Vigoureux),

NM/OPS ADS, and Suresh Krishnan (IEEE liaison) 

on Tom's question regard the use of  IEEE References as 

informative references in 

 
<https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-l2-network-topology/>
draft-ietf-i2rs-yang-l2-network-topology-11.txt 

 

and as imported references in: 

 

 import ieee802-dot1q-types {

  prefix dot1q-type;

  reference

"IEEE Std 802.1Qcp-2018: Bridges and Bridged

 Networks - Amendment: YANG Data Model.";

 }

 

The question is whether this import is a normative reference even though 

It is listed as informative. 

 

The yang doctors can determine whether IEEE 802.1Qcp-2018 

Should or should not be a normative references for

 
<https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-l2-network-topology/>
draft-ietf-i2rs-yang-l2-network-topology-11.txt.

 

In the case the IEEE 802.1Cp-208 is consider a normative reference, 

the following RFC2026  Section 7.1  (described below) might apply

that requires the WG LC to clearly indicate that a portion of the 

specification depends on  an external standard that exists behind 

a "paywall".   However,  RFC7241 section 3.2 specifies that any 

IEEE 802 published standard  and any IEEE 802 working group 

documents, are available for this  type of review at no charge.

  

Therefore, the "paywall" argument does not currently apply. 

 

It is the opinion of this WG chair that the 

dependence of this specification on IEEE 802.1Qcp definitions 

has been adequately discussed in the three WG LCs 

this document has gone through. 

 

My conclusion as shepherd/chair is that the "paywall" 

restriction does not exist even if  the Yang Doctors should decide 

the 802.1Qcp-2018 Yang reference needs to be informative. 

 

I am grateful to Tom Petch and Qin Wu for raising these issues. 

I believe it has fulfilled the discussion requirements for this 3rd WG LC. 

 

I will include this information in my shepherd's write-up early next week. 

I will hold this WG LC open for comments on this until 9/20/2019. 

If no other issues come in, it appears this WG LC is heading toward 

Consensus on this document.  

 

The ADs have been apprised that they will need to reference this discussion 

In the IETF LC. 

 

Susan Hares 

 

===

Discussion from ADS [Suresh, Warren, Martin, Alvaro]

 

Alvaro points out that the IEEE interactions are governed by 

RFC7241. 

- 

 

Suresh Krishnan and Warren Kumari discussion of section 7.1 

 

As described in Section 7.1 of RFC 2026, RFCs may have normative 

 references on external standards.

 In some cases, however, those references are themselves not generally 

 available (for instance, they might be accessible only after paying a 

 fee). This can interfere both with the ability of implementers to 

 implement the protocol as well as with the ability of the IETF 

 community to review it. 

 In such cases:

 1. The WG MUST be explicitly informed of any such normative reference 

 and the WG MUST reach consensus that it is acceptable. The document 

 shepherd MUST include this information in the shepherd writeup.

 2. The reference MUST be explicitly noted as part of the IETF Last 

 Call. If such a note is omitted, the last call MUST be repeated after 

 including it.

 

___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

[i2rs] Delays in response from I2rs Chair

[Susan Hares]

Greetings 

 

One of my day jobs is being a professor and this is the first week of class.


The week before classes start and the first week of classes is a busy time 

for professors.Due to this my reporting of the i2rs status has been
delayed.  

I hope complete my open action items/responses/reviews  by Thursday noon.   

 

Cheerily, Sue 

 

 

___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

Re: [i2rs] I-D Action: draft-ietf-i2rs-yang-l2-network-topology-09.txt

[Susan Hares]

Rob:

You and I are aligned our opinions of the correct approach and what I need to 
chat with the ADs about. 

However, as a chair my responsibility is to grease the wheels of progress by 
checking with the ADs before we send in the document. 

Dutifully  Sue 

-Original Message-
From: Rob Wilton (rwilton) [mailto:rwil...@cisco.com] 
Sent: Wednesday, August 21, 2019 1:06 PM
To: tom petch; Susan Hares; 'Qin Wu'; i2rs@ietf.org
Subject: RE: I-D Action: draft-ietf-i2rs-yang-l2-network-topology-09.txt

Hi Tom,

I've no issues with Sue checking with the ADs, but it might be helpful to point 
out:
 - There is already a regular IEEE/IETF liaison meeting that invariable 
includes discussion on YANG issues.  The sub-interface VLAN YANG model was part 
of this meeting for several years (due to technology overlap).
 - The VLAN definitions are in ieee802-dot1q-types.yang because (i) that is 
what we asked them to do, and (ii) they own the technology, and want to 
maintain control over it.
 - Generally, I think that IEEE and IETF currently have good form working 
together.  Of course, that could change in the future, but I suspect that if 
the IEEE decided to completely ditch YANG then I would expect them to be 
willing to find a solution for ieee802-dot1q-types.yang as well.

Also looking at this from the other direction, if we want to redefine these 
types then I think that we would risk slowing down the draft to get permission 
from the IEEE 802.1 WG that they are happy for us to redefine these types (my 
initial instinct from my previous interactions is that IEEE 802.1 WG would 
probably not be happy - although of course I do not and cannot speak for them!)

Thanks,
Rob


> -Original Message-
> From: i2rs  On Behalf Of tom petch
> Sent: 21 August 2019 17:38
> To: Susan Hares ; 'Qin Wu' ; 
> i2rs@ietf.org
> Subject: Re: [i2rs] I-D Action: 
> draft-ietf-i2rs-yang-l2-network-topology-
> 09.txt
> 
> - Original Message -
> From: "Susan Hares" 
> Sent: Wednesday, August 21, 2019 2:35 PM
> 
> Tom:
> 
> Would you like me to check with the NM/OPS AD as well on this point?
> They
> may have an agreement with the IEEE folks on yang models.
> 
> 
> 
> Sue
> 
> Yes please.
> 
> I have posted to Netmod where Rob Wilton thinks that it is fine and 
> copied it to Scott Mansfield.  My unease is rather vague that the IETF 
> and IEEE may take separate paths, on YANG, at some point. I see this 
> not as technical, where IEEE clearly have the skills in 802, but 
> rather as political or management, noting that the tools do not cope 
> with this, as Qin has found, that the module does not appear in the 
> IANA registry (and cannot from 802.1Q as it is RFC Required), that Rob 
> sees the reference as 801.1Qcp and not 802.1Q and so on.  We are 
> making the IETF dependent on something we have no control and little 
> influence over.
> 
> I would like an AD to say that they can see the issues and are content 
> that there will be no problem in future (I may turn round in five 
> years time and say 'I told you so' but that is business as usual, for me).
> 
> Tom Petch
> 
> Cheerily, Sue
> 
> -Original Message-
> From: tom petch [mailto:ie...@btconnect.com]
> Sent: Wednesday, August 21, 2019 4:53 AM
> To: Qin Wu; i2rs@ietf.org
> Cc: Susan Hares
> 
> Qin
> 
> You had a note in -07 about whether or not to import definitions from 
> draft-ietf-softwire; and now I see that -09 imports definitions from 
> IEEE 802.1Q.
> 
> Um.  Different.
> 
> I have seen this before but in an I-D that AFAICT never progressed.
> 
> I am uncertain what the implications of this are, in terms of the 
> evolution of the model, of the YANG language and so on, given the 
> different philosophies of the IETF and IEEE.  I think that it needs a 
> wider review than it will get on this list so I will flag this to 
> NETMOD and perhaps again at IETF Last call.
> 
> Tom Petch
> 
> 
> - Original Message -
> From: "Qin Wu" 
> To: 
> Cc: "Susan Hares" ; "tom petch" 
> Sent: Monday, August 19, 2019 8:08 AM
> 
> > v-09 is posted to address Tom's comments.
> > The diff is:
> >
> https://www.ietf.org/rfcdiff?url2=draft-ietf-i2rs-yang-l2-network-topo
> lo
> gy-09
> > Becuase datatracker pyang integration tool issue, Data model
> "ieee802-dot1q-types" can not been found
> > And imported into the model defined in this draft.
> >
> > -Qin
> > -邮件原件-
> > 发件人: I-D-Announce [mailto:i-d-announce-boun...@ietf.org] 代表
> internet-dra...@ietf.org
> > 发送时间: 2019年8月19日 15:04
> > 收件人: i-d-annou...@ietf.org
> > 抄送: i2rs@ietf.org
> > 主题: I-D Action: draft-ietf-i2rs-yang-l2-network

Re: [i2rs] I-D Action: draft-ietf-i2rs-yang-l2-network-topology-09.txt

[Susan Hares]

RobI knew about all these efforts with IEEE.  My suggested approach to Qin 
aligns with yours.  However I am glad to talk to ADs to check Sent via the 
Samsung Galaxy S7 edge, an AT 4G LTE smartphone
 Original message From: "Rob Wilton (rwilton)" 
 Date: 8/21/19  1:05 PM  (GMT-05:00) To: tom petch 
, Susan Hares , 'Qin Wu' 
, i2rs@ietf.org Subject: RE: I-D Action: 
draft-ietf-i2rs-yang-l2-network-topology-09.txt Hi Tom,I've no issues with Sue 
checking with the ADs, but it might be helpful to point out: - There is already 
a regular IEEE/IETF liaison meeting that invariable includes discussion on YANG 
issues.  The sub-interface VLAN YANG model was part of this meeting for several 
years (due to technology overlap). - The VLAN definitions are in 
ieee802-dot1q-types.yang because (i) that is what we asked them to do, and (ii) 
they own the technology, and want to maintain control over it. - Generally, I 
think that IEEE and IETF currently have good form working together.  Of course, 
that could change in the future, but I suspect that if the IEEE decided to 
completely ditch YANG then I would expect them to be willing to find a solution 
for ieee802-dot1q-types.yang as well.Also looking at this from the other 
direction, if we want to redefine these types then I think that we would risk 
slowing down the draft to get permission from the IEEE 802.1 WG that they are 
happy for us to redefine these types (my initial instinct from my previous 
interactions is that IEEE 802.1 WG would probably not be happy - although of 
course I do not and cannot speak for them!)Thanks,Rob> -Original 
Message-> From: i2rs  On Behalf Of tom petch> Sent: 
21 August 2019 17:38> To: Susan Hares ; 'Qin Wu' 
;> i2rs@ietf.org> Subject: Re: [i2rs] I-D Action: 
draft-ietf-i2rs-yang-l2-network-topology-> 09.txt> > - Original Message 
-> From: "Susan Hares" > Sent: Wednesday, August 21, 2019 
2:35 PM> > Tom:> > Would you like me to check with the NM/OPS AD as well on 
this point?> They> may have an agreement with the IEEE folks on yang models.> > 
> > Sue> > Yes please.> > I have posted to Netmod where Rob Wilton thinks 
that it is fine and copied> it to Scott Mansfield.  My unease is rather vague 
that the IETF and IEEE> may take separate paths, on YANG, at some point. I see 
this not as> technical, where IEEE clearly have the skills in 802, but rather 
as> political or management, noting that the tools do not cope with this, as> 
Qin has found, that the module does not appear in the IANA registry (and> 
cannot from 802.1Q as it is RFC Required), that Rob sees the reference as> 
801.1Qcp and not 802.1Q and so on.  We are making the IETF dependent on> 
something we have no control and little influence over.> > I would like an AD 
to say that they can see the issues and are content> that there will be no 
problem in future (I may turn round in five years> time and say 'I told you so' 
but that is business as usual, for me).> > Tom Petch> > Cheerily, Sue> > 
-Original Message-> From: tom petch [mailto:ie...@btconnect.com]> Sent: 
Wednesday, August 21, 2019 4:53 AM> To: Qin Wu; i2rs@ietf.org> Cc: Susan Hares> 
> Qin> > You had a note in -07 about whether or not to import definitions from> 
draft-ietf-softwire; and now I see that -09 imports definitions from IEEE> 
802.1Q.> > Um.  Different.> > I have seen this before but in an I-D that AFAICT 
never progressed.> > I am uncertain what the implications of this are, in terms 
of the> evolution of the model, of the YANG language and so on, given the> 
different philosophies of the IETF and IEEE.  I think that it needs a> wider 
review than it will get on this list so I will flag this to NETMOD> and perhaps 
again at IETF Last call.> > Tom Petch> > > - Original Message -> From: 
"Qin Wu" > To: > Cc: "Susan Hares" 
; "tom petch" > Sent: Monday, August 19, 
2019 8:08 AM> > > v-09 is posted to address Tom's comments.> > The diff is:> >> 
https://www.ietf.org/rfcdiff?url2=draft-ietf-i2rs-yang-l2-network-topolo> 
gy-09> > Becuase datatracker pyang integration tool issue, Data model> 
"ieee802-dot1q-types" can not been found> > And imported into the model defined 
in this draft.> >> > -Qin> > -邮件原件-> > 发件人: I-D-Announce 
[mailto:i-d-announce-boun...@ietf.org] 代表> internet-dra...@ietf.org> > 发送时间: 
2019年8月19日 15:04> > 收件人: i-d-annou...@ietf.org> > 抄送: i2rs@ietf.org> > 主题: I-D 
Action: draft-ietf-i2rs-yang-l2-network-topology-09.txt> >> >> > A New 
Internet-Draft is available from the on-line Internet-Drafts> directories.> > 
This draft is a work item o

Re: [i2rs] I-D Action: draft-ietf-i2rs-yang-l2-network-topology-09.txt

[Susan Hares]

Tom:

Would you like me to check with the NM/OPS AD as well on this point?  They
may have an agreement with the IEEE folks on yang models. 

Cheerily, Sue 

-Original Message-
From: tom petch [mailto:ie...@btconnect.com] 
Sent: Wednesday, August 21, 2019 4:53 AM
To: Qin Wu; i2rs@ietf.org
Cc: Susan Hares
Subject: Re: I-D Action: draft-ietf-i2rs-yang-l2-network-topology-09.txt

Qin

You had a note in -07 about whether or not to import definitions from
draft-ietf-softwire; and now I see that -09 imports definitions from IEEE
802.1Q.

Um.  Different.

I have seen this before but in an I-D that AFAICT never progressed.

I am uncertain what the implications of this are, in terms of the evolution
of the model, of the YANG language and so on, given the different
philosophies of the IETF and IEEE.  I think that it needs a wider review
than it will get on this list so I will flag this to NETMOD and perhaps
again at IETF Last call.

Tom Petch


- Original Message -
From: "Qin Wu" 
To: 
Cc: "Susan Hares" ; "tom petch" 
Sent: Monday, August 19, 2019 8:08 AM

> v-09 is posted to address Tom's comments.
> The diff is:
>
https://www.ietf.org/rfcdiff?url2=draft-ietf-i2rs-yang-l2-network-topolo
gy-09
> Becuase datatracker pyang integration tool issue, Data model
"ieee802-dot1q-types" can not been found
> And imported into the model defined in this draft.
>
> -Qin
> -邮件原件-
> 发件人: I-D-Announce [mailto:i-d-announce-boun...@ietf.org] 代表
internet-dra...@ietf.org
> 发送时间: 2019年8月19日 15:04
> 收件人: i-d-annou...@ietf.org
> 抄送: i2rs@ietf.org
> 主题: I-D Action: draft-ietf-i2rs-yang-l2-network-topology-09.txt
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
directories.
> This draft is a work item of the Interface to the Routing System WG of
the IETF.
>
> Title   : A YANG Data Model for Layer-2 Network
Topologies
> Authors : Jie Dong
>   Xiugang Wei
>   Qin Wu
>   Mohamed Boucadair
>   Anders Liu
> Filename: draft-ietf-i2rs-yang-l2-network-topology-09.txt
> Pages   : 31
> Date: 2019-08-19
>
> Abstract:
>This document defines a YANG data model for Layer 2 network
>topologies.
>
> Editorial Note (To be removed by RFC Editor)
>
>Please update these statements within the document with the RFC
>number to be assigned to this document:
>
>o  "This version of this YANG module is part of RFC ;"
>
>o  "RFC : A YANG Data Model for Layer-2 Network Topologies";
>
>o  reference: RFC 
>
>Please update the "revision" date of the YANG module.
>
>
> The IETF datatracker status page for this draft is:
>
https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-l2-network-topolog
y/
>
> There are also htmlized versions available at:
>
https://tools.ietf.org/html/draft-ietf-i2rs-yang-l2-network-topology-09
>
https://datatracker.ietf.org/doc/html/draft-ietf-i2rs-yang-l2-network-to
pology-09
>
> A diff from the previous version is available at:
>
https://www.ietf.org/rfcdiff?url2=draft-ietf-i2rs-yang-l2-network-topolo
gy-09
>
>
> Please note that it may take a couple of minutes from the time of
submission until the htmlized version and diff are available at
tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> ___
> I-D-Announce mailing list
> i-d-annou...@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html or
ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>


___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

Re: [i2rs] WG LC: draft-ietf-i2rs-yang-l2-network-topology-07.txt - Extended to 8/30/2019

[Susan Hares]

Tom and Qin:

During the summer as an chair, I am a bit more flexible on the closing for
WGs.This WG LC was to close by this week, but I will extended it 2 weeks
to allow two things to  happen: 
1) RTGWG to provide WG LC 
2) I2RS members to address Qin's changes to address Tom Petch's comments. 

Cheerily, Sue Hares 

-Original Message-
From: Qin Wu [mailto:bill...@huawei.com] 
Sent: Monday, August 19, 2019 1:04 AM
To: tom petch; Susan Hares; i2rs@ietf.org
Cc: r...@riw.us
Subject: RE: [i2rs] WG LC: draft-ietf-i2rs-yang-l2-network-topology-07.txt

Hi, Tom:
Thank for your valuable review. See comments inline below.
-邮件原件-
发件人: i2rs [mailto:i2rs-boun...@ietf.org] 代表 tom petch
发送时间: 2019年8月16日 20:00
收件人: Susan Hares ; i2rs@ietf.org
抄送: r...@riw.us
主题: Re: [i2rs] WG LC: draft-ietf-i2rs-yang-l2-network-topology-07.txt

Not ready

The text says
/*Consider udpating this part to make use of
draft-ietf-softwire-iftunnel*/ Well yes, consider it and come to a
conclusion otherwise I cannot see how this is ready to advance.
[Qin]: Good catch, will fix this. The idea is to align with RFC7224 and
reuse iana-interface-type.

The YANG module contains many references - good - but they are not in the
I-D references; again, not ready to advance.  I see

4761
4762
6325
6326
7348

802.1ad
802.1ah
802.1Q

[Qin]:Fixed.
IANA considerations references RFC7950 - RFC 6020 is better here as all that
RFC7950 says is go see RFC6020.
[Qin]:Agree, will update based on your suggestion.

OLD

   This version of this YANG module is part of
   draft-ietf-i2rs-yang-l2-network-topo-07;

NEW
   This version of this YANG module is part of
"RFC : A YANG Data Model for Layer-2 Network Topologies"

[Qin]:Fixed.
You also have this unsuitable reference twice in the state module
[Qin]:Fixed.
The state module lacks references for the imports [Qin]:Fixed.
The state module description clause seems misleading; it is only the state
part of a module when NMDA is not supported.
[Qin]:Fixed.
Appendix A - is it Normative?  The customary convention is the Appendices
are not unless stated otherwise and there is no statement here.
[Qin]:No, will make this clear.
'An Example' does not use the addresses set aside for documentation
[Qin]:Good catch, will use RFC7042 recommended address range.
What is the closing date for this Last call?

Tom Petch

- Original Message -----
From: "Susan Hares" 
To: 
Cc: 
Sent: Friday, August 09, 2019 4:42 PM


> Greetings:
>
>
>
> This draft on L2 network topology has been reviewed by the I2RS WG 3
times.
>
> However, in discussion with the ADs it is deemed appropriate to do one
more
>
> WG LC and include any input from rtgwg or grow.
>
>
>
> Please indicate whether you support publication of this document.
>
> In your comments, please indicate "support" or no "support".
>
>
>
> If you feel there issues that need to be resolved,
>
> Please indicate whether these issues are editorial,
>
> Yang syntax, or technical content.
>
>
>
> It would be helpful to indicate whether you know of
>
> Network deployments or potential network deployments of this draft.
>
>
>
> Cheerily,
>
>
>
> Sue Hares
>
>
>
>






> ___
> i2rs mailing list
> i2rs@ietf.org
> https://www.ietf.org/mailman/listinfo/i2rs
>

___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

[i2rs] WG LC: draft-ietf-i2rs-yang-l2-network-topology-07.txt

[Susan Hares]

Greetings: 

 

This draft on L2 network topology has been reviewed by the I2RS WG 3 times. 

However, in discussion with the ADs it is deemed appropriate to do one more 

WG LC and include any input from rtgwg or grow. 

 

Please indicate whether you support publication of this document. 

In your comments, please indicate "support" or no "support". 

 

If you feel there issues that need to be resolved, 

Please indicate whether these issues are editorial, 

Yang syntax, or technical content. 

 

It would be helpful to indicate whether you know of 

Network deployments or potential network deployments of this draft. 

 

Cheerily, 

 

Sue Hares 

 

___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

[i2rs] WG LC: draft-ietf-i2rs-yang-l2-network-topology-07.txt - IPR Call

[Susan Hares]

Qin:

Thank you for catching up with these edits.   The Yanglint still has an
error in this draft.   Would take of this while I start the IPR Call? 

This draft has been through WG LC 3 times with the same technical content in
I2RS.   It has been through 3 early  reviews.  

 After these delays, I need to move rapidly to close this work with the
following 3 steps:

1) All authors need to send in their IPR Statement by Friday 7/26 
2) We'll do a 2 week WG call (7/26 to 8/9/2019) and cross post to rtgwg WG 
3)   At the same time, we will ask for another Yang Doctor review of this
document. 

Our AD (Martin) have indicated that I have this one last attempt to get
consensus.

Would you also help your co-authors respond to the IPR statement? 

Sue Hares 
 


___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

Re: [i2rs] Protocol Action: 'A YANG Data Model for Fabric Topology in Data Center Networks' to Proposed Standard (draft-ietf-i2rs-yang-dc-fabric-network-topology-12.txt)

[Susan Hares]

Congratulations to Yan, Danian, Rong, and Hari on getting this document
approved for publication by the IESG.   Thank you for all your hard work
over the course of the publication period. 

A bit thank you to Martin for his work as the AD who shepherd this document
through the process!

Sue Hares 


-Original Message-
From: i2rs [mailto:i2rs-boun...@ietf.org] On Behalf Of The IESG
Sent: Monday, November 26, 2018 1:28 PM
To: IETF-Announce
Cc: i2rs@ietf.org; draft-ietf-i2rs-yang-dc-fabric-network-topol...@ietf.org;
i2rs-cha...@ietf.org; The IESG; martin.vigour...@nokia.com; sha...@ndzh.com;
rfc-edi...@rfc-editor.org
Subject: [i2rs] Protocol Action: 'A YANG Data Model for Fabric Topology in
Data Center Networks' to Proposed Standard
(draft-ietf-i2rs-yang-dc-fabric-network-topology-12.txt)

The IESG has approved the following document:
- 'A YANG Data Model for Fabric Topology in Data Center Networks'
  (draft-ietf-i2rs-yang-dc-fabric-network-topology-12.txt) as Proposed
  Standard

This document is the product of the Interface to the Routing System Working
Group.

The IESG contact persons are Alvaro Retana, Deborah Brungard and Martin
Vigoureux.

A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-dc-fabric-network-topo
logy/





Technical Summary

   This document defines a YANG data model for fabric topology in Data
   Center Network.

   Normally, a data center (DC) network is composed of single or
   multiple fabrics which are also known as PODs (Points Of Delivery).
   These fabrics may be heterogeneous due to implementation of different
   technologies when a DC network is upgraded or new techniques and
   features are enrolled.The configuration and management of such DC
networks with
   heterogeneous fabrics will result in considerable complexity,
   requiring a fair amount of sophistication.   As a basis for DC fabric
management, 
   this document defines a YANG  data model [6020][7950] for fabric-based
data center topology. 
   To do so, it augments the generic network and network topology data
models
   defined in [I-D.ietf-i2rs-yang-network-topo] with information that is
   specific to Data Center fabric networks.

Working Group Summary

  There was solid consensus in the working group to take
  on the work both on the list, and at IETF meetings. 

Document Quality

There is an implementation of this yang data model. 

Personnel

 Susan Hares is the Document Shepherd
 Martin Vigoureux is the Responsible Area Director

___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

[i2rs] Congratulations!

[Susan Hares]

I2RS WG: 

Congratulations!  The IESG has now approved the I2RS RIB Information Model and 
Data Model.  I want to thank all the members of the I2RS WG for their years of 
hard work on these specifications. 

Susan Hares 

-Original Message-
From: The IESG [mailto:iesg-secret...@ietf.org] 
Sent: Monday, May 14, 2018 10:11 AM
To: IETF-Announce
Cc: i2rs@ietf.org; Susan Hares; draft-ietf-i2rs-rib-data-mo...@ietf.org; 
i2rs-cha...@ietf.org; The IESG; martin.vigour...@nokia.com; sha...@ndzh.com; 
rfc-edi...@rfc-editor.org
Subject: Protocol Action: 'A YANG Data Model for Routing Information Base 
(RIB)' to Proposed Standard (draft-ietf-i2rs-rib-data-model-15.txt)

The IESG has approved the following document:
- 'A YANG Data Model for Routing Information Base (RIB)'
  (draft-ietf-i2rs-rib-data-model-15.txt) as Proposed Standard

This document is the product of the Interface to the Routing System Working 
Group.

The IESG contact persons are Alvaro Retana, Deborah Brungard and Martin 
Vigoureux.

A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft-ietf-i2rs-rib-data-model/





Technical Summary

  This document defines a YANG data model for Routing Information Base
  (RIB) that aligns with the I2RS RIB information model.
 
  This yang data model complies with the network management datastore
  architecture.  It can be loaded in configuration datastores or in dynamic
  datastores. 

Working Group Summary

  The I2RS WG and the authors have waited on the
  NETMOD/NETCONF WG to complete its work on
  revising the network management datastore architecture. 
  Now that the latter is completed the I2RS WG believes this Document
  can now itself progress.

Document Quality

  Some early implementations of this protocol existed as far back as 3 years 
ago. 

Personnel

 Susan Hares is the Document Shepherd
 Martin Vigoureux is the Responsible Area Director

___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

Re: [i2rs] Yangdoctors early review of draft-ietf-i2rs-yang-l2-network-topology-04

[Susan Hares]

Jie and Lada: 

I've recently listened to the I2RS meeting in IETF 101.  

Chris Hopps asked about the notifications in L2.  He was asking about a more
general use of the notification that might be useful in the 

I'm not really sure how to approach responding to his operational request -
since it really impacts all topology models.  My inclination is to push this
draft through into RFC usage, and then to work through a "-bis"
functionality.  

Jie - would you ask the individuals pushing for L2 model if that works for
them. 

Lada - would you ask the Yang doctors if this is the right approach to take.
Of course, this might be easier if we had versioning instead of a model name
change.  

Sue Hares 
-Original Message-
From: i2rs [mailto:i2rs-boun...@ietf.org] On Behalf Of Dongjie (Jimmy)
Sent: Thursday, May 3, 2018 10:09 PM
To: Ladislav Lhotka; yang-doct...@ietf.org
Cc: i2rs@ietf.org; i...@ietf.org;
draft-ietf-i2rs-yang-l2-network-topology@ietf.org
Subject: Re: [i2rs] Yangdoctors early review of
draft-ietf-i2rs-yang-l2-network-topology-04

Hi Lada, 

Thanks a lot for your review comments. Please see some replies inline:

> -Original Message-
> From: Ladislav Lhotka [mailto:lho...@nic.cz]
> Sent: Wednesday, May 02, 2018 9:32 PM
> To: yang-doct...@ietf.org
> Cc: i2rs@ietf.org; i...@ietf.org;
> draft-ietf-i2rs-yang-l2-network-topology@ietf.org
> Subject: Yangdoctors early review of 
> draft-ietf-i2rs-yang-l2-network-topology-04
> 
> Reviewer: Ladislav Lhotka
> Review result: Ready
> 
> This draft and YANG modules contained therein fit into the framework 
> of I2RS network topology models. I have no substantial comments, from 
> the YANG point of view this document is ready to be published.
> 
> Comments and questions:
> 
> 1. What is the purpose of the 'flag-type' type and 'flag-identity'
identity?
> There are no identities derived from the latter.

The "flag-type" type is used in the grouping "l2-network-attributes",
"l2-node-attributes" and "l2-link-attributes".

While there is no identities derived from the "flag-identity", it is used in
the typedef flag-type. Is this OK?

> 2. Some descriptions overuse capitalization. For example, instead of 'VLAN
Name'
> I would suggest 'VLAN name'.

Thanks for catching this. Will fix in next revision.

> 3. An example of an instance document in an appendix would be very
helpful.

Thanks for your suggestion. We will add an example to the appendix.

Best regards,
Jie

___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

[i2rs] Advice requested - Regarding I2RS Rib YANG model

[Susan Hares]

Greetings: 

 

The I2RS WG chair would like some advice.  

 

Is there ever a case when doing label swap you would ever want to decrease
the TTL at the same time?  Our initial I2RS RIB
(draft-ietf-i2rs-rib-data-model-10) had added this 3 years ago due to
comments.  However, we are question now whether this is valid. 

 

Thank you, Susan Hares 

Co-chair I2RS WG

 

___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

Re: [i2rs] Suresh Krishnan's No Objection on draft-ietf-i2rs-rib-info-model-15: (with COMMENT)

[Susan Hares]

Nitin:

Thanks for fixing Suresh's comments.  I've trimmed the text below to text 
tunnel-encap/decap text and LPM text.  

I will do a deep dive on the tunnel encap/decap on the mail list to see if I 
can find any additional comments to help your text.  However, I suspect that 
what you will naturally write will be the best text. 

On the LPM, let's see if Suresh has a suggestion on where to add text.   Again, 
I'm sure you will do a great job writing up the text. 

Would you remember to send the revised text to Warren and to Ignas.  We could 
really use their review of the revisions for these two points.   Warren and 
Ignas have experience with RIBs. 

Sue Hares 

-Original Message-
From: Nitin Bahadur [mailto:nitin_baha...@yahoo.com] 
Sent: Friday, April 13, 2018 1:52 AM
To: Susan Hares; 'Suresh Krishnan'; 'The IESG'
Cc: i2rs@ietf.org; i2rs-cha...@ietf.org; draft-ietf-i2rs-rib-info-mo...@ietf.org
Subject: Re: [i2rs] Suresh Krishnan's No Objection on 
draft-ietf-i2rs-rib-info-model-15: (with COMMENT)

  Suresh:   
Shouldn't the tunnel-encap and tunnel-decap also loop the packet back into
nexthop processing just like the derived nexthops do?

Suresh - I need to check the email list archives and get back to you on this
point.  My recollection was that there was a case where things  people did
not want to automatically loop this  back. However, I cannot bring the
discussion of 3.5 years ago to mind. I will take this as an action item as a
reviewer to try to recreate the discussion.   Thank you for mentioning this
point. It is important to clarify in either case. 


NB> Sue is right that there were some cases where folks did not want the packet 
to be automatically sent back for lookup. They wanted an explicit specification 
on what to do with the packet.  I believe the reasoning was there might be L2 
processing that needs to be performed after the encap/decap and L2 processing 
was mainly out of scope of this draft.

Sue> Could you put this in the draft?  It makes my recollection.  I will be 
doing a deep dive on the I2RS mail list and presentation today to provide 
additional test. 


Suresh> 
* Section 6

I would have expected the match type to have some indication about whether
it requires an exact match or LPM (e.g. A MAC route uses an exact match but
an
IPv6 route uses LPM). Has the WG discussed this?

The short answer is yes, extensive in early interims, list discussions and
in session.  Can you provide more depth to your questions.  For the early
discussions, I may need to query Alia Atlas and Jeff Haas (previous chairs)
to get the institutional memory on this topic.  (One of the reason I really
want to have this document discussed with Alia Atlas as AD0. 

NB> Quoting from the grammar

 ::= 
 ( |  |
( ))
 ::= 
 ::= 
 ::=  

Thus IP addresses have a "prefix length" associated with them indicating a LPM 
(or exact-match if prefix length is 32). A MAC route is expected to have an 
exact match. LPM for MAC routes was out of scope.

Sue: This matches my understanding.   If Suresh is confused, others will be.  
Let's see if Suresh has a suggestion on where to add text.  Will you follow up 
with Suresh on this point? 



___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

Re: [i2rs] Alvaro Retana's No Objection on draft-ietf-i2rs-rib-info-model-15: (with COMMENT)

[Susan Hares]

Nitin: 

On #1) -  These drafts will work through the process at the same time.
There will be a "MISREF" - but it should be cleared.   

Originally we were concerned about this fact because we wanted to send the
I2RS Info model earlier.  However, due to the network management datastore
model work in netmod/netconf - this work has been held up. 

Please put the reference in and spin it as -16.txt. 

Thanks!

Sue Hares 


-Original Message-
From: i2rs [mailto:i2rs-boun...@ietf.org] On Behalf Of Nitin Bahadur
Sent: Friday, April 13, 2018 2:09 AM
To: Alvaro Retana; The IESG
Cc: i2rs@ietf.org; i2rs-cha...@ietf.org; Susan Hares;
draft-ietf-i2rs-rib-info-mo...@ietf.org
Subject: Re: [i2rs] Alvaro Retana's No Objection on
draft-ietf-i2rs-rib-info-model-15: (with COMMENT)

Hi Alvaro,

   Thanks for the review. Please see NB> below

(1) Even if just Informative, it would be nice to have a reference to
draft-ietf-i2rs-rib-data-model.

NB> I'm not sure how referencing works. If I understand correctly,
rib-info-model then can't be published until data-model is published...and
then there is circular referencing.

(2) I think that the use of some Normative Language is not as expected.

(2.1) For example, in S2.1 (RIB definition): "There MAY be many routing
instances and each routing instance MAY contain RIBs."  In both cases
"MAY"
seems to be a statement of fact, and not a normative statement to
indicate that
a routing instance can optionally include RIBs.  

NB> Rewording to " A network device MAY contain routing instances and each
routing instance MAY contain RIBs."

Note that S2.2 (Routing
instance) identifies a rib-list as a mandatory component of a routing
instance,
and there's no clear indication that the list may be empty.

NB> Good point. I'll fix that.

(2.2) S2.1: "A routing instance MAY even have two or more RIBs of the
same rib
family (e.g., IPv6)."  This use of "MAY" also seems to be stating a
fact.
  
NB> Yes it is a fact. So removed use of "MAY".
  
(2.3) "MAY be optionally", "MAY contain the following optional fields"
are
redundant phrases as MAY already means optional.

 NB> Good point. Fixed.

Thanks
Nitin   
   


___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

Re: [i2rs] Benjamin Kaduk's No Objection on draft-ietf-i2rs-rib-info-model-15: (with COMMENT)

[Susan Hares]

Nitin: 

Thank you for email.  It really helps the process!

Sue 

-Original Message-
From: i2rs [mailto:i2rs-boun...@ietf.org] On Behalf Of Nitin Bahadur
Sent: Friday, April 13, 2018 2:19 AM
To: Susan Hares; 'Benjamin Kaduk'; 'The IESG'
Cc: i2rs@ietf.org; i2rs-cha...@ietf.org;
draft-ietf-i2rs-rib-info-mo...@ietf.org
Subject: Re: [i2rs] Benjamin Kaduk's No Objection on
draft-ietf-i2rs-rib-info-model-15: (with COMMENT)

Hi Benjamin/Sue,

NB> The reason string is indeed not relevant for the success case. The
success case is "Installed is TRUE AND Active is TRUE". For everything else
a reason will help. It will help the client to know why something was
installed but is not active.

As I recall (and my memory may be spotty), the reason was available for
both "yes" and "no" in case "yes" it is active, and "no" it is not installed
(example - 20 ECMP routes and only 10 get installed).   Nitin may have more
details on this RFC. 

Cheerily, Susan Hares

-Original Message-
From: Benjamin Kaduk [mailto:ka...@mit.edu] 
Sent: Wednesday, April 4, 2018 9:37 PM
To: The IESG
    Cc: draft-ietf-i2rs-rib-info-mo...@ietf.org; Susan Hares;
i2rs-cha...@ietf.org; sha...@ndzh.com; i2rs@ietf.org
Subject: Benjamin Kaduk's No Objection on
draft-ietf-i2rs-rib-info-model-15: (with COMMENT)

Benjamin Kaduk has entered the following ballot position for
draft-ietf-i2rs-rib-info-model-15: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to
https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-i2rs-rib-info-model/



--
COMMENT:
--

I share Warren's question (and, IIRC, asked a similar one about the
associated data-model document).

Just one other minor question: in Section 4

   Route programming in the RIB MUST result in a return code that
   contains the following attributes:

   o  Installed - Yes/No (Indicates whether the route got installed in
  the FIB)

   o  Active - Yes/No (Indicates whether a route is fully resolved and
  is a candidate for selection)

   o  Reason - e.g., Not authorized

Is the Reason only relevant when one of the other two is "No"?






___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

Re: [i2rs] Alissa Cooper's No Objection on draft-ietf-i2rs-rib-data-model-10: (with COMMENT)

[Susan Hares]

Tom - thank you for your continued review of this work!

Sue Hares 

-Original Message-
From: t.petch [mailto:ie...@btconnect.com] 
Sent: Wednesday, April 11, 2018 5:22 AM
To: Alissa Cooper; Mach Chen
Cc: IESG; i2rs@ietf.org; draft-ietf-i2rs-rib-data-mo...@ietf.org; 
i2rs-cha...@ietf.org; sha...@ndzh.com
Subject: Re: [i2rs] Alissa Cooper's No Objection on 
draft-ietf-i2rs-rib-data-model-10: (with COMMENT)

Mach

One additional thought on tree diagrams.

This is now RFC8340

and

YANG guidelines 6087bis section 3.4 says

"   If YANG tree diagrams are used, then an informative reference to the
   YANG tree diagrams specification MUST be included in the document.
"
whereas you currently have it as a Normative Reference (well, perhaps two 
related thoughts:-(

Tom Petch

- Original Message -
From: "Alissa Cooper" 
Sent: Monday, April 09, 2018 8:50 PM

> On Apr 8, 2018, at 9:20 AM, Mach Chen  wrote:
>
> Hi Tom,
>
>> -Original Message-
>> From: t.petch [mailto:ie...@btconnect.com]
>> Sent: Sunday, April 08, 2018 7:42 PM
>> To: Mach Chen ; Alissa Cooper 
>> ; The IESG 
>> Cc: i2rs@ietf.org; draft-ietf-i2rs-rib-data-mo...@ietf.org;
i2rs-cha...@ietf.org;
>> sha...@ndzh.com
>> Subject: Re: [i2rs] Alissa Cooper's No Objection on
draft-ietf-i2rs-rib-data-
>> model-10: (with COMMENT)
>>
>>  Original Message -
>> From: "Mach Chen" 
>> To: "Alissa Cooper" ; "The IESG" 
>> Cc: ; ;
>> ; 
>> Sent: Sunday, April 08, 2018 9:23 AM
>>
>>> Hi Alissa,
>>>
>>> Thanks for your comments!
>>>
>>> Please see my responses inline...
>>>
 -Original Message-
 From: i2rs [mailto:i2rs-boun...@ietf.org] On Behalf Of Alissa
Cooper
 Sent: Tuesday, April 03, 2018 11:10 PM
 To: The IESG 
 Cc: i2rs@ietf.org; draft-ietf-i2rs-rib-data-mo...@ietf.org;
>> i2rs-cha...@ietf.org;
 sha...@ndzh.com
 Subject: [i2rs] Alissa Cooper's No Objection on
>> draft-ietf-i2rs-rib-data-model-10:
 (with COMMENT)

 Alissa Cooper has entered the following ballot position for
 draft-ietf-i2rs-rib-data-model-10: No Objection

 When responding, please keep the subject line intact and reply to
>> all email
 addresses included in the To and CC lines. (Feel free to cut this
>> introductory
 paragraph, however.)


 Please refer to
>> https://www.ietf.org/iesg/statement/discuss-criteria.html
 for more information about IESG DISCUSS and COMMENT positions.


 The document, along with other ballot positions, can be found here:
 https://datatracker.ietf.org/doc/draft-ietf-i2rs-rib-data-model/



>>>
>>> 
--
 COMMENT:
>>>
>>> 
--

 Sec 1.2:

 "YANG tree diagrams provide a concise representation of a YANG
>> module,
   and SHOULD be included to help readers understand YANG module
   structure."

 This document does not seem like an appropriate place to have
>> normative
 guidance about this. And if this sentence is removed, I don't see
>> the point of
 including Section 1.2 otherwise. This would also imply deleting the
>> reference to
 I-D.ietf-netmod-yang-tree-diagrams.
>>>
>>> This results from a YANG doctor review.  I saw it also occurs in
other
>> published documents. I personally think it's no harm to keep it, how
do you
>> think?
>>
>> Mach
>>
>> I think that this is very odd.
>>
>> YANG guidelines rfc6087bis says
>> "   YANG tree diagrams provide a concise representation of a YANG
>> module,
>>   and SHOULD be included to help readers understand YANG module
>>   structure.  Guidelines on tree diagrams can be found in Section 3
of
>>   [I-D.ietf-netmod-yang-tree-diagrams].
>> "
>> which I think is the correct guidance in the correct place.
>>
>> A quick look at the recently published RFC8343, RFC8344, RFC8345,
>> RFC8346 contain no text of the kind you suggest so if it occurs in
other I-D, then
>> I would regard those other I-D as being in error.
>>
>> If I look back at a thread from Ebben for a yang doctor review of an
earlier
>> version of this I-D, the text I see proposed is
>>
>> "
>>>   A simplified graphical representation of the data model is used in
>>>   this document.  The meaning of the symbols in these diagrams is
>>>   defined in [I-D.ietf-netmod-yang-tree-diagrams].
>> "
>> which I think is rather different.
>
> Indeed, my fault, I just checked Ebben's suggestion, it's as above
quoted.
>
> To Alissa:
> If change to following text, is it OK for you?
>
> "A simplified graphical representation of the data model is used in 
> this document.  The meaning of the symbols in these diagrams 

Re: [i2rs] Ignas Bagdonas' Discuss on draft-ietf-i2rs-yang-dc-fabric-network-topology-08: (with DISCUSS and COMMENT)

[Susan Hares]

Ignas: 

Thank you for the clarifying email.  I just wanted to understand the type of 
discuss.   This statement clarifies the discuss: 

  DISCUSS is based on the impact of proposed mechanism to operations

This matches the following category from DISCUSS:"It would present serious 
operational issues in widespread deployment, by for example neglecting network 
management or configuration entirely." 
 
May I suggest if the TE is a minor issue, you move the TE comparison to 
comments so we can focus on the others?  You can always raise it to the DISCUSS 
level later after we solve the main issue.   

Do the suggestions that Yan start to address the problem? Is she heading in the 
right direction? If not, we may need to open up the discussion to a wider 
audience in the WG and the I2RS AD. 

Cheerily, Susan Hares 



When you say "not of primary importance", does this mean the I2RS/TE models are 
in the DISCUSS or out of it? 



-Original Message-
From: Ignas Bagdonas [mailto:ibagd...@gmail.com] 
Sent: Thursday, April 5, 2018 4:36 PM
To: Susan Hares; war...@kumari.net; martin.vigour...@nokia.com
Cc: i2rs@ietf.org; draft-ietf-i2rs-yang-dc-fabric-network-topol...@ietf.org; 
i2rs-cha...@ietf.org; 'The IESG'
Subject: Re: [i2rs] Ignas Bagdonas' Discuss on 
draft-ietf-i2rs-yang-dc-fabric-network-topology-08: (with DISCUSS and COMMENT)

Hi Sue,

I am responding as a DISCUSS holder. Warren may have different ABSTAIN views.

On 05/04/2018 16:12, Susan Hares wrote:
> Ignas and Warren:
>
> Your comments on the IESG telechat (4/5/2018) have two components:
> 1) a DISCUSS based on direct comparison of the I2RS models (dynamic 
> and configuration) with the TE models (configuration only),

This is incorrect. DISCUSS is based on very different background. I2RS and TE 
models are a small fragment in that background, and as I have mentioned in 
previous mails, it is not of primary importance.

> 2) "This will not work".

This is incorrect. DISCUSS is based on the impact of proposed mechanism to 
operations.

Please take a look at my DISCUSS notes again. And let's analyse them in detail 
then.

Network management mechanisms do not exist in vacuum, they are applied onto the 
entities being managed. Management mechanisms need to fit with the entities (in 
a broad sense of the word, including network elements and how those elements 
bind together - the network design) that they are trying to manage. Network 
design prescribes how the management mechanism will look and operate. DC fabric 
topology document appears to try to do the opposite - it provides assumptions 
and restrictions on how the network design that would be suitable for this 
model to be applied to has to look like. And that design appears to be 
substantially different than majority of practical deployments in DC network 
space. Given that this document is on standards track, it sends a strong 
message to the community saying that if one wants to use IETF approved DC 
network management mechanism, one needs to design a network based on the 
assumptions in this document. This is the core of my DISCUSS - the document as 
it is
  worded now prescribes network designs and manageability approaches that are 
disconnected from operational reality. 
If this was an informational document - likely I would not have much concerns 
on the same basis, but STD track document has a different impact.

Now onto the detailed parts of the DISCUSS. The scope of this model - where is 
it intended to be applied? Underlay? Overlay? Both at the same time? The text 
intermixes underlay and overlay scope, there are parts that seem to target one, 
the other, and both of them. The scope of ODL FAAS project does not help either 
- it intermixes the concepts even more freely. What might have been authors' 
intention - and I am not prescribing that, just guessing - was to take a single 
overlay instance and present it as an underlay, a "fabric as a service" in 
marketing terms, and to provide a model for managing the elements of that 
specific instance _ONLY_. I do not see problems with such approach, but the 
document needs to be very clear on the scope and the proposed mechanisms. If 
authors' scope intentions were different then it needs to be clarified in 
detail - the document, at least to me, does not provide clarity on the scope. 
This is a major part of DISCUSS.

The clarity of the model's logic. Model based network management is the new 
command line interface. It needs to be no worse than the industry norms for 
CLI. Having in a model leaf-this with a description of "this is leaf-this" does 
not seem to be sufficient. This is a minor part of DISCUSS.

TE topology - I fail to see anything resembling suggestions in the text of the 
DISCUSS. That is a question. It is a minor part of DISCUSS.

Stages, ports, roles, policies - those all are questions. All are minor parts 
of DISCUSS.

RPC - again, 

Re: [i2rs] Ignas Bagdonas' Discuss on draft-ietf-i2rs-yang-dc-fabric-network-topology-08: (with DISCUSS and COMMENT)

[Susan Hares]

Warren:

Thank you for making clear your concerns.   I started with the same concerns 
and came to resolve these concerns. I will try to write up a clear summary of 
why I resolved it.  However, I do not have some of the same datacenter 
perspective you or Ignas has.  I would like your review on these concerns and 
the authors comments on these points.  

The delay until Friday is due to my day jobs (professor and other IETF hats).  
I'm just out of time to do a proper job of this work. 

Sue Hares 

-Original Message-
From: Warren Kumari [mailto:war...@kumari.net] 
Sent: Thursday, April 5, 2018 1:52 PM
To: Susan Hares
Cc: Ignas Bagdonas; martin.vigour...@nokia.com; i2rs@ietf.org; 
draft-ietf-i2rs-yang-dc-fabric-network-topol...@ietf.org; i2rs-cha...@ietf.org; 
The IESG
Subject: Re: [i2rs] Ignas Bagdonas' Discuss on 
draft-ietf-i2rs-yang-dc-fabric-network-topology-08: (with DISCUSS and COMMENT)

On Thu, Apr 5, 2018 at 11:12 AM, Susan Hares <sha...@ndzh.com> wrote:
> Ignas and Warren:
>
> Your comments on the IESG telechat (4/5/2018) have two components:
> 1) a DISCUSS based on direct comparison of the I2RS models (dynamic and 
> configuration) with the TE models (configuration only), 2) "This will not 
> work".  I need clarity to guide the WG/authors to a successful resolution of 
> your DISCUSS/Abstain.
>
> 1) a DISCUSS based on direct comparison of the I2RS models (dynamic and 
> configuration) with the TE models (configuration only).
>
> The I2RS models are both available for the dynamic and configuration 
> datastore.  The dynamic configuration models are for models that do not 
> exactly align with perceptions of the configuration model.These set of 
> models are for situations that do not align with the configuration store only.
>
> As Martin indicated, trying these alternate  management Yang models in 
> dynamic/configuration model configuration needs feedback based on deployment 
> and interoperability issues.
>
> This does not align with RFC8342 (NMDA) or and I2RS requirement documents 
> (RFC8242).If this is your DISCUSS Criteria, then I have a strong 
> objection to your DISCUSS based on these RFCs.
>
> If the Discuss/Abstain is based on one of the following discuss criteria, 
> please state this clear in your emails so I can guide the authors and the WG.
>
> 1) The protocol has technical flaws that will prevent it from working 
> properly, or the description is unclear in such a way that the reader cannot 
> understand it without ambiguity.
> 2) Widespread deployment would be damaging to the Internet or an enterprise 
> network for reasons of congestion control, scalability, or the like.
>
> These are objections I take seriously as a shepherd/WG chair.  However, I 
> need you both to disambiguate between these two components.   I have been 
> trying to get clarity on which DISCUSS criteria Ignas' comments indicate.
>
> I expect an IESG members to be able to inform a WG chair which the discuss 
> criteria you are specifying.

I specifically did not ballot DISCUSS as there are no Discuss criteria which I 
felt applied - Abstain is a non-blocking position (and so practically 
indistinguishable from No Record, and fairly similar to No Objection).

Much of my twitchiness with the document is that it feels like it is trying to 
define what a datacenter fabric is (in an Introduction and a single term - 
"Fabric: also known as a POD, is a module of network, compute, storage, and 
application components that work together to deliver networking services.  It 
represents a repeatable design pattern.  Its components maximize the 
modularity, scalability, and manageability of data centers.").

There are a huge number of different data center "fabric" designs, and I don't 
really think that the document goes into enough detail about what exactly it is 
meaning when it says fabric. It also asserts:
"for a DC network, a fabric can be considered as an atomic structure for 
management purposes." -- at some level this is probably true, but at the level 
that I look at fabrics it definitely isn't -- a fabric is a thingie made up of 
many devices and they all require management and monitoring and care and 
feeding and love and attention.

A lot of the document seems to be written with a specific sets of views and 
assumptions (yes, it is obviously extensible, but the base selections reflect a 
certain understanding / world view):
the 'fabric-type' can be Vxlan, Vlan or Trill (most fabrics I've seen are plain 
ethernet), 'port-types' are "Port type: ethernet or serial or others" (I've 
never seen a serial fabric, and this leaves out InfiniBand), 'traffic-behavior' 
can be normal or policy-driven (with no description of what the actual 
difference is, nor what 'policy-driven' means), the 'fabric-options' are not 
really opt

Re: [i2rs] Ignas Bagdonas' Discuss on draft-ietf-i2rs-yang-dc-fabric-network-topology-08: (with DISCUSS and COMMENT)

[Susan Hares]

Ignas and Warren:

Your comments on the IESG telechat (4/5/2018) have two components: 
1) a DISCUSS based on direct comparison of the I2RS models (dynamic and 
configuration) with the TE models (configuration only), 2) "This will not 
work".  I need clarity to guide the WG/authors to a successful resolution of 
your DISCUSS/Abstain. 

1) a DISCUSS based on direct comparison of the I2RS models (dynamic and 
configuration) with the TE models (configuration only). 

The I2RS models are both available for the dynamic and configuration datastore. 
 The dynamic configuration models are for models that do not exactly align with 
perceptions of the configuration model.These set of models are for 
situations that do not align with the configuration store only.   

As Martin indicated, trying these alternate  management Yang models in 
dynamic/configuration model configuration needs feedback based on deployment 
and interoperability issues. 

This does not align with RFC8342 (NMDA) or and I2RS requirement documents 
(RFC8242).If this is your DISCUSS Criteria, then I have a strong objection 
to your DISCUSS based on these RFCs. 

If the Discuss/Abstain is based on one of the following discuss criteria, 
please state this clear in your emails so I can guide the authors and the WG. 

1) The protocol has technical flaws that will prevent it from working properly, 
or the description is unclear in such a way that the reader cannot understand 
it without ambiguity.
2) Widespread deployment would be damaging to the Internet or an enterprise 
network for reasons of congestion control, scalability, or the like.

These are objections I take seriously as a shepherd/WG chair.  However, I need 
you both to disambiguate between these two components.   I have been trying to 
get clarity on which DISCUSS criteria Ignas' comments indicate. 

I expect an IESG members to be able to inform a WG chair which the discuss 
criteria you are specifying. Please let me know if you have additional 
questions.  Your comments on the telechat did not indicate you understood my 
concerns. 

Cheerily, Susan Hares


-Original Message-----
From: Susan Hares [mailto:sha...@ndzh.com] 
Sent: Wednesday, April 4, 2018 6:08 PM
To: 'Ignas Bagdonas'; 'The IESG'
Cc: i2rs@ietf.org; draft-ietf-i2rs-yang-dc-fabric-network-topol...@ietf.org; 
i2rs-cha...@ietf.org
Subject: RE: [i2rs] Ignas Bagdonas' Discuss on 
draft-ietf-i2rs-yang-dc-fabric-network-topology-08: (with DISCUSS and COMMENT)

Ignas:

I'm not saying yes/no to change this model.  I've forwarded Yan's comments 
regarding changes to your specific issues.  Yan is very proactive.  It is 
likely that she will change most of the details if you respond to her.

I am acting as a shepherd/WG chair.  I'm trying to determine  Discuss Criteria 
are you using from the following document are you using to restrict I2RS models 
(dynamic + configuration capable) because there are TE specific models in the 
same area:
https://www.ietf.org/blog/discuss-criteria-iesg-review/

This goes against the design criteria I2RS has used.

You asked for text sequences that lead me to this conclusion:
(1st thread):
 [Ignas] > Excellent. Please get feedback from user community - even if it is 
not yet implemented and operations groups will not be able to provide feedback, 
architecture and engineering groups look into upcoming things and will have 
what to say.

[Sue]: (Repeating earlier comments from email and shepherd's  )  We obtain a 
vendor (Huawei) and a target deployment situation (Data Centers) with two 
potential data centers in China who wanted to work with this type of logical 
deployment.   To this shepherd's eyes, this is the operational information.

[Sue] (new clarifying comments): If you are still objecting, what else do you 
want as proof that the WG did due diligence on obtaining the operational 
feedback for deployment of a model which has I2RS capabilities (dynamic and
configuration) must be judged against any TE (configuration only ) data models.

(2) Further indication that you are comparing I2RS data models against the 4 TE 
models without a consideration to dynamic datastore design issues:

[Sue's comment]:  3rd - How many of the user community have implemented I2RS 
dynamic models or the RFC version of the TE models?

[Ignas] I am aware of 1 I2RS model family implementation. I am aware of 4 TE 
model implementations that I happen to use daily, and aware of several more 
that I do not deal with. And I am not certain what value such counting of 
implementations brings to this discussion.

Summary of my question:
I2RS models (configuration and dynamic) are different than regular TE models 
and you are lumping the I2RS models in with the configuration datastore TE 
models.  Please provide me with the DISCUSS criteria or RFCs you are using to 
make categorization.

After we settle on these issues, we can go on to the other comments.

Sue Hares

-Original Message-
From: I

Re: [i2rs] Warren Kumari's No Objection on draft-ietf-i2rs-rib-data-model-10: (with COMMENT)

[Susan Hares]

Warren:

 

I cannot find your original text - so I hope this email finds you quickly.  

 

As the shepherd reviewer, I'll encourage the authors to fix the nits.  Thank
you.  Do you want re-review any of issues before publication? 

 

Susan Hares 

--

 

On the large question, see below. 

 

I do have a large question, a comment,  and a bunch of nits:

1: Question:

o  NEXTHOP_LB_WEIGHT: This is used for load-balancing.  Each list

  member MUST be assigned a weight between 1 and 99.  The weight

  determines the proportion of traffic to be sent over a nexthop

  used for forwarding as a ratio of the weight of this nexthop

  divided by the weights of all the nexthops of this route that are

  used for forwarding.  To perform equal load-balancing, one MAY

  specify a weight of "0" for all the member nexthops.  The value

  "0" is reserved for equal load-balancing and if applied, MUST be

  applied to all member nexthops.

 

I'm confused what makes 0 special -- if I have e.g 17 links and I assign a
weight of e.g 42 to each of them I'll still get equal load-balancing, yes?

 

Why is 0 reserved? I get that having one link with a weigh of e.g 12 and
another link with a weight of 0 that would cause issues, but perhaps 0
should simply be unusable?

I a: really don't understand and b: thing the document should have some text
answering this.

 

Sue: I agree the document should have text that resolves discusses why zero
is unique.  

 

My recollection of 3 years ago - is that that "0" was utilized by many RIB
functions as a unique case.  In order to ease gluing this to the current
operational RIBS, the "zero" value was deemed as reserved. In doing the text
update, I will go back to past chairs (Alia Atlas and Jeff Haas) to get
context.  Or you can send Alia an Email. 

[Sigh - this would have been easier in March]. 

 

2: Comment: Section 7.1.  Using route preference

The entire "Route preference can also be used..." paragraph, while true,
feels very out of place. I'd suggest jsut removing it. 

 

I'll review this with the authors and send  proposed text.   This paragraph
was suggested to be insert in some past reviews.  [Sigh] 

 

___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

Re: [i2rs] Adam Roach's No Objection on draft-ietf-i2rs-rib-data-model-10: (with COMMENT)

[Susan Hares]

Adam:

Good catch.  If you see any others, please let me know.  This initially was a 
"hack" to provide references.  We'll go with the yang:mac-address for the MAC 
Address.  

 I will also ask the RTG-DIR whether we should make this an index into the 
actual MACS.  I do not think that is appropriate, but it is worth a question to 
the RTG-DIR and OPS-DIR. 

We will move this references to the standard references that Martin mentioned 
in his email. 

   inet:ipv6-flow-label
   yang:mac-address

I really appreciate all the new reviews on this draft.  Due to the history on 
this draft, please mention any questionable references you might have notice. I 
will track them down. 

Susan Hares 

-Original Message-
From: Adam Roach [mailto:a...@nostrum.com] 
Sent: Thursday, April 5, 2018 12:39 AM
To: The IESG
Cc: draft-ietf-i2rs-rib-data-mo...@ietf.org; Susan Hares; i2rs-cha...@ietf.org; 
sha...@ndzh.com; i2rs@ietf.org
Subject: Adam Roach's No Objection on draft-ietf-i2rs-rib-data-model-10: (with 
COMMENT)

Adam Roach has entered the following ballot position for
draft-ietf-i2rs-rib-data-model-10: No Objection

When responding, please keep the subject line intact and reply to all email 
addresses included in the To and CC lines. (Feel free to cut this introductory 
paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-i2rs-rib-data-model/



--
COMMENT:
--


This is similar enough to Suresh's DISCUSS that I don't see the point in making 
it a DISCUSS also (which it would be otherwise). I'll let him make sure field 
size issues are taken care of.

>case mac-route {
>  description
>"MAC route case.";
>  leaf mac-address {
>type uint32 ;
>mandatory true;
>description
>  "The MAC address used for matching.";
>  }
>}

The intention here is to use IEEE EUI-48 and/or EUI-64 identifiers here, right?
These don't fit into a uint32.

This problem arises elsewhere in the module; e.g.:

>  leaf ieee-mac-address {
>type uint32;
>mandatory true;
>description
>  "The nexthop points to an interface with
>   a specific mac-address.";
>  }

===

§2.6:

>Nexthops can be fully resolved or an unresolved.

Nit: remove "an"

---

§3:

>  import ietf-interfaces {
>prefix if;
>reference "RFC 7223";
>  }
>
>  import ietf-yang-types {
>prefix yang;
>reference "RFC 6991";
>  }

The indenting of the "reference" fields seems odd.


>  identity ipv6-decapsulation {
>base "tunnel-decapsulation-action";
>description
>  "IPv4 tunnel decapsulation.";
>  }

The description here appears to be incorrect (should say "IPv6")


>  identity decrease-and-copy-to-next {
>base "ttl-action";
>description
>  "Decrease TTL by one and copy the TTL
>   to the next header.For example: when
>   MPLS label swapping, decrease the TTL
>   of the inner label and copy it to the
>   outer label.";
>  }

Nit: insert a space before "For".


>  identity resolved {
>base "nexthop-state";
>description
>  "Reolved nexthop state.";
>  }

Nit: "Resolved" rather than "Reolved."


>  typedef nexthop-lb-weight-definition {
>type uint8 {
>  range "1..99";
>}
>description
>  "Nexthop-lb-weight is used for load-balancing.
>   Each list member MUST be assigned a weight
>   between 1 and 99. The weight determines the
>   proportion of traffic to be sent over a nexthop
>   used for forwarding as a ratio of the weight of
>   this nexthop divided by the weights of all the
>   nexthops of this route that are used for forwarding.
>   To perform equal load-balancing, one MAY specify
>   a weight of 0 for all the member nexthops.  The
>   value 0 is reserved for equal load-balancing
>   and if applied, MUST be applied to all member nexthops.";  }

To match the text (which allows 0 as a special case), the range needs to be 
updated to be "0..99" rather than "1..99"


>

Re: [i2rs] Suresh Krishnan's Discuss on draft-ietf-i2rs-rib-data-model-10: (with DISCUSS and COMMENT)

[Susan Hares]

Martin:

Thank you for the proactive response on the types.  I'll work with the
authors to change to these standard types.   

Sue 

-Original Message-
From: Martin Bjorklund [mailto:m...@tail-f.com] 
Sent: Thursday, April 5, 2018 10:06 AM
To: sha...@ndzh.com
Cc: sur...@kaloom.com; i...@ietf.org; i2rs@ietf.org;
draft-ietf-i2rs-rib-data-mo...@ietf.org; i2rs-cha...@ietf.org
Subject: Re: [i2rs] Suresh Krishnan's Discuss on
draft-ietf-i2rs-rib-data-model-10: (with DISCUSS and COMMENT)

Hi,

There are standard types for IPv6 flow label and for MAC addresses defined
in RFC 6991:

   inet:ipv6-flow-label
   yang:mac-address 


/martin


"Susan Hares" <sha...@ndzh.com> wrote:
> Suresh:
> 
> Thank you for catching these issues.   I missed these as a Shepherd (as
did
> the other reviewers) and AD.  See my answers below. 
> 
> Would you or Martin hold a discuss until these critical issues are 
> resolved and checked with the YANG doctors?  I will work with the authors
to resolve
> these issues.   This revision will take some time as we seek advice from
the
> YANG doctors and from the community on the IEEE MAC Address being an 
> index or a full MAC Address.
> 
> Susan Hares
> 
> -Original Message-
> From: i2rs [mailto:i2rs-boun...@ietf.org] On Behalf Of Suresh Krishnan
> Sent: Wednesday, April 4, 2018 12:39 AM
> To: The IESG
> Cc: i2rs@ietf.org; draft-ietf-i2rs-rib-data-mo...@ietf.org;
> i2rs-cha...@ietf.org; sha...@ndzh.com
> Subject: [i2rs] Suresh Krishnan's Discuss on
> draft-ietf-i2rs-rib-data-model-10: (with DISCUSS and COMMENT)
> 
> Suresh Krishnan has entered the following ballot position for
> draft-ietf-i2rs-rib-data-model-10: Discuss
> 
> When responding, please keep the subject line intact and reply to all 
> email addresses included in the To and CC lines. (Feel free to cut 
> this introductory paragraph, however.)
> 
> 
> Please refer to 
> https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-i2rs-rib-data-model/
> 
> 
> 
> --
> DISCUSS:
> --
> 
> This model tries to squeeze the 20 bit IPv6 flow label into a 16 bit
field.
> This will result in a loss of data and needs to be fixed before the 
> document is published.
> 
> 
> --
> COMMENT:
> --
> 
> * Section 3
> 
> => Under
> 
> identity ipv6-decapsulation {
> 
> it looks like the description is wrong ("IPv4 tunnel decapsulation.")
> 
> You are correct.  It will be replaced with the following =
>identity ipv6-decapsulation {
>  base "tunnel-decapsulation-action";
>  description
>"IPv6 tunnel decapsulation.";
>}
> 
> =>  What use case is the ttl-action decrease-and-copy-to-inner used for?
> 
> Good catch! 
> This feature may be used for tunnels (7.2.1 of
> draft-ietf-i2rs-rib-info-model) or nexthops chains (section 7.2.5 of
> draft-ietf-i2rs-rib-info-model).   Good catch in that it does not provide
> enough detail in this version.  
> 
> We've had comments over the last years to put this level of detail in 
> or out of the YANG model.  I believe the latest wisdom from 
> NETMOD/NETCONF is to put the level of detail back in
>  
> => Under case egress-interface-mac-nexthop {
> 
> It is not clear to me how you fit a MAC address into a 32 bit space ,or am
I
> misreading this somehow and this is some form of index?   
> 
> Good Catch. 
> 
> Early on it was a holding place for a the official IEEE:MAC table, and 
> should have been transferred to either the IEEE:MAC-ADDRESS (see page 
> 17 RIB-INFO draft). However, this definitely needs to get fixed.  I 
> need to check with the YANG Doctors to determine which is the 
> preferred fix for this reference at this time.  I'm sure implementers 
> have been using a fully qualified IEEE_MAC_ADDRESS or a reference to the
Table.
> 
> High level - case points to an outgoing interface, ieee-mac address -
> 
>case egress-interface-mac-nexthop {
>  container egress-interface-mac-address {
>leaf outgoing-interface {
>  type if:interface-ref;
>  mandatory true;
>  description
>"Name of the outgoing interface.";
>}
>leaf ieee-mac-address {

Re: [i2rs] Suresh Krishnan's No Objection on draft-ietf-i2rs-rib-info-model-15: (with COMMENT)

[Susan Hares]

Suresh:

Thank you for catching these errors.  See my comments below.  

Summary: 
Section 2.3 (good catch).  
Section 4 and 6 - I think the document represents the WG consensus.  I will
review the emails, WG documents, and contact previous chairs. 

Susan Hares 

-Original Message-
From: i2rs [mailto:i2rs-boun...@ietf.org] On Behalf Of Suresh Krishnan
Sent: Thursday, April 5, 2018 1:08 AM
To: The IESG
Cc: i2rs@ietf.org; i2rs-cha...@ietf.org; sha...@ndzh.com;
draft-ietf-i2rs-rib-info-mo...@ietf.org
Subject: [i2rs] Suresh Krishnan's No Objection on
draft-ietf-i2rs-rib-info-model-15: (with COMMENT)

Suresh Krishnan has entered the following ballot position for
draft-ietf-i2rs-rib-info-model-15: No Objection

When responding, please keep the subject line intact and reply to all email
addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-i2rs-rib-info-model/



--
COMMENT:
--

* Section 2.3.

Regarding the OSPF route for 2001:DB8::1/32

Did you mean 2001:DB8::1/128 for the host route? If not, this example is
wrong since 2001:DB8::1/32 expands to 2001:DB8::::::1/32
->
2001:DB8::/32 as the route

Sue: Yes - this is an error. 

* Figure 4.

Shouldn't the tunnel-encap and tunnel-decap also loop the packet back into
nexthop processing just like the derived nexthops do?

Suresh - I need to check the email list archives and get back to you on this
point.  My recollection was that there was a case where things  people did
not want to automatically loop this  back. However, I cannot bring the
discussion of 3.5 years ago to mind. I will take this as an action item as a
reviewer to try to recreate the discussion.   Thank you for mentioning this
point. It is important to clarify in either case. 

* Section 6

I would have expected the match type to have some indication about whether
it requires an exact match or LPM (e.g. A MAC route uses an exact match but
an
IPv6 route uses LPM). Has the WG discussed this?

The short answer is yes, extensive in early interims, list discussions and
in session.  Can you provide more depth to your questions.  For the early
discussions, I may need to query Alia Atlas and Jeff Haas (previous chairs)
to get the institutional memory on this topic.  (One of the reason I really
want to have this document discussed with Alia Atlas as AD0. 


___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

[i2rs] FW: [Gen-art] Genart last call review of draft-ietf-i2rs-rib-info-model-14

[Susan Hares]

Alissa:

 

Here’s Nitin’s response to Peter. 

 

Sue Hares 

 

From: i2rs [mailto:i2rs-boun...@ietf.org] On Behalf Of Nitin Bahadur
Sent: Friday, March 23, 2018 2:55 AM
To: pe...@akayla.com
Cc: i2rs@ietf.org
Subject: Re: [i2rs] [Gen-art] Genart last call review of 
draft-ietf-i2rs-rib-info-model-14

 

Hi Peter,

 

  Thanks for the Gen-art review. Sorry it missed my attention back when you 
sent it. Please see NB> below for comments.

 

 

Reviewer: Peter Yee
Review result: Ready with Issues
 
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.
 
For more information, please see the FAQ at
<  
https://trac.ietf.org/trac/gen/wiki/GenArtfaq>;.
 
Document: draft-ietf-i2rs-rib-info-model-14
Reviewer: Peter Yee
Review Date: 2018-02-22
IETF LC End Date: 2018-02-23
IESG Telechat date: 2018-03-08
 
Summary: This Informational draft specifies an information model for routing
information bases, providing modeling of the internal information of a router
or similar network device.  The draft is mostly ready, but has some issues that
should be considered. [Ready with issues]
 
Major issues: None
 
Minor issues:
 
Page 4, 3rd full paragraph, 1st sentence: the draft introduces the concept of
"RIB clients" in Figure 1, notes that they are generally routing protocols, and
then never uses the term again.  All other references to the what must be the
users of the northbound interface are then called "external entities" for the
most part.  This is confusing because the term "external entity" is not defined
nor fully equated with "RIB client".  The term also seems to indicate that the
"external entity" is not necessarily running on the network device.  While that
might be one way of looking at the feeding of data into the RIB via NETCONF or
RESTCONF, that doesn't seem to be the case for a routing protocol.  A fuller
explanation of the users of the northbound interface and a revision to Figure 1
might help clarify this situation.
 
NB> You are right. I’m updating the draft to replace “external entities” to 
“RIB client”.
 
Page 7, 1st paragraph after bullet list, last sentence: Routing instances are
identified by ROUTER_IDs anyhow, so this sentence seems superfluous. 
Perhaps you are trying to get across the point that the ROUTER_ID (which is 
definitely
present for the router) is not *used* by this routing instance.
 
NB> That sentence was requested by some folks to ensure that ROUTER_ID based 
conflicts do not occur.
 
The term "ethernet" is used in several places in the document.  Except in the
grammar of section 6, change these to the capitalized "Ethernet". 
 
NB> Done
 
This brings up a larger point, however.  Not all IEEE MAC addresses are 
associated with
Ethernet interfaces and I believe this document is expected to be applicable to
other IEEE 802 MACs such as IEEE 802.11 (WLAN) and IEEE 802.15 (WPAN).  IEEE
802.15 has long and short forms of MAC addresses, so you may want to give some
additional thought to what you want to say with this term and pick something
more appropriate.
 
NB> In Section 2.4.1, when talking about the IEEE MAC we say that “The egress 
interface 
must be an Ethernet interface.” So the MAC is to be used only in the context of 
Ethernet interfaces.
 
NB> With regards to short and long form of MAC addresses, these should get 
specified in the data-model, 
since the data-model will need to validate things.
 
I think there's a discussion missing that may or may not be within scope of
this document.  RIBs appear to be typically divided according to the protocol
for which they are providing routing (IPv4, MPLS, etc.)  Section 7.1 discusses
routing preferences, with an example of OSPF route and a route from some other
protocol.  When the OSPF route is withdrawn, the other route is installed in
the FIB.  What's not clear is what makes the decision to do this and cause a
specific RIB to push its route into the FIB.  Is that the routing instance or
the RIB manager? 
 
NB> It should be the RIB manager.
 
 A routing instance is described as a set of interfaces, RIBs,
and routing parameters.  It's description does not make it clear that it
arbitrates among the RIBs or the routing protocols which are using the
northbound interface to talk to the RIB manager.  Figure 1 makes it seem like
there is a RIB manger per RIB, in which case how can the RIB manager make
decisions between multiple RIBs?
 
NB> Good point. I’ll change the figure to indicate that the RIB manager handles 
1 or more RIBs.
 
Page 14, Section 3, 2nd paragraph, 2nd sentence: a "connection" is mentioned
here.  This document purports to deal with an API (and one that would mostly be
used by local routing protocols if the figures are to be believed) and hasn't
otherwise made any mention of a connection, let 

Re: [i2rs] Suresh Krishnan's Discuss on draft-ietf-i2rs-rib-data-model-10: (with DISCUSS and COMMENT)

[Susan Hares]

Suresh:

Thank you for catching these issues.   I missed these as a Shepherd (as did
the other reviewers) and AD.  See my answers below. 

Would you or Martin hold a discuss until these critical issues are resolved
and checked with the YANG doctors?  I will work with the authors to resolve
these issues.   This revision will take some time as we seek advice from the
YANG doctors and from the community on the IEEE MAC Address being an index
or a full MAC Address. 

Susan Hares

-Original Message-
From: i2rs [mailto:i2rs-boun...@ietf.org] On Behalf Of Suresh Krishnan
Sent: Wednesday, April 4, 2018 12:39 AM
To: The IESG
Cc: i2rs@ietf.org; draft-ietf-i2rs-rib-data-mo...@ietf.org;
i2rs-cha...@ietf.org; sha...@ndzh.com
Subject: [i2rs] Suresh Krishnan's Discuss on
draft-ietf-i2rs-rib-data-model-10: (with DISCUSS and COMMENT)

Suresh Krishnan has entered the following ballot position for
draft-ietf-i2rs-rib-data-model-10: Discuss

When responding, please keep the subject line intact and reply to all email
addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-i2rs-rib-data-model/



--
DISCUSS:
--

This model tries to squeeze the 20 bit IPv6 flow label into a 16 bit field.
This will result in a loss of data and needs to be fixed before the document
is published.


--
COMMENT:
--

* Section 3

=> Under

identity ipv6-decapsulation {

it looks like the description is wrong ("IPv4 tunnel decapsulation.")

You are correct.  It will be replaced with the following
=
   identity ipv6-decapsulation {
 base "tunnel-decapsulation-action";
 description
   "IPv6 tunnel decapsulation.";
   }

=>  What use case is the ttl-action decrease-and-copy-to-inner used for?

Good catch! 
This feature may be used for tunnels (7.2.1 of
draft-ietf-i2rs-rib-info-model) or nexthops chains (section 7.2.5 of
draft-ietf-i2rs-rib-info-model).   Good catch in that it does not provide
enough detail in this version.  

We've had comments over the last years to put this level of detail in or out
of the YANG model.  I believe the latest wisdom from NETMOD/NETCONF is to
put the level of detail back in 
 
=> Under case egress-interface-mac-nexthop {

It is not clear to me how you fit a MAC address into a 32 bit space ,or am I
misreading this somehow and this is some form of index?   

Good Catch. 

Early on it was a holding place for a the official IEEE:MAC table, and
should have been transferred to either the IEEE:MAC-ADDRESS (see page 17
RIB-INFO draft). However, this definitely needs to get fixed.  I need to
check with the YANG Doctors to determine which is the preferred fix for this
reference at this time.  I'm sure implementers have been using a fully
qualified IEEE_MAC_ADDRESS or a reference to the Table. 

High level - case points to an outgoing interface, ieee-mac address - 

   case egress-interface-mac-nexthop {
 container egress-interface-mac-address {
   leaf outgoing-interface {
 type if:interface-ref;
 mandatory true;
 description
   "Name of the outgoing interface.";
   }
   leaf ieee-mac-address {
 type uint32;
 mandatory true;
 description
   "The nexthop points to an interface with
a specific mac-address.";
   }
   description
 "The egress interface must be an Ethernet
  interface. Address resolution is not required
  for this nexthop.";
 }
   }

It is not clear to me how you fit a MAC address into a 32 bit space ,or am I
misreading this somehow and this is some form of index?

"   leaf ieee-mac-address {
  type uint32;"


___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

Re: [i2rs] [Gen-art] Genart last call review of draft-ietf-i2rs-rib-info-model-14

[Susan Hares]

Peter and Alissa: 

Thank you for your careful review.  I believe I saw Nitin's reply to Peter's 
comments in email - so I'll look for that email and forward it. 

As Shepherd, I will work with the authors to try to address the issues in 2.2, 
and section 5. 

>I think there's a discussion missing that may or may not be within scope of
>this document.  RIBs appear to be typically divided according to the protocol
>for which they are providing routing (IPv4, MPLS, etc.)  Section 7.1 discusses
>routing preferences, with an example of OSPF route and a route from some other
>protocol.  When the OSPF route is withdrawn, the other route is installed in
>the FIB.  What's not clear is what makes the decision to do this and cause a
>specific RIB to push its route into the FIB.  Is that the routing instance or
>the RIB manager?  A routing instance is described as a set of interfaces, RIBs,
>and routing parameters.  It's description does not make it clear that it
>arbitrates among the RIBs or the routing protocols which are using the
>northbound interface to talk to the RIB manager.  Figure 1 makes it seem like
>there is a RIB manger per RIB, in which case how can the RIB manager make
>decisions between multiple RIBs?

There is a RIB manager per RIB, but there is an overall RIB policy that 
determines how the RIBs install things in specific FIBs. The specific policy 
and issues may be guided by defacto standards (E.g. open-source implementations 
or copying of a methodology among vendors).  However, it is a implementation 
detail.   We'll try to work on a set of text that explains this feature. 

As Warren indicated this progresses into a nice introductions to how RIBS work 
for University or for new hires.  We'll work together to get some text to 
explain this in the next revision. 

Cheerily, Sue 

-Original Message-
From: i2rs [mailto:i2rs-boun...@ietf.org] On Behalf Of Alissa Cooper
Sent: Thursday, April 5, 2018 9:31 AM
To: Peter Yee
Cc: i2rs@ietf.org; IETF Gen-ART; draft-ietf-i2rs-rib-info-model@ietf.org
Subject: Re: [i2rs] [Gen-art] Genart last call review of 
draft-ietf-i2rs-rib-info-model-14

Peter, thanks for your review. Authors, thanks for addressing some of Peter’s 
comments. I tried to pick out those of his comments that remain unaddressed and 
put them in my No Objection ballot.

Alissa

> On Feb 23, 2018, at 8:35 PM, Peter Yee  wrote:
> 
> Reviewer: Peter Yee
> Review result: Ready with Issues
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area 
> Review Team (Gen-ART) reviews all IETF documents being processed by 
> the IESG for the IETF Chair.  Please treat these comments just like 
> any other last call comments.
> 
> For more information, please see the FAQ at
> 
> .
> 
> Document: draft-ietf-i2rs-rib-info-model-14
> Reviewer: Peter Yee
> Review Date: 2018-02-22
> IETF LC End Date: 2018-02-23
> IESG Telechat date: 2018-03-08
> 
> Summary: This Informational draft specifies an information model for 
> routing information bases, providing modeling of the internal 
> information of a router or similar network device.  The draft is 
> mostly ready, but has some issues that should be considered. [Ready 
> with issues]
> 
> Major issues: None
> 
> Minor issues:
> 
> Page 4, 3rd full paragraph, 1st sentence: the draft introduces the 
> concept of "RIB clients" in Figure 1, notes that they are generally 
> routing protocols, and then never uses the term again.  All other 
> references to the what must be the users of the northbound interface 
> are then called "external entities" for the most part.  This is 
> confusing because the term "external entity" is not defined nor fully 
> equated with "RIB client".  The term also seems to indicate that the 
> "external entity" is not necessarily running on the network device.  
> While that might be one way of looking at the feeding of data into the 
> RIB via NETCONF or RESTCONF, that doesn't seem to be the case for a 
> routing protocol.  A fuller explanation of the users of the northbound 
> interface and a revision to Figure 1 might help clarify this situation.
> 
> Page 7, 1st paragraph after bullet list, last sentence: Routing 
> instances are identified by ROUTER_IDs anyhow, so this sentence seems 
> superfluous.  Perhaps you are trying to get across the point that the 
> ROUTER_ID (which is definitely present for the router) is not *used* by this 
> routing instance.
> 
> The term "ethernet" is used in several places in the document.  Except 
> in the grammar of section 6, change these to the capitalized 
> "Ethernet".  This brings up a larger point, however.  Not all IEEE MAC 
> addresses are associated with Ethernet interfaces and I believe this 
> document is expected to be applicable to other IEEE 802 MACs such as 
> IEEE 802.11 (WLAN) and IEEE 802.15 (WPAN).  IEEE
> 802.15 has long and short forms of MAC addresses, so you may want to 
> give some 

Re: [i2rs] Suresh Krishnan's No Objection on draft-ietf-i2rs-rib-info-model-15: (with COMMENT)

[Susan Hares]

Suresh: 

On WG discussions, 

LPM = Longest prefix match?   If so, LPM was discussed. 

I will follow-up with the authors on resolving this in section 6.  Thanks for 
catching this error. 

Cheerily, Sue 

-Original Message-
From: Suresh Krishnan [mailto:sur...@kaloom.com] 
Sent: Thursday, April 5, 2018 1:08 AM
To: The IESG
Cc: draft-ietf-i2rs-rib-info-mo...@ietf.org; Susan Hares; i2rs-cha...@ietf.org; 
sha...@ndzh.com; i2rs@ietf.org
Subject: Suresh Krishnan's No Objection on draft-ietf-i2rs-rib-info-model-15: 
(with COMMENT)

Suresh Krishnan has entered the following ballot position for
draft-ietf-i2rs-rib-info-model-15: No Objection

When responding, please keep the subject line intact and reply to all email 
addresses included in the To and CC lines. (Feel free to cut this introductory 
paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-i2rs-rib-info-model/



--
COMMENT:
--

* Section 2.3.

Regarding the OSPF route for 2001:DB8::1/32

Did you mean 2001:DB8::1/128 for the host route? If not, this example is wrong 
since 2001:DB8::1/32 expands to 2001:DB8::::::1/32 ->
2001:DB8::/32 as the route

* Figure 4.

Shouldn't the tunnel-encap and tunnel-decap also loop the packet back into 
nexthop processing just like the derived nexthops do?

* Section 6

I would have expected the match type to have some indication about whether it 
requires an exact match or LPM (e.g. A MAC route uses an exact match but an
IPv6 route uses LPM). Has the WG discussed this?



___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

Re: [i2rs] Ignas Bagdonas' No Objection on draft-ietf-i2rs-rib-info-model-15: (with COMMENT)

[Susan Hares]

Ignas:

Thank you for your comments.  I will check that these are addressed in the next 
version. 

Cheerily, Susan Hares

-Original Message-
From: Ignas Bagdonas [mailto:ibagd...@gmail.com] 
Sent: Thursday, April 5, 2018 8:01 AM
To: The IESG
Cc: draft-ietf-i2rs-rib-info-mo...@ietf.org; Susan Hares; i2rs-cha...@ietf.org; 
sha...@ndzh.com; i2rs@ietf.org
Subject: Ignas Bagdonas' No Objection on draft-ietf-i2rs-rib-info-model-15: 
(with COMMENT)

Ignas Bagdonas has entered the following ballot position for
draft-ietf-i2rs-rib-info-model-15: No Objection

When responding, please keep the subject line intact and reply to all email 
addresses included in the To and CC lines. (Feel free to cut this introductory 
paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-i2rs-rib-info-model/



--
COMMENT:
--

A few nits:

Terminology: rib family vs address family. Address family term is more widely 
used in the industry.

VPLS is a subset of L2VPN.

ROUTER_ID usage is orthogonal to router virtualization. MUST restriction for 
the domain is factually incorrect - it is typically per source protocol, not 
per domain.



___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

Re: [i2rs] Benjamin Kaduk's No Objection on draft-ietf-i2rs-rib-info-model-15: (with COMMENT)

[Susan Hares]

Benjamin: 

Thank you for your comments.  The authors work will to clarify this portion. 

As I recall (and my memory may be spotty), the reason was available for both 
"yes" and "no" in case "yes" it is active, and "no" it is not installed 
(example - 20 ECMP routes and only 10 get installed).   Nitin may have more 
details on this RFC. 

Cheerily, Susan Hares

-Original Message-
From: Benjamin Kaduk [mailto:ka...@mit.edu] 
Sent: Wednesday, April 4, 2018 9:37 PM
To: The IESG
Cc: draft-ietf-i2rs-rib-info-mo...@ietf.org; Susan Hares; i2rs-cha...@ietf.org; 
sha...@ndzh.com; i2rs@ietf.org
Subject: Benjamin Kaduk's No Objection on draft-ietf-i2rs-rib-info-model-15: 
(with COMMENT)

Benjamin Kaduk has entered the following ballot position for
draft-ietf-i2rs-rib-info-model-15: No Objection

When responding, please keep the subject line intact and reply to all email 
addresses included in the To and CC lines. (Feel free to cut this introductory 
paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-i2rs-rib-info-model/



--
COMMENT:
--

I share Warren's question (and, IIRC, asked a similar one about the associated 
data-model document).

Just one other minor question: in Section 4

   Route programming in the RIB MUST result in a return code that
   contains the following attributes:

   o  Installed - Yes/No (Indicates whether the route got installed in
  the FIB)

   o  Active - Yes/No (Indicates whether a route is fully resolved and
  is a candidate for selection)

   o  Reason - e.g., Not authorized

Is the Reason only relevant when one of the other two is "No"?



___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

Re: [i2rs] Mirja Kühlewind's No Objection on draft-ietf-i2rs-yang-dc-fabric-network-topology-08: (with COMMENT)

[Susan Hares]

Mirja:

Thank you for mentioning the boilerplate.  I'll work with the authors to 
address in this in the next revision. 

Cheerily, Susan Hares

-Original Message-
From: Mirja Kühlewind [mailto:i...@kuehlewind.net] 
Sent: Wednesday, April 4, 2018 2:00 PM
To: The IESG
Cc: draft-ietf-i2rs-yang-dc-fabric-network-topol...@ietf.org; Susan Hares; 
i2rs-cha...@ietf.org; sha...@ndzh.com; i2rs@ietf.org
Subject: Mirja Kühlewind's No Objection on 
draft-ietf-i2rs-yang-dc-fabric-network-topology-08: (with COMMENT)

Mirja Kühlewind has entered the following ballot position for
draft-ietf-i2rs-yang-dc-fabric-network-topology-08: No Objection

When responding, please keep the subject line intact and reply to all email 
addresses included in the To and CC lines. (Feel free to cut this introductory 
paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-dc-fabric-network-topology/



--
COMMENT:
--

Please use RFC 8174 boilerplate!



___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

Re: [i2rs] Mirja Kühlewind's No Objection on draft-ietf-i2rs-rib-data-model-10: (with COMMENT)

[Susan Hares]

Mirja and Alissa:

I will work with the authors addressing this in the next revision. 

Cheerily, Susan Hares

-Original Message-
From: Mirja Kühlewind [mailto:i...@kuehlewind.net] 
Sent: Wednesday, April 4, 2018 2:11 PM
To: The IESG
Cc: draft-ietf-i2rs-rib-data-mo...@ietf.org; Susan Hares; i2rs-cha...@ietf.org; 
sha...@ndzh.com; i2rs@ietf.org
Subject: Mirja Kühlewind's No Objection on draft-ietf-i2rs-rib-data-model-10: 
(with COMMENT)

Mirja Kühlewind has entered the following ballot position for
draft-ietf-i2rs-rib-data-model-10: No Objection

When responding, please keep the subject line intact and reply to all email 
addresses included in the To and CC lines. (Feel free to cut this introductory 
paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-i2rs-rib-data-model/



--
COMMENT:
--

I agree with Alissa's comments on use of normative language.



___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

Re: [i2rs] Opsdir early review of draft-ietf-i2rs-rib-data-model-10

[Susan Hares]

Sarah:

Thank you for your comments.   These are helpful.  

As a Shepherd, I'll help the authors address your comments in the latest
revision. 

On #1) The nexthop chains are described in detail in
draft-ietf-i2rs-rib-info-model in section 7.2.5.  Would reference in the
appropriate place provide the necessary detail or would you like additional
comments added? 

On #2) Thank you for mentioning this point.  I will work with the authors to
reduce the Nits. 

On #3) Thank you for mentioning this point. 

The longer list of authors was vetted with the AD due to the combination of
multiple drafts into 1.  Since we cleared this with the AD early in the
process, it seems unreasonable to change it at this point.  

Susan Hares


-Original Message-
From: Sarah Banks [mailto:sba...@encrypted.net] 
Sent: Wednesday, April 4, 2018 4:50 PM
To: ops-...@ietf.org
Cc: i2rs@ietf.org; draft-ietf-i2rs-rib-data-model@ietf.org;
i...@ietf.org
Subject: Opsdir early review of draft-ietf-i2rs-rib-data-model-10

Reviewer: Sarah Banks
Review result: Has Nits

I have reviewed this document as part of the Operational directorate's
ongoing effort to review all IETF documents being processed by the IESG.
These comments were written with the intent of improving the operational
aspects of the IETF drafts. Comments that are not addressed in last call may
be included in AD reviews during the IESG review.  Document editors and WG
chairs should treat these comments just like any other last call comments.

Upon review, I think the document is in decent shape, but needs work in the
WG first. There are 3 things I'd like to point out:

1. There are areas in the document where we assume the reader knows , but
the document text could be helped if the authors were more concise in their
wording. For example:

"At the same time, nexthop chains can be used to specify multiple  headers
over a packet, before that particular packet is forwarded. Not every network
device will be able to support all kinds of nexthop chains along with the
arbitrary number of headers which are chained together."

I would think that while this might often be true, it doesn't have to always
be true, and depending on how wide the domain is, it might not be true. I
realize this isn't written with normative language, and it's a minor point,
but it lacks precision.

2. Nits has issues. Yup, a lot of authors think we'll just toss it in the
queue and let the RFC Editors fix this, but I think it's our job to be
sending clean docs into the queue. We pay for the RFC Editors service, why
have them spending time on things we have a tool that allows the authors to
do this for themselves? Fix your nits. :)

3. The document violates the number of named authors at the top - another
expense of RFC Editors time and effort I don't think we should be doing. I'd
prefer to see the authors/WG/WG Chairs address these items before they go
into the queue.

Thanks
Sarah



___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

Re: [i2rs] Ignas Bagdonas' Discuss on draft-ietf-i2rs-yang-dc-fabric-network-topology-08: (with DISCUSS and COMMENT)

[Susan Hares]

Ignas:

I'm not saying yes/no to change this model.  I've forwarded Yan's comments 
regarding changes to your specific issues.  Yan is very proactive.  It is 
likely that she will change most of the details if you respond to her. 

I am acting as a shepherd/WG chair.  I'm trying to determine  Discuss Criteria 
are you using from the following document are you using to restrict I2RS models 
(dynamic + configuration capable) because there are TE specific models in the 
same area:  
https://www.ietf.org/blog/discuss-criteria-iesg-review/

This goes against the design criteria I2RS has used. 

You asked for text sequences that lead me to this conclusion: 
(1st thread): 
 [Ignas] > Excellent. Please get feedback from user community - even if it is 
not yet implemented and operations groups will not be able to provide feedback, 
architecture and engineering groups look into upcoming things and will have 
what to say.

[Sue]: (Repeating earlier comments from email and shepherd's  )  We obtain a 
vendor (Huawei) and a target deployment situation (Data Centers) with two 
potential data centers in China who wanted to work with this type of logical 
deployment.   To this shepherd's eyes, this is the operational information.   

[Sue] (new clarifying comments): If you are still objecting, what else do you 
want as proof that the WG did due diligence on obtaining the operational 
feedback for deployment of a model which has I2RS capabilities (dynamic and 
configuration) must be judged against any TE (configuration only ) data models. 

(2) Further indication that you are comparing I2RS data models against the 4 TE 
models without a consideration to dynamic datastore design issues: 

[Sue's comment]:  3rd - How many of the user community have implemented I2RS 
dynamic models or the RFC version of the TE models?

[Ignas] I am aware of 1 I2RS model family implementation. I am aware of 4 TE 
model implementations that I happen to use daily, and aware of several more 
that I do not deal with. And I am not certain what value such counting of 
implementations brings to this discussion.

Summary of my question: 
I2RS models (configuration and dynamic) are different than regular TE models 
and you are lumping the I2RS models in with the configuration datastore TE 
models.  Please provide me with the DISCUSS criteria or RFCs you are using to 
make categorization.   

After we settle on these issues, we can go on to the other comments. 

Sue Hares 

-Original Message-
From: Ignas Bagdonas [mailto:ibagd...@gmail.com] 
Sent: Wednesday, April 4, 2018 2:40 PM
To: Susan Hares; 'The IESG'
Cc: i2rs@ietf.org; draft-ietf-i2rs-yang-dc-fabric-network-topol...@ietf.org; 
i2rs-cha...@ietf.org
Subject: Re: [i2rs] Ignas Bagdonas' Discuss on 
draft-ietf-i2rs-yang-dc-fabric-network-topology-08: (with DISCUSS and COMMENT)



On 04/04/2018 16:03, Susan Hares wrote:
> Ignas:
>
> I am not trying to clarify the specifics.  This response (as I mentioned), 
> will come from the authors.  As a shepherd/WG chair, I am asking for 
> information regarding the basis of your DISCUSS models for specific points.
>
> The 2014 document on the IESG discuss criteria is at:
> https://www.ietf.org/blog/discuss-criteria-iesg-review/
>
> What on this list does the following comment refer to:
> "Why DISCUSS? DC fabric is a type of network topology, yes, it has some 
> specifics, but nothing radically different than any purpose built network 
> topology. Developing a separate model for a specific use case at the same 
> time when there is generic and extensible TE model is questionable."
The fact that for managing similar functionality there appears to be a need for 
different models that would as a result require different model lifecycle 
management clearly falls into the category of operational issues.


> Perhaps you are not considering the fact this is an I2RS model.  Let me 
> provide 3 comments regaring that point:
I am considering the fact that this model defines configuration of something 
that is widely deployed in a way that is not compatible with how it is 
deployed. The fact that this may be I2RS model is not of the primary importance.

>   
> 1st - I2RS is focusing on models that are capable for the dynamic state and 
> configuration state.  These models have qualitative differences.  The 
> mechanisms of a model which does both dynamic state and configuration state 
> is qualitative different that the basic TE models. This model extends the TE 
> models toward this approach (see   module ietf-dc-fabric-topology reference 
> import of ietf-network-topology).
>
> 2nd - During the I2RS process we talked to the TE topology authors and the TE 
> WG.  We agreed that this model has differences.  As a WG Co-chair, I spent 
> time reviewing this interaction.
>
> 3rd - How many of the user community have implemented I2RS dynamic models or 
> the R

[i2rs] FW: Ignas Bagdonas' Discuss on draft-ietf-i2rs-yang-dc-fabric-network-topology-08: (with DISCUSS and COMMENT)

[Susan Hares]

Ignas:

 

I’m forwarding Yan’s specific answers to each of your questions. I had held 
this response back until I tried to learn more about what specific questions 
were tag with specific DISCUSS quality comments 

per the IESG 2014 DISCUSS criteria comments: 

https://www.ietf.org/blog/discuss-criteria-iesg-review/

 

I’m sure Yan will be glad to make adjustments in the draft (see below).  You 
will note that you are asking us to put back in RPCs that others had us take 
out.  

 

This leads me to back to my questions as a Shepherd. My concern is that many of 
your requested changes are counter to agreements in discussions with WG, TE WG, 
NETCONF/NETMOD, and previous ADS (OPS, RTG) regarding I2RS drafts.   Since 
these drafts were delayed due to the reading load of the IESG, it seems we are 
working under different rules.  So, please specify how your comments match the 
DISCUSS criteria.  If you are setting new rules for I2RS documents, please 
detail the new rules of review.   

 

It is too bad that we could not have reviewed these documents during their 
originally scheduled telechat with previous  ADs.  

 

Susan Hares 

 

-Original Message-
From: Ignas Bagdonas [mailto:ibagd...@gmail.com] 
Sent: Tuesday, April 03, 2018 7:40 PM
To: The IESG <i...@ietf.org>
Cc: draft-ietf-i2rs-yang-dc-fabric-network-topol...@ietf.org; Susan Hares 
<sha...@ndzh.com>; i2rs-cha...@ietf.org; sha...@ndzh.com; i2rs@ietf.org
Subject: Ignas Bagdonas' Discuss on 
draft-ietf-i2rs-yang-dc-fabric-network-topology-08: (with DISCUSS and COMMENT)

 

Ignas Bagdonas has entered the following ballot position for

draft-ietf-i2rs-yang-dc-fabric-network-topology-08: Discuss

 

When responding, please keep the subject line intact and reply to all email 
addresses included in the To and CC lines. (Feel free to cut this introductory 
paragraph, however.)

 

 

Please refer to  <https://www.ietf.org/iesg/statement/discuss-criteria.html> 
https://www.ietf.org/iesg/statement/discuss-criteria.html

for more information about IESG DISCUSS and COMMENT positions.

 

 

The document, along with other ballot positions, can be found here:

 
<https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-dc-fabric-network-topology/>
 
https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-dc-fabric-network-topology/

 

 

 

--

DISCUSS:

--

 

I have concerns about the practical usability of this proposed model as it is 
specified now.

 

The intended decoupling of fabric implementation properties (what is termed as 
"underlay network infrastructure" in the document) and its topology seems to be 
contradicting to general operational practices of fabric based networks. It is 
generally true for the context of the overlay but that is not what the document 
seems to be focusing on. Fabric defines and implements the underlay, not the 
other way around.

[Y] The intention of this model is to represent the entire topology of a data 
center fabric network. The whole network can be considered as a single fabric 
network which is composed by several PODs defined as “node” in this module. 
Under these “nodes”, there are supporting-nodes (reference to device-nodes 
belonged to the POD) and connections. 

 

The term of POD/fabric is a bit confusing in the draft. How about we updating 
the Terminology section as below?

POD: a module of network, compute, storage, and application components that 
work together to deliver networking services. It represents a repeatable design 
pattern. Its components maximize the modularity, scalability, and manageability 
of data centers.

Fabric: composed of several PODs to form a data center network.

 

Does it make sense?

 

The document does not contain a sufficient description of the logic of the 
model itself, the reasons for choices made for representation of types and 
attributes, and at the same time descriptions in modules are single lines that 
do not add clarification beyond being copies of leaf names. Either there needs 
to be a section that describes the logic of the model and how it relates to 
other models, also including examples, or module description fields need to 
have enough content to be able to have equivalent understanding of model intent 
and operation. Both are strongly encouraged, as descriptions have value of 
itself for being a reference for use, and model description is needed for 
understanding how this particular model fits into the larger hierarchy. Network 
management does not end at the boundary of the single domain-specific model, it 
is important to build it into a whole system.

 

Why TE topology model is not sufficient for modelling the representation of DC 
fabric? Why is DC fabric network topology special compared to any generic 
fabric based topology?

[Y] We discussed with TE topology model authors about 

Re: [i2rs] Ignas Bagdonas' Discuss on draft-ietf-i2rs-yang-dc-fabric-network-topology-08: (with DISCUSS and COMMENT)

[Susan Hares]

Ignas: 

I am not trying to clarify the specifics.  This response (as I mentioned), will 
come from the authors.  As a shepherd/WG chair, I am asking for information 
regarding the basis of your DISCUSS models for specific points.

The 2014 document on the IESG discuss criteria is at: 
https://www.ietf.org/blog/discuss-criteria-iesg-review/

What on this list does the following comment refer to: 
"Why DISCUSS? DC fabric is a type of network topology, yes, it has some 
specifics, but nothing radically different than any purpose built network 
topology. Developing a separate model for a specific use case at the same time 
when there is generic and extensible TE model is questionable." 

Perhaps you are not considering the fact this is an I2RS model.  Let me provide 
3 comments regaring that point: 
 
1st - I2RS is focusing on models that are capable for the dynamic state and 
configuration state.  These models have qualitative differences.  The 
mechanisms of a model which does both dynamic state and configuration state is 
qualitative different that the basic TE models. This model extends the TE 
models toward this approach (see   module ietf-dc-fabric-topology reference 
import of ietf-network-topology).  
  
2nd - During the I2RS process we talked to the TE topology authors and the TE 
WG.  We agreed that this model has differences.  As a WG Co-chair, I spent time 
reviewing this interaction. 

3rd - How many of the user community have implemented I2RS dynamic models or 
the RFC version of the TE models?  

See the comments from Chris Hopps and others on slow pace of the netconf work.  
If you are going to restrict to two deployed implementations, you will be 
joining the IDR camp of requirements and slowing the work further.  The only 
reason we require 2 implementations for IDR is for the fragile BGP environment 
and that operators request it due to the global consequences.  Network 
Management of these early yang models have a much more restricted case. 

Sue Hares 


-Original Message-
From: i2rs [mailto:i2rs-boun...@ietf.org] On Behalf Of Ignas Bagdonas
Sent: Wednesday, April 4, 2018 10:31 AM
To: Susan Hares; 'The IESG'
Cc: i2rs@ietf.org; draft-ietf-i2rs-yang-dc-fabric-network-topol...@ietf.org; 
i2rs-cha...@ietf.org
Subject: Re: [i2rs] Ignas Bagdonas' Discuss on 
draft-ietf-i2rs-yang-dc-fabric-network-topology-08: (with DISCUSS and COMMENT)

Hi Sue,


On 03/04/2018 14:59, Susan Hares wrote:
> Ignas:
>
> Yan will answer for the authors but I would like to share some information 
> related to the I2RS working group reviews.  In your response, please specify 
> why each question is a "DISCUSS" quality question rather than a "Comment" 
> question.  The authors and I (as the shepherd) will work to resolve both 
> DISCUSS and comment issues.
>
> Let me review only 5 of your many points because they are pointing in a 
> direction which is different from earlier QA reviews of this document 
> (rtg-dir, ops-dir, yang-doctors) in the 2017-2018 timeframe.

> 1st - Why TE topology model is not sufficient for modelling the 
> representation of DC fabric? Why is DC fabric network topology special 
> compared to any generic fabric based topology?

Why DISCUSS? DC fabric is a type of network topology, yes, it has some 
specifics, but nothing radically different than any purpose built network 
topology. Developing a separate model for a specific use case at the same time 
when there is generic and extensible TE model is questionable.

> This document was reviewed by authors with the TE topology models to make 
> sure there was no conflict or duplication.
>
> Your question implies that only one yang model is appropriate for each type 
> of fabric.

That is exactly opposite. What is special about DC fabric that it has to have a 
separate model? What is special about fabric type of topology that it has to 
have a separate model? Why is TE model not suitable?

> This theory of one yang mode per fabric does not apply to dynamic 
> (ephemeral) datastore versus configuration datastore models.  It is also not 
> true of all models even within the configuration datastore.
> Since there is a yang catalog and selection of yang models is specific to a 
> implemented, there has been no early winnowing of the yang models per type.  
> If you are insisting on this theory of "one yang model" per fabric type, 
> please provide an RFC reference so that I can help review this DISCUSS 
> criteria with the authors.
>
> This yang model has been implemented by 1 vendor, and there was interest by 
> other vendors.  A deployment target has been identified for this model, and 
> feedback is expected from the users.
Excellent. Please get feedback from user community - even if it is not yet 
implemented and operations groups will not be able to provide feedback, 
architecture and engineering gro

Re: [i2rs] Ignas Bagdonas' Discuss on draft-ietf-i2rs-yang-dc-fabric-network-topology-08: (with DISCUSS and COMMENT)

[Susan Hares]

Martin: 

You are correct, this is not a concern about the rules for the Yang module
itself.   Hence, my questions to Ignas about why he placed a DISCUSS based
on "introduction material" that was not specified in any document. 

Thank you for your comments,
Susan Hares 

-Original Message-
From: Martin Bjorklund [mailto:m...@tail-f.com] 
Sent: Tuesday, April 3, 2018 5:57 PM
To: sha...@ndzh.com
Cc: ibagd...@gmail.com; i...@ietf.org; i2rs@ietf.org;
draft-ietf-i2rs-yang-dc-fabric-network-topol...@ietf.org;
i2rs-cha...@ietf.org
Subject: Re: [i2rs] Ignas Bagdonas' Discuss on
draft-ietf-i2rs-yang-dc-fabric-network-topology-08: (with DISCUSS and
COMMENT)

"Susan Hares" <sha...@ndzh.com> wrote:
> Martin:
> 
> Thank you for the comments on the Yang doctors.  The discussion 
> reference was in the introductory material and not in the descriptions 
> in the YANG text.  Do you also want additional comments in the
introductory section?

No.  The comment was just about the YANG module.

You wrote:

> > Earlier feedback (rtg-dir, ops-dir, yang-doctors) on YANG suggested 
> > taking out the lengthy descriptions regarding logic and history.  If 
> > we are switching the rules for the YANG models, would you please 
> > update the requirements for the YANG models so that shepherds, 
> > rtg-dir, ops-dir, and yang-doctors can have rules for review clearly 
> > spelled out.

My point is that I don't think we are changing the rules for the YANG
modules, which this reply seemed to indicate.



/martin



> 
> Sue Hares
> 
> -Original Message-
> From: Martin Bjorklund [mailto:m...@tail-f.com]
> Sent: Tuesday, April 3, 2018 4:30 PM
> To: sha...@ndzh.com
> Cc: ibagd...@gmail.com; i...@ietf.org; i2rs@ietf.org; 
> draft-ietf-i2rs-yang-dc-fabric-network-topol...@ietf.org;
> i2rs-cha...@ietf.org
> Subject: Re: [i2rs] Ignas Bagdonas' Discuss on
> draft-ietf-i2rs-yang-dc-fabric-network-topology-08: (with DISCUSS and
> COMMENT)
> 
> Hi,
> 
> Just a quick comment on the YANG doctor's review.
> 
> "Susan Hares" <sha...@ndzh.com> wrote:
> > Earlier feedback (rtg-dir, ops-dir, yang-doctors) on YANG suggested 
> > taking out the lengthy descriptions regarding logic and history.
> 
> It is very common that the YANG doctor review ask for *more* details 
> in the descriptions.  In general, we want the module to have as much 
> explanatory text as possible.  So was the case for the YD review for 
> this document as well; the YD wrote "The descriptions in all YANG 
> Modules are very short/terse."  That was for the -02 version, and even 
> the -00 version did not contain lengthy descriptions AFAICT.
> 
> 
> /martin
> 

___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

Re: [i2rs] Ben Campbell's No Objection on draft-ietf-i2rs-yang-dc-fabric-network-topology-08: (with COMMENT)

[Susan Hares]

Ben:

Could you unpack the "share concern" on definition of fabric comment a bit? 

Sue 

-Original Message-
From: Ben Campbell [mailto:b...@nostrum.com] 
Sent: Tuesday, April 3, 2018 10:26 PM
To: The IESG
Cc: draft-ietf-i2rs-yang-dc-fabric-network-topol...@ietf.org; Susan Hares; 
i2rs-cha...@ietf.org; sha...@ndzh.com; i2rs@ietf.org
Subject: Ben Campbell's No Objection on 
draft-ietf-i2rs-yang-dc-fabric-network-topology-08: (with COMMENT)

Ben Campbell has entered the following ballot position for
draft-ietf-i2rs-yang-dc-fabric-network-topology-08: No Objection

When responding, please keep the subject line intact and reply to all email 
addresses included in the To and CC lines. (Feel free to cut this introductory 
paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-dc-fabric-network-topology/



--
COMMENT:
--

I share Ignas's concern about the definition of "fabric". Otherwise, I have a 
couple of nits:

Abstract: Missing article before "Data Center Network".

§2: Please use the boilerplate from RFC 8174 rather than rolling your own text 
to constrain the keywords to their all-caps forms.



___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

Re: [i2rs] Ignas Bagdonas' Discuss on draft-ietf-i2rs-yang-dc-fabric-network-topology-08: (with DISCUSS and COMMENT)

[Susan Hares]

Martin:

I apologize if my response seem to indicate the descriptions in the YANG
modules or the YANG module overall description.  My response was intended to
query if there were now rules on what needed to be in the introductory
material (non-YANG) in the RFC prior to the YANG module.  

AFAIK, the only formal definition for this portion of the YANG RFCs is
regarding the Yang diagram RFC. 
Therefore, I was asking Ignas to provide clarity on his DISCUSS to determine
references for his expectations for the introductory material.  A DISCUSS
should have some reference to a YANG web page, or an RFC or some written
context to help the shepherd.   As a shepherd unless I have a reference it
is hard to handle conflicting reviews (shorten the introduction vs. add the
introduction). 

If you know of such a web page or RFC, I would appreciate a reference. 

Thank you,
Susan Hares

-Original Message-
From: i2rs [mailto:i2rs-boun...@ietf.org] On Behalf Of Martin Bjorklund
Sent: Tuesday, April 3, 2018 5:57 PM
To: sha...@ndzh.com
Cc: ibagd...@gmail.com; i2rs@ietf.org;
draft-ietf-i2rs-yang-dc-fabric-network-topol...@ietf.org; i...@ietf.org;
i2rs-cha...@ietf.org
Subject: Re: [i2rs] Ignas Bagdonas' Discuss on
draft-ietf-i2rs-yang-dc-fabric-network-topology-08: (with DISCUSS and
COMMENT)

"Susan Hares" <sha...@ndzh.com> wrote:
> Martin:
> 
> Thank you for the comments on the Yang doctors.  The discussion 
> reference was in the introductory material and not in the descriptions 
> in the YANG text.  Do you also want additional comments in the
introductory section?

No.  The comment was just about the YANG module.

You wrote:

> > Earlier feedback (rtg-dir, ops-dir, yang-doctors) on YANG suggested 
> > taking out the lengthy descriptions regarding logic and history.  If 
> > we are switching the rules for the YANG models, would you please 
> > update the requirements for the YANG models so that shepherds, 
> > rtg-dir, ops-dir, and yang-doctors can have rules for review clearly 
> > spelled out.

My point is that I don't think we are changing the rules for the YANG
modules, which this reply seemed to indicate.



/martin



> 
> Sue Hares
> 
> -Original Message-
> From: Martin Bjorklund [mailto:m...@tail-f.com]
> Sent: Tuesday, April 3, 2018 4:30 PM
> To: sha...@ndzh.com
> Cc: ibagd...@gmail.com; i...@ietf.org; i2rs@ietf.org; 
> draft-ietf-i2rs-yang-dc-fabric-network-topol...@ietf.org;
> i2rs-cha...@ietf.org
> Subject: Re: [i2rs] Ignas Bagdonas' Discuss on
> draft-ietf-i2rs-yang-dc-fabric-network-topology-08: (with DISCUSS and
> COMMENT)
> 
> Hi,
> 
> Just a quick comment on the YANG doctor's review.
> 
> "Susan Hares" <sha...@ndzh.com> wrote:
> > Earlier feedback (rtg-dir, ops-dir, yang-doctors) on YANG suggested 
> > taking out the lengthy descriptions regarding logic and history.
> 
> It is very common that the YANG doctor review ask for *more* details 
> in the descriptions.  In general, we want the module to have as much 
> explanatory text as possible.  So was the case for the YD review for 
> this document as well; the YD wrote "The descriptions in all YANG 
> Modules are very short/terse."  That was for the -02 version, and even 
> the -00 version did not contain lengthy descriptions AFAICT.
> 
> 
> /martin
> 

___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

Re: [i2rs] Ignas Bagdonas' Discuss on draft-ietf-i2rs-yang-dc-fabric-network-topology-08: (with DISCUSS and COMMENT)

[Susan Hares]

Martin:

Thank you for the comments on the Yang doctors.  The discussion reference
was in the introductory material and not in the descriptions in the YANG
text.  Do you also want additional comments in the introductory section?

Sue Hares 

-Original Message-
From: Martin Bjorklund [mailto:m...@tail-f.com] 
Sent: Tuesday, April 3, 2018 4:30 PM
To: sha...@ndzh.com
Cc: ibagd...@gmail.com; i...@ietf.org; i2rs@ietf.org;
draft-ietf-i2rs-yang-dc-fabric-network-topol...@ietf.org;
i2rs-cha...@ietf.org
Subject: Re: [i2rs] Ignas Bagdonas' Discuss on
draft-ietf-i2rs-yang-dc-fabric-network-topology-08: (with DISCUSS and
COMMENT)

Hi,

Just a quick comment on the YANG doctor's review.

"Susan Hares" <sha...@ndzh.com> wrote:
> Earlier feedback (rtg-dir, ops-dir, yang-doctors) on YANG suggested 
> taking out the lengthy descriptions regarding logic and history.

It is very common that the YANG doctor review ask for *more* details in the
descriptions.  In general, we want the module to have as much explanatory
text as possible.  So was the case for the YD review for this document as
well; the YD wrote "The descriptions in all YANG Modules are very
short/terse."  That was for the -02 version, and even the -00 version did
not contain lengthy descriptions AFAICT.


/martin

___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

Re: [i2rs] Ignas Bagdonas' Discuss on draft-ietf-i2rs-yang-dc-fabric-network-topology-08: (with DISCUSS and COMMENT)

[Susan Hares]

Ignas:

Yan will answer for the authors but I would like to share some information 
related to the I2RS working group reviews.  In your response, please specify 
why each question is a "DISCUSS" quality question rather than a "Comment" 
question.  The authors and I (as the shepherd) will work to resolve both 
DISCUSS and comment issues.  

Let me review only 5 of your many points because they are pointing in a 
direction which is different from earlier QA reviews of this document (rtg-dir, 
ops-dir, yang-doctors) in the 2017-2018 timeframe.  

1st - Why TE topology model is not sufficient for modelling the representation 
of DC fabric? Why is DC fabric network topology special compared to any generic 
fabric based topology?

This document was reviewed by authors with the TE topology models to make sure 
there was no conflict or duplication.

Your question implies that only one yang model is appropriate for each type of 
fabric.   This theory of one yang mode per fabric does not apply to dynamic 
(ephemeral) datastore versus configuration datastore models.  It is also not 
true of all models even within the configuration datastore. Since there is a 
yang catalog and selection of yang models is specific to a implemented, there 
has been no early winnowing of the yang models per type.  If you are insisting 
on this theory of "one yang model" per fabric type, please provide an RFC 
reference so that I can help review this DISCUSS criteria with the authors. 

This yang model has been implemented by 1 vendor, and there was interest by 
other vendors.  A deployment target has been identified for this model, and 
feedback is expected from the users. 

If you are asking this model to cover three-four layer datacenters, this 
approach is opposite some of the initial feedback to the group to keep the 
initial model - that is to keep it simple and restricted to 2 layers in order 
to test the concepts.  If you are asking to provide text (in introduction or 
appendix) that indicates the initial focus, this can be added. 

2nd - Multiple layers and multiple roles.  

 The authors provide slides in several meetings I2RS meeting repository 
regarding this point. 
The initial feedback suggested reducing the "why" text within the draft.   
Again, the initial feedback was to reduce the initial model's text to 2 layers 
and simple "whys".  See proceedings from IETF 95 forward on I2RS on fabric data 
model for discussions. 

3rd - The authors will comment on the port restrictions.  Early feedback during 
the I2RS meetings from vendors may have taken the authors down this path.  In 
my review, I expect major issues in this area - but I will let the authors 
comment. 

 4 - policy is simple. 

Again, the initial feedback was to keep initial policies simple and gain 
feedback from the deployments. 

5 - You indicate that the document requires a "major" rewrite clarifying the 
logic. 

Earlier feedback (rtg-dir, ops-dir, yang-doctors) on YANG suggested taking out 
the lengthy descriptions regarding logic and history.  If we are switching the 
rules for the YANG models, would you please update the requirements for the 
YANG models so that shepherds, rtg-dir, ops-dir, and yang-doctors can have 
rules for review clearly spelled out. 

Summary on Shepherd's comment:  

The authors will respond to others specifics, but in order to guide these 
diligent authors - I need to know what rules you are setting for the 2018 IESG 
approval of YANG models.  If you are placing a DISCUSS on a YANG model based on 
a set criteria, the criteria needs to be published on a web page or in an RFC. 
If I've missed this criteria that the OPS Area has specified, 

Thank you for your review, 
Susan Hares 

-Original Message-
From: Ignas Bagdonas [mailto:ibagd...@gmail.com] 
Sent: Tuesday, April 3, 2018 7:40 AM
To: The IESG
Cc: draft-ietf-i2rs-yang-dc-fabric-network-topol...@ietf.org; Susan Hares; 
i2rs-cha...@ietf.org; sha...@ndzh.com; i2rs@ietf.org
Subject: Ignas Bagdonas' Discuss on 
draft-ietf-i2rs-yang-dc-fabric-network-topology-08: (with DISCUSS and COMMENT)

Ignas Bagdonas has entered the following ballot position for
draft-ietf-i2rs-yang-dc-fabric-network-topology-08: Discuss

When responding, please keep the subject line intact and reply to all email 
addresses included in the To and CC lines. (Feel free to cut this introductory 
paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-dc-fabric-network-topology/



--
DISCUSS:
--

I have concerns about the practical usability of this proposed model as it is 
spec

Re: [i2rs] Last Call: (A YANG Data Model for Fabric Topology in Data Center Networks) to Proposed Standard

[Susan Hares]

Yan:

Thank you for the update. 

Sue Hares 

-Original Message-
From: i2rs [mailto:i2rs-boun...@ietf.org] On Behalf Of Zhuangyan (Yan)
Sent: Sunday, March 18, 2018 11:02 PM
To: tom p.; i...@ietf.org
Cc: i2rs@ietf.org; draft-ietf-i2rs-yang-dc-fabric-network-topol...@ietf.org;
i2rs-cha...@ietf.org; sha...@ndzh.com; akat...@gmail.com
Subject: Re: [i2rs] Last Call:
 (A YANG Data Model
for Fabric Topology in Data Center Networks) to Proposed Standard

Hi Tom,

Thank you for your comments. 
We changed the words in description statement as you suggested and added an
introductory section before the module codes in section "Fabric YANG
Module". The draft-ietf-netmod-rfc7277bis is added as well.

We think the new version-07 resolved all your comments :) Thank you.

Best Regards,

Yan (on behalf of all authors)


-Original Message-
From: tom p. [mailto:daedu...@btconnect.com]
Sent: Tuesday, March 13, 2018 8:30 PM
To: i...@ietf.org
Cc: i2rs@ietf.org; draft-ietf-i2rs-yang-dc-fabric-network-topol...@ietf.org;
i2rs-cha...@ietf.org; sha...@ndzh.com; akat...@gmail.com
Subject: Re: Last Call:
 (A YANG Data Model
for Fabric Topology in Data Center Networks) to Proposed Standard

I see

description "Number of vni(VXLAN Network Identifier, see [RFC7348])s that
the fabric has";

which looks like XML/HTML style reference in the YANG module, which will not
work as the YANG module must be plain text.

I suggest an introductory section along the lines of

This module imports ...
from ...
and references [RFC7348]

along the lines of
draft-ietf-netmod-rfc7277bis
without which [RFC7348] will be an unused Reference.

Tom Petch

- Original Message -
From: "The IESG" 
To: "IETF-Announce" 
Cc: ;
;
; ; 
Sent: Friday, March 09, 2018 9:28 PM
Subject: Last Call:
 (A YANG Data Model
for Fabric Topology in Data Center Networks) to Proposed Standard


>
> The IESG has received a request from the Interface to the Routing
System WG
> (i2rs) to consider the following document: - 'A YANG Data Model for
Fabric
> Topology in Data Center Networks'
>as Proposed
>   Standard
>
> The IESG plans to make a decision in the next few weeks, and solicits
final
> comments on this action. Please send substantive comments to the 
> i...@ietf.org mailing lists by 2018-04-03. Exceptionally, comments may
be
> sent to i...@ietf.org instead. In either case, please retain the
beginning of
> the Subject line to allow automated sorting.
>
> Abstract
>
>
>This document defines a YANG data model for fabric topology in Data
>Center Network.
>
>
>
>
> The file can be obtained via
>
https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-dc-fabric-network-
topology/
>
> IESG discussion can be tracked via
>
https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-dc-fabric-network-
topology/ballot/
>
>
> No IPR declarations have been submitted directly on this I-D.
>
>
> The document contains these normative downward references.
> See RFC 3967 for additional information:
> rfc7348: Virtual eXtensible Local Area Network (VXLAN): A
Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks
(Informational - Independent Submission Editor stream)
>
>
>

___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

Re: [i2rs] RFC 8340 to 8346 published

[Susan Hares]

Benoit:

 

A Big Thank you to you and Alia Atlas!   I’m thrilled to see the I2RS topology 
RFCs happen. 

 

Sue Hares 

 

From: i2rs [mailto:i2rs-boun...@ietf.org] On Behalf Of Benoit Claise
Sent: Saturday, March 17, 2018 6:36 PM
To: NETMOD Working Group; NETCONF; i2rs@ietf.org
Subject: [i2rs] RFC 8340 to 8346 published

 

Dear all,

RFC8340  | 
draft-ietf-netmod-yang-tree-diagrams-06.txt

RFC8341  | 
draft-ietf-netconf-rfc6536bis-09.txt
RFC8342  | 
draft-ietf-netmod-revised-datastores-10.txt
RFC8343  | 
draft-ietf-netmod-rfc7223bis-03.txt
RFC8344  | 
draft-ietf-netmod-rfc7277bis-03.txt
RFC8345  | 
draft-ietf-i2rs-yang-network-topo-20.txt
RFC8346  | 
draft-ietf-i2rs-yang-l3-topology-16.txt

Congratulations to all persons involved.

Regards, Benoit

___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

[i2rs] WG LC confirmation on draft-ietf-i2rs-yang-l2-network-topology (3/7 to 3/21/2018)

[Susan Hares]

Greetings I2RS folks: 

 

This is a 2 Week WG LC to confirm the WG LC on
draft-ietf-i2rs-yang-l2-network-topology.   During this WG LC, please
indicate any issues with the updates to align with Network Management Data
Store Module.  These may include: 

 

1)  Yang data model structure, 

2)  High level Yang language format 

3)  Security consideration section, 

4)  Any issues with the notification calls.

 

If you feel this updated data model is ready for publication, please send
indicate that in your response. 

 

Cheerily, Susan Hares 

 

 

___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

Re: [i2rs] Secdir last call review of draft-ietf-i2rs-rib-info-model-14

[Susan Hares]

Paul:

I hit return to soon.  Thank you for the security review. 

Cheerily, Susan Hares 

-Original Message-
From: Susan Hares [mailto:sha...@ndzh.com] 
Sent: Sunday, February 25, 2018 6:45 PM
To: 'Paul Wouters'; sec...@ietf.org
Cc: i2rs@ietf.org; i...@ietf.org;
draft-ietf-i2rs-rib-info-model@ietf.org
Subject: RE: [i2rs] Secdir last call review of
draft-ietf-i2rs-rib-info-model-14

Paul: 

The current I2RS  RIB Data model is a yang model which can be access via
netconf and restconf with the restrictions in the network management
datastore architecture.   Are you looking for us to specify the
netconf/restconf suite protocols, and the CBOR for binary in this section. 

If you are looking for more than that, are you looking for what is in
https://datatracker.ietf.org/doc/draft-ietf-i2rs-security-environment-reqs/

Thank you,
Sue Hares
WG co-chair

-Original Message-
From: i2rs [mailto:i2rs-boun...@ietf.org] On Behalf Of Paul Wouters
Sent: Sunday, February 25, 2018 1:59 PM
To: sec...@ietf.org
Cc: i2rs@ietf.org; i...@ietf.org;
draft-ietf-i2rs-rib-info-model@ietf.org
Subject: [i2rs] Secdir last call review of draft-ietf-i2rs-rib-info-model-14

Reviewer: Paul Wouters
Review result: Has Issues

I have reviewed this document as part of the security directorate's  ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written primarily for the benefit of the security area
directors.
 Document editors and WG chairs should treat  these comments just like any
other last call comments.

The summary of the review is Has Issues.

This Informational draft specifies an information model for routing
information bases (RIBs) , and hints at how a read/write API would look
like. I think the document should be improved to clarify this API beyond a
simple mention of SSH and TLS in its own section, outside of the Security
Consideration section. For example, if this is TLS, what is used? Something
restful? xml? json? What would the URI be? And for ssh, what kind of access
would be given? How is this restricted to the RIB API ?


___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs


___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

Re: [i2rs] Secdir last call review of draft-ietf-i2rs-rib-info-model-14

[Susan Hares]

Paul: 

The current I2RS  RIB Data model is a yang model which can be access via
netconf and restconf with the restrictions in the network management
datastore architecture.   Are you looking for us to specify the
netconf/restconf suite protocols, and the CBOR for binary in this section. 

If you are looking for more than that, are you looking for what is in 
https://datatracker.ietf.org/doc/draft-ietf-i2rs-security-environment-reqs/

Thank you, 
Sue Hares
WG co-chair

-Original Message-
From: i2rs [mailto:i2rs-boun...@ietf.org] On Behalf Of Paul Wouters
Sent: Sunday, February 25, 2018 1:59 PM
To: sec...@ietf.org
Cc: i2rs@ietf.org; i...@ietf.org;
draft-ietf-i2rs-rib-info-model@ietf.org
Subject: [i2rs] Secdir last call review of draft-ietf-i2rs-rib-info-model-14

Reviewer: Paul Wouters
Review result: Has Issues

I have reviewed this document as part of the security directorate's  ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written primarily for the benefit of the security area
directors.
 Document editors and WG chairs should treat  these comments just like any
other last call comments.

The summary of the review is Has Issues.

This Informational draft specifies an information model for routing
information bases (RIBs) , and hints at how a read/write API would look
like. I think the document should be improved to clarify this API beyond a
simple mention of SSH and TLS in its own section, outside of the Security
Consideration section. For example, if this is TLS, what is used? Something
restful? xml? json? What would the URI be? And for ssh, what kind of access
would be given? How is this restricted to the RIB API ?


___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

Re: [i2rs] Last Call: (A YANG Data Model for Routing Information Base (RIB)) to Proposed Standard

[Susan Hares]

Tom:

Thank you for your input. 

Sue 

-Original Message-
From: tom p. [mailto:daedu...@btconnect.com] 
Sent: Saturday, February 24, 2018 7:19 AM
To: Susan Hares; 'ietf'
Cc: i2rs@ietf.org; draft-ietf-i2rs-rib-data-mo...@ietf.org;
i2rs-cha...@ietf.org; 'Alia Atlas'
Subject: Re: [i2rs] Last Call:  (A
YANG Data Model for Routing Information Base (RIB)) to Proposed Standard

- Original Message -
From: "Susan Hares" <sha...@ndzh.com>
Sent: Friday, February 23, 2018 7:11 PM

> Tom:
>
> Before I dig deeper into this point, let me ask a question - have you
read
> the rib Info model?  If you have, what would like moved from the RIB
info
> model to the Data model?  If you have not, please review it.

Susan

Why should I review the Info model? It is only a Informational Reference so
I do not need it to understand the data model.

I have looked at it and see no useful information about how to interpret
this uint32.

It may be that this is too early in the process to specify the hard codes
but if that is the case, then I think that the mechanics for specifying them
should be.

Tom Petch

> The authors of the Data model aligned it with the RIB info model.
> Comments from WG at the time were - just say error code.
>
> Cheerily, Susan Hares
>
> -Original Message-
> From: tom p. [mailto:daedu...@btconnect.com]
> Sent: Friday, February 23, 2018 12:23 PM
> To: ietf
> Cc: i2rs@ietf.org; draft-ietf-i2rs-rib-data-mo...@ietf.org;
> i2rs-cha...@ietf.org; sha...@ndzh.com; Alia Atlas
> Subject: Re: [i2rs] Last Call: 
(A
> YANG Data Model for Routing Information Base (RIB)) to Proposed
Standard
>
> This model has a
>  leaf error-code {
>type uint32;
>description
>  "The error code that reflects the failure reason.";
>
> I work with error codes and know that understanding what they are
telling me
> is key to resolving problems promptly but I can see no list of
possible
> error codes and what they mean, just a statement that the code is a
uint32.
> The text part of the I-D contains no mention of error-code - outside
the
> appearance in the tree diagram - AFAICT.
>
> Tom Petch
>
> - Original Message -
> From: "The IESG" <iesg-secret...@ietf.org>
> To: "IETF-Announce" <ietf-annou...@ietf.org>
> Cc: <i2rs@ietf.org>; <draft-ietf-i2rs-rib-data-mo...@ietf.org>;
> <i2rs-cha...@ietf.org>; <sha...@ndzh.com>; <akat...@gmail.com>
> Sent: Tuesday, February 20, 2018 5:40 PM
> Subject: [i2rs] Last Call:  (A
YANG
> Data Model for Routing Information Base (RIB)) to Proposed Standard
>
>
> >
> > The IESG has received a request from the Interface to the Routing
> System WG
> > (i2rs) to consider the following document: - 'A YANG Data Model for
> Routing
> > Information Base (RIB)'
> >as Proposed Standard
> >
> > The IESG plans to make a decision in the next few weeks, and
solicits
> final
> > comments on this action. Please send substantive comments to the 
> > i...@ietf.org mailing lists by 2018-03-06. Exceptionally, comments
may
> be
> > sent to i...@ietf.org instead. In either case, please retain the
> beginning of
> > the Subject line to allow automated sorting.
> >
> > Abstract
> >
> >
> >This document defines a YANG data model for Routing Information
> Base
> >(RIB) that aligns with the I2RS RIB information model.
> >
> >
> > The file can be obtained via
> > https://datatracker.ietf.org/doc/draft-ietf-i2rs-rib-data-model/
> >
> > IESG discussion can be tracked via
> >
>
https://datatracker.ietf.org/doc/draft-ietf-i2rs-rib-data-model/ballot/
> >
> >
> > No IPR declarations have been submitted directly on this I-D.
> >
> >
>
>


___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

Re: [i2rs] IPR recall for draft-ietf-i2rs-rib-data-model - Urgent

[Susan Hares]

Sri:

 

Thank you for the fast response. 

 

Sue Hares

 

From: i2rs [mailto:i2rs-boun...@ietf.org] On Behalf Of Sri
Sent: Thursday, February 15, 2018 3:28 PM
To: Susan Hares
Cc: nitin_baha...@yahoo.com; i2rs@ietf.org; wang_little_s...@sina.com; 
mach.c...@huawei.com; h...@packetdesign.com; 
draft-ietf-i2rs-rib-data-mo...@ietf.org; Alia Atlas; Russ White; 
amit.d...@ericsson.com
Subject: Re: [i2rs] IPR recall for draft-ietf-i2rs-rib-data-model - Urgent

 

Hi Sue,

 

My response to the IPR  re-call:

I am not aware of any IPR related to this draft.

 

Sri

 

On Feb 15, 2018 11:11 AM, "Susan Hares" <sha...@ndzh.com> wrote:

Greetings I2RS: 

 

We are trying to finalize the I2RS RIB Document, and there has been a question 
regarding our IPR statements raised during the review process.  Due to this 
request, I must do an urgent recall for all authors of the I2RS RIB data model 
to resend their answer to the question: “Do you know of an IPR related to this 
draft”?  I must also ask the WG if they still wish to have 6 authors on this 
draft.

 

Unfortunately, due to the nature of the query I MUST have all authors respond 
by February 18th.  If at all possible, we need the authors to respond within 48 
hours.  Authors who do not respond by February 18th, may be dropped from the 
authors list until we can get the IPR Statements from the authors.  Alia has 
sent out repeated calls for quick responses on this draft, and we cannot wait 
any longer.  

 

Please note that this is one of the required duties of a WG chair to push this 
along during the last phases.  I consider this draft to be one of the key 
drafts of the whole I2RS WG, and I would like to see it in IETF LC on Monday.  

 

Cheerily, Susan Hares 

Co-chair

 

___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

Re: [i2rs] Last Call: (A YANG Data Model for Routing Information Base (RIB)) to Proposed Standard

[Susan Hares]

Tom:

Before I dig deeper into this point, let me ask a question - have you read
the rib Info model?  If you have, what would like moved from the RIB info
model to the Data model?  If you have not, please review it. 

The authors of the Data model aligned it with the RIB info model.
Comments from WG at the time were - just say error code.

Cheerily, Susan Hares 

-Original Message-
From: tom p. [mailto:daedu...@btconnect.com] 
Sent: Friday, February 23, 2018 12:23 PM
To: ietf
Cc: i2rs@ietf.org; draft-ietf-i2rs-rib-data-mo...@ietf.org;
i2rs-cha...@ietf.org; sha...@ndzh.com; Alia Atlas
Subject: Re: [i2rs] Last Call:  (A
YANG Data Model for Routing Information Base (RIB)) to Proposed Standard

This model has a
 leaf error-code {
   type uint32;
   description
 "The error code that reflects the failure reason.";

I work with error codes and know that understanding what they are telling me
is key to resolving problems promptly but I can see no list of possible
error codes and what they mean, just a statement that the code is a uint32.
The text part of the I-D contains no mention of error-code - outside the
appearance in the tree diagram - AFAICT.

Tom Petch

- Original Message -
From: "The IESG" <iesg-secret...@ietf.org>
To: "IETF-Announce" <ietf-annou...@ietf.org>
Cc: <i2rs@ietf.org>; <draft-ietf-i2rs-rib-data-mo...@ietf.org>;
<i2rs-cha...@ietf.org>; <sha...@ndzh.com>; <akat...@gmail.com>
Sent: Tuesday, February 20, 2018 5:40 PM
Subject: [i2rs] Last Call:  (A YANG
Data Model for Routing Information Base (RIB)) to Proposed Standard


>
> The IESG has received a request from the Interface to the Routing
System WG
> (i2rs) to consider the following document: - 'A YANG Data Model for
Routing
> Information Base (RIB)'
>as Proposed Standard
>
> The IESG plans to make a decision in the next few weeks, and solicits
final
> comments on this action. Please send substantive comments to the 
> i...@ietf.org mailing lists by 2018-03-06. Exceptionally, comments may
be
> sent to i...@ietf.org instead. In either case, please retain the
beginning of
> the Subject line to allow automated sorting.
>
> Abstract
>
>
>This document defines a YANG data model for Routing Information
Base
>(RIB) that aligns with the I2RS RIB information model.
>
>
> The file can be obtained via
> https://datatracker.ietf.org/doc/draft-ietf-i2rs-rib-data-model/
>
> IESG discussion can be tracked via
>
https://datatracker.ietf.org/doc/draft-ietf-i2rs-rib-data-model/ballot/
>
>
> No IPR declarations have been submitted directly on this I-D.
>
>


___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

[i2rs] Publication has been requested for draft-ietf-i2rs-yang-dc-fabric-network-topology-06

[Susan Hares]

Susan Hares has requested publication of 
draft-ietf-i2rs-yang-dc-fabric-network-topology-06 as Proposed Standard on 
behalf of the I2RS working group.

Please verify the document's state at 
https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-dc-fabric-network-topology/

___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

[i2rs] Publication has been requested for draft-ietf-i2rs-rib-data-model-10

[Susan Hares]

Susan Hares has requested publication of draft-ietf-i2rs-rib-data-model-10 as 
None on behalf of the I2RS working group.

Please verify the document's state at 
https://datatracker.ietf.org/doc/draft-ietf-i2rs-rib-data-model/

___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

[i2rs] FW: IPR recall for draft-ietf-i2rs-rib-data-model - Urgent

[Susan Hares]

This IPR email did not post without removal of authors.   I am reposting. 

 

Sue Hares

 

From: Hariharan Ananthakrishnan [mailto:h...@packetdesign.com] 
Sent: Thursday, February 15, 2018 4:45 PM
To: Susan Hares; i2rs@ietf.org
Cc: 'Alia Atlas'; wang_little_s...@sina.com; mach.c...@huawei.com; 
amit.d...@ericsson.com; sriganeshk...@gmail.com; nitin_baha...@yahoo.com; 
draft-ietf-i2rs-rib-data-mo...@ietf.org; 'Russ White'
Subject: Re: IPR recall for draft-ietf-i2rs-rib-data-model - Urgent 

 

I am not aware of any IPR related to this draft.

 

- Hari

From: Susan Hares <sha...@ndzh.com>
Date: Thursday, 15 February 2018 at 11:12
To: "i2rs@ietf.org" <i2rs@ietf.org>
Cc: 'Alia Atlas' <akat...@gmail.com>, "wang_little_s...@sina.com" 
<wang_little_s...@sina.com>, Hariharan Ananthakrishnan <h...@packetdesign.com>, 
"mach.c...@huawei.com" <mach.c...@huawei.com>, "amit.d...@ericsson.com" 
<amit.d...@ericsson.com>, "sriganeshk...@gmail.com" <sriganeshk...@gmail.com>, 
"nitin_baha...@yahoo.com" <nitin_baha...@yahoo.com>, 
"draft-ietf-i2rs-rib-data-mo...@ietf.org" 
<draft-ietf-i2rs-rib-data-mo...@ietf.org>, 'Russ White' <r...@riw.us>
Subject: IPR recall for draft-ietf-i2rs-rib-data-model - Urgent 

 

Greetings I2RS: 

 

We are trying to finalize the I2RS RIB Document, and there has been a question 
regarding our IPR statements raised during the review process.  Due to this 
request, I must do an urgent recall for all authors of the I2RS RIB data model 
to resend their answer to the question: “Do you know of an IPR related to this 
draft”?  I must also ask the WG if they still wish to have 6 authors on this 
draft.

 

Unfortunately, due to the nature of the query I MUST have all authors respond 
by February 18th.  If at all possible, we need the authors to respond within 48 
hours.  Authors who do not respond by February 18th, may be dropped from the 
authors list until we can get the IPR Statements from the authors.  Alia has 
sent out repeated calls for quick responses on this draft, and we cannot wait 
any longer.  

 

Please note that this is one of the required duties of a WG chair to push this 
along during the last phases.  I consider this draft to be one of the key 
drafts of the whole I2RS WG, and I would like to see it in IETF LC on Monday.  

 

Cheerily, Susan Hares 

Co-chair

___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

[i2rs] FW: 回复：IPR recall for draft-ietf-i2rs-rib-data-model - Urgent

[Susan Hares]

IPR response sent to chair.

 

Sue

 

From: wang_little_s...@sina.com [mailto:wang_little_s...@sina.com] 
Sent: Thursday, February 15, 2018 4:25 PM
To: Susan Hares; i2rs@ietf.org
Cc: 'Alia Atlas'; h...@packetdesign.com; mach.c...@huawei.com; 
amit.d...@ericsson.com; sriganeshk...@gmail.com; nitin_baha...@yahoo.com; 
draft-ietf-i2rs-rib-data-mo...@ietf.org; 'Russ White'
Subject: 回复：IPR recall for draft-ietf-i2rs-rib-data-model - Urgent

 

Hi Sue,


My response to the IPR  re-call:

I am not aware of any IPR related to this draft.

Lixing Wang


发自我的华为手机



 原始邮件 
主题：IPR recall for draft-ietf-i2rs-rib-data-model - Urgent
发件人：Susan Hares 
收件人：i2rs@ietf.org
抄送：'Alia Atlas' 
,wang_little_s...@sina.com,h...@packetdesign.com,mach.c...@huawei.com,amit.d...@ericsson.com,sriganeshk...@gmail.com,nitin_baha...@yahoo.com,draft-ietf-i2rs-rib-data-mo...@ietf.org,'Russ
 White' 




Greetings I2RS: 

 

We are trying to finalize the I2RS RIB Document, and there has been a question 
regarding our IPR statements raised during the review process.  Due to this 
request, I must do an urgent recall for all authors of the I2RS RIB data model 
to resend their answer to the question: “Do you know of an IPR related to this 
draft”?  I must also ask the WG if they still wish to have 6 authors on this 
draft.

 

Unfortunately, due to the nature of the query I MUST have all authors respond 
by February 18th.  If at all possible, we need the authors to respond within 48 
hours.  Authors who do not respond by February 18th, may be dropped from the 
authors list until we can get the IPR Statements from the authors.  Alia has 
sent out repeated calls for quick responses on this draft, and we cannot wait 
any longer.  

 

Please note that this is one of the required duties of a WG chair to push this 
along during the last phases.  I consider this draft to be one of the key 
drafts of the whole I2RS WG, and I would like to see it in IETF LC on Monday.  

 

Cheerily, Susan Hares 

Co-chair

___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

Re: [i2rs] Yangdoctors early review of draft-ietf-i2rs-rib-data-model-09

[Susan Hares]

Lixing:

 

You stalled the process by not responding to the IPR statement.  Without it, I 
will not actively include you in the author list and I will nominate authors.   
Why?  Because the IESG will not approve a RIB Yang model without the IPR 
statements. 

 

If you wish to be included, please send your IPR statement to the WG list.   I 
will do a secondary call for this in a few moments.  

 

Sue Hares

 

From: Alia Atlas [mailto:akat...@gmail.com] 
Sent: Thursday, February 15, 2018 12:46 PM
To: wang_little_s...@sina.com
Cc: Susan Hares; Amit Dass; i2rs@ietf.org; 
draft-ietf-i2rs-rib-data-model@ietf.org
Subject: Re: Yangdoctors early review of draft-ietf-i2rs-rib-data-model-09

 

Lixia,

 

When an internet-draft is submitted, there is an irrevocable and permanent 
copyright given to the IETF.

Authors also retain their own copyright, of course.

 

The draft has 6 authors; there is always a need to justify that.  The IETF 
strongly prefers no more than

5 authors.  The fact that you have stalled the process because you did not 
respond to the IPR query

does not help.

 

WG Chairs may appoint and replace editors and authors of WG drafts.

 

Regards,

Alia

 

On Thu, Feb 15, 2018 at 12:17 PM, wang_little_s...@sina.com 
<wang_little_s...@sina.com> wrote:

Hello Susan,
I'm the original author of this draft.
Even now 70% of this draf is written by me, I have 70% copyright of this draft.
So you cann't remove my name.

Best Regards
Lixing Wang

发自我的华为手机



 原始邮件 
主题：RE: Yangdoctors early review of draft-ietf-i2rs-rib-data-model-09
发件人：Susan Hares 
收件人：'Amit Dass' ,'Alia Atlas' 
抄送：i2rs@ietf.org,






Amit:

 

Remove one of the authors.   Please consider removing LIxing Wang.   I have not 
received an IPR statement from this person.   Please do this today.   I 
apologize for the delay in responding. 

 

Sue 

 

From: Amit Dass [mailto:amit.d...@ericsson.com] 
Sent: Monday, February 12, 2018 8:23 AM
To: Alia Atlas 
Cc: Susan Hares; i2rs@ietf.org; draft-ietf-i2rs-rib-data-model@ietf.org
Subject: FW: Yangdoctors early review of draft-ietf-i2rs-rib-data-model-09

 

Hi Alia,

 

Apologies for the delay. Needed to redo all again due to the laptop crashed. 
Updated the draft with the below comments. Couldn’t upload the same due to max 
5 author limit kicking in.

 

Best regards,

Amit

 

From: Alia Atlas [mailto:akat...@gmail.com] 
Sent: Saturday, February 10, 2018 1:51 AM
To: Amit Dass <amit.d...@ericsson.com>
Cc: Susan Hares <sha...@ndzh.com>; i2rs@ietf.org; 
draft-ietf-i2rs-rib-data-model@ietf.org
Subject: Re: Yangdoctors early review of draft-ietf-i2rs-rib-data-model-09

 

Hi Amit,

 

It has been three weeks.

 

Can you please get the update ASAP?  I need to get it reviewed and into IETF 
Last Call.

As you know, I am closing I2RS at IETF 101 - which means this draft needs to be 
on the March 8 telechat.

That means it really should be in IETF Last Call by February 16 - and I am 
traveling all next week 

and busy.   I REALLY need it ASAP to review.

 

Regards,

Alia

 

On Thu, Jan 18, 2018 at 4:58 AM, Amit Dass <amit.d...@ericsson.com> wrote:

Hi Sue,

I expect to have some free time during this week.  Should be able to send the 
update by Monday next week.

Best regards,
Amit

-Original Message-

From: Susan Hares [mailto: <mailto:sha...@ndzh.com> sha...@ndzh.com]
Sent: Thursday, January 18, 2018 10:55 AM
To: Amit Dass < <mailto:amit.d...@ericsson.com> amit.d...@ericsson.com>; 'Ebben 
Aries' < <mailto:e...@juniper.net> e...@juniper.net>;  
<mailto:yang-doct...@ietf.org> yang-doct...@ietf.org
Cc:  <mailto:i2rs@ietf.org> i2rs@ietf.org;  
<mailto:draft-ietf-i2rs-rib-data-model@ietf.org> 
draft-ietf-i2rs-rib-data-model@ietf.org;  <mailto:i...@ietf.org> 
i...@ietf.org
Subject: RE: Yangdoctors early review of draft-ietf-i2rs-rib-data-model-09

Amit:iir

Do you think you and your co-authors can do this within a few days.   I would 
like to forward the publication request.

Also, please remember to look at the latest Revised datastore draft and yang 
tree module drafts.

Sue Hares

-Original Message-
From: Amit Dass [mailto:amit.d...@ericsson.com]
Sent: Thursday, January 18, 2018 4:53 AM
To: Ebben Aries; yang-doct...@ietf.org
Cc: i2rs@ietf.org; draft-ietf-i2rs-rib-data-model@ietf.org; i...@ietf.org
Subject: RE: Yangdoctors early review of draft-ietf-i2rs-rib-data-model-09

Thanks Ebben for reviewing the draft. I will update the same based on below 
comments and feedback.


Best regards,
Amit

-Original Message-
From: Ebben Aries [mailto:e...@juniper.net]
Sent: Thursday, January 18, 2018 9:33 AM
To: yang-doct...@ietf.org
Cc: i2rs@ietf.org; draft-ietf-i2rs-rib-data-model@ietf.org; i...@ietf.org
Subject: Yangdoctors early review of draft-ietf-i2rs-rib-data-model-09

Reviewer: Ebben Aries
Review result: On the Right Track

1 module in this draft:
- ietf-i2r

Re: [i2rs] Yangdoctors early review of draft-ietf-i2rs-rib-data-model-09

[Susan Hares]

Amit:

 

Remove one of the authors.   Please consider removing LIxing Wang.   I have not 
received an IPR statement from this person.   Please do this today.   I 
apologize for the delay in responding. 

 

Sue 

 

From: Amit Dass [mailto:amit.d...@ericsson.com] 
Sent: Monday, February 12, 2018 8:23 AM
To: Alia Atlas 
Cc: Susan Hares; i2rs@ietf.org; draft-ietf-i2rs-rib-data-model@ietf.org
Subject: FW: Yangdoctors early review of draft-ietf-i2rs-rib-data-model-09

 

Hi Alia,

 

Apologies for the delay. Needed to redo all again due to the laptop crashed. 
Updated the draft with the below comments. Couldn’t upload the same due to max 
5 author limit kicking in.

 

Best regards,

Amit

 

From: Alia Atlas [mailto:akat...@gmail.com] 
Sent: Saturday, February 10, 2018 1:51 AM
To: Amit Dass <amit.d...@ericsson.com>
Cc: Susan Hares <sha...@ndzh.com>; i2rs@ietf.org; 
draft-ietf-i2rs-rib-data-model@ietf.org
Subject: Re: Yangdoctors early review of draft-ietf-i2rs-rib-data-model-09

 

Hi Amit,

 

It has been three weeks.

 

Can you please get the update ASAP?  I need to get it reviewed and into IETF 
Last Call.

As you know, I am closing I2RS at IETF 101 - which means this draft needs to be 
on the March 8 telechat.

That means it really should be in IETF Last Call by February 16 - and I am 
traveling all next week 

and busy.   I REALLY need it ASAP to review.

 

Regards,

Alia

 

On Thu, Jan 18, 2018 at 4:58 AM, Amit Dass <amit.d...@ericsson.com> wrote:

Hi Sue,

I expect to have some free time during this week.  Should be able to send the 
update by Monday next week.

Best regards,
Amit

-Original Message-

From: Susan Hares [mailto: <mailto:sha...@ndzh.com> sha...@ndzh.com]
Sent: Thursday, January 18, 2018 10:55 AM
To: Amit Dass < <mailto:amit.d...@ericsson.com> amit.d...@ericsson.com>; 'Ebben 
Aries' < <mailto:e...@juniper.net> e...@juniper.net>;  
<mailto:yang-doct...@ietf.org> yang-doct...@ietf.org
Cc:  <mailto:i2rs@ietf.org> i2rs@ietf.org;  
<mailto:draft-ietf-i2rs-rib-data-model@ietf.org> 
draft-ietf-i2rs-rib-data-model@ietf.org;  <mailto:i...@ietf.org> 
i...@ietf.org
Subject: RE: Yangdoctors early review of draft-ietf-i2rs-rib-data-model-09

Amit:iir

Do you think you and your co-authors can do this within a few days.   I would 
like to forward the publication request.

Also, please remember to look at the latest Revised datastore draft and yang 
tree module drafts.

Sue Hares

-Original Message-
From: Amit Dass [mailto:amit.d...@ericsson.com]
Sent: Thursday, January 18, 2018 4:53 AM
To: Ebben Aries; yang-doct...@ietf.org
Cc: i2rs@ietf.org; draft-ietf-i2rs-rib-data-model@ietf.org; i...@ietf.org
Subject: RE: Yangdoctors early review of draft-ietf-i2rs-rib-data-model-09

Thanks Ebben for reviewing the draft. I will update the same based on below 
comments and feedback.


Best regards,
Amit

-Original Message-
From: Ebben Aries [mailto:e...@juniper.net]
Sent: Thursday, January 18, 2018 9:33 AM
To: yang-doct...@ietf.org
Cc: i2rs@ietf.org; draft-ietf-i2rs-rib-data-model@ietf.org; i...@ietf.org
Subject: Yangdoctors early review of draft-ietf-i2rs-rib-data-model-09

Reviewer: Ebben Aries
Review result: On the Right Track

1 module in this draft:
- ietf-i2rs-...@2017-12-05.yang

No YANG validation errors or warnings (from pyang 1.7.3 and yanglint 0.14.59)

0 examples are provided in this draft (section 3.12 of
draft-ietf-netmod-rfc6087bis-15)

Module ietf-i2rs-...@2017-12-05.yang:
- yang-version statement missing - should be 1.1
- prefix 'iir' is recommended for this module, would 'rib' suffice better?
- import "ietf-inet-types" should reference RFC 6991 per (not as a comment)
  https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-15#section-4.7
- import "ietf-interfaces" should reference RFC 7223 per
  https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-15#section-4.7
- import "ietf-yang-types" should reference RFC 6991 per
  https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-15#section-4.7
- Since this module imports "ietf-interfaces", a normative references must be
  added per
  https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-15#section-3.9
- prefix "if" in the import "ietf-interfaces" can remove quotes to remain
  consistent with other imports
- Remove WG Chairs from contact information per
  https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-15#appendix-C
- Module description must contain most recent copyright notice per
  https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-15#appendix-C
- Module description should contain note to RFC Ed. and placeholder reference
  to RFC when assigned
  https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-15#appendix-C
- Add placeholder reference and note to RFC Ed. for RFC when assigned
  https://tools.ietf.org/html/draft-ietf-netmod-rfc608

[i2rs] Publication has been requested for draft-ietf-i2rs-rib-info-model-13

[Susan Hares]

Susan Hares has requested publication of draft-ietf-i2rs-rib-info-model-13 as 
Proposed Standard on behalf of the I2RS working group.

Please verify the document's state at 
https://datatracker.ietf.org/doc/draft-ietf-i2rs-rib-info-model/

___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

Re: [i2rs] Missing IPR statements for draft-ietf-i2rs-rib-info-model-13.txt - Urgent

[Susan Hares]

Jan:

 

Thank you for this rapid fire response to the IPR request. 

 

Sue 

 

From: i2rs [mailto:i2rs-boun...@ietf.org] On Behalf Of Jan Medved (jmedved)
Sent: Friday, February 9, 2018 1:39 PM
To: Sri; Susan Hares
Cc: Nitin Bahadur; i2rs@ietf.org; Alia Atlas
Subject: Re: [i2rs] Missing IPR statements for 
draft-ietf-i2rs-rib-info-model-13.txt - Urgent

 

I am not aware of any IPR on this draft either.

 

 

/Jan

 

From: i2rs <i2rs-boun...@ietf.org> on behalf of Sri <sriganeshk...@gmail.com>
Date: Friday, February 9, 2018 at 10:09 AM
To: Susan Hares <sha...@ndzh.com>
Cc: Nitin Bahadur <nitin_baha...@yahoo.com>, "i2rs@ietf.org" <i2rs@ietf.org>, 
Alia Atlas <akat...@gmail.com>
Subject: Re: [i2rs] Missing IPR statements for 
draft-ietf-i2rs-rib-info-model-13.txt - Urgent

 

I am not aware of any IPR on this draft. 

 

Sri

 

On Fri, Feb 9, 2018 at 9:10 AM, Susan Hares <sha...@ndzh.com> wrote:

Jan, Sri, and Nitin: 

 

I need your IPR statements on draft-ietf-i2rs-rib-info-model-13.txt.  Please 
post the IPR statements in response to this email.   I have Nitin’s IPR 
statements from 07.txt which might work and might not.  

 

Alia must have this draft in WG LC.  I need these IPR statements in order to 
send this to the IESG. 

 

Sue Hares 

 


___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

 

___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

Re: [i2rs] Missing IPR statements for draft-ietf-i2rs-rib-info-model-13.txt - Urgent

[Susan Hares]

Sri:

 

Thank you for your very prompt response. 

 

Sue Hares

 

From: i2rs [mailto:i2rs-boun...@ietf.org] On Behalf Of Sri
Sent: Friday, February 9, 2018 1:09 PM
To: Susan Hares
Cc: Nitin Bahadur; i2rs@ietf.org; Alia Atlas
Subject: Re: [i2rs] Missing IPR statements for 
draft-ietf-i2rs-rib-info-model-13.txt - Urgent

 

I am not aware of any IPR on this draft.

 

Sri

 

On Fri, Feb 9, 2018 at 9:10 AM, Susan Hares <sha...@ndzh.com> wrote:

Jan, Sri, and Nitin: 

 

I need your IPR statements on draft-ietf-i2rs-rib-info-model-13.txt.  Please 
post the IPR statements in response to this email.   I have Nitin’s IPR 
statements from 07.txt which might work and might not.  

 

Alia must have this draft in WG LC.  I need these IPR statements in order to 
send this to the IESG. 

 

Sue Hares 

 


___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

 

___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

[i2rs] Missing IPR statements for draft-ietf-i2rs-rib-info-model-13.txt - Urgent

[Susan Hares]

Jan, Sri, and Nitin: 

 

I need your IPR statements on draft-ietf-i2rs-rib-info-model-13.txt.  Please
post the IPR statements in response to this email.   I have Nitin's IPR
statements from 07.txt which might work and might not.  

 

Alia must have this draft in WG LC.  I need these IPR statements in order to
send this to the IESG. 

 

Sue Hares 

 

___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

Re: [i2rs] Yangdoctors early review of draft-ietf-i2rs-rib-data-model-09

[Susan Hares]

Amit:

Do you think you and your co-authors can do this within a few days.   I would 
like to forward the publication request. 

Also, please remember to look at the latest Revised datastore draft and yang 
tree module drafts. 

Sue Hares 

-Original Message-
From: Amit Dass [mailto:amit.d...@ericsson.com] 
Sent: Thursday, January 18, 2018 4:53 AM
To: Ebben Aries; yang-doct...@ietf.org
Cc: i2rs@ietf.org; draft-ietf-i2rs-rib-data-model@ietf.org; i...@ietf.org
Subject: RE: Yangdoctors early review of draft-ietf-i2rs-rib-data-model-09

Thanks Ebben for reviewing the draft. I will update the same based on below 
comments and feedback.


Best regards,
Amit

-Original Message-
From: Ebben Aries [mailto:e...@juniper.net] 
Sent: Thursday, January 18, 2018 9:33 AM
To: yang-doct...@ietf.org
Cc: i2rs@ietf.org; draft-ietf-i2rs-rib-data-model@ietf.org; i...@ietf.org
Subject: Yangdoctors early review of draft-ietf-i2rs-rib-data-model-09

Reviewer: Ebben Aries
Review result: On the Right Track

1 module in this draft:
- ietf-i2rs-...@2017-12-05.yang

No YANG validation errors or warnings (from pyang 1.7.3 and yanglint 0.14.59)

0 examples are provided in this draft (section 3.12 of
draft-ietf-netmod-rfc6087bis-15)

Module ietf-i2rs-...@2017-12-05.yang:
- yang-version statement missing - should be 1.1
- prefix 'iir' is recommended for this module, would 'rib' suffice better?
- import "ietf-inet-types" should reference RFC 6991 per (not as a comment)
  https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-15#section-4.7
- import "ietf-interfaces" should reference RFC 7223 per
  https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-15#section-4.7
- import "ietf-yang-types" should reference RFC 6991 per
  https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-15#section-4.7
- Since this module imports "ietf-interfaces", a normative references must be
  added per
  https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-15#section-3.9
- prefix "if" in the import "ietf-interfaces" can remove quotes to remain
  consistent with other imports
- Remove WG Chairs from contact information per
  https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-15#appendix-C
- Module description must contain most recent copyright notice per
  https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-15#appendix-C
- Module description should contain note to RFC Ed. and placeholder reference
  to RFC when assigned
  https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-15#appendix-C
- Add placeholder reference and note to RFC Ed. for RFC when assigned
  https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-15#appendix-C
- Security Considerations should be updated to reflect new template at
  https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines
- Section 1.2 should be replaced with reference to
  draft-ietf-netmod-yang-tree-diagrams-02 rather (as-is in other i2rs YANG
  drafts in progress) per
  https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-15#section-2.5.1
- This module contains '12' features.  While it is understood the purpose of
  these features in the module, take precaution as to complexity for clients
  if they need to understand >= quantity of features per module in use on a
  network-element.
- A few comments exist that are either unecessary or redundant.  Encode the
  comment intent rather in description fields if need be.
- Per NMDA, which datastores are targeted for the module?  Will all RPC
  operations be acting upon the dynamic/ephemeral datastore?  It is not clear
  to me if the intention is to be persistent or ephemeral

General comments/Nits:
- references to 'def' could be expanded out to 'definition'
- references to 'decap' could be expanded out to 'decapsulation' for
  readability (across definitions and descriptions)
- Follow consistent capitalization of 'RIB' throughout document text.  Mixed
  use of 'Rib' and 'rib' exists (Outside of YANG node lowercase definitions).
- Is it necessary to prefix all nodes under the nexthop container with
  "nexthop-"?
- Section 2.5 - route-add RPC - text mentions it is required that the nh-add
  RPC be called as a pre-requisite however if the nh already exists and the
  nexthop-id is known, this should not be necessary.  In addition, the text
  reads 'or return' which should rather be a result of querying the
  appropriate node in the data tree.
- In 'IANA Considerations' - s/This document requests to register/This
  document registers/


___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

[i2rs] WG LC on the draft-ietf-i2rs-yang-dc-fabric-network-topology-03

[Susan Hares]

The WG LC call has been completed on
draft-ietf-i2rs-yang-dc-fabric-network-topology-03.txt, and the working
group has reached consensus on this data model.  This data model will be
forwarded to the IESG for publications. 

 

Thank you for your hard work on this data model, 

Susan Hares  and Russ White 

Co-chairs 

___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

[i2rs] WG LC for draft-ietf-i2rs-rib-data-model - 3rd WG LC (12/7 to 12/21)

[Susan Hares]

The I2RS RIB yang model has passed WG last call.   We had no comments on the
list.  This is not surprising since the WG has approved this 3 times. I will
forward the RIB models to the IESG for publication. 

 

Thank you for all your hard work on these models. 

 

Susan Hares 

 

 

___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

[i2rs] WG LC for draft-ietf-i2rs-rib-data-model - 3rd WG LC (12/7 to 12/21)

[Susan Hares]

This is the 3rd WG Last call for draft-ietf-i2rs-rib-data-model.  You can
find the draft at: 

 

https://datatracker.ietf.org/doc/draft-ietf-i2rs-rib-data-model/

 

In the previous 2 WG LCs, the WG did not change anything with the base model
- except those things that impact on the network management datastore
architecture (NMDA) or the security considerations.

 

In this WG LC discussion, please consider these questions?  

1)  Is this document ready for publication? 

2)  Do you see any technical problems with the document as part of NMDA
architecture where the model can be in ephemeral datastore or a
configuration datastore. 

 

3)  Do you have any concerns about the security considerations section? 

 

The Authors should again respond to this email indicating if they know of
any IPR with this draft. 

 

Susan Hares

Co-chair and shepherd.  

 

 

___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

[i2rs] draft-ietf-i2rs-yang-dc-fabric-network-topology - WG LC from 11/28 to 12/12/2017

[Susan Hares]

This begins a 2 week WG LC on the I2RS draft
draft-ietf-i2rs-yang-dc-fabric-network-topology from 11/28 to 12/12/2017. 

 

https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-dc-fabric-network-topo
logy/

 

The authors should indicate if they know of any IPR relating to this draft. 

 

Please consider during your WG LC review, the following questions: 

 

1)  Do you know of any implementations of this draft? 

2)  Does this draft adhere to the Network Management Datastore
architecture (NMDA)? 

3)  Do you know of any technical issues with this yang module? 

4)  Will the deployment of this yang module aid the management of Data
Center Fabrics? 

5)  Do you support publication of this yang module? 

 

Sue Hares 

 

 

 

 

___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

[i2rs] Publication has been requested for draft-ietf-i2rs-yang-l3-topology-13

[Susan Hares]

Susan Hares has requested publication of draft-ietf-i2rs-yang-l3-topology-13 as 
Proposed Standard on behalf of the I2RS working group.

Please verify the document's state at 
https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-l3-topology/

___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

[i2rs] Publication has been requested for draft-ietf-i2rs-yang-network-topo-18

[Susan Hares]

Susan Hares has requested publication of draft-ietf-i2rs-yang-network-topo-18 
as Proposed Standard on behalf of the I2RS working group.

Please verify the document's state at 
https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-network-topo/

___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

Re: [i2rs] [secdir] Security review of draft-ietf-i2rs-yang-l3-topology-03.txt

[Susan Hares]

Hilary: 

 

Your secdir-review was done on draft-ietf-i2rs-yang-l3-topology-08 back in
January.   The WG and authors have been slow to respond to your careful
comments.  The I2RS WG appreciates your comments. 

 

The illustrative example in this draft have been reduced to OSPF.   Would
review the improved security considerations in this draft
(draft-ietf-i2rs-yang-l3-topology-12.txt)?  The security considerations
sections were added in -11.txt.   

 

This shepherd believes we have resolved the security issues you raised.
Please let me know if you agree. 

 

Susan Hares

I2rs document shepherd 

___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

Re: [i2rs] Issues raised by Lada on draft-ietf-i2rs-yang-network-topo in draft-ietf-i2rs-yang-l3-topology-10 review.

[Susan Hares]

Alex:

 

I suggested some additions for Lada based on our conversation in email.
However, I suggest that you submit the two revisions of the draft that
contain the changes you've suggested in email
(draft-ietf-i2rs-yang-network-topo-18.txt, and
draft-ietf-i2rs-yang-l3-topology-11.txt).My suggestions to LADA were
editorial nits in nature. 

 

I believe you have resolved all comments for
draft-ietf-i2rs-yang-network-topo and we are ready for publication of this
document.  As soon as I see draft-ietf-i2rs-yang-network-topo-18.txt in the
repository, I will request the publication for
draft-ietf-i2rs-yang-network-topo-18.txt. 

 

Susan Hares 

Shepherd for draft-ietf-i2rs-yang-network-topo-18.txt 

 

From: i2rs [mailto:i2rs-boun...@ietf.org] On Behalf Of Alexander Clemm
Sent: Tuesday, November 14, 2017 5:07 AM
To: 'Susan Hares'
Cc: i2rs@ietf.org; draft-ietf-i2rs-yang-network-t...@ietf.org; 'Ladislav
Lhotka'
Subject: Re: [i2rs] Issues raised by Lada on
draft-ietf-i2rs-yang-network-topo in draft-ietf-i2rs-yang-l3-topology-10
review.

 

Hi Susan, all,

 

Please find responses below, 

 

Thanks

--- Alex

 

From: i2rs [mailto:i2rs-boun...@ietf.org] On Behalf Of Susan Hares
Sent: Sunday, November 12, 2017 9:41 AM
To: 'Alexander Clemm' <lud...@clemm.org>
Cc: i2rs@ietf.org; draft-ietf-i2rs-yang-network-t...@ietf.org
Subject: [i2rs] Issues raised by Lada on draft-ietf-i2rs-yang-network-topo
in draft-ietf-i2rs-yang-l3-topology-10 review.

 

Alex: 

In doing my final shepherd's review of draft-ietf-yang-network-topo for
-17.txt version I found a few Yang Doctor's comments you need to resolve. 

The review of draft-ietf-i2rs-yang-l3-topology-10 contains comments from
Lada on Comments to draft-ietf-i2rs-yang-network-topo-14.  See the message
linked to by: 

https://mailarchive.ietf.org/arch/msg/yang-doctors/ZdwwMUpvXaBiCQN6A3hm76joS
7Q

In this reviewing, draft-ietf-i2rs-yang-network-topo-17.txt, I do not see
the following addressed: 

1.  With YANG 1.1, the network type information looks like a perfect
candidate for identities (with multiple inheritance). Instead, it is
modelled with presence containers, which is cumbersome and redundant. I
don't see any reasons for doing so, if there are any, then they should be
explained in sec. 4.4.8.

Comment from shepherd:  I do not see the explanation Lada requested in for
"why containers" in: 

https://mailarchive.ietf.org/arch/msg/yang-doctors/ZdwwMUpvXaBiCQN6A3hm76joS
7Q

https://mailarchive.ietf.org/arch/msg/yang-doctors/0AcgU2Zr6RoMgF-vEx-3NHFh6
dM

 We do want to retain the ability to represent topologies of multiple
types and to construct correlated topologies, which is a major ODL use case:
'I want to see both OpenFlow and NETCONF view of my device state in one
place'.  So, we would like to keep it as is.  



 

2.  The document defines "supporting network" and then says "A
supporting network is in effect an underlay network." In the subsequent text
"underlay network" is used almost exclusively. So perhaps the term
"supporting network" should be dropped altogether?

Comment from shepherd: If you wish to keep supporting network to align with
TEAS or other work please just point to it.  Or if you wish to keep the term
because of common use, make that comment.  Either way - please resolve or
respond to LADA with reason. 

 We reread the document and believe this should remain as is.  TEAS
(one of our major use cases) also uses the term underlay; the term underlay
is fairly common.  An the same time, use of "supporting" in the model itself
is appropriate since it expresses the dependency. 



 

3.  The text should be better aligned with the terminology of
draft-ietf-netmod-revised-datastores. In particular,  "system-controlled"
should be used instead of "server-provided".

Comment from shepherd: If you can use the "system-controlled", it would be
better. If you cannot, please indicate why in the definitions. 

 Yes, this has been addressed.  It is all system controlled now. 



4.  Is it necessary to use URIs for identifying all objects in the data
model. 

URIs are difficult to use, so applications are likely to introduce some
abbreviations and keep an internal mapping, which could cause problems, e.g.
when matching objects in notifications with a GUI representation. In my
view, it should be sufficient to use URIs for network-id and plain strings
for other IDs, because all other objects are encapsulated inside a network,
so their name conflicts shouldn't matter.

Comment from shepherd:   A comment should be included on why
URIs.  Did I miss the comment? 

 

 This issue is a matter of design preference -- using strings is
certainly possible, but it has the downside of being a flat namespace, which
does not have any semantic meaning outside of YANG model. With URIs, the
identifier is structured and it has an inherent property th

Re: [i2rs] [yang-doctors] Yangdoctors early review of draft-ietf-i2rs-yang-l3-topology-10

[Susan Hares]

Lada:

During your review of the draft-ietf-i2rs-yang-l3-topology-10.txt, you
raised the following issues.  As part of the shepherd's review of
draft-ietf-i2rs-network-topo-14, I have investigated the resolution.  
I found that these comments have not be resolved.  Could  you review this
email to see if it resolves the questions on
draft-ietf-i2rs-network-topo-14?   The current draft is
draft-ietf-i2rs-network-topo-14.txt.   

The suggest changes below would go into draft-ietf-i2rs-network-topo-17.  

Thank you, Susan Hares 



*** Comments to draft-ietf-i2rs-yang-network-topo-14:

1. With YANG 1.1, the network type information looks like a perfect
   candidate for identities (with multiple inheritance). Instead, it
   is modelled with presence containers, which is cumbersome and
   redundant. I don't see any reasons for doing so, if there are any,
   then they should be explained in sec. 4.4.8.

Suggested text: 
[This topology model utilizes presence containers in order to support
correlated topologies. 
While identities (with multiple inheritance), might be used to support these
network 
topologies - it would prevent the support of network topologies.]

Question: Do you agree with Robert's comment below, and this resolution to
the text. 

2. The document defines "supporting network" and then says "A
   supporting network is in effect an underlay network." In the
   subsequent text "underlay network" is used almost exclusively. So
   perhaps the term "supporting network" should be dropped altogether?

Response:  These terms have specific in the body of work that the TEAS WG
has. 
See section 2 and section 5.8 in draft-ietf-teas-yang-te-topo-13.txt for the
use of overlay/underlay 
terminology.  Your comment points out that we have a common understanding 
in the I2RS and the routing-area's understanding of TEAS topology.

Suggested text addition:   
[draft-ietf-teas-yang-te-topo-13.txt] provides a description of supporting
network 
and underlay network in sections 2 and section 5.8 for traffic engineering
topology. ]


3. The text should be better aligned with the terminology of
   draft-ietf-netmod-revised-datastores. In particular,
   "system-controlled" should be used instead of "server-provided".

"server-provider has been removed" by version 17. 

4. Is it necessary to use URIs for identifying all objects in the
   data model. URIs are difficult to use, so applications are likely
   to introduce some abbreviations and keep an internal mapping, which
   could cause problems, e.g. when matching objects in notifications
   with a GUI representation. In my view, it should be sufficient to
   use URIs for network-id and plain strings for other IDs, because
   all other objects are encapsulated inside a network, so their name
   conflicts shouldn't matter.

Response: Lada - Robert Wilton feels this choice is a design preference
as do the authors.  Please review the message below, and determine if
you wish to discuss this further. 

Sue Hares 

-Original Message-
From: Alexander Clemm [mailto:alexander.cl...@huawei.com] 
Sent: Monday, November 13, 2017 9:54 PM
To: Róbert Varga; Susan Hares
Cc: Alexander Clemm; xufeng_...@jabil.com; Xufeng Liu; Jan Medved (jmedved);
Hariharan Ananthakrishnan; 'Nitin Bahadur'
Subject: RE: [i2rs] I-D Action: draft-ietf-i2rs-yang-l3-topology-11.txt

Thanks for your feedback, Robert!
--- Alex

> -Original Message-
> From: Róbert Varga [mailto:robert.va...@pantheon.tech]
> Sent: Monday, November 13, 2017 7:08 PM
> To: Alexander Clemm <alexander.cl...@huawei.com>; Susan Hares 
> <sha...@ndzh.com>
> Cc: Alexander Clemm <lud...@clemm.org>; xufeng_...@jabil.com; Xufeng 
> Liu <xufeng.liu.i...@gmail.com>; Jan Medved (jmedved) 
> <jmed...@cisco.com>; Hariharan Ananthakrishnan 
> <h...@packetdesign.com>; 'Nitin Bahadur' <nitin_baha...@yahoo.com>
> Subject: RE: [i2rs] I-D Action: 
> draft-ietf-i2rs-yang-l3-topology-11.txt
> 
> Hello,
> 
> The first issue is a problem, as it would make it impossible to 
> construct correlated topologies, which is a major ODL use case: 'I 
> want to see both OpenFlow and NETCONF view of my device state in one
place.'
> 
> The second issue is a matter of design preference -- using strings is 
> certainly possible, but it has the downside of being a flat namespace, 
> which does not have any semantic meaning outside of YANG model. With 
> URIs, the identifier is structured and it has an inherent property 
> that it is something someone somewhere may be able to resolve -- such 
> that a node's identifier can be turned into, say, RESTCONF URL to 
> access the management endpoint... I don't particularly care either 
> way, as the URI can be added as an augmentation where appropriate.
> 
> Regards,
> Robert
> 
> > -Original 

[i2rs] FW: New Version Notification for draft-hares-i2rs-ephemeral-ds-00.txt

[Susan Hares]

I2RS WG: 

This short draft provides a definition of a yang model for the I2RS ephemeral 
datastore.  

A majority of this draft comes from the excellent work in the example of an 
ephemeral datastore in draft-ietf-netmod-revised-datastores Appendix B.  This 
appendix was written with I2RS ephemeral state in mind.This will be 
discussed in I2RS today at 15:50-17:50.   


Sue Hares 

-Original Message-
From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] 
Sent: Sunday, November 12, 2017 4:50 PM
To: Alexander Clemm; Alex Clemm; Susan Hares
Subject: New Version Notification for draft-hares-i2rs-ephemeral-ds-00.txt


A new version of I-D, draft-hares-i2rs-ephemeral-ds-00.txt
has been successfully submitted by Susan Hares and posted to the IETF 
repository.

Name:   draft-hares-i2rs-ephemeral-ds
Revision:   00
Title:  I2RS Ephemeral Datastore
Document date:  2017-11-12
Group:  Individual Submission
Pages:  8
URL:
https://www.ietf.org/internet-drafts/draft-hares-i2rs-ephemeral-ds-00.txt
Status: https://datatracker.ietf.org/doc/draft-hares-i2rs-ephemeral-ds/
Htmlized:   https://tools.ietf.org/html/draft-hares-i2rs-ephemeral-ds-00
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-hares-i2rs-ephemeral-ds-00


Abstract:
   This document the Yang module for the I2RS ephemeral datastore.


  


Please note that it may take a couple of minutes from the time of submission 
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

[i2rs] Issues raised by Lada on draft-ietf-i2rs-yang-network-topo in draft-ietf-i2rs-yang-l3-topology-10 review.

[Susan Hares]

Alex: 

In doing my final shepherd's review of draft-ietf-yang-network-topo for
-17.txt version I found a few Yang Doctor's comments you need to resolve. 

The review of draft-ietf-i2rs-yang-l3-topology-10 contains comments from
Lada on Comments to draft-ietf-i2rs-yang-network-topo-14.  See the message
linked to by: 

https://mailarchive.ietf.org/arch/msg/yang-doctors/ZdwwMUpvXaBiCQN6A3hm76joS
7Q

In this reviewing, draft-ietf-i2rs-yang-network-topo-17.txt, I do not see
the following addressed: 

1.  With YANG 1.1, the network type information looks like a perfect
candidate for identities (with multiple inheritance). Instead, it is
modelled with presence containers, which is cumbersome and redundant. I
don't see any reasons for doing so, if there are any, then they should be
explained in sec. 4.4.8.

Comment from shepherd:  I do not see the explanation Lada requested in for
"why containers" in: 

https://mailarchive.ietf.org/arch/msg/yang-doctors/ZdwwMUpvXaBiCQN6A3hm76joS
7Q

https://mailarchive.ietf.org/arch/msg/yang-doctors/0AcgU2Zr6RoMgF-vEx-3NHFh6
dM

 

2.  The document defines "supporting network" and then says "A supporting
network is in effect an underlay network." In the subsequent text "underlay
network" is used almost exclusively. So perhaps the term "supporting
network" should be dropped altogether?

Comment from shepherd: If you wish to keep supporting network to align with
TEAS or other work please just point to it.  Or if you wish to keep the term
because of common use, make that comment.  Either way - please resolve or
respond to LADA with reason. 

 

3.  The text should be better aligned with the terminology of
draft-ietf-netmod-revised-datastores. In particular,  "system-controlled"
should be used instead of "server-provided".

Comment from shepherd: If you can use the "system-controlled", it would be
better. If you cannot, please indicate why in the definitions. 

 

4.  Is it necessary to use URIs for identifying all objects in the data
model. 

URIs are difficult to use, so applications are likely to introduce some
abbreviations and keep an internal mapping, which could cause problems, e.g.
when matching objects in notifications with a GUI representation. In my
view, it should be sufficient to use URIs for network-id and plain strings
for other IDs, because all other objects are encapsulated inside a network,
so their name conflicts shouldn't matter.

Comment from shepherd:   A comment should be included on why
URIs.  Did I miss the comment? 

 

Perhaps we can chat today at the social on where you are with these changes.
Let's see if we can both celebrate IETF 100 by submitting the base topology
draft and l3 draft to the IESG. 

 

Sue Hares 

___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

Re: [i2rs] WG LC on draft-ietf-i2rs-yang-network-topo (9/27/2017 to 10/11/2017) - WG Consensus declared by Chairs

[Susan Hares]

Alex: 

 

Welcome to Singapore.  Wow!  Today’s going to be a long day for you.  Perhaps 
we should talk after you take a short nap. 

 

#1 definition - Section 3 still defines datastore uniquely, although you do 
point to the revised datastores.  It would be best to make the same reference 
in section 3. 

 

#2 No examples – Please confirm by asking Kent Watsen on list regarding the 
examples.   Otherwise, we’ll cycle on this when we get to the IESG. 

 

Also – please see the comments that were unresolved from Lada’s review of the 
L3 topology.   

 

Sue Hares 

 

 

From: Alexander Clemm [mailto:lud...@clemm.org] 
Sent: Saturday, November 11, 2017 8:40 PM
To: i2rs@ietf.org; Susan Hares
Cc: 'Kent Watsen'; i2rs-cha...@ietf.org; i2rs-...@ietf.org; 'Alia Atlas'
Subject: Re: [i2rs] WG LC on draft-ietf-i2rs-yang-network-topo (9/27/2017 to 
10/11/2017) - WG Consensus declared by Chairs

 

Hi Sue, I just arrived in Singapore.

I did adopt the definition. This is addressed in -17. 

I did not put the example per earlier email exchange and at the time Kent 
seemed to be fine with that?

Thanks, Alex

Get Outlook for Android <https://aka.ms/ghei36> 

 





On Sun, Nov 12, 2017 at 9:13 AM +0800, "Susan Hares" <sha...@ndzh.com> wrote:

Alex: 

 

I had hoped to celebrate IETF-100 with submitting 
draft-ietf-i2rs-yang-network-topo-17 to the IESG.  However, there are still a 
few things to resolve from Kent Watens review 
(https://www.ietf.org/mail-archive/web/i2rs/current/msg04501.html). 

 

In reviewing draft-ietf-i2rs-yang-network-topo-17, I found the following things 
addressed: 

1)  "ietf-network" uses prefix “nd”, should be “nw” and 
"ietf-network-topology" uses  prefix “lnk” should be “nt” or maybe “nwtp”.

2)  the groupings "link-ref" and "tp-ref" descriptions should indicate why 
they are defined but not used in these modules

3)  Both /nd:networks/network/network-id and 
/nd:networks/network/link/link-id are the key fields to their respective lists, 
but they are not the first nodes listed in the list.

 

In reviewing draft-ietf-i2rs-yang-network-topo-17, I do not find the following 
things address that Ken commented on: 

1)  Kent’s comment: Use cases exist in appendix A, but yang examples do not 
exist.  

Fix: Short examples could be put in Appendix A with each use case) 

2)  Kent’s comment: The document defines its own "datastore" term, rather 
than import the term from revised-datastores.  

Question: Section 3 still gives its own datastore definition.  Is there a 
reason I missed on this approach? 

Could you wrap up these two issues today and submit a -18 to the IETF drafts?  
I’d love to chat today about these two issues. 

Susan Hares

(shepherd/co-chair) 

 

She

 

 

 

___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

Re: [i2rs] WG LC on draft-ietf-i2rs-yang-network-topo (9/27/2017 to 10/11/2017) - WG Consensus declared by Chairs

[Susan Hares]

Alex: 

 

I had hoped to celebrate IETF-100 with submitting
draft-ietf-i2rs-yang-network-topo-17 to the IESG.  However, there are still
a few things to resolve from Kent Watens review
(https://www.ietf.org/mail-archive/web/i2rs/current/msg04501.html). 

 

In reviewing draft-ietf-i2rs-yang-network-topo-17, I found the following
things addressed: 

1)  "ietf-network" uses prefix "nd", should be "nw" and
"ietf-network-topology" uses  prefix "lnk" should be "nt" or maybe "nwtp".


2)  the groupings "link-ref" and "tp-ref" descriptions should indicate
why they are defined but not used in these modules

3) Both /nd:networks/network/network-id and
/nd:networks/network/link/link-id are the key fields to their respective
lists, but they are not the first nodes listed in the list.

 

In reviewing draft-ietf-i2rs-yang-network-topo-17, I do not find the
following things address that Ken commented on: 

1)  Kent's comment: Use cases exist in appendix A, but yang examples do
not exist.  

Fix: Short examples could be put in Appendix A with each use case) 

2)  Kent's comment: The document defines its own "datastore" term,
rather than import the term from revised-datastores.  

Question: Section 3 still gives its own datastore definition.  Is there a
reason I missed on this approach? 

Could you wrap up these two issues today and submit a -18 to the IETF
drafts?  I'd love to chat today about these two issues. 

Susan Hares

(shepherd/co-chair) 

 

She

 

 

 

___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

Re: [i2rs] WG LC on draft-ietf-i2rs-yang-network-topo (9/27/2017 to 10/11/2017) - WG Consensus declared by Chairs

[Susan Hares]

Greetings: 

 

We've only received approval from this last call.  However, this is the 4th
WG LC. All others have been positive and well-attended.  The draft has been
kicked back for integration with security considerations and the NETMOD
revised data stores.   We've resolved these issues.   This draft and the L3
Topology draft are key to other drafts.

 

The WG chairs plan  declare consensus on this draft, and send it to the
IESG.  If anyone objects, please send email to the list by 10/20. 

 

Susan Hares and Russ White 

___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs