Hi Eric, On 9/1/15 3:54 PM, Eric C Rosen wrote: > Brian, > >> I support the publication of this document, but I have one (non-blocking) >> comment... > > Thanks! > >> I do not see any forwarding plane discussions in this document >> and I wonder if there was discussion about impacts on multicast >> forwarding. With the removal of the VPN-related checks, is there a >> possibility of loops in the forwarding of multicast data based on the GTM >> information? What about implications for RPF checks? > > I don't think there are any issues here. Is there something specific > that concerns you?
No, I put the Comment in before I had time to thoroughly review the normative RFCs. And having had to work through a variety of inter-domain multicast proposals in the past... > > As in MVPN, each egress node still has to select an ingress node for a > given flow, and has to discard traffic that is not from that ingress > node. This requires that the egress be able to infer the identity of > the ingress from the data packet's encapsulation. But the relevant > mechanisms are not impacted by the fact that there is no VPN-specific > context. > > Similarly, the procedures for setting up the multicast tunnels are not > impacted by the lack of VPN-specific context; if the global table > unicast routing is loop-free, the resulting multicast trees should be > loop-free as well. > Right. Now that I have reviewed the MVPN specs in more detail, my initial (minor) concern was unfounded. Thanks for the quick response. Regards, Brian
signature.asc
Description: OpenPGP digital signature
_______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
