Re: [MBONED] MNAT draft

["Holland, Jake" <[e-mail]>]

Hi Lenny,

On 11/13/20, 1:09 PM, "Leonard Giuliano" <[e-mail]> wrote:
> Jake- OK, I'm starting to grasp this all, as I map the text to the right 
> buzzwords.  So it seems the motivating use cases are the following:
> 
> 1) v4 <-> v6 mcast translation
>
> 2) solving the problem of RPF with a BGP-free core
>
> 3) SSM mapping (turning ASM reports into SSM joins/subscribes)
>
> 4) static multicast routing
>
> Let me know if this is correct.  See comments inline:

Yes, exactly.

> | As I understood it, in MVPN the PBR needs to have some new functionality
> | that's not already present on the CMTS or CPE devices, and those can't
> | easily be upgraded, so the PBR would have to be north of the CMTS.
>
> No, in GTM (RFC7716), no changes are needed on the attachment networks, 
> which in this case would include CPE and CMTS.  Also, please try to avoid 
> thinking about MVPN, as GTM is explicitly designed to work in a non-VPN 
> environment (the "Global Table").  It borrows MVPN concepts and applies 
> them to the non-VPN Global Table case.

Cool, thanks for the explanation.

> | Maybe I'm not understanding something, but I don't see a place the
> | MVPN functionality can be deployed at the receive side that solves
> | the problem in this scenario, since it has to be both to the north
> | and south of the same point in the network.
>
> Let me know if this diag is accurate and helpful:
>
> CPE--CMTS---AR1---MPLS_IR1---MPLS_TR1---MPLS_IR2---AR2---AR3---Src
...
> forwards it to AR1.  So this prevents the need for mcast NAT to avoid RPF 
> problems (#2), but from your context, I get the impression that you are 
> more concerned with the SSM mapping part (#3) here.

Thanks for the explanation.

Yes, in the problem I was outlining for this case, the SSM mapping
was the focus.

But this helps a lot for my understanding of how GTM can help with
the RPF problem.  I'm not sure I have the whole picture yet, but this
is very helpful and gets me a lot closer.

Of course I agree that networks that can ingest traffic and solve all
their delivery constraints with GTM (or otherwise) would not need MNAT,
and I agree that some of the problems MNAT can solve could be solved
with GTM instead, and that networks that only have those problems would
probably prefer GTM for at least the near future.

> | A key representative scenario was:
> | - There's an IPTV app that only uses ASM, and an access device that uses
> |   only IGMPv2.
...
> This is a fairly common scenario for SSM mapping, where the end device 
> (usually a set-top box) only supports IGMPv2.  Usually the LHR is 
> statically configured with a mapping for g1 = s1,g1, and that LHR sends a 
> join for s1,g1 upstream.  DNS is also used sometimes as part of this to 
> avoid some of the manual provisioning of the mapping in the router.
>
> Still not seeing where translation would be needed here.

OK, so imagine that I've got some externally sourced traffic that happens
to use the same g1, so (s2,g1) is my traffic, while (s1,g1) is the local
network's traffic, and LHR is configured to add s1 to (*,g1) joins, as
above.

Without MNAT, my app will try to join (s2,g1) from inside the CPE,
the join propagates through the CPE becoming a join of (*,g1) due to
IGMPv2, then at the LHR the configuration adds s1 due to the config
above, and the join propagates as (s1,g1) within the core, so my app
receives (s1,g1) traffic at layer 2 and discards it at the socket
layer for not being (s2,g1), so no payloads are processed by the app.

If instead MNAT operates in this scenario, my app would tell MNAT
about the subscription to (s2,g1) and ask it whether there is a NAT
mapping for this network.  The MNAT server now has the opportunity to
assign "(s3,g2) is the NAT for (s2,g1)", with g2 pulled from a pool
configured by the network (perhaps from 239 or 233, or perhaps from
a part of 232 that they're not using for their traffic).

Since my app is operating as an MNAT egress, it learns that (s3,g2)
is the mapping for (s2,g1) for this network over its connection to the
MNAT server, so my app now issues a join for (s3,g2) to the network,
which propagates to the ingress in the network.  (The LHR would likely
be configured to add s3 to the (*,g2) joins it sees, just like it's
configured to add s1 for (*,g1) joins.)

The ingress is likewise talking to the MNAT service, and thus also
learns that (s2,g1) traffic should be ingested and should be forwarded
in the network as (s3,g2).

Now (s3,g2) traffic is forwarded to my app, which (as an MNAT egress)
understands it to be traffic that was NATted from (s2,g1) and processes
the payloads as (s2,g1) traffic.

(s1,g1) joins from the network's TV service are unaffected, and the LHR
continues to receive those as (*,g1) joins that it turns to (s1,g1) due
to its config.

> | The scenario is:
> | - They've got an IPTV service running
> | - They're using static routing.  Each TV channel has its own group address.
> | - I come along and say "I've got some receivers in your network trying to
> |   subscribe to my (S,G)s, can you please set up to ingest for it"?
> | - They say "we're happy to set up some static channels and not run our own
> |   TV on them, and let you use those channels if you can put traffic on
> |   them.  But we're not going to deploy PIM for you".
>
> This is also a fairly common scenario for video distribution, usually over 
> an MPLS network that doesn't want to run PIM.  So P2MP MPLS LSPs are 
> provisioned and the multicast groups are statically routed down those 
> LSPs.
>
> Here again, I don't see where the translation is needed.

The translation is needed so that my (s2,g1) traffic can be transported
on those multicast groups.

Suppose network in this scenario decides they would like to ingest
external traffic.  They have allocated (g1-g100) for their TV services,
and now they add (g101-g200) and designate it for use with external
traffic, provisioning the static routing in the core exactly like they
did for (g1-100).

My app is deployed in their network, and would like to join (s2,g300),
which is my global (S,G) containing the traffic a user wants,
ingestable with DRIAD+AMT, having metadata in DORMS, CBACC, etc.

In order for (s2,g300) traffic to be carried in this network, it has
to be somehow put in a packet with a destination in (g101-g200). (And
something at the receive side has to know that traffic to g101
originally came from (s2,g300).)

MNAT is the mechanism I'm proposing that would place the (s2,g300)
traffic into (s3,g101) while it's inside this network, so it can
be delivered to my app.  Without some such mechanism, my app won't
be able to get the traffic delivered as multicast in this network.

HTH.

-Jake