Re: [MBONED] MNAT draft

["Holland, Jake" <[e-mail]>]

Hi Lenny,

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

On 11/11/20, 8:29 PM, "Leonard Giuliano" <[e-mail]> 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.

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.
</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?
</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"?
</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
| [e-mail]
| https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/mboned__;!!NEt6yMaO-gk!WWrhysPgI-3oi4ENEZG06n5mKR9GaBavMtFzqhprxgPbUsFr9BxIDx7LI6pWc6A$
|