Re: [MBONED] Trace mechanism to build multicast tree from source

Hi Mankamana, Ravinder, 

Thank you for bring this interesting topic. From my point of view YANG data can be used to generate the multicast tree by specific executions of PIM model. 

Please see if these steps below are feasible.

For example, if we want to get a (S1,G1) multicast tree from the network below,

( Please see the attachment if the figure showing is disordered. )

                if3 +---+if5  if8 +---+

              +---> | B +-------> | D |

              |     +---+         +---+

           if1|

            +---+

(S1,G1)+--> | A |

            +---+              if9+---+

           if2|       +---------> | E |

              |       |if6        +---+

              | if4 +---+

              +---> | C |

                    +---+

                      |if7    if10+---+

                      +---------> | F |

                                  +---+

Suppose that A is the first hop which connects the source (S1,G1), the multicast tree for (S1,G1) has been built by PIM protocol. 

Ietf-pim-base model (draft-ietf-pim-yang-17) should be used.

Suppose that we would like to get a multicast tree for (S1,G1) by a controller, and the controller can get the ietf-pim-base models from all routers.

Suppose that the network is IPv4 environment.

Step1, ietf-pim-base models from routers A-F are got by controller.

Step2, ietf-pim-base model got from A is checked, the associated outgoing interface list indexed by (S1,G1) can be got. 

The outgoing interface list includes the interfaces if1, if2.

Step3, the associated neighbors indexed by if1 and if2 are got also from the model. The neighbors’ addresses is the interface address of if3 and if4.

Step4, the (S1,G1) items in ietf-pim-base models got from routers B-F are checked, B and C are selected because the addresses of if3 and if4 match the neighbors’ addresses in step3. 

( The rpf-neighbor value can be checked to valid the upstream neighbor’s address, such as if1’s address matches the rpf-neighbor value in B’s (S1,G1). )

Step5, repeat step2 ~ step4, we can get all the interface/ neighbor information associated with (S1,G1), then a multicast tree can be generated.

Thanks,

Sandy

原始邮件

发件人：MankamanaMishra(mankamis) <mankamis=40cisco.com@dmarc.ietf.org>
收件人：mboned@ietf.org <mboned@ietf.org>mboned-chairs@ietf.org <mboned-chairs@ietf.org>
抄送人：Ravinder Badwal <Ravinder.Badwal@sjrb.ca>
日 期 ：2018年09月21日 05:37
主 题 ：[MBONED] Trace mechanism to build multicast tree from source

_______________________________________________
MBONED mailing list
MBONED@ietf.org
https://www.ietf.org/mailman/listinfo/mboned

Hi WG members,

During last IETF,  Ravinder (Service provider) had a point that it would be nice to have mechanism where network administrator has flexibility to find complete tree view from source. Basically, mtrace does  reverse of it where we tracec it from receiver. But his point was , as a service provider it would be good to see complete tree where multicast traffic is flowing.

While thinking in this direction, I thought it might be good to take this question to list and get the input.

One way would be to have mtrace mechanism, which starts from a given point, and goes to each of next hop from where there is PIM join for given (S,G)  and then report it back to actual originator.

Can any mechanism from Yang data be used for this purpose ?

Any other thoughts ?

Thanks

Mankamana

Re: [MBONED] Trace mechanism to build multicast tree from source

Attachment: =?UTF-8?B?bmV0d29yay50eHQ=?=