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:[email protected]]
Sent: Saturday, February 10, 2018 6:28 AM
To: [email protected]; [email protected]
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
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs

Reply via email to