Re: [i2rs] AD review of draft-ietf-i2rs-yang-dc-fabric-network-topology-04

["Zhuangyan (Yan)" <[e-mail]>]

Hi Alia,

It is moved to informative reference in rev-06.
Thank you very much.

Best Regards,

Yan

From: Alia Atlas [mailto:[e-mail]]
Sent: Sunday, February 11, 2018 8:18 PM
To: Zhuangyan (Yan) <[e-mail]>
Cc: [e-mail]; [e-mail]
Subject: RE: AD review of draft-ietf-i2rs-yang-dc-fabric-network-topology-04

Thank you for the revision.
Given that Geneve is just an example, please have it as an Informative reference.  Otherwise, this work will not issue as an RFC until Geneve does and that tight a coupling kids not needed.

Regards,
Alia

On Feb 11, 2018 5:14 AM, "Zhuangyan (Yan)" <[e-mail]<mailto:[e-mail]>> wrote:
Hi Alia,

Thank you for your comments~ A new revision has been published to resolve your comments.
Detailed responses as below.

Best Regards,

Yan

From: Alia Atlas [mailto:[e-mail]<mailto:[e-mail]>]
Sent: Saturday, February 10, 2018 6:28 AM
To: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: AD review of draft-ietf-i2rs-yang-dc-fabric-network-topology-04

As is customary, I have done my AD review of draft-ietf-i2rs-yang-dc-fabric-network-topology.  First, I would like to thank the authors - Yan Zhuang, Danian Shi, Rong Gu, and Hari Ananthakrishnan - for their excellent and quick work on this document.

I do have a few minor comments below, that can be handled while the document is in IETF Last Call - though sooner is better.  When the last author responses around IPR notifications are received, Sue will pass this to me and I'll put it into IETF Last Call.  I expect it to be on the IEST telechat on March 8.

Minor:

1) In the Introduction: " may implement a technique
     discussed in NVO3 WG, such as GPE [I-D. draft-ietf-nvo3-vxlan-gpe]."
   Unless there is a strong motivation for referring to VXLAN-GPE, please
   refer to Geneve instead; that is the Standards Track encapsulation that
   NVO3 is doing.
Y: Geneve is used instead ☺.

2) Can a device have a role that is both spine and border or both leaf and border?
  As defined, I don't see that as possible - but it's just a matter of another
 device-role.  Is the assumption that the gateway mode determines whether
border means also spine or also leaf?
Y: Thanks, we corrected the definition of ‘role’. It is now defined as “leaf-list” which can include both two identities e.g. leaf and border.
To your question, a spine can be the gateway while a border can be placed on a leaf if the network administrator wants…

 3) leaf traffic-behavior {
            type enumeration {
                enum normal {
                    description "Normal";
  What is "Normal"?  Is this shortest-path first?  Or more flexible?  A few more words of description
would be helpful.
Y: Added. The normal behavior is that there is no policy enforced to traffics…
4)  container vni-capacity {
         description "Number of vnis that the fabric has";
Could you please expand VNI and provide a reference (Geneve or VXLAN or NVO3 Architecture is fine)?
Y: Thank you. Expanded VNI and provided a reference to VXLAN.

5)  I don't see [I-D.draft-ietf-nvo3-vxlan-gpe] as a normative reference.  Perhaps it is informative - but only mentioned in the introduction and I'm suggesting changing to refer to Geneve.

Y: Geneve is added as a normative reference.

Nits:

a)  description "Links that include within a fabric.";  change to "Links that are included within the fabric"

b)  description "Ports that include in the fabric.";  change to "Ports that are included within the  fabric"

c) description "Augmentation for fabric nodes created by faas.";  please expand "faas"  It isn't defined or used elsewhere.  Perhaps it is "Fabric As A Service"?
Y: yes☺ and thank you for the nits.

Regards,
Alia