Subject: [MBONED] MNAT draft

From: "Holland, Jake" <[email-masked]>
Date: Mon, 9 Nov 2020 17:28:01 +0000

Hi mboned,

I also wanted to draw to your attention a new draft I'll be
going over in the upcoming meeting.  It's about automating
multicast NAT to get global multicast traffic delivered in
spite of restrictions that may prevent the use of the global
addresses inside particular networks, for a few different
reasons:
https://tools.ietf.org/html/draft-jholland-mboned-mnat-00

This work came out of the feedback I got about stoppers for
ISPs to deploy delivery for externally sourced multicast
traffic to clients inside their networks. So I think it's a
suitable topic for mboned to consider as part of solving that
end-to-end delivery problem.

I touched on this (under the name GNATS) in IETF 108[1], but
now I've finally posted a draft with something closer to a
detailed explanation of how it might work.  It's still kinda
rough, but feedback is very welcome.

I took Lenny's suggestion to call it "Multicast NAT", but
this name perhaps conflicts with some existing features in
existing routers[2] that are only loosely related to what
this doc is describing.  Maybe I need to change it to
"Multicast NAT Service" or something, or maybe it needs a
different name altogether, not sure.

I'm not sure how firm this particular approach is.  I'm still
working on cobbling together a prototype and might encounter
a need for some significant changes or extensions to the
model, but I wanted to get a strawman version out there to kick
around and see if anybody has a problem with the approach I'm
proposing.

Assuming I don't find a fatal flaw in this approach before we
meet, I'd like the WG to consider adoption (or suggest a
better path forward), so please take a look at the draft if
you get a chance.

Thanks and regards,
Jake

[1] Page 7-9 of the slides from mboned 108:
https://www.ietf.org/proceedings/108/slides/slides-108-mboned-status-update-on-multicast-to-the-browser-00.pdf#page=7

[2] For example, Juniper and Cisco each have configuration docs
for multicast NAT:
https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipaddr_nat/configuration/xe-16/nat-xe-16-book/iadnat-multicast-dynamic.html
https://www.juniper.net/documentation/en_US/junos/topics/example/nat-multicast-traffic-configuring.html

---

From: <[email-masked]>
Date: Tue, 10 Nov 2020 17:44:08 +0800 (CST)

Hi Jake, 

thank you very much for bringing this draft.

I think this draft is very interesting and valuable for multicast deployment.

Several years ago, when we discussed the BIER deployment, we talked about the similar situation as you describing in this draft.

But we didn't know if there was actual deployment.

Now from your draft and your presentation in IETF108#, we know that there is actual deployment situation. This draft vefifies our assumption. Thank you again for it!

In terms of BIER deployment in this situation, fortunately when we need not do NAT in the ingress/egress router.

Ingress/egress router only needs to exchange the (S,G) info, let the ingress router know all the egress routers for one flow.

For other multicast technologies like PIM, the NAT is still needed.

If you want to know more about BIER application in this situation, we can talk about it. :-)

Thanks,

Sandy

原始邮件

发件人：Holland,Jake
收件人：[email-masked];
日 期 ：2020年11月10日 01:42
主 题 ：[MBONED] MNAT draft

Hi mboned,

Thanks and regards,
Jake

_______________________________________________
MBONED mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mboned

---

From: "Holland, Jake" <[email-masked]>
Date: Wed, 11 Nov 2020 05:05:43 +0000

Hi Sandy,

Thanks for taking a look, and I appreciate the feedback!

As a secondary goal, I’m hoping to define this service so that
other kinds of encapsulation mappings can also be supported in
addition to or instead of NAT, specifically including BIER (but also
perhaps some others as well, for instance SPRING, or a way to
specify particular layer 1 broadcast channels, like maybe ATSC).

I wanted to put those extensions off to separate drafts that extend
this one, if and when this gets further along.

I think I’d be looking for a co-author who’s done more BIER work
than myself for the BIER extension part, but I think after there’s a
prototype for this and before this goes to last call (if it gets that far),
it would be useful to try to put together a draft and a prototype that
adds BIER as an extension to this, to make sure it will work.

I assume that work, if it happens, would mostly be done in BIER,
and would only start if this one gets far enough along, but yes, that
would be very helpful to discuss at some point, thanks.

If you’ve got pointers to mail thread discussions that would be good
background reading, maybe you coul send those along?  But yes, I’d
love to talk about this if we move the mnat draft forward, I think BIER
seems like a use case where it would be nice if the same service could
do that job as well.

Thanks and regards,
Jake

