Re: [MBONED] MNAT draft

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;
抄送人：mboned@ietf.org;
日 期 ：2020年11月11日 13:07
主 题 ：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