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