From: "[email-masked]" <[email-masked]>
Date: Tuesday, November 10, 2020 at 1:44 AM
To: "jholland=[email-masked]" <jholland=[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [MBONED] MNAT draft

Hi Jake,

Thanks,

Sandy
原始邮件
发件人：Holland,Jake
收件人：[email-masked];
日 期 ：2020年11月10日 01:42
主 题 ：[MBONED] MNAT draft
Hi mboned,

Thanks and regards,
Jake

---

From: <[email-masked]>
Date: Wed, 11 Nov 2020 15:52:47 +0800 (CST)

Hi Jake, 

that's great you will consider BIER usecase. 

And you are right the P2MP policy can also be included into it (may be another draft?).

Sorry that there may be no mailing list thread about the early BIER discussion,  but if it's needed, more BIER people can be involved in to discuss it again.

About the prototype of the MNAT through BIER, it may not be a prototype, it's a router product implementation that has already be done.

But something new may be added for it, so I would like to do more study on MNAT draft. 

And further if you need help on BIER part or draft about this topic, I can do some help. :-)

Best regards,

Sandy

原始邮件

发件人：Holland,Jake
收件人：张征00007940;
抄送人：[email-masked];
日 期 ：2020年11月11日 13:07
主 题 ：Re: [MBONED] MNAT draft

Hi Sandy,

 

 

 

 

 

do that job as well.

Thanks and regards,

Jake

 

 

Hi Jake, 

Thanks,

Sandy

原始邮件

发件人：Holland,Jake

收件人：[email-masked];

日期：2020年11月10日
 01:42

主题：[MBONED] MNAT draft

Hi mboned,

Thanks and regards,
Jake

---

From: Leonard Giuliano <[email-masked]>
Date: Wed, 11 Nov 2020 20:29:44 -0800

Jake,

Thanks for posting this draft.  Some comments:

-Based on the discussion in MBONED in IETF 108, my understanding of the 
purpose of this translation is to handle the situation where routers 
within a domain (eg, BGP-free core) do not have routes to the source and 
thus RPF will fail.  Is that the case, or am I misunderstanding the 
motivation of this translation?  I found 1.3 to be pretty vague and it's 
not terribly clear to me from the doc what is the exact problem being 
solved here.

-If my assumption was correct, and this is trying to solve the issue of 
RPF failing bc intermediate routers lack source routes in the MRIB, there 
have been some other solutions proposed to solve this problem.  GTM 
(RFC7716) is one example, and I recall from long ago an "rpf-hint" was 
proposed, but I think that may have been abandoned in later versions of 
the Rosen MVPN draft.  Anyway, might be worth covering why these solutions 
fell short in solving the problem.

-I could find no mention of what is being translated, the source or the 
group?  Again, I would have assumed just the source, but this is never 
mentioned explicitly.  I can't think of a good reason for translating the 
group address, but maybe I'm missing something.  In any event, might be 
worth explaining whether it's the source or group or both being translated 
and why.

-Sect 1, 2nd para: "for the purpose of working around various 
addressing-related issues"
	-this is pretty vague; might be good to specify some examples of those issues

-Sect 2.1: given that directionality of mcast routing can be relative 
(control plane goes in one direction, traffic in the other), might be 
helpful to specify that the "ingress node" is the translating node closest 
to the source while "egress node" is the node closest to the receiver to 
make it absolutely clear.

-Sect 1.3, 3rd bullet: "...packet replication channels with static group addresses ..."
	-static groups or static routing?

-Sect 1.3, next sentence: "...use of static provisioning of multicast groups..."
	-same as above, static provisioning, or static routing?  Can you 
be more specific about what is static here?

-Sec 2.1, last sentence: yes, a diagram would be very helpful.  The slide 
referenced was very helpful.

-Sect 2.1.1, penultimate para: "Premesis" misspelled.

-Sect 2.4.3, last para: "addreessing" misspelled

-Lenny

On Mon, 9 Nov 2020, Holland, Jake wrote:

