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

From: Alia Atlas <[email-masked]>
Date: Fri, 9 Feb 2018 17:28:01 -0500

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.

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?

 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.

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)?

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.

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"?

Regards,
Alia

---

From: "Zhuangyan (Yan)" <[email-masked]>
Date: Sun, 11 Feb 2018 10:14:36 +0000

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-masked]]
Sent: Saturday, February 10, 2018 6:28 AM
To: [email-masked]; [email-masked]
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:

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

---

From: Alia Atlas <[email-masked]>
Date: Sun, 11 Feb 2018 07:18:09 -0500

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)" <[email-masked]>
wrote:

> *From:* Alia Atlas [mailto:[email-masked]]
> *Sent:* Saturday, February 10, 2018 6:28 AM
> *To:* [email-masked]; draft-ietf-i2rs-yang-dc-fabric-network-topology@ietf.
> org
> *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.
>
>
>
> Y: Geneve is used instead J.
>
>
>
> 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…
>
>
>
> 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: yesJ and thank you for the nits.
>
>
>
> Regards,
>
> Alia
>

---

From: "Zhuangyan (Yan)" <[email-masked]>
Date: Mon, 12 Feb 2018 03:43:07 +0000

Hi Alia,

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

Best Regards,

Yan

From: Alia Atlas [mailto:[email-masked]]
Sent: Sunday, February 11, 2018 8:18 PM
To: Zhuangyan (Yan) <[email-masked]>
Cc: [email-masked]; [email-masked]
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)" <[email-masked]<mailto:[email-masked]>> wrote:
Hi Alia,

Best Regards,

Yan

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

Minor:

Nits:

Regards,
Alia