Re: [MBONED] MNAT draft

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
| MBONED@ietf.org
| https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/mboned__;!!NEt6yMaO-gk!WWrhysPgI-3oi4ENEZG06n5mKR9GaBavMtFzqhprxgPbUsFr9BxIDx7LI6pWc6A$
| 