| 
| 
| Hi mboned,
| 
| I also wanted to draw to your attention a new draft I'll be
| going over in the upcoming meeting.  It's about automating
| multicast NAT to get global multicast traffic delivered in
| spite of restrictions that may prevent the use of the global
| addresses inside particular networks, for a few different
| reasons:
| https://urldefense.com/v3/__https://tools.ietf.org/html/draft-jholland-mboned-mnat-00__;!!NEt6yMaO-gk!WWrhysPgI-3oi4ENEZG06n5mKR9GaBavMtFzqhprxgPbUsFr9BxIDx7LOA1GhU4$
| 
| This work came out of the feedback I got about stoppers for
| ISPs to deploy delivery for externally sourced multicast
| traffic to clients inside their networks. So I think it's a
| suitable topic for mboned to consider as part of solving that
| end-to-end delivery problem.
| 
| I touched on this (under the name GNATS) in IETF 108[1], but
| now I've finally posted a draft with something closer to a
| detailed explanation of how it might work.  It's still kinda
| rough, but feedback is very welcome.
| 
| I took Lenny's suggestion to call it "Multicast NAT", but
| this name perhaps conflicts with some existing features in
| existing routers[2] that are only loosely related to what
| this doc is describing.  Maybe I need to change it to
| "Multicast NAT Service" or something, or maybe it needs a
| different name altogether, not sure.
| 
| I'm not sure how firm this particular approach is.  I'm still
| working on cobbling together a prototype and might encounter
| a need for some significant changes or extensions to the
| model, but I wanted to get a strawman version out there to kick
| around and see if anybody has a problem with the approach I'm
| proposing.
| 
| Assuming I don't find a fatal flaw in this approach before we
| meet, I'd like the WG to consider adoption (or suggest a
| better path forward), so please take a look at the draft if
| you get a chance.
| 
| Thanks and regards,
| Jake
| 
| [1] Page 7-9 of the slides from mboned 108:
| https://urldefense.com/v3/__https://www.ietf.org/proceedings/108/slides/slides-108-mboned-status-update-on-multicast-to-the-browser-00.pdf*page=7__;Iw!!NEt6yMaO-gk!WWrhysPgI-3oi4ENEZG06n5mKR9GaBavMtFzqhprxgPbUsFr9BxIDx7LNL6bFeI$
| 
| [2] For example, Juniper and Cisco each have configuration docs
| for multicast NAT:
| https://urldefense.com/v3/__https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipaddr_nat/configuration/xe-16/nat-xe-16-book/iadnat-multicast-dynamic.html__;!!NEt6yMaO-gk!WWrhysPgI-3oi4ENEZG06n5mKR9GaBavMtFzqhprxgPbUsFr9BxIDx7LiRw-85I$
| https://www.juniper.net/documentation/en_US/junos/topics/example/nat-multicast-traffic-configuring.html
| 
| 
| _______________________________________________
| MBONED mailing list
| [email-masked]
| https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/mboned__;!!NEt6yMaO-gk!WWrhysPgI-3oi4ENEZG06n5mKR9GaBavMtFzqhprxgPbUsFr9BxIDx7LI6pWc6A$
|

---

From: "Holland, Jake" <[email-masked]>
Date: Thu, 12 Nov 2020 08:55:56 +0000

Hi Lenny,

Thanks for taking a look.  Responses inline with <jake></jake>

On 11/11/20, 8:29 PM, "Leonard Giuliano" <[email-masked]> wrote:

Jake,

<jake>
It wasn't just one problem.

Several different networks raised several different issues, and I
noticed they all can be solved by giving the network the ability
to assign their own local addresses for transporting traffic from
global (S,G)s.

I think I actually forgot to include the case where RPF fails
because the route to the source doesn't go backwards through the
ingest point.  That was one of the scenarios as well and I should
have included it, thanks for reminding me.  But even with a
solution for RPF, the other use cases I listed were still stoppers
to deploying multicast for at least one network each, and can be
solved by using locally assigned addresses for a global (S,G)'s
traffic.
</jake>

<jake>
I think some networks might be able to use RFC 7716 instead of this,
yes.  I was planning to suggest it as an alternative for those where
it's appropriate.  In cases where the egress is an on-path device in
the network, it's probably basically equivalent, I think.

However, one concern raised was that the CPEs would have to act as a
CE in the MVPN because the restrictions come from their access devices,
but upgrading the CPEs is too hard.

One of the benefits of using an HTTPS-based approach is that the end
receiver app can directly discover and connect to the MNAT service, so
that the CPE doesn't have to change in order to get the reassignment.
Although this might not be technically impossible to do with a VPN
client library, I think it would be a much harder sell for including
in for instance a browser, since a BGP connection and a VPN can be a
lot more heavyweight than a more targeted API that's just about
address mappings.

I can put something to that effect in the motivation section along with
an informative reference to 7716 if you think that's helpful.
</jake>

<jake>
Both the source and the group are (potentially) translated.  And
sorry, I agree this part of the text is rough, and I hope to flesh
it out to a better explanation if this moves along.  The YANG model
does provide for both options though (though I should also mention
that's undergoing development as I'm hacking on a prototype...)

One of the key reasons for translating the group is to support
deployment models where they are just using static routing for fanout
and replication (I think either in 239 or 233), but are willing to
allow external traffic on some set of dedicated group addresses.

