Subject: [bess] Brian Haberman's No Objection on draft-ietf-bess-mvpn-global-table-mcast-02: (with COMMENT)

From: "Brian Haberman" <[email-masked]>
Date: Tue, 01 Sep 2015 09:38:12 -0700

Brian Haberman has entered the following ballot position for
draft-ietf-bess-mvpn-global-table-mcast-02: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-global-table-mcast/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I support the publication of this document, but I have one (non-blocking)
comment... 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?

---

From: Eric C Rosen <[email-masked]>
Date: Tue, 1 Sep 2015 15:54:15 -0400

Brian,

> comment...

Thanks!

> I do not see any forwarding plane discussions in this document

I don't think there are any issues here.  Is there something specific 
that concerns you?

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.

Eric

---

From: Brian Haberman <[email-masked]>
Date: Tue, 01 Sep 2015 20:11:56 -0400

Hi Eric,

> I don't think there are any issues here.  Is there something specific

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...

> unicast routing is loop-free, the resulting multicast trees should be

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