Re: [MBONED] MNAT draft

Thanks Jake, comments inline:

On Thu, 12 Nov 2020, Holland, Jake wrote:

| 
| 
| Hi Lenny,
| 
| Thanks for taking a look.  Responses inline with <jake></jake>
| 
| On 11/11/20, 8:29 PM, "Leonard Giuliano" <lenny@juniper.net> 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.

Well, keep in mind 7716, by definition, addresses the non-MVPN case.  It 
basically steals MVPN machinery to work in the non-VPN, GRT.  So the CPE 
(or AR in 7716-speak) shouldn't need any modification- as long as it can 
send PIM joins toward the PBRs, as usual, they should be fine.  GTM 
signalling only happens between PBRs (over the BGP-free core), and the ARs 
just follow normal PIM procedures.

| 
| 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.

I get the v4-v6 translation, but the rest of this is a bit foggy.  SSM 
mapping is fairly common for legacy devices that can't do IGMPv3.  But in 
order for a collision in SSM to happen, BOTH the source and group must be 
the same.  I'm struggling to see how that kind of overlap would happen, so 
I must not be understanding this scenario correctly.

Also, I am missing the part about the static stuff entirely.  I don't see 
a nexus between static multicast routing and the need for translation, so 
again, I'm misunderstanding this scenario.

| </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?

No, I guess the problem is that 2 of the 3 cases mentioned in 1.3 are 
foggy for me, and the one case I did have in mind was not there.

| </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"?

I would guess that static routing is pretty well-understood.  It's less 
common for mcast, but does happen.  As written, it sems to be referring to 
addressing, not 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
| | MBONED@ietf.org
| | https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/mboned__;!!NEt6yMaO-gk!WWrhysPgI-3oi4ENEZG06n5mKR9GaBavMtFzqhprxgPbUsFr9BxIDx7LI6pWc6A$
| |
| 
| 