Another reason group addresses need reassigning is to avoid collisions.

One of the ways people are working around legacy IGMPv2 systems is by
using an ASM join to a 232 group from within the home, but then
translating it into an SSM join for the same group at the BNG with a
configured source so it can propagate as SSM within the network.

However, this fails when there's a collision on the 232 group for an
external source.  By allowing the network to reassign the group address
for the global (S,G), the network can avoid collisions with externally
sourced traffic, even though they're using 232. 

Also for IPv4<->IPv6 translations, of course.
</jake>

<jake>
Section 1.3 lists examples, and the next sentence after this one
provides a reference to it.

I thought it was clearer this way than trying to make the sentence
longer to include examples.  I'm open to suggestions on making this
clearer, but everything I tried here seemed worse until I landed on
"put examples in a different section and reference that".  Do you
have any suggestions of text that does this better?
</jake>

<jake>
I agree the terms "closest to the source" and "closest to the receiver"
are a very helpful clarification to include, probably both here and in
the definitions section, thanks.  I was thinking I'd also try to get a
diagram in here before long if this is to move forward, but I agree it's
important to be really clear on this point, and thanks for the suggestion.
</jake>

<jake>
I guess I probably mean static routing.  Now that you mention it though,
I'm not sure I know the difference, except that "static groups" might not
be defined.  I know everybody uses the term "static route", but I'm also
not sure where that's defined--do you think there's a good reference, or
that it's sufficiently well-understood if I just change it to "static
routing"?
</jake>

<jake>
Thanks, spelling errors fixed in my local copy.

And thanks very kindly for the review and all the thoughtful
comments!

-Jake
</jake>

-Lenny

| 
| 
| Hi mboned,
| 
| https://urldefense.com/v3/__https://www.juniper.net/documentation/en_US/junos/topics/example/nat-multicast-traffic-configuring.html__;!!GjvTz_vk!DFkAbwF3nscWJGh0s2Yt0bG7GakNAlHE_DUY6YLvJP03HbOLOh6xvttE_1rL0QA$

---

From: Leonard Giuliano <[email-masked]>
Date: Thu, 12 Nov 2020 15:28:16 -0800

Thanks Jake, comments inline:

On Thu, 12 Nov 2020, Holland, Jake wrote:

| 
| 
| Hi Lenny,
| 
| Thanks for taking a look.  Responses inline with <jake></jake>
| 
| On 11/11/20, 8:29 PM, "Leonard Giuliano" <[email-masked]> wrote:
| 
| Jake,
| 
| Thanks for posting this draft.  Some comments:
| 
| -Based on the discussion in MBONED in IETF 108, my understanding of the
| purpose of this translation is to handle the situation where routers
| within a domain (eg, BGP-free core) do not have routes to the source and
| thus RPF will fail.  Is that the case, or am I misunderstanding the
| motivation of this translation?  I found 1.3 to be pretty vague and it's
| not terribly clear to me from the doc what is the exact problem being
| solved here.
| 
| <jake>
| It wasn't just one problem.
| 
| Several different networks raised several different issues, and I
| noticed they all can be solved by giving the network the ability
| to assign their own local addresses for transporting traffic from
| global (S,G)s.
| 
| I think I actually forgot to include the case where RPF fails
| because the route to the source doesn't go backwards through the
| ingest point.  That was one of the scenarios as well and I should
| have included it, thanks for reminding me.  But even with a
| solution for RPF, the other use cases I listed were still stoppers
| to deploying multicast for at least one network each, and can be
| solved by using locally assigned addresses for a global (S,G)'s
| traffic.
| </jake>
| 
| -If my assumption was correct, and this is trying to solve the issue of
| RPF failing bc intermediate routers lack source routes in the MRIB, there
| have been some other solutions proposed to solve this problem.  GTM
| (RFC7716) is one example, and I recall from long ago an "rpf-hint" was
| proposed, but I think that may have been abandoned in later versions of
| the Rosen MVPN draft.  Anyway, might be worth covering why these solutions
| fell short in solving the problem.
| 
| <jake>
| I think some networks might be able to use RFC 7716 instead of this,
| yes.  I was planning to suggest it as an alternative for those where
| it's appropriate.  In cases where the egress is an on-path device in
| the network, it's probably basically equivalent, I think.
| 
| However, one concern raised was that the CPEs would have to act as a
| CE in the MVPN because the restrictions come from their access devices,
| but upgrading the CPEs is too hard.

