Re: [MBONED] Continued Review of multicast-yang-model

[[e-mail]]

Hi Jake, 


Thank you very much! 


I misunderstood your previous email that has the title "partial review", 


I thought you have not finished the review, so I waited for further review. 


I'll study your review and come back as soon as possible. 



Much appreciate for your review! :-)


Best regards,


Sandy





原始邮件



发件人：Holland,Jake
收件人：MBONED WG;张征00007940;
日 期 ：2021年03月20日 11:01
主 题 ：Continued Review of multicast-yang-model




Hi Sandy,
 
During the mboned meeting I think you said you were waiting on a review from
me, but I thought I had sent one here the day after IETF 109, so I didn't
realize you were waiting:
https://mailarchive.ietf.org/arch/msg/mboned/cjVQ_qM2yeboxY0i3vvjSe9g3Xo/
 
Also, after a quick review of what I said during 109, I think I was expecting
you to send something to the list detailing which parts of the model were
well-proven with its use in production, and which parts of the model needed
a closer look since nobody has used it yet:
https://www.youtube.com/watch?v=K1FS3XqqWTw&t=3371s
 
Anyway, I see from my last review that there's parts of the document I didn't
cover, so I guess I'll try to do that now:
 
0.
I'm struggling with the high-level expectations of what happens in a
network if I configure something with this model.  In Appendix A, a
helpful example is given, but what happens when you set that data
instance in a netconf instance?  Does it make the forwarding get
configured, so this is mostly a transport path signaling mechanism?
 
What happens if the underlay does not match?  (For example, what if
the underlay in the setting says ospf, but it's in fact the network
between ingress and egress was running isis?)
 
1.
There are errors in the yang rules validation, as reported on the datatracker
page:
https://datatracker.ietf.org/doc/draft-ietf-mboned-multicast-yang-model/
 
[e-mail]:252: error: RFC 8407: 4.14: statement "grouping" must have a "description" substatement
[e-mail]:363: error: RFC 8407: 4.14: statement "grouping" must have a "description" substatement
[e-mail]:364: error: RFC 8407: 4.14: statement "choice" must have a "description" substatement
 
These seem to need a fix.
 
2.
In 3.2/3.3, the multicast-keys list seems to be a problem, especially with
respect to vni-type and vni-value, because there's only 3 possibilities for
virtual-type (vxlan, nvgre, and geneve), but a value is required in order
to have it as a key.  Likewise, I'm not sure the vpn-rd and vni-value make
sense for all (S,G)s, do these have a value?  (What about in a traditional
PIM network?)
 
Would it make sense to use a type that permits these to be blank where
appropriate?
 
3.
I'm confused about the multicast-underlay/ospf/ospf/toplogy location.  What
is that, and why don't the other underlays have anythin analogous?
 
4.
In section 3.3, there are a lot of grammar problems.  I'll list some of
them here, do you need text suggestions for these?
 
4.a.
 
    ... Multicast keys include the features of multicast flow,
   such as(vpnid, multicast source and multicast group) information.  In
   data center network, for fine-grained to gather the nodes belonging
   to the same virtual network, there may need VNI-related information
   to assist.
 
4.b.
 
    ... there may define BIER
   information including (Subdomain, ingress-node BFR-id, egress-nodes
   BFR-id).  If no (ingress-node, egress-nodes) information are defined
   directly, there may need overlay multicast signaling technology, such
   as MLD or MVPN, to collect these nodes information.
 
 
5.
In section 3.3, I was confused by this bit:
 
   ... One or
   several transport technologies could be defined at the same time.
 
What does it mean if several transport technologies are defined at
the same time, are those for redundant paths or something?
 
Likewise this about the underlay:
 
    ... One or several underlay
   technologies could be defined at the same time if there is protective
   requirement.
 
By "protective environment" do you mean a redundant setup that can
forward the traffic through multiple paths?  (And if so, what if the
redundant paths use the same type of underlay?  Or if not, what does
it mean?)
 
 
6.
As an overview comment:
 
I still feel like I'm missing something when I read through this
spec--am I understanding correctly that the whole purpose is to
set up the forwarding for each of the given (S,G)s through the
network?  If so, I'm confused about what the underlay and overlay
properties are for, exactly.  How does the controller use the
information that there's an OSPF underlay, when it has that info?
 
 
I hope that's helpful, and please let me know if you're expecting
anything else from me on this revision.
 
Best regards,
Jake