Tutorial: Deploying Interdomain IP Multicast

Tutorial: Deploying Interdomain IP Multicast



so just introduce myself my name is Mike McBride I work in a multicast development group and I'm on the deployment team within that group I spend the majority of my time working with providers in the inner domain space as they have deployed multicast so today that's what will be discussed is deploying multicast across the internet between domains and I was both here we go the agenda that will we'll go through is will first talk about the protocols that are used today to make multicast work and that is multi-protocol BGP and M SDP those are the two primary protocols that are what is being used today and what is going to be used in the foreseeable future I'll share a variety examples of deployment scenarios of how this works including how we're getting multicast to work here at Nanog out to the out to the world and then towards the latter part of the presentation we'll be presenting the the newer concepts of source-specific multicast multicast VPNs and even more recently multicast in the ipv6 world so we have a lot to cover in an hour and a half I'm going to be due diligence and getting through it all I may have to click through a few slides rapidly to reach that goal but I think we can do it if there's any questions feel free to tal them out we won't be able to spend a whole lot of time getting into them but we can discuss them as each section ends or feel free to send me an email it's McBride at Cisco comm or I'll be hanging around afterwards feel free to to discuss anything you may have question about alright says since this is not an intro to multicast presentation I just wanted to give a brief overview of the piece that we will be discussing today we're not going to get into exactly how PIM sparse mode works I'm assuming that hopefully you already understand that concept which isn't critical in understanding what I'll be presenting today but it does help so the Campus side the enterprise side there are protocols of course there's hosts that desire to receive certain multicast streams I know popular one it with the guys that I work with is you know the fashion TV streaming you get to see all the models cruising around on the on the catwalk so your host needs to find out which group this is so they're going to send an i jean-pierre report once they know which group it is that they want to join and the IGP report will be intercepted by a router and that router will subsequently be able to afford that request out throughout the internet drop the network of course they're typically switches and switches have been optimized with a variety of protocols to make it so they want to simply flood the multicast packets like they would with broadcast packets so there are protocols out there that we won't be discussing today but you can use to make it more optimized to have them sent out the multicast packets sent out to certain ports and then there's multicast routing protocols the protocols that actually do the forwarding of the multicast traffic there's sparse mode there's source-specific mode there's bi-directional Pam and the what we will be discussing today is multicast VPNs and then we get into where we'll be spending the majority of our time today and that is on the inner main side the protocols such as multi-protocol bgp which makes it possible that we can control a multicast traffic between domains and what the kiss source discovery protocol which allows us to discover which sources exist so that we can join them and source-specific multicast which I'll go into these some more detail as well throughout this presentation I've been asked to try to keep this as vendor-neutral as as possible so I've taken out a lot of the configuration examples that were specific to one vendor and so everything that I am so I've I think I've done a pretty good job of making it everything that I'll be presenting today is is true across across vendors there are some slides where I I wasn't able to remove certain configurations specific just because it I needed to have that to explain some details so multi-protocol BGP sometimes people refer to this as multicast BGP and since that's the what we're going to be discussing today that's really what really what it applies to you for our discussions multi-protocol BGP makes it possible for us now to have a variety of prefixes advertised we can include it in an update now we can have V for unicast s– we can have V for multicast we can also now have v4 v6 unicast a v6 multicast updates as well as you can tag information you can have a variety of updates within multi-protocol BGP however you still need to have PIM to do the actual forwarding of the multicast packets and the neat thing about multi-protocol bgp which we'll be going into a fair amount of detail is that you can use the same rules for BGP as you can with multi-protocol BGP can have the same policies and sing of my preferences so with multi-protocol bgp now we can have separate tables we can have a BGP table use for our unicode unicast prefixes to use for the regular unicast forwarding and we can have a multicast BGP table because we're receiving multicast prefixes now within these updates and so we can maintain a separate table multicast BGP table that can be used for our controlling our multicast traffic do you have to have an BGP to make multicast work across the internet the answer is no you don't you can simply use the unicast the regular BGP protocol to do your RPF checking throughout the Internet but for those of us that want to control our multicast traffic to either have it go a certain path or to sign certain policies to a multicast traffic you do need to have multicast bgp just a very quick reminder of how multicast reverse path forwarding check works because it is key to understand this is that if let's say that I'm a router and my arms and my head are interface it's tough I get a multicast packet in on my left arm before I forward it out my other interfaces I'm going to do a reverse path forwarding check and I'm gonna look in my even my multicast BGP table if I have it or I'll look in my unicast table and I'll look at the source of that multicast packet I'll and I'll decide if that left arm that that multicast packet came in on if it's the same interface that I would use to get to that source then I'll go and accept that packet and send it out the other interfaces but if the multicast packet comes in through my head but the unicast routing table is saying to go out my left arm to get to that packet then though the packet will RPF check fell that's a good thing it prevents loops so all this that we'll be discussing with multicast bgp cable this makes it so you can control your traffic in ways that you want it to be controlled the way this works of the multi-protocol BGP is that we have address families now we have address family one AFI one for ipv4 and address family two for ipv6 and within each of these address families we have sub address families so if I receive an update and if it's an AFI one with a sub a of five one that's an ipv4 packet and it's only used for unicast so it's going to go into my unicast table for unicast forwarding if I receive a packet with say bail Phi two I'll put that in my multicast BGP table so I can use that for RPF checking and sub a if I three is used for both will go into both tables now all vendors have their way to be able to prefer the packets as they come in for reverse path forwarding with multicast we have static routes static em rail it's just like with with unit so that we can force the youth RPF check to go out a particular way and that would have a default distance of 1 but with this multicast BGP table we can now have that as a preference and the way that that works is if I have a if I receive a multicast BGP update as well as a unicast BGP update if they both have the same distance the MB gpupdate will be preferred and that will be used for our RPF checks so that's again the way that we can control our traffic by default we'll do a distance comparison between the tables with our implementation you have to configure another keyword longest match to make it if you wanted to have a more unicast like for a longest match prefix you can configure it to do to do that there are some scenarios or you may want to have always use the longest match to be your RPF check if you're sure that that's going to be something that will be able to handle multicast so there's a capability negotiation that occurs between between routers just as you know there there should be so if both routers are trying to establish a connection with one another with BGP if they're both specifying that yes I can understand both unicast and multicast updates I'm multi-protocol BGP aware then the capability negotiation occurs between these routers and the sessions brought up it's established looking at this a little bit more closely if I receive an update from a BGP peer if it comes in with an address family of one which is for v4 with a sub a fi of one which is for unicast and go ahead and put that into my unicast BGP table now if I receive another update with a sub B fi of two I'll go and put that in my multicast BGP table for my again my RPF checking and if I receive one with a sub a v 3 then we'll go into and do both so we wonder why would you even bother having you know running multicast BGP in a environment where there's a concurrent topology like your your unicast and multicast traffic is going along the same wing well one reason would be that you may want to assign different policies to your multicast traffic and you would subsequently want to advertise those updates to the rest of the world with those with those policies so that would be one reason apply the more obvious reason that you would want to run in multicast bgp is when you would want to have your unicast traffic on one link and your multicast traffic on another link and so on one link you can just specify this will be just unicast only and on your other link you can specify that it'll just be multicast only sub AFI two so multi-protocol bgp multicast bgp now it solves part of the inner domain problem you can now control your traffic sign policies to it just like you can with BGP but we still need to have PIM to do the actual forwarding and b2b again just allows us to control that traffic so that leads us to the next piece of the puzzle that is M SDP which is required so that we can discover sources out there M HDPE is an amazing beast it was meant to be a temporary solution until something else came out that would take takeover originally it was thought that BGM P would be the protocol that would would take over to be used as a long-term solution I'm not sure where BGM P is today I don't maybe some of you you know it seems like it's kind of died in the ITF but what's happened subsequently is the Emmis the different vendors have optimized MSBP to make it more scalable and to make it better or I'll talk about the amazing spec but spec 20 was published this week for M SDP I don't know if that's a record or not but it's been just hideous with trying to have agreement and all different rules and you know what it's just an amazing process but MSTP isn't going to be going away definitely not for a v4 we'll get into what will happen with v6 toward the end of this presentation but it's being used today it's being used well if you're if you regulate nit f you'll find a lot of MSD P bashing but it's being used in production and most people like it it's just hard to understand and that's why we're gonna go into some detail so let's say that we have which is the case we have a variety of different domains and they're all doing their own multicast they're all enjoying receiving it they all have their own rendezvous points but the problem is they don't know sources that exist or throughout the internet like you know just different you know Microsoft and HP they got their own sources and other people want to be able to view those if you're not within their internet how you gonna give you that well that's where MSTP comes into play let's say that in domain II you have a receiver that's wanting to join a particular group it wants to receive fashion te so it's tend to join to that domain ease rata good point in domain a is where the actual sources for this stream it starts sending out the packets and it registers to the right of a point in domain a as soon as a register is received by that rendezvous point in domain a it if it's configured for MSTP peering with all these other audio points it will send an MSD PSA update a source active update just letting everybody know in a small packet that this is the source and this is the group if you ever have a receiver that's interested in this you know how to get to me and I'll will will start forwarding it throughout the internet that router in domain a is the region or originating RP that's important concept to understand because that's what we do our PF check against with regular multicast packets as they come in we do the RPF check based upon the source with MSD P it's a separate RPF check it's called an MSD P P R RPF check and we do it on the originating R P so that's what domain a is our P is so the essays are flooded throughout the internet there's a variety of rules that have been hard for people to grasp to make it so that these packets don't just get flooded endlessly since these packets do have a infinite TTL limit so they would endlessly loop if there wasn't this complex rule so the essays do eventually get to domain II it does have a receiver it's interested in getting that traffic so it sends a join if it's running multi-protocol beach appeals from the joints throughout the internet that way and the way that sparse mode works is you cut over to the shortest path tree of the main e and the receiver is able to happily see the fashion TV models walking along the catwalk so that is s a forwarding for M SDP again it does contain your not only the source and the group but it also contains the originating RP address it will also carry the first multicast packet which is a hack primarily for SDR I won't go into the details of that but it just makes it possible so that SDR can it's it's bursty so that's that's required so here we go for the next ten fifteen minutes or so I'm going to talk about some rules with MSD P and this has been difficult it's it's I think I've all presented in a way they'll be fairly clear I hope it's cause for a lot of confusion with for people in trying to implement a misty P wondering why the packets are getting dropped but there's really just a few rules here that I think I'll make pretty clear with the variety of illustrations to help you understand how M SDP works within your domain whether it's just within your own enterprise or as a service provider the certain thing you need to do to make M SDP successful so there are primarily three rules it's really two rules and I'll explain why that is but sometimes you have an MST P P R within your own domain sometimes you have an MS DP P R outside of your domain and sometimes you have an MST P period without being a BGP pair at all what was decided originally with M SDP is that we were going to have our RPF checking based upon bgp it's already out there in the internet and so we'll use BGP as the next hops and the advertisers of the next tops as our underlying RPF mechanism so it's very reliant upon BGP there are a few exceptions however and we'll go into detail on these but when you're appearing directly with the originating RP there's not a chance for a loop so you'll just skip the RPF check altogether there if your MSD PP r is a mesh group here we'll also skip the RPF check and if your MSD PP r is your only MSD PP r there's no chance for a loop so you'll also skip the RPF check so let's get into rule 1 on how this works your MSD PP r is within your domain it's a internal BGP peer the rule with this is and this is the most strict case within your domain and there's ways again to skip around this but within your own domain you ask the router check to see if your MSD PP or address equals the BGP PR address if yes the RPF check succeed if not it will fail let's look at this in detail and I think I'll that make this clear so router G in a s5 is the originating R P it has a source it's registered to it it's a router G's address 172 16 6.1 is the reasoning RP and it's going to go ahead and for it out at the MSD psas to the other RP is that it's appearing with in this case a s7 it gets flooded down into a s 100 and that's where our focus is now is a s 100 router a specifically so router a receives an MST MST PDSA update coming from router II so it has the choice now am I going to accept this or am I not and we're going to fill on this to prevent a loop so what router a does is okay okay my bgp peer dress is 170 216 3.1 I received the MSD PPR dress I received a mess DPS a update from a peer address of 170 216 3.1 they match they're the same so I will RPF check succeed it's pretty basic it's kind of anal but it's pre its that it works which we made sure that it was it has to be the exact address with when it's within your domain now robbery down in s 100 wool as it should forward off that sa also to router diem out our D before gone to router a router a will get this si from two different MSTP peers so the same decision algorithm occurs in this case the MSTP peer address 1 33 16 4.1 which is router D is different than the actual BGP pure address that I would use to get back to the originating RP c router a in its BGP table it says ok what's the best path to get back to the originating RP originating RP is router G up there in a s 5 so the best path is saying to do that would be to go to 172 16 3.1 which is router AE so they don't match our PF check fails and the packet is dropped as it should be that's a good thing continuing on with rule 1 a common mistake and we've a question back that's exactly right so the question was is is the RPF check done based upon the the next top it's actually and i'm going to get into some newer rules towards the end but it's actually the advertiser of the next top in bgp back towards the originating RP so it's all based upon we don't care about the actual source in the nest API RPF check it's the originating RPE exactly right that's a very good address that's a very good question and we're gonna address that right now because you are mystique peering it could be on the loopback it could be on the directly connected and you know which one you're gonna use same with bgp well that's a common mistake and that was a great segue thank you is that when a update in this case we have our BGP pure dresses 172 16 3.1 let's say it's a loopback address it's not the next hop okay that's that's fine Miami's TPP our address is 152 1621 maybe that's another or loopback or some other interface on the same router they're not the same address so we're gonna RPF check well it's extremely rigid on the in your in the inner domain side even though their addresses are on the same box they're not using the same address so that will RPF check fill so a common problem is if you're using a route reflector route reflectors become the advertiser of the next hop they don't become the next hop but they become the advertiser the next stop so what happens here well same problem is what I mentioned before we've you know this is a common problem when you're deploying multicast in your domain is when you're using route reflectors in this case the BGP pure dress is the route reflective 172 16 1.1 your MST pure addresses router over there they don't match so we're gonna rqf check fail so what do you do about that there's a couple things and we're gonna get you to med scripts but you can put it into a mesh group let's as I mentioned earlier we'll make it so that you'll skip the RPF check you can peer to the route reflector some people balk at that they don't have to be appearing always with the rail reflector but that's one way to get around it but it's just important that within your domain that you use the same members DP pure address as you would for your BGP peer address and it's a common mistake and it's you know it's just time to be aware of so now we're getting to another all this is really the only other rule you really need to remember within your domain you've got up here with the same BGP address the second rule is when your MSD peep here is an external address it's outside of your domain how do we do this RPF check back towards originated RP what we do is we look instead of the next instead of the advertiser of the next top back towards an AARP now we're looking at the next AAS in the best path back towards originating RP so it's not quite as rigid you don't have to be so concerned about using the same ip address it just has to be the next day s and the best path back towards resuming RP let's look at some examples to illustrate this to make it clearer okay so same scenario router G is the originating RP either PEC the SA is flooded throughout the internet it gets down to router a and a s 100 that's what we're gonna be concerning ourselves with I need to make a decision as the SA comes in from router e the decision is okay I received the SA from 172 16 3.1 I know that address is in a s 3 so for me to be able to accept this packet my as3 better be the same the next day yes and the best path back towards original RP if it is all accepted in this case they are the same and RPF check succeed let's see what happens when it comes away the other way around yes three will flood that sa over day s 1 and s 1 will flood that packet down to a s 100 decision process needs to take place first day s and the best path back towards visioning RP is still a s 3 that's the preferred route whether you have it in em bgp or bgp whatever whatever you're using but the a s of the MSTP peers and asks one they don't match so the RPF check will fail so this is our way to make it so that our PMS DP essays will not endlessly loop those are really the two rules need to to understand just kind of a slide to kind of see what happens yes in back that's right that's that's correct so the question is is you know this is based upon a s path you know what the best a s path is back towards visioning RP and that typically if not always we need to be in software and that would be true so looking at this a little bit further is when you're using your border routers for your honesty peering you very quickly within your own domain a s100 have to very quickly get back to these very rigid internal MSD be peering rules of having to use the same IP address because router a in this case becomes the announcer of the next table so everybody's got a peer towards that address but if he peered further into your network like if router e here instead of pairing with router a was instead peering with router B then you would be able to skip all that having to appear with all the exact IP addresses and I'll illustrate that a little bit more further cuz that's not commonly done okay even though this next rule is listed as rule three it really it's basically just an off take of rule two and that is when your MSTP pair does not equal your BGP peer it's the same exact scenario where you have to just find the next day s and the best path back towards originating RP and just hang on what hang on with me for like another five minutes we're almost out of this tedious RPF check e but it's just kind of important to understand if you understand this you're probably the only 30 or so people on the planet to understand it and you make yourselves extremely valuable to people you work with and this time of day that's kind of important unfortunately so let's look at that rule router a gets a si from route or e it's not n bgp appearing with router e it's appearing with router B so it's a very reliant upon BGP so you know how's this going to work what's the same way router aides table will just show that router E is the in as3 which is the best path back towards originating RP and the S of the MST PP r is an s3 so we're going to RPF check succeed and when it comes around the other way we will RPF check fail for the same reason as in the rule to just happens that we don't have a direct MPG peering with them so the nice thing about this and this is what's commonly used in service providers today is they have a group of rendezvous points within the core of the network they're running any cast of RP and all you discussed that in detail and a few slides and those routers are the routers that are appearing with all the customers instead of using all the border routers to MSTP peer with all their customers that just uses subset of routers you know 10 or so or 10 or under are peas that are MSTP peering and the nice thing about that is since those are external MSTP pairings we're just using the the next day s and the best path back towards originating our P rule we don't have to be so concerned about the actual IP address as with internal MSD be peering and router he and router F would be in a mess group so it would be skipping the RPF check all together and you'll understand that if you don't already get more detail but that's this is a typical deployment scenario and as our PF check works the same as a previously previously discussed alright so mesh groups mesh groups were created to cut down on SA flooding and this is the intra-domain solutions a lot of providers use this as well as enterprises if you have a lot of MST preparing going on they are flooding the essays to one another eventually it will stop but they are going to be flooding as they should to all their M SDP peers to cut down on that you can put them all in a mess group and what happens within a mesh group is if you receive an essay from a mess you appear you will not forward it out to any other message to appear you'll forward it out to other peers you may have outside the mesh group but not to any others within it so it cuts down the flooding and the reason that you don't have to send it out to other mesh appears is because you know that they've already received it because within a message group you have to be fully meshed so looking at it in this scenario if router 4 in this case is outside of the mesh group it sends an sa-2 router to router 2 has mesh group peers router 1 router three that could be 20 or so these peers but in this case there's just three to illustrate it simply rather to afford those essays – its MSD P mesh group ears but router 1 and rally 3 will not afford them to one another because they know that they've already received them that cuts down on the disait flooding but router 3 will send it off to another MSD PPR outside of the mesh group and there's there's some examples configuration examples that you can easily apply to other vendors but just kind of illustrates how that works so as I mentioned before we're at draft spec 20 and it's just been an amazing process of trying to get agreement and just to get the darn thing closed and it looks like as of this week it will be an experimental RFC don't have a number yet but it looks like we are finally done what we did is we just basically took out a ton of stuff and just try to find a common denominator that we can all agree upon and you know made a lot of maze instead of musts and so y'all take a look at that spec it's a it's pretty efficient I've subsequently submitted a multicast an MSD PBC P that's common practice which discusses a lot of the things which we are discussing today to help understand how you would deploy it came up on the mailing list that it's just really difficult to deploy MSD P that's the one of the reasons we hate it so we need to have some sort of a best common practice and so that's been submitted David Meyer and John miler are on that as well they gave it their blessings so that's good so you can look those up to take a look at that's on ya right so the question is in this back on slide 38 router 1 and router 3 being though they're in the mesh group peer peering they aren't going to send the essays to each other and the whole motivation it's pretty simple is just what you just said is just to cut down an essay let's say you had 50 M SDP peers they had if they received if router 2 received that essay and had it sent it off to it would have the Senate it would set it off to all that semester group if M SDP peers they would subsequently send it to all the other all their other peers and they would send it to all their peers so if you send it it be its scaling is what it is exactly so it's if you have a lot of M SDP peers it works good if you don't then it's not that critical however it is used than many can start Peas and we'll discuss that also good question all right so I'm this is the first time that I presented this portion of the presentation all these RPF rules that I've discussed that presented to you in the latest draft there's been some additions to Tam SDP to try to make things a little bit better and I would assume most implementations now have implemented these new these new options these new rules and so in latest code not what's up primarily not without their today but without their today is what I've just discussed but with newer code that has the latest draft it's compliant latest draft there's some new things that need to be aware of one of them is that we've taken out the requirement of always having to use BGP to do the RPF check now if there is no BGP you can fall to an IG PDO SPF is is whatever to the RPF check and that's kind of cool we can now accept essays from a BGP next-hop not just the advertiser of the next top but the next top itself and it will straight each of these and there's also the ability now of latest draft to accept essays from the closest peer along the path not just the next a s and the best path back originally RP but any a s that's the closest one in the next-best bat next path back towards visioning RP so I'll talk about each of them briefly and then we'll move on out of the nightmare of RPF checking so let's say again you don't have BGP but you are winning OSPF and you want to be able to use that for your RPF check now and now you can you can you can get to that so in this environment we're not running BGP router a gets an update si from router B they'll just look in its unicast routing table it does have a route back towards originating RP which is 2.1 1.1 the MSTP peer is also 2 2 3 . 1 2 1 2 1 and so the Nats and the RPF check is successful will forward that on to other MSTP beer we can also use as part of the IGP check the advertiser of the next top like OSPF and is is where you have a router ID you have that rip doesn't have that just has the next top but with protocols like OSPF you do have a router IP so you can use that if you wish if that you're not required just to use the next hop so let's say 4.1.1 2 1 is a loop back on router B we can peer with that the next hop towards with it the originating RP is 3.1 dot 1.1 so what normally we'd fail but we do have the advertiser originating RP which is for that one don't want at once that we're all happy RPF check succeeds so let's be aware of that that's something that's if it's a requirement of yours that you just you want to be able to use an IDP then just be aware that there's code out there now that in the FT form that you can use we can also now accept essays from the next hop not just the advertiser next hop and in fact next top is actually preferred so in this case in this route reflect your scenario router e is the next hop towards the next hop back toward region ERP the MST be pure dress is 172 16 3.1 but the bgp next hop is 172 6 3.1 so the reflector is the advertisers are next top so normally it would fail as I stated before but the next top is if you're using like next top self is the next top and we'll use that now for RPF check just again just put that in your bag of tricks and just be aware of that and then yes yes it's implementations lagging behind the spec so implementations are now becoming spec compliant as we've quickly tried to bring the spec home into tow RFC status which looks like we've done now and so this option is now available to use if you need to but if you were going to implement with existing code today probably on all vendors I'm guessing not only ours the rules that I've mentioned at the beginning is what you would need to be aware of so it's going to be some time before the the new code you know how radical is that you know obviously and you're usually in the in your service provider space usually use brand new code out there so well maybe maybe live on the edge I don't know so the last thing is to be aware of is that in this case s1 receives an essay from a s3 in the existing rules if the first day s in the next best bath back towards original RPE is not your MST be peer which would be router 2 then it would fail because round 2 is the neck a s2 is the next day yes and the best path back we're judging our piece you'd have to MSTP peer with a s – now we've relaxed that a bit so just a no look at the ass path just look at the closest a s and just if that's good and behind just let's just let's just use that one and be on our way so there we are that's MSTP we do know what we're doing pretty good for time so we've discussed the two protocols now that are being used to make multicast work across the internet if you have your own company and you want to start forwarding multicast traffic out to the world you need to talk to your provider and say okay we need to start setting up some carrying and I'm get an MSD Peep hearing setup with you it will go over some right now some examples different deployment scenarios of how you'd get this to work let's first go into any cash star piece most of you probably from so much familiar with any cast RP any cast RP is a solution that was created to be able to have redundancy and load sharing what you with most multicast you can have one rendezvous point for a particular group it should be nice to be able to have a variety of you know rendezvous points the bill do you use for for backup load sharing and redundancy and that's what any cats RPE function does is it allows you to assign usually it's a loopback interface on several lot rendezvous points let's say to two or three or whatever and they had the same exact IP address slash thirty-two and your sources and receivers will be directed just using unicast routing towards the nearest rendezvous point and if that one fails they'll just be directed to the next nearest one it's it's kind of cool and all we'll look at an example of how exactly that works it's very fast convergence just depends upon unicast routing that you're using so let's let's take a look at example we have East Coast and West Coast rendezvous points and they have an MSTP peering with one another they both have the same in a cast RP address 10.1.1.1 so the receivers on the west coast send their joints from particular group and those joins are directed towards the nearest RP which is on the west coast same thing happens for the receivers on the East Coast a source fires up on the west coast and the receivers on the west coast receive that that traffic cuz they're interested in receiving it but the routers the receivers on the East Coast have no clue on that source existence because they're not using the same actual rendezvous point so that's why MSTP is needed the West Coast run of a point will sent an SI over to the East Coast letting that router know that it has an active source and if he has a receivers interested go ahead and join towards the source which it does and receivers get the packets and if there's a source on the East Coast the same process occurs so let's say that router a dies heaven forbid so what happens while the receivers continue to get the traffic because typically with sparse mode you're gonna cut over to the shortest path tree and the Ronnie of a point can die you don't care you're just you're getting the traffic natively for any news sources they're going to be directed over to the other Ottoman point just as quickly as unicast direct Rodney connected over to the other rendezvous point so it's very quick fell over it's very seamless and it works it works awesome this is where I had to just put in configuration commands that I was familiar with just to kind of make it clear all your router is within yes question yeah very good very good question I will discuss it right now they'll answer your question how it's good this the question is that since we're using the same ip address where they accept the essay from one another if they receive the essay from the same IP addresses itself no it wouldn't so that's why it's important to use a different address no illustrate that right here so all the routers in the internet within a domain and this is commonly done is in a service provider space typically we would recommend using static configuration for your RPS so they're all configured to statically point to the one in the cast RP address in this case 10 dot 0 dot 0 dot your loopback interface on both rendezvous point 1 and 2 loop X 0 on both routers however are used for their MSTP peering those are separate loopback interfaces and they need to be used to use your MST be period you use those addresses because as was mentioned if you were using your anycast RP address as your MSTP peering address you would fail because if you receive an essay from peer that's the same as you that would be a loop so you're gonna you're going to drop it so your anycast RP address is just use for anycast RPS that's where all your routers in your net point to separately you have a loopback interface which you use for all your M SDP peering alright let's move to a multicast exchange environment we have multicast exchanges throughout the world there's the games multicast exchange NASA its own familiar with mostly as well as the Palo Alto exchange what they do is all these here one providers are appearing with one another or using n BGP and MSTP so that they can have the sources known to them as well and typically you'll have just a regular you know switch everybody connected up to a switch what is getting more common nowadays like at star star cap in Chicago I believe it is where they use point-to-point VLANs instead for a more deterministic approach to yard PF checking the best way that it works today is is just as it is with unicast is you have your multicast exchanges sharing essays and mpg peering one with one with another for security with MSTP we do have a recommended filter list and there's a draft out now this one from build nicholas has actually timed out and I paint him and he's going to resurrect that one and it's gonna be a note too I guess but there's there's certain groups out there that particularly an application side they've chosen for their application global multicast addresses and so that's kind of a bummer for the multicast and the inter domain space because when they're setting these the local RP will reg will go ahead and send out essays about these applications that are meant to be just domain local so the whole internet is hearing about these these applications which they don't need any be hearing about so as we find them and as well as as well as other well-known groups we add those to the list of recommended filtering so that we prevent at the edge unnecessary essays to be flooded throughout the internet while we're on the topic of MSD P and security there's also recommend and recommendation to use a sa limit all vendors that have implemented s MSD P will have an SI limit right now the essay counts is typically hovering around 2500 essays so people usually either choose 3,000 for an MSD ps8 limit or maybe 5,000 just to give kind of a room but it's possible and it's happened in the past and the things about a lot better nowadays but it's possible that there could just be a huge flood you know you get you know 30,000 essays and that sa limit we'll make it for that won't cause a problem alright we're going to now quickly go through a variety of scenarios of deployment scenarios with with multicast across domains this first say that you have a customer who is interested in well you're the customer interested in sourcing multicast or just receiving multicast from the internet you don't have your own RP you don't want to maintain you on RP just want to use the service providers rendezvous point and there's fighter set fines go ahead use ours so what do you do well you point to their rendezvous point and so any sources on your domain or any receivers that send a join that will all be forwarded off to their audit good point those transit provider over here in a s 109 it has its dual rendezvous points and you're pointing as a customer to to one of those and so that the provider will also be pointing to its own inaudible points and both the customer and the provider will be doing some filtering they'll do the the filtering for BSR border and the important thing on that is as I had a nightmare one time working with a provider where a customer is using BSR which is an auto discovery auto RP discovery program and that was getting flooded into the providers network and so it's wreaking havoc on its own art piece and we don't know what the heck was going on and the BSR border command wasn't being implemented which will stop it at its tracks it won't go in or out when that border command is is configured so that's an important one to use a boundary of command is also recommended to use you create an access list and you filter out any multicast group ranges that you want with with our static assignments it's important to have the override and this is another thing that we were missing with this provider is we were missing the override command we have a static RP assignment you receive adenine a mcli learned RP whether it's through auto RPE or BSR and that will be preferred unless you have override on your static command if you have override your static command that static command will always be the one chosen for your ERP that's the critical to to use if you look at your RP mapping you'll show the RP address of the providers RP there's no MSD P running here you're not running your own RP at the customer site so there's no need to have it so there's no RPF check the multicast RPF check once the packets do come into this customers site it will just use its if it's running BGP it will use that if it's using a default route it will use that as it's just it's regular multicast RPF check and the transit provider will have a static route for your subnet and advertise that out to the rest of the world both via unicast and multicast because the rest of the world may assign policies to your your updates so that's why they will want to have yours be known to the rest of world via MIBG B all right so let's say the provider tells the customer you know what can you maintain your own RP already or just it's simpler just use own RP or maybe the customer wants to mean they're on to RP they want to have more control over that so they do so they create their own RP and they're using multicast just fine within their own domain and they want to be able to advertise their sources out to the rest of the world or receive information out from the rest of the world so the same filtering would apply but now we're running MSD P because that's the only way that we're going to learn sources that exists out there in the world since we have our own RP now we're on our own Island we need to know what the other islands are doing so we'll MSD beep here with one another will have a filter list to make sure that we don't get hammered by unnecessary traffic will have our miss TP RPF check if it's just a tell site customer with one ms DP appearing then the RPF check will just be skipped because there's no need for a there's no looping problem it's just one MSTP peer the transit provider will be pairing with you typically there would be beep hearing what the customers originating our so there's no need to do an RPF check on that either because it's there's no chance for looping and then the multicast RPF check will just be done as before when the multicast do start the packets do start flowing in though this use your unicast routing table to do the RPF check so this is the scenario of how we're doing multicast here this few next few days here at nanog the University of Utah has has made it as provided the network scenario we have an N bgp pairing with Sprint they actually have their multi homes they're preparing with internet they got a link the Internet to you as well but just to make it as simple as possible we have a MPT preparing with a border router within Sprint we have an MST pairing with one of the several RPS within the Sprint's backbone we have the filters set up the run of appoints the the Sprint's backbone is running the thinny cast RP as a mesh group going on these are peas within the Sprint backbone are have MS deep appearances with all the other customers in addition to nanog and the MSTP RPF check is done just as as we've discussed the nanog router will just you know use it it would have multiple MSTP pairings because it has other other providers out there so we'll just use whatever the BGP route would take it to get there it will use the Sprint's AAS and the next best backdoor path back towards originating RP if that does happen to be the next day as the best path back towards the ERP and then Sprint's MSD be pairing with nan out and the nanog AAS here would be the next day s and the best path back towards originating RP since then I gar P is the original RP and the multicast RPF check is is yes question the back which we're all supposed to talk about but yeah go ahead I'm just you know I'm just joking all right it's vendor-specific so just go who cares the connect source address makes it so that you can control which address is used in the MSD P update so in this case in at Nanog it sparingly 3.33 3 which is a sprint router and it needs to know about that address via BGP or M BGP that's significant that's just specifying an IP address you could just as well specify an IP address that's exactly right that's right that's oh I see that ok yeah so there was no confusion on the pause that's just no that's like with the unicast you just can specify instead of actually specifying IP address you specified in your face yeah I don't try to make that clear next time so then the multicast RPF check dis uses you know be TPM bgp if it's there hopefully it is and where you go another scenario is where you are dual home one provider may be multicast only another provider may be unicast only you want to break it out that way so you'll obviously just be MSTP peering with the multicast only provider and not the unicast only so you'll just be setting up filters with that transit provider the MSTP RPF check again you just have one MSTP pairing so there's a no-brainer there's no there's no check necessary if there was you just use em BGP and decide which which path you should accept and the multicast RPF check is done similarly with with BGP and then lastly which is most ideal is you have multiple providers both providing multicast and unicast transit your peering with both ms DP as well as m bgp setting up filters with with both their advertising your networks because they're learning about your network for you at NB GP and you'll just choose the whatever the a s is that's next best path back towards written erp that's what will be used to do the RPF the winning of the RPF check for ms DP and same is true for the multicast packets which is again a different RPF check once they cut start coming in will just whatever is the best path that will be the one that will be you chosen for the RPF check so there's a variety examples that kind of flew through those but hopefully that gives you an idea of kind of the deployment options and we'll continue to talk about some more here i've got a fly a little bit but we're doing not do it too bad with time glop you may ask with you know with unicast you have addresses assigned by iana with multicast that's not the case it's kind of a free-for-all you've got this multicast group address range and what do you do so you know you could pick some people could be picking the same group address for the multicast sources and there could be a conflict and that's true that could be the case a a concept of glop was created which has gone from the concept stage to the implementation stage I don't think glop stands for anything that's just an acronym I believe that David Meyer came up with and it's a temporary allocation of 2:30 3/8 and again I say temporary MSD P was temporary and it's going forever so maybe this will last longer than we we plan but it's just a way to allocate if you have an a s you can inject that a s into 2:30 3/8 and come up with your own slash 24 used for your multicast groups the way you figure it out is just you know take it write it out in binary if you want or hex and map the high-order octet at the second octet of the to 30 3/8 address and the lower lower order octet to the third octet and you get your address all these slides are should be posted by the way on the site so you are you viewing them where yeah okay cool alright so you guys have them so you can review this later if it's confusing at all but the easiest way to do it is just to go to a website from our friends at university of oregon plop in your AAS and it will tell you what your last 24 is for use and again that's the recommendation here there's been a lot of different proposals in v4 for more dynamic allocation of bad dresses nothing has stuck yet and so we'll wait and see if anything changes with that any questions before I move on to the last three sections here I've got about a half hour all right on a router it's probably vendor specific ours is six minutes you'll stay in the cache and then timeout if it's not updated once a minute we send out the contents of our si cache it was specified in the spec that you must cache yes a so well you're not concerned about the receivers you're just concerned about the source so yeah okay sources so so yeah and you register your receipt from a source you're gonna go ahead and send out a new essay it will be the new it'll be an essay for that for that new source because otherwise you'd be flooding all the time so once a minute you play the entire contents your essay cache if a new essay comes in within that you're gonna flood that so there all right yeah you're still sending at least for us it's the one that dealing and that's been a Pacific I I don't know how other vendors do that younger so source-specific multicast it's a great idea it's something that would have been awesome if we come up with this years ago we would have been able to avoid all the rendezvous point mechanisms altogether with the advent of IGP version three host can now specify the actual source that they want to receive with AGP version one host sent a report to the local router saying okay this in the group that I want to receive you can send me any source for that group it's a stark emoji just any sources for this group in IP version two it was the same thing but the enhancement is that when a host left a group it would actually send a leave message to let the writer know that I'm gone so you can send out you can quickly prune me off or in version one it would take several minutes for it actually to stop forwarding onto that land with version three the hosts again can now specify the source and the group I don't want to just receive any source there could be a hundred sources for this group and I have to receive them all I just want this particular source very cool source-specific multicast on the routers make it possible that one would received such an IP version three join we already know the source we don't have to go through this whole process of trying to find out sending the packet to the rendezvous point the receivers join they're sent to the rendezvous point we cut over to the source path tree we already know what the sources we gonna immediately cut over to the source path reach towards the to the sources it's very cool the last top router sends the joins towards the source it definitely simplifies address allocation if you think about it if the two different companies choose the same group two to four de 1.1.1 who cares because they're both sourcing it from their own unique source and since this the host is now specifying both the source in the group it definitely solves that it definitely simplifies that problem and there's a variety of RFC's out there that describe you two different versions of ijp which we've discussed version three is more and more prevalent now in the stacks of various hosts we're just now trying to push to get more and more applications that are SSM or ijp version 3 aware so that we can start getting this thing to take off in the inner domain space because if there's not rendezvous points needed then it eliminates the need to even have MS DP you don't need to have the SA feel that we've all been talking about if if SSM is used as the same is being used today it's just not widely used as maybe hopefully as more and more applications get developed it will be used more privately so the way that this works is a sources firing off its multicast content a receiver learns of this source and group through some out-of-band mechanism network administrators are cheering because we don't have to deal with having to have that around a bit points there anything have the network take care of it it's we're just letting the receivers take care of figuring out how they're gonna get the source and the group advertised either via email or web server or whatever so the receiver learns what that sourcing group is it sends an IP version 3 s comma G join to its local router that local router is running SSM so it recognizes that and it immediately sends a join towards the source because it knows what the source IP address is traffic begins to flow and those of us in the multicast development group are out of a job because it's extremely simple this is awesome and we hope it goes nuts these are just different drafts and whatnot that specify where s SS SS m is and IgE v3 is and it's supported in a variety of router vendor os's we do maintain a list of stacks I did pv3 that's right in the pro-peace witches it is getting there yeah the question was is v3 now widely deployed widely supported in vendor switches and the answer is yes and no it is it is getting there there are certain you know like with us for instance it's you know it makes sense to concentrate on certain switches and make them v3 aware and depending upon customer feedback others may not be included in that so the answer is yes I don't know if you're running code right now that supports that but but you could okay so this is just a summary it is also just another thought for security it also will help prevent certain types of denial of service attacks if I'm receiving a stream I even if it in my own domain let's say that I met a you know I'm at my desk and I'm receiving a corporate broadcast from the company CEO and it's being broadcast out on TG 4.1.1 Taiwan if I'm not running SS am and using v3 then some malicious co-worker could be in his cube you know thinking a video of his own head doing you know who knows what and sitting for that same group and jamming that content so I could be receiving both and it could be all messed up because I haven't specified what source I want it just any source of that group so that's one of the neat things about SSM is that you've requested a certain source and groups would be much more difficult to specify spoof both yeah that's the question is can you run the SSM with him well that's a good point because that's the same is Pam there's Pam sparse know there's Pam dense mode which we don't talk about anymore really it's kind of old school and there's bi-directional Pam there's source-specific multicast Pam there different types of modes that yes can be used in different parts of your network so if you're currently using rendezvous points which you typically would be and you wanted to start introducing SSM then you just mainly at first just need to upgrade your border routers they're not the border routers your last top routers the router is closest to the receivers because they need to be able to understand the v3 joins and since SSM is the 232 / 8 range you can just specify this is my range that I'll be using only for SSM and then in the long term you can if you wished you can just open up that range to not only include 230 but for all your groups if you wish so that would be a that is something that's commonly done of course we can have local SSS so the question is is there been any studies done or testing that has to do if what makes sense when you know depending upon whether you want to use that's a sam or sparse node or any other mode for that matter I think that there's actually been some with us some scalability numbers done but I don't know what I don't know if that is but SSM is designed for one too many you know because it's you know one yeah at what point is the one to many of the few too many and the many to many you know what point it's you know that's I don't that's that's AG accident question I don't think we have really good answer for that it's just kind of depending upon your preference you know a lot of people that have many demand either that's where they're gonna be going to by directional pan and so it's there's the logical solutions for different environments inner domain multicast is primarily a one-to-many situations so SSM is ideal but the pipe is not a bad idea to try to come up with some sort of a study on what makes sense number wise good question all right so we've got about twenty minutes to discuss these last two I think well I think I'll make it so more and more now there are providers using multicast MPLS VPNs and up until now only unicast has been supported in such a MPLS environment and service providers were coming to vendor router vendors saying hey I've got these customers who we have started implementing MPLS VPNs and they want to now start running their multicast traffic over this environment and there's no switching of multicast packets within the MPLS VPN environment it's only unicast package there's no there's no fixing the label to a multicast packet so what we're going to do about that we need to we need to come up with some sort of a solution well the workaround up until recently has been just to create a bunch of point-to-point GRE tunnels between all the CII's which is if you have a lot of CDs can be an administrative nightmare and it's just not scalable but that's you know that's what that's what you would do and the supervisors and the customers have come to us and said okay so whatever your solution you come up with to make this better instead of all these point-to-point tunnels it needs to be a solution where the provider can use whatever pinmode he wants SSM bi-directional Pam or sparse mode whatever and the customers should be able to have their own mode as well it need to be independent not dependent upon one another so okay we take that and we'll make the implementation support any PIM operating mode and customer and provider networks so our implementation as well as other implementations are based upon multicast domains specified in the ROS and draft and it does just this and that is that you've got your provider network and you get your customer network and what we do is when a multicast packet comes in from a customer VPN well take that multicast packet and encapsulate it in another multicast packet for it across our network D capsulated on the far inside and send it off on its merry way and its original multicast source mode so it's what the solution is it's a dynamic mechanism for creating tunnels between the different TPEs per customer and I'm going to illustrate it as we go along here I think it'll make sense on how this how this works it's being used today in a variety of provider networks so from a customer's high point of view what they have is they have their own independent VPN for both unicast and multicast they have their own color and it's it's being being forwarded from the providers perspective of what they've done is they said okay for a blue customer I'm going to use a particular group address 2:39 dot one dot one dot one for the blue murders for instance so again when multicast packets come in from the blue VPN and I want to transit my MPLS VPN core i will encapsulate it in 239 dot 1.1.1 which will be that only that address will only be used for the blue customer and that will be sent to the other pease that lead to that customer's remote locations and then for other customers will use a different group address range for all those multicast packets so let's take a look at little more detail and exactly what's going on with multicast VPNs so receiver joins a particular group and it's the pin packet the pin joint is sent from the CEO off to the PE that PE router gets that join and it sends that packet to a destination address of 239 1.1.1 it encapsulates the customers packet multicast packet and creates a new multicast destination address which goes to the other PE s within the VPN the PE that leads to the source will the TCAPS like that join send it off towards the router that leads to the source the multicast data would begin to flow the PE router that is connected to that source will encapsulate that multicast packet he the PE router will become the source IP address again we have a new destination multicast group address to 39.1 1.1 they'll be sent to all the PE s the PE that leads to receivers will D capsulate it and send it on its way and the receiver gets the packet and it's able to view fashion TV receivers all happy so if there's any news sources that come up they will also be encapsulated in that same group address so one benefit of this is that it definitely reduces state and for the P routers PT routers just have to they're just going to know one group address range one group address for that fill out the forward so that's one of the advantages disadvantages can redo it can result in wasted bandwidth there are PE s that don't lead to receivers but they're getting the packet for getting the data anyway that's one of the the problems in the solution and this is something that is where the interoperability stops we could between vendors use the default NPT and everything would work just fine but beyond that it's not specified exactly what to do and one of the solutions that you could do that we've done is to use a separate data MDT for high rate sources so what that would mean is that when this the multicast traffic is forwarding across this default multicast distribution tree MDT it would exceed a certain configurable threshold on the PD router that's connected to the high rate source the PE router would send a control packet to all the other peo outers signaling those routers that if you're if you have receivers that interested in particular source please send a join towards me to me and we're going to use a new group to 39.2 to one so the PE routers that have receivers will send a join to this new group now and the data MDT is built using this new group and the traffic begins flowing along this new this new tree you still have the existing default MDT for any news sources that come up and all the control packets they still occur on the depot in DT but you can now cut over and again that's about as specific as I want to get because that's a solution that that that we do and you may just want to ask your vendor what solution if any that they may have for that they may decide that it's maybe just not it may not be necessary they just want to stick on the default NDT so that's kind of just that this is just kind of the picture of how it all halite up how it all ends up with your different VPNs and setting up your default NDT and and works pretty good any questions on that before we move on to v6 yes in the back that's right so one of the potential drawbacks of cutting over to a data MDT is that now the PT routers have to maintain more State for new groups and that's true so you would just need to decide whether and that with us is configurable whether you'd want to you've ever even cut over to the data MTT I would think that for efficiency's sake in many cases would be preferred to covert to it data MDT but good point maybe not always all right v6 right lastly and this is kind of the fun part this is all new stuff we have a new multicast address range and you know it's F F F F F /a excuse me and that's why I neat things about v6 addresses you've got four scoped bits that you can specify whether this address is link local or global or regional or whatever so that you can on your routers set up your filtering so that ok no address that's global will will pass my my interface so it's ooh but so it's much it's just it's it's easier to do your boundaries with v4 today we have to set up a boundary command and specify the the group address range that we want to to bound just a little brief history I'll try to make a brief on were multicast v6 stands with unicast v6 it's been around for several years now a tunnel topology in the six bone and at the last IETF it was decided to decommission the the six bone and to go native and that I there was a specific date that was chosen some of you may have been there and at that working group and we're following suit we really want to aggressively make it so that we've learned from previous experience with the old M bone which in some ways we're still kind of fighting with what the tunnel topology is to kind of go native as quickly as possible so what renee der out in europe did is they created a m6 multicast six bone so it is a tunnel topology for a lot of testing and a lot of people are involved in that a fair amount of applications have been created to it to work on on v6 and it's it's there today and again we knew that we wanted to aggressively get out of that mode however and go to a more native approach a lot of people have created native networks as we vendors have come up with with implementations and so there's a lot of different environments now like for instance nasa their production network is v6 capable for multicast and so there's a lot of these little different islands people of companies that have now gone to a native native mode and there is a new network that was created a new environment that was to be able to support these native implementations and that is six net rene der who maintained this m6 bone is an active participant in em in the six net and this is a network of a native solution where we're able to test and people are able to natively get a solution for for multicast and unicast for that matter and so we're in this mode now we're just really trying to it's really trying to push people to go natively with these sixes as quickly as possible there's a variety of stacks come a I believe was the one of the first ones if not the first one there's a variety of applications now that support v6 from multicast there are some obvious differences between v6 and B for multicast one of the differences to be aware of if you're not familiar with the terms is with v4 I've talked about IGMP internet group management protocol where the hosts and reports in v6 that's referred to as MLD multicast listener discovery and there isn't even a version of MLD that's equivalent to ijen p version one well ml d version one is equivalent to i GN pv version 2 and ml d version two is equivalent to a champion version 3 so just I put that slide in there because you may have to go back and look at that one again I mentioned the scope identify those the four scope bits which make it a little bit easier to filter on the edges and the interesting thing and this is kind of what we're going to get into is the whole idea of how we are gonna have an inter domain solution with v6 and that's still in debate people in ITF are aggressively trying to make it so M SDP isn't even allowed to be implemented within v6 they don't want to have to deal with all these different rules that I've mentioned and the SI flooding and 14 throughout the internet some of us think that it may be unavoidable at least at the beginning so we can get things to work quickly we shall we shall see you know one of the solutions is to you know have global our P's everybody's dependent upon a certain RP a solution that was brought up for B 4 and M SDP replaced that because people service providers didn't have to rely on the RP of somebody else and you know it makes it so you're reliant upon other domains I'm gonna in a few slides here discussing different options that we have available to us and we'll end on that so RPF with v6 multicast is the same as with the v4 or multicast you just use your you know it's protocol independent and you just use your unicast routing cable m bgp supports v6 address families and we can use those for RPF there are some definitions to be aware of a pim domain is a topology served by a common RP so if we have one big fat happy kim domain within the internet we have a bunch of different routing domains of course that's based upon the AAS but one big PIM domain is that what we want well time will tell and I've mentioned scopes and boundaries so I'll pass on that one so this is our last two slides here so I think we've done pretty good so here's our here's our inner domain solutions I can see three solutions that are available to us to make this work with v6 and we need your feedback on what you'd prefer because the ITF sometimes is kind of a you know it's our own academic sometimes world and we we need real customer feedback so we have SSM there's no need for rendezvous points it's extremely simple have the receivers learner the sources and groups and just fire off the joins towards the source and it's extremely simple some people really support this saying you know what let's just have SSM only it startup right from the very beginning let's SMS SSM only in v6 yeah I hear yep yep back there okay so that's something that a lot of people want to see happen another solution would be okay well we some people feel that leaders really can't get away from any source multicast it's just you know it's gonna be a long time between all of our host acts are up created to build support v3 and all the routers etc so we just we want to be able to use v6 multicast today we need have a solution well if that's the case then today we need to have M SDP like solution or just use M SDP to make it so that we can learn of sources and other PIM domains and as we've discussed we have all our different RPF rules etc but the receiver will be able to receive the packets from the source so that's another option that's available that still being debated and then lastly is the concept of again having one rendezvous point out there using ASM and everybody is able to just rely upon that one RP for certain groups and that's what our solution will be at first that would probably work because it's kind of a small still kind of in the testing phase and that's in fact what's being used today but going forward would that work well there is a proposal out there that some of us have actually implemented that has to do with embedding the RP address in a multicast address so with v6 again there's the there's certain bits that you can set that will flag that the RP is embedded within this multicast v6 address so the RP address is known so there's no need to use MSD P to find out their sources everybody as long as they're using routers that understand this embedded RP will they'll to know what there are P addresses based upon the multicast group and then be able to send the packets off to the rendezvous point some people that think that's very attractive it in the spec specifies that this is a temporary solution it may or may not be or maybe it won't take off at all we need to know if everybody is ok with depending upon some other RP out there for our sources and groups to get the our sources and receivers to get together we need to have anybody to hear from you guys you still a need MSD P for any cast RP solution or an MSD P like solution at least it's pretty simple to implement for PIM sparse mode you intermediate you know your outer is again need to be upgraded to be able to handle understanding these end up embedded our piece and perhaps there could be some scalability concerns because you have this big virtual flat domain instead of a bunch of little domain islands so this is this is where we're at all three of these are being used right now in the m6 bone and six net all three of these meaning we have embedded RP solution we have static our peas that are being used as well as BS are those are the three ways right now that we know of a rendezvous point within the v6 world if anybody's interested in actively participating in v6 let us know feel free to send me an email if you wish and I can steer you in the right direction again it's McBride at Cisco comm and that is it any questions before we close not bad I had like three minutes to spare thank you that's it

Leave a Reply

Your email address will not be published. Required fields are marked *