Well, keep in mind 7716, by definition, addresses the non-MVPN case.  It 
basically steals MVPN machinery to work in the non-VPN, GRT.  So the CPE 
(or AR in 7716-speak) shouldn't need any modification- as long as it can 
send PIM joins toward the PBRs, as usual, they should be fine.  GTM 
signalling only happens between PBRs (over the BGP-free core), and the ARs 
just follow normal PIM procedures.

| 
| One of the benefits of using an HTTPS-based approach is that the end
| receiver app can directly discover and connect to the MNAT service, so
| that the CPE doesn't have to change in order to get the reassignment.
| Although this might not be technically impossible to do with a VPN
| client library, I think it would be a much harder sell for including
| in for instance a browser, since a BGP connection and a VPN can be a
| lot more heavyweight than a more targeted API that's just about
| address mappings.
| 
| I can put something to that effect in the motivation section along with
| an informative reference to 7716 if you think that's helpful.
| </jake>
| 
| -I could find no mention of what is being translated, the source or the
| group?  Again, I would have assumed just the source, but this is never
| mentioned explicitly.  I can't think of a good reason for translating the
| group address, but maybe I'm missing something.  In any event, might be
| worth explaining whether it's the source or group or both being translated
| and why.
| 
| <jake>
| Both the source and the group are (potentially) translated.  And
| sorry, I agree this part of the text is rough, and I hope to flesh
| it out to a better explanation if this moves along.  The YANG model
| does provide for both options though (though I should also mention
| that's undergoing development as I'm hacking on a prototype...)
| 
| One of the key reasons for translating the group is to support
| deployment models where they are just using static routing for fanout
| and replication (I think either in 239 or 233), but are willing to
| allow external traffic on some set of dedicated group addresses.
| 
| Another reason group addresses need reassigning is to avoid collisions.
| 
| One of the ways people are working around legacy IGMPv2 systems is by
| using an ASM join to a 232 group from within the home, but then
| translating it into an SSM join for the same group at the BNG with a
| configured source so it can propagate as SSM within the network.
| 
| However, this fails when there's a collision on the 232 group for an
| external source.  By allowing the network to reassign the group address
| for the global (S,G), the network can avoid collisions with externally
| sourced traffic, even though they're using 232.
| 
| Also for IPv4<->IPv6 translations, of course.

I get the v4-v6 translation, but the rest of this is a bit foggy.  SSM 
mapping is fairly common for legacy devices that can't do IGMPv3.  But in 
order for a collision in SSM to happen, BOTH the source and group must be 
the same.  I'm struggling to see how that kind of overlap would happen, so 
I must not be understanding this scenario correctly.

Also, I am missing the part about the static stuff entirely.  I don't see 
a nexus between static multicast routing and the need for translation, so 
again, I'm misunderstanding this scenario.

| </jake>
| 
| -Sect 1, 2nd para: "for the purpose of working around various
| addressing-related issues"
|         -this is pretty vague; might be good to specify some examples of those issues
| 
| <jake>
| Section 1.3 lists examples, and the next sentence after this one
| provides a reference to it.
| 
| I thought it was clearer this way than trying to make the sentence
| longer to include examples.  I'm open to suggestions on making this
| clearer, but everything I tried here seemed worse until I landed on
| "put examples in a different section and reference that".  Do you
| have any suggestions of text that does this better?

No, I guess the problem is that 2 of the 3 cases mentioned in 1.3 are 
foggy for me, and the one case I did have in mind was not there.

| </jake>
| 
| -Sect 2.1: given that directionality of mcast routing can be relative
| (control plane goes in one direction, traffic in the other), might be
| helpful to specify that the "ingress node" is the translating node closest
| to the source while "egress node" is the node closest to the receiver to
| make it absolutely clear.
| 
| <jake>
| I agree the terms "closest to the source" and "closest to the receiver"
| are a very helpful clarification to include, probably both here and in
| the definitions section, thanks.  I was thinking I'd also try to get a
| diagram in here before long if this is to move forward, but I agree it's
| important to be really clear on this point, and thanks for the suggestion.
| </jake>
| 
| -Sect 1.3, 3rd bullet: "...packet replication channels with static group addresses ..."
|         -static groups or static routing?
| 
| <jake>
| I guess I probably mean static routing.  Now that you mention it though,
| I'm not sure I know the difference, except that "static groups" might not
| be defined.  I know everybody uses the term "static route", but I'm also
| not sure where that's defined--do you think there's a good reference, or
| that it's sufficiently well-understood if I just change it to "static
| routing"?

I would guess that static routing is pretty well-understood.  It's less 
common for mcast, but does happen.  As written, it sems to be referring to 
addressing, not routing.

