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

[Alia Atlas <[e-mail]>]

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]>
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]]
> *Sent:* Saturday, February 10, 2018 6:28 AM
> *To:* [e-mail]; 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.
>
>
>
> 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 J.
>
>
>
> 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: yesJ and thank you for the nits.
>
>
>
> Regards,
>
> Alia
>