Subject: [mpls] seamless-mcast: Question re Leaf A-D routes for internet multicast

From: Eric Rosen <[email-masked]>
Date: Thu, 06 Oct 2011 10:12:22 -0400

I have a question about the "Leaf A-D Route for Internet Multicast"
described in section 6.2.2 of draft-ietf-mpls-seamless-mcast-01.txt.  The
NLRI seems to be a bit different than the NLRI of Leaf A-D routes derived
from MVPN I-PMSI/S-PMSI A-D routes, and I'd like to understand whether this
difference is (a) intentional and (b) a good idea.

Let's look at a Leaf A-D route that is derived from an MVPN S-PMSI A-D
route.

Suppose the S-PMSI A-D route has the following NLRI:

        route type = 3 (S-PMSI A-D route),
        length of this NLRI,
        RD,
        multicast source length,
        multicast source,
        multicast group length,
        multicast group,
        originating router (call it X).

According to draft-ietf-l3vpn-2547bis-mcast-bgp-08.txt, a Leaf A-D
route derived from this S-PMSI A-D route will have the following NLRI:

        route type = 5 (Leaf A-D route),
        length,
        route key,
        originating router (call it Y)

where "route key" is defined as the MCAST-VPN NLRI of the route from which
the Leaf A-D route is derived.  So if we modify the diagram to show the
individual fields of the route key, we find that the MCAST-VPN NLRI of the
Leaf A-D route is:

        route type = 5 (Leaf A-D route),
        length of this NLRI,
        route type = 3 (derived from S-PMSI A-D route),
        length of the S-PMSI A-D route's NLRI (i.e., length from here
                  to the field containing Y)
        RD,
        multicast source length,
        multicast source,
        multicast group length,
        multicast group,
        originator of the S-PMSI A-D route (X)
        originator of the Leaf A-D route (Y)

However, in draft-ietf-mpls-seamless-mcast-01.txt, the NLRI of a Leaf A-D
route for "Internet multicast" is defined somewhat differently, as:

        route type = 5 (Leaf A-D route),
        length of this NLRI,
        RD,
        multicast source length,
        multicast source,
        multicast group length,
        multicast group,
        ingress router,
        originator of the Leaf A-D route (Y)

Note that the NLRI for "internet multicast" is two bytes shorter than the
NLRI for MVPN, omitting the octets that would otherwise hold the type of the
S-PMSI A-D route from which the Leaf A-D route was derived, as well as the
length of the NLRI of that S-PMSI A-D route.

The draft does state that for "internet multicast", only two RD values are
legal: all zeroes or all ones.  So it appears that there is a way to tell
whether a Leaf A-D route was derived from some other route or not: look at
the third octet of its NLRI.  If that octet has the value 0x00 or the value
0xff, then the Leaf A-D route is not derived from another route, and hence
must be an "Internet Multicast" route.  The only other proper values of this
octet are the values 0x01, 0x02, and 0x03.

I would appreciate it if the authors would verify whether this is the
correct interpretation or not.  If it is, it would be good to add some text
that calls attention to this difference, and that explains explicitly how to
determine whether a received Leaf A-D route is or is not derived from some
other route.

If I understand this correctly, this piece of the protocol design doesn't
seem like a good practice to me.  The procedures for parsing the Leaf A-D
route NLRI should not depend upon a priori knowledge that, in the envisioned
use cases, the valid "route type" values are different than the valid values
of the first octet of the RD.  The coding rules for the RD and the coding
rules for the route type byte should be independent.  Otherwise we are just
opening the door for incompatibilities and interworking problems in the
future.

The obvious alternative for an "internet multicast" Leaf A-D route would be:

        route type = 5,
        length of this NLRI,
        route type = TBD (new value to indicate that is Leaf A-D route is
                          not derived from a PMSI A-D route.)
        length from here to Y (perhaps this field could be omitted
                               without problem)
        RD,
        multicast source length,
        multicast source,
        multicast group length,
        multicast group,
        ingress router,
        originator of the Leaf A-D route (Y)

This keeps the RD coding rules independent from the "route type" coding
rules.

BTW, page 13 of the draft says "the entire MCAST-VPN NLRI of the [Leaf A-D
route used for Internet multicast] has the following format", and then shows
a diagram that begins with the RD.  This diagram does not actually show the
"entire NLRI", as it omits the route type and length fields.  This should be
corrected.

Also BTW, I think the term "Internet multicast" should actually be "global
table multicast".  The use of "internet multicast" in this document doesn't
actually mean that the multicast comes from the internet, it just means that
the multicast is not a VPN customer multicast.  The "internet multicast"
procedures could be used to set up, e.g., P-tunnels for MVPN, and there
shouldn't be any suggestion that the P-tunnels are "internet multicasts".

---

From: Yakov Rekhter <[email-masked]>
Date: Thu, 27 Oct 2011 08:32:21 -0700

Eric,

>         originator of the Leaf A-D route (Y)

That is correct.

> length of the NLRI of that S-PMSI A-D route.

That is correct too.

> determine whether a received Leaf A-D route is or is not derived from some

We will add some text to cover this in the next version of the draft.

> "entire NLRI", as it omits the route type and length fields.  This should be

We will correct the diagram in the next version of the draft.

> shouldn't be any suggestion that the P-tunnels are "internet multicasts".

We'll replace "Internet multicast" with "global table multicast"
in the next version of the draft.

Yakov.