| </jake>
| 
| -Sect 1.3, next sentence: "...use of static provisioning of multicast groups..."
|         -same as above, static provisioning, or static routing?  Can you
| be more specific about what is static here?
| 
| -Sec 2.1, last sentence: yes, a diagram would be very helpful.  The slide
| referenced was very helpful.
| 
| -Sect 2.1.1, penultimate para: "Premesis" misspelled.
| 
| -Sect 2.4.3, last para: "addreessing" misspelled
| 
| <jake>
| Thanks, spelling errors fixed in my local copy.
| 
| And thanks very kindly for the review and all the thoughtful
| comments!
| 
| -Jake
| </jake>
| 
| 
| -Lenny
| 
| On Mon, 9 Nov 2020, Holland, Jake wrote:
| 
| |
| |
| | Hi mboned,
| |
| | I also wanted to draw to your attention a new draft I'll be
| | going over in the upcoming meeting.  It's about automating
| | multicast NAT to get global multicast traffic delivered in
| | spite of restrictions that may prevent the use of the global
| | addresses inside particular networks, for a few different
| | reasons:
| | https://urldefense.com/v3/__https://tools.ietf.org/html/draft-jholland-mboned-mnat-00__;!!NEt6yMaO-gk!WWrhysPgI-3oi4ENEZG06n5mKR9GaBavMtFzqhprxgPbUsFr9BxIDx7LOA1GhU4$
| |
| | This work came out of the feedback I got about stoppers for
| | ISPs to deploy delivery for externally sourced multicast
| | traffic to clients inside their networks. So I think it's a
| | suitable topic for mboned to consider as part of solving that
| | end-to-end delivery problem.
| |
| | I touched on this (under the name GNATS) in IETF 108[1], but
| | now I've finally posted a draft with something closer to a
| | detailed explanation of how it might work.  It's still kinda
| | rough, but feedback is very welcome.
| |
| | I took Lenny's suggestion to call it "Multicast NAT", but
| | this name perhaps conflicts with some existing features in
| | existing routers[2] that are only loosely related to what
| | this doc is describing.  Maybe I need to change it to
| | "Multicast NAT Service" or something, or maybe it needs a
| | different name altogether, not sure.
| |
| | I'm not sure how firm this particular approach is.  I'm still
| | working on cobbling together a prototype and might encounter
| | a need for some significant changes or extensions to the
| | model, but I wanted to get a strawman version out there to kick
| | around and see if anybody has a problem with the approach I'm
| | proposing.
| |
| | Assuming I don't find a fatal flaw in this approach before we
| | meet, I'd like the WG to consider adoption (or suggest a
| | better path forward), so please take a look at the draft if
| | you get a chance.
| |
| | Thanks and regards,
| | Jake
| |
| | [1] Page 7-9 of the slides from mboned 108:
| | https://urldefense.com/v3/__https://www.ietf.org/proceedings/108/slides/slides-108-mboned-status-update-on-multicast-to-the-browser-00.pdf*page=7__;Iw!!NEt6yMaO-gk!WWrhysPgI-3oi4ENEZG06n5mKR9GaBavMtFzqhprxgPbUsFr9BxIDx7LNL6bFeI$
| |
| | [2] For example, Juniper and Cisco each have configuration docs
| | for multicast NAT:
| | https://urldefense.com/v3/__https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipaddr_nat/configuration/xe-16/nat-xe-16-book/iadnat-multicast-dynamic.html__;!!NEt6yMaO-gk!WWrhysPgI-3oi4ENEZG06n5mKR9GaBavMtFzqhprxgPbUsFr9BxIDx7LiRw-85I$
| | https://urldefense.com/v3/__https://www.juniper.net/documentation/en_US/junos/topics/example/nat-multicast-traffic-configuring.html__;!!GjvTz_vk!DFkAbwF3nscWJGh0s2Yt0bG7GakNAlHE_DUY6YLvJP03HbOLOh6xvttE_1rL0QA$
| |
| |
| | _______________________________________________
| | MBONED mailing list
| | [email-masked]
| | https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/mboned__;!!NEt6yMaO-gk!WWrhysPgI-3oi4ENEZG06n5mKR9GaBavMtFzqhprxgPbUsFr9BxIDx7LI6pWc6A$
| |
| 
|

---

From: "Holland, Jake" <[email-masked]>
Date: Fri, 13 Nov 2020 13:18:31 +0000

Hi Lenny,

> just follow normal PIM procedures.

(NB: at the CPE they generally use IGMP proxying, not PIM, but I think
that's irrelevant according to 7716 if I'm reading it right.)

