Re: [MBONED] MNAT draft

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: "zhang.zheng@zte.com.cn" <zhang.zheng@zte.com.cn>
Date: Tuesday, November 10, 2020 at 1:44 AM
To: "jholland=40akamai.com@dmarc.ietf.org" <jholland=40akamai.com@dmarc.ietf.org>
Cc: "mboned@ietf.org" <mboned@ietf.org>
Subject: Re: [MBONED] MNAT draft

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
收件人：mboned@ietf.org;
日 期 ：2020年11月10日 01:42
主 题 ：[MBONED] MNAT draft
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

_______________________________________________
MBONED mailing list
MBONED@ietf.org
https://www.ietf.org/mailman/listinfo/mboned