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

[Gyan Mishra <[e-mail]>]

Hi Sandy

Most welcome.  Happy to help out and provide guidance on the major
undertaking with the Yang model.  Again, excellent work by the authors.

Let me know when you have the draft updated with the hierarchy and I would
be happy to provide some further feedback.

Kind Regards

Gyan

On Tue, May 11, 2021 at 11:08 PM <[e-mail]> wrote:

> Hi Gyan,
>
> Thank you very much for your review! The suggestion is great!
>
> We'll consider how to improve the draft and model.
>
> Please find my answer inline with Sandy>.
>
>
> <http://www.zte.com.cn/>
> 原始邮件
> *发件人：*GyanMishra
> *收件人：*张征00007940;
> *抄送人：*[e-mail];[e-mail];
> *日 期 ：*2021年05月09日 02:01
> *主 题 ：**Re: [MBONED] Continued Review of multicast-yang-model*
> Hi Sandy & Authors
>
> Excellent work capturing all the complexity and nuances of all the
> scenarios related to multicast deployments in the Yang model.
>
>
> I just reviewed the Multicast Yang model and as this should capture I
> believe existing and future PTA tunnels types I noticed a few missing.
>
> The Yang framework diagram is quite complicated and maybe we can setup a
> call to go over it below is confusing.
>
> 3.1 Diagram
>
> This diagram provides a really nice flow chart for the overall multicast
> Yang model.  Few comments
>
> Multicast model has 3 categories underlay, transport and overlay.
>
> The layering horizontally is a bit hard to follow in the diagram and here
> are some ideas.
>
> So there are two main cases fork in the road
>
> 1. Underlay-only  netwok
> 2. Underlay/Overlay network
>
> Sandy> These categories are from the protocol perspective. Do I understand
> right? Yes, some of the protocols, for example PIM, can be used as
> transport and overlay as well.
>
> Because there is no explicit layer concept before. Now we can find that
> the layered architecture is more beneficial for current and future
> multicast depolyment.
>
> So the model is classified for three layers.
>
>
> The difficulty is how do you represent it all together in a homogeneous
> Yang model hierarchy
>
> Sandy> Yes. It's difficult. But it may help more multicast deployment work
> after it's improved.
>
>
> Underlay/Overlay network - “BGP free” core with PIM option for MVPN Rosen
> PTA
>
> BGP is part of MVPN SAFI 129 so I don’t think we have to call our BGP in
> overlay
>
> Sandy> It sounds reasonable, we will consider the modification about it.
>
> MLD / MLD snooping is v6 underlay - Underlay only IP transport related
>
> Sandy> Because MLD/IGMP is a single hop protocol, it can not be used as
> multiple hop transport protocol, but it can be used as overlay protocol to
> collect the receiver information.
>
> MLD/IGMP snooping is analogous though it can transport more hops.
>
> So here am showing both together as you have it in the diagram
>
> Overlay
>
> MVPN SAFI 129( RFC 6513 6514 procedures)
>
> FEC TLV - Type, Root, Opaque
>
> Ingress - FEC Root  Type 1-5
> Egress  Type 6 7
>
>
> Egress  triggered-mLDP
> Ingress triggered- RSVP-TE /BIER Type 4 leaf-ad
>
> Sandy> Yes. A set of keys needs to be used for make relationship between
> this model and MVPN YANG model. And further IMO the specific information
> about types may not need to be defined in this model but in MVPN YANG model.
>
>
> Transport
>
> IP - could be v4 or v6 and would be for Underlay only scenario
>
> Sandy> Yes. We will consider add some description.
>
>
> MPLS  / SR-MPLS
>
> PTA = mLDP P2P MP2MP, P2MP TE, IR, BIER, Replication SID
> PIM GRE - ASM, SSM, BIDIR
>
> Sandy> Good catch. We will consider to add some or all of them.
>
>
> SRv6
> PTA - Replication SID
> BIER
>
> Sandy> Good suggestion. We will think about to add the segment routing
> technology as transport technology.
>
>
> Underlay v4 v6 dual stacked
>
> L3
>
> OSPF PIM or no PIM for non MVPN Rosen PTA
> ISIS PIM no PIM for non MVPN Rosen PTA
> BGP PIM no PIM for non MVPN Rosen PTA
> BABEL PIM
>
> L2
>
> Snooping v4
>
> MLD Snooping v6
> Sandy> I am not much sure if we need to split to L3 and L2. But we will
> consider about it.
>
> Much appreciate for your review and suggestion!
>
> Best regards,
>
> Sandy
>
> Kind Regards
>
>
> Gyan
>
> On Sat, May 8, 2021 at 4:49 AM <[e-mail]> wrote:
>
>> Hi Jake,
>>
>> Thank you very much for your review! And sorry for the late response.
>>
>> Please find my answer with Sandy> inline.
>>
>>
>> 原始邮件
>> *发件人：*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/
>>
>> Sandy> Appreciate for your review again! :-)
>>
>>
>>
>> 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
>>
>> Sandy> Because we verified this model in ODL BIER project, so some other
>> parts included in this model, such as mldp or p2mp-te, has not been
>> verified yet.
>>
>> So experience with these protocols may do good help for the model review.
>>
>>
>>
>> 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?
>>
>> Sandy> The model can be used by netconf, but it won't affect the netconf
>> running. When this model configured, some other model may be also
>> configured. For example, when BIER is configured as transport, BIER model
>> may also be configured if you have any parameter needs to be set in BIER
>> model.
>>
>>
>> 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?)
>>
>> Sandy> Yes. The underlay may not match. So the nofitication can be used
>> to report this situation to controller. But what the controller needs to do
>> is out of scope of this draft.
>>
>>
>> 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.
>>
>> Sandy> Thank you very much for your reminder, I'll fix it.
>>
>> 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?
>>
>> Sandy> Yes. If these keys are not used, it can be set to blank or zero.
>>
>>
>> 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?
>>
>> Sandy> Thank you for your pointing out it. OSPF and ISIS support
>> multi-topoloty feature, so the underlay can map to a specific topology.
>> I'll also add it in ISIS underlay.
>>
>>
>> 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?
>>
>> Sandy> Much appreciate if you make some suggestion 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?)
>> Sandy> Yes. But I am not sure if these usage is existed actually. Do you
>> think it's better to only keep one for it?
>>
>> 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?
>> Sandy> For example, if the OSPF topology is configured, the associated
>> OSPF YANG should also be configured in the controller. And the controller
>> will push the multicast model and OSPF model to the device. But as you
>> said, the description needs to be updated. It's great if you have any
>> suggestion for it.
>>
>> I hope that's helpful, and please let me know if you're expecting
>> anything else from me on this revision.
>>
>> Sandy> Thank you very much again for your help!
>>
>> Best regards,
>>
>> Sandy
>>
>>
>> Best regards,
>> Jake
>>
>>
>>
>> _______________________________________________
>> MBONED mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mboned
>>
> --
>
> <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> *Network Solutions A**rchitect *
>
> *Email [e-mail] <[e-mail]>*
>
>
>
> *M 301 502-1347*
>
>
>

-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [e-mail] <[e-mail]>*



*M 301 502-1347*