I've tried to read thru these specs but I confess there's a lot I'm
not completely following, never having actually set one up, so maybe I'm
missing something.  I'd be open to trying to figure it out with a more
step-by-step how-to, if you've got one.

But I think there's a fundamental problem.  I'll try to describe why.

Consider:
- The receiving app knows it wants SSM traffic from a global (S,G) and
  can do the SSM join.
- The CPE is the Last Hop Router for the receiving app.  It's using IGMP
  proxying (it supports v3, but I think it doesn't much matter)
- The next hop router from the CPE is connected over a CMTS.  It does
  IGMP snooping and understands IGMPv2.  It can do multicast, but it
  can't do SSM.

I can't get them to upgrade their CPE or their CMTS.  But they're using
these already with multicast, and they're willing to carry my traffic,
they just need a viable way to do it.

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.

However, the restrictions coming from IGMPv2 are on the CMTS.  If we're
going to do a translation step so that the CMTS is part of the "provider"
network of the MVPN so it can use addresses that work around the CMTS's
ASM restrictions while still transporting the global (S,G) traffic for
the "customer" network of the MVPN to the end receiver, the PBR would
have to be south of the CMTS (so that the CMTS can be part of the "core")
which requires an upgrade to the CPE.

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.

> I must not be understanding this scenario correctly.

A key representative scenario was:
- There's an IPTV app that only uses ASM, and an access device that uses
  only IGMPv2.
- They want to use SSM in the core.
- So they put the groups in 232.  The App does an ASM join to 232.x.x.x,
  and then the last-hop router adds a source to the join (without changing
  the group) before it propagates upstream.
- 232.x.x.x as an ASM group can of course conflict with my external traffic
  if there's a collision just on the group, because the LHR only has the
  group to work with from IGMPv2, and assigns the source regardless of
  whether the app intended to join a different (S,G).

> again, I'm misunderstanding this scenario.

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 scenario was more on my mind than any of the others for the MNAT
design, I hadn't heard it before.

I would guess this can also be solved with MVPN, but it seems to add a
lot of complexity to add BGP into this setup, and complexity was the
reason they weren't using PIM in the first place.

By contrast, an HTTP API that allows the network to advertise a local
mapping allows the complexity to be handled by the receiver app instead,
if the network doesn't want to deploy egress nodes.  (If the network does
want to deploy its own egress nodes, I think the complexity is probably
pretty close to the MVPN case.)

Does that all make sense?  If that helps clears things up, I guess I
need to get a better explanation of these points into the draft.

- Jake

---

From: Leonard Giuliano <[email-masked]>
Date: Fri, 13 Nov 2020 13:09:52 -0800

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:

On Fri, 13 Nov 2020, Holland, Jake wrote:

| 
| Hi Lenny,
| 
| On 11/12/20, 3:27 PM, "Leonard Giuliano" <[email-masked]> wrote:
| > On Thu, 12 Nov 2020, Holland, Jake wrote:
| > | However, one concern raised was that the CPEs would have to act as a
| > | CE in the MVPN because the restrictions come from their access devices,
| > | but upgrading the CPEs is too hard.
| >
| > Well, keep in mind 7716, by definition, addresses the non-MVPN case.  It
| > basically steals MVPN machinery to work in the non-VPN, GRT.  So the CPE
| > (or AR in 7716-speak) shouldn't need any modification- as long as it can
| > send PIM joins toward the PBRs, as usual, they should be fine.  GTM
| > signalling only happens between PBRs (over the BGP-free core), and the ARs
| > just follow normal PIM procedures.
| 
| (NB: at the CPE they generally use IGMP proxying, not PIM, but I think
| that's irrelevant according to 7716 if I'm reading it right.)
| 
| I've tried to read thru these specs but I confess there's a lot I'm
| not completely following, never having actually set one up, so maybe I'm
| missing something.  I'd be open to trying to figure it out with a more
| step-by-step how-to, if you've got one.
| 
| But I think there's a fundamental problem.  I'll try to describe why.
| 
| Consider:
| - The receiving app knows it wants SSM traffic from a global (S,G) and
|   can do the SSM join.
| - The CPE is the Last Hop Router for the receiving app.  It's using IGMP
|   proxying (it supports v3, but I think it doesn't much matter)
| - The next hop router from the CPE is connected over a CMTS.  It does
|   IGMP snooping and understands IGMPv2.  It can do multicast, but it
|   can't do SSM.
| 
| I can't get them to upgrade their CPE or their CMTS.  But they're using
| these already with multicast, and they're willing to carry my traffic,
| they just need a viable way to do it.
| 
| 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.

| 
| However, the restrictions coming from IGMPv2 are on the CMTS.  If we're
| going to do a translation step so that the CMTS is part of the "provider"
| network of the MVPN so it can use addresses that work around the CMTS's
| ASM restrictions while still transporting the global (S,G) traffic for
| the "customer" network of the MVPN to the end receiver, the PBR would
| have to be south of the CMTS (so that the CMTS can be part of the "core")
| which requires an upgrade to the CPE.
| 
| 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

MPLS_IR1 is an ingress/egress MPLS LSR, MPLS_TR1 is an MPLS transit LSR, 
MPLS_IR2 is an ingress/egress MPLS LSR.  All other ARs (and CMTS and CPE) 
are plain-old PIM/IGMP Internet routers.  GTM solves the problem that 
MPLS_TR1 is a BGP-free router and thus has no route to the source in it's 
MRIB.  So if a PIM join came it's way, RPF would fail.  So MPLS_IR1 and 
MPLS_IR2 become PBRs and MPLS_IR1 takes the PIM join (or IGMP report) 
coming from AR1, turns it into a BGP-join and sends that join to MPLS_IR2.  
MPLS_IR2 then turns the BGP-join back into a PIM join and forwards it 
towards the source (to AR2).  MPLS_IR2 can then forward the mcast stream 
over an MPLS LSP to MPLS_IR1 (and thus through MPLS_TR1), which then 
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.

| 
| > | Also for IPv4<->IPv6 translations, of course.
| >
| > I get the v4-v6 translation, but the rest of this is a bit foggy.  SSM
| > mapping is fairly common for legacy devices that can't do IGMPv3.  But in
| > order for a collision in SSM to happen, BOTH the source and group must be
| > the same.  I'm struggling to see how that kind of overlap would happen, so
| > I must not be understanding this scenario correctly.
| 
| A key representative scenario was:
| - There's an IPTV app that only uses ASM, and an access device that uses
|   only IGMPv2.
| - They want to use SSM in the core.
| - So they put the groups in 232.  The App does an ASM join to 232.x.x.x,
|   and then the last-hop router adds a source to the join (without changing
|   the group) before it propagates upstream.
| - 232.x.x.x as an ASM group can of course conflict with my external traffic
|   if there's a collision just on the group, because the LHR only has the
|   group to work with from IGMPv2, and assigns the source regardless of
|   whether the app intended to join a different (S,G).

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.

| 
| > Also, I am missing the part about the static stuff entirely.  I don't see
| > a nexus between static multicast routing and the need for translation, so
| > again, I'm misunderstanding this scenario.
| 
| 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.

| This scenario was more on my mind than any of the others for the MNAT
| design, I hadn't heard it before.
| 
| I would guess this can also be solved with MVPN, but it seems to add a
| lot of complexity to add BGP into this setup, and complexity was the
| reason they weren't using PIM in the first place.

MVPN and GTM can add dynamic mcast routing capabilities, but indeed at a 
cost of complexity, over static multicast routing.  Similar to dynamic vs 
static routing in unicast.  But again, I'm missing where translation fits 
here.

| 
| By contrast, an HTTP API that allows the network to advertise a local
| mapping allows the complexity to be handled by the receiver app instead,
| if the network doesn't want to deploy egress nodes.  (If the network does
| want to deploy its own egress nodes, I think the complexity is probably
| pretty close to the MVPN case.)

I'm still missing how the receiver app is handling the complexity.  The 
multicast packets still need to be forwarded through the network by the 
routers.  

| Does that all make sense?  If that helps clears things up, I guess I
| need to get a better explanation of these points into the draft.
| 
| - Jake
| 
| 
|

---

From: "Holland, Jake" <[email-masked]>
Date: Sat, 14 Nov 2020 03:26:38 +0000

Hi Lenny,

> Let me know if this is correct.  See comments inline:

Yes, exactly.

> them to the non-VPN Global Table case.

Cool, thanks for the explanation.

> CPE--CMTS---AR1---MPLS_IR1---MPLS_TR1---MPLS_IR2---AR2---AR3---Src
...
> 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.

> | - There's an IPTV app that only uses ASM, and an access device that uses
...
> 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.

> 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

---

From: Leonard Giuliano <[email-masked]>
Date: Tue, 17 Nov 2020 09:45:53 -0800

Jake- thanks for the clarifications, I now understand the motivations and 
how MNAT can solve these use cases.

On Sat, 14 Nov 2020, Holland, Jake wrote:

| 
| 
| Hi Lenny,
| 
| On 11/13/20, 1:09 PM, "Leonard Giuliano" <[email-masked]> 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
| 
| 
|