Re: [j-nsp] Segment Routing Real World Deployment (was: VPC mc-lag)
On 5/Jul/18 10:15, James Bensley wrote: > > If you get any feedback you can publicly share I'm all ears! Will do. I'm currently working on getting those that have deployed it in the wild to do a preso at an upcoming conference. > As far as a greenfield deployment goes I'm fairly convinced that SR > would be a good idea now, it would future proof that deployment and > for our use case it does actually bring some benefits. If you are deploying greenfield, then you have a good opportunity here to go with SR. In our case, we have different boxes from Cisco, each with varying support for SR. This makes things very tricky, and then we need to also throw in our Juniper gear. For me, the potential pain isn't worth the hassle, as we are not suffering in any way that makes the move to SR overly compelling. > - Go IPv6 native: If using ISIS as the IGP we should be able to go > IPv4 free (untested and I haven't research that much!). For me, this is the #1 use-case I was going for; to be able to natively forward IPv6 packets inside MPLS, and remove BGPv6 from within my core. I had a discussion about this with Saku on NANOG: http://seclists.org/nanog/2018/May/257 Where we left things was that while the spec allows for signaling of IPv6 in the IGP, there is no clear definition and/or implementation of MPLSv6 in the data plane today. For me, I don't really care whether I get MPLSv6 via LDPv6 or SR. For the moment, LDPv6 has varying support within Cisco, so it's currently not a migration path. SR support for MPLSv6 is unknown at the moment, and certainly not a priority either, which leaves me with no immediate appetite for SR. > - Remove LACP from the network: SR has some nice ECMP features, I'm > not going to start an ECMP vs LAG discussion (war?) but ECMP means we > don't need LACP which again is one less protocol for inter-op testing, > less to configure, less to support etc.It also keeps our p-t-p links > all they same instead of two kinds, p-t-p L3 or LAG bundle (also fewer > config templates). I feel your pain. As a matter of course, we stopped using LACP for IP/MPLS backbone links. We rely on ECMP, until it makes sense to move a circuit to 100Gbps. Mark. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Segment Routing Real World Deployment (was: VPC mc-lag)
On 4 July 2018 at 18:13, Mark Tinka wrote: > > > On 4/Jul/18 18:28, James Bensley wrote: > > Also > > Clarence Filsfils from Cisco lists some of their customers who are > happy to be publicly named as running SR: > > https://www.youtube.com/watch?v=NJxtvNssgA8=youtu.be=11m50s > > > We've been struggling to get vendors to present deployments from their > customers when they submit talks around SR. So the SR talks end up becoming > updates on where SR is from a protocol development standpoint, recaps for > those that are new to SR, e.t.c. > > Perhaps those willing to talk about SR from the vendor community do not have > the in with their customers like folk like Clarence might, but I'm not sure. > > I'll reach out to Clarence and see if we can get him to talk about this with > one or two of his customers at an upcoming meeting. Hi Mark, If you get any feedback you can publicly share I'm all ears! As far as a greenfield deployment goes I'm fairly convinced that SR would be a good idea now, it would future proof that deployment and for our use case it does actually bring some benefits. To explain further; we don't have one large contiguous AS or IGP, we build regional MPLS networks, each on a private AS (and with a stand alone IGP+LDP) and use Inter-AS services to provide end-to-end services over the core AS network between regional networks. If we built a new regional network tomorrow these are the benefits I see from SR over our existing IGP+LDP design: - Obviously remove LDP which is one less protocol in the network: This means less to configure, less for CoPPs/Lo0 filter, less for inter-op testing as we're mixed vendor, less for operations to support. - Easier to support: Now that labels are transported in the IGP I hope that it would be easier to train support staff and troubleshooting MPLS related issues.They don't need to check LDP is up, they should see the SID for a prefix inside the IGP along with the prefix. No prefix, then no SID, etc. I would ideally move all services into BGP (so no more LDP signaled pseudowires, BGP signaled only service to unify all services as BGP signaled [L3 VPN, L2 VPN VPWS/EVPN/VPLS/etc.]). - Go IPv6 native: If using ISIS as the IGP we should be able to go IPv4 free (untested and I haven't research that much!). - Bring label mapping into the IGP: No microloops during re-convergence as we heavily use IP FRR rLFA. - 100% rFLA coverage: TI-LA covers the "black spots" we currently have. - Remove LACP from the network: SR has some nice ECMP features, I'm not going to start an ECMP vs LAG discussion (war?) but ECMP means we don't need LACP which again is one less protocol for inter-op testing, less to configure, less to support etc.It also keeps our p-t-p links all they same instead of two kinds, p-t-p L3 or LAG bundle (also fewer config templates). - Remove microBFD sessions: In the case of LAGs in the worst case scenario we would have LACP, uBFD, IGP, LDP and BGP running over a set of links between PEs, we can chop that down to just BFD, IGP and BGP with SR. If we wish, we can still have visibility of the ECMP paths or we can use prefix-suppression and hide them (this goes against my IPv6 only item above as I think IS-IS is missing this feature?). The downsides that I know of are; - Need to up-skill staff: For NOC staff it should be easy, use this command "X" to check for prefix/label, this command "Y" to check for label neighborship. For design and senior engineers since we don't use MPLS-TE it shouldn't be difficult, we're typically deploying set-and-forget LDP regional networks so they don't need to know every single detail of SR (he said, naively). - New code: Obviously plenty of bugs exist, in the weekly emails I receive from Cisco and Juniper with the latest bug reports many relate to SR. But again, any established operator should have good testing procedures in place for new hardware and software, this is no different to all those times Sales sold something we don't actually do. We should all be well versed in testing new code and working out when it's low risk enough for us to deploy. Due to our lack of MPLS-TE I see SR as fairly low risk. I'd be very interested to hear yours or anyone else's views on the pros and cons of SR in a greenfield network (I don't really care about brownfield right now because we have no problems in that existing networks that only SR can fix). Cheers, James. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Segment Routing Real World Deployment (was: VPC mc-lag)
> Of James Bensley > Sent: Thursday, July 05, 2018 9:15 AM > > - 100% rFLA coverage: TI-LA covers the "black spots" we currently have. > Yeah that's an interesting use case you mentioned, that I haven't considered, that is no TE need but FRR need. But I guess if it was business critical to get those blind spots FRR-protected then you would have done something about it already right? So I guess it's more like it would be nice to have, now is it enough to expose the business to additional risk? Like for instance yes you'd test the feature to death to make sure it works under any circumstances (it's the very heart of the network after all if that breaks everything breaks), but the problem I see is then going to a next release couple of years later -since SR is a new thing it would have a ton of new stuff added to it by then resulting in higher potential for regression bugs with comparison to LDP or RSVP which have been around since ever and every new release to these two is basically just bug fixes. adam netconsultings.com ::carrier-class solutions for the telecommunications industry:: ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Segment Routing Real World Deployment (was: VPC mc-lag)
> Of Gustav Ulander > Sent: Wednesday, July 04, 2018 10:46 PM > > Has anyone actually managed to verify a business case with SR? Im guessing > those mentioned bellow did? > How I see it, currently the only feasible business case to go with SR is if you outgrew your scaling limits with regards to the amount of RSVP state or you plan on deploying a solution that will not scale using "stateful" RSVP. (so in other words only if you have to). Cause clearly if you are looking at SR you already have a valid business case for TE, and in my opinion the only business reason why would one not leverage the years of development and debugging done for RSVP and become a pioneer in SR is if there's an absolute need. If you're using RSVP solely for TE purposes and not to enforce QOS and it's contained within a single AS/IGP-domain then it's fairly easy, and with SR some of the complexity is still there it's just moved around. adam netconsultings.com ::carrier-class solutions for the telecommunications industry:: ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Segment Routing Real World Deployment (was: VPC mc-lag)
Thanks a lot James, that's very nice of you to explain all that to me and the community. I have Cisco and Juniper network. MX960 - (5 nodes) supercore ACX5048 - (~40 nodes) distribution ASR9k - (15 nodes) core ME3600 - (~50 nodes) distribution Aaron > On Jul 5, 2018, at 2:46 AM, James Bensley wrote: > >> On 4 July 2018 at 22:25, Aaron Gould wrote: >> I'm concerned how to go from my LDP environment to SR/SPRING and what if >> some of my gear doesn't support SR/SPRING ? Is this LDP/SR mapping thing >> easy ? >> >> >> Aaron > > Hi Aaron, > > I think you're running Cisco gear too right so hopefully it's OK if I > supply you with a Cisco link? SR has been designed to explicitly > support an LDP to SR migration. To do this you need to use an SR > mapping server and mapping client. In terms of implementation though, > this is as simple as nominating one (or preferably more) of your boxes > that support both LDP and SR to be the mapping server and client. Here > is an IOS-XR example, it's literally a couple of lines of config: > > https://www.cisco.com/c/en/us/td/docs/routers/asr9000/software/segment-routing/configuration/guide/b-seg-routing-cg-asr9k/b-seg-routing-cg-asr9k_chapter_01001.html > > SR mapping nodes that support both LDP and SR will allocate SIDs to > label mappings received from your LDP only nodes and advertise them > through IGP extensions to your SR only nodes. Vice versa they can map > SR to LDP. There is also no problem having SR and LDP running on the > same box, set your SRGB/SRLB appropriate and SR and LDP will allocate > labels in different ranges and not overlap. > > SR has been designed such that if you have a TE-free deployment and > have an LDP set-and-forget type deployment you don't need a controller > to deploy it and a controller-free migration is natively supported. So > risks relating to the SR technology it's self should be minimal. > > Having said all that - I'm not telling you this works perfectly and > without bugs, the usual caveats apply, YMMV etc. It is new code and > not all the drafts are finalised but vendors are implemented them even > though are still subject to change, which we all know comes with > virtually guaranteed issues ;) I'm just saying all this because I've > been reading through all the drafts lately trying to evaluate SR like > everyone else.See this link for more details on LDP to SR migration: > https://tools.ietf.org/html/draft-ietf-spring-segment-routing-ldp-interop-13 > > Cheers, > James. > ___ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Segment Routing Real World Deployment (was: VPC mc-lag)
I really like the simplicity of my ldp-based l2vpn's... eline and elan You just made me realize how that would change if I turned off ldp. So, SR isn't able to signal those l2circuits, and manual vpls instances ? ... I would have to do all that with bgp ? I use bgp in some cases for rfc4762, but not for simple martini l2circuits. My entire cell backhaul environment is based on ldp based pseudowires. -Aaron ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] format of minimum and maximum value of math:random() in SLAX
Michael Loftis writes: >idk if there's a floor function but the general solution is floor(rand() * >16) when rand() produces values 0-1(exclusive) IE if random does not >generate 1.0 - dunno implementation details for slax Yes, XPath has a floor() function that can be used directly in SLAX. https://www.w3.org/TR/1999/REC-xpath-19991116/#section-Number-Functions So you'd say: var $res = floor(rand() * 16); Also see the "number" statement for additional number-formatting options: http://libslax.readthedocs.io/en/latest/content.html#the-number-statement Thanks, Phil ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] format of minimum and maximum value of math:random() in SLAX
Hi! According to the documentation, math:random() function returns a random number with a minimum value of 0 and a maximum value of 1. Larger values than 0 and smaller values than 1 have a format similar to 0.663341003779015. What is the format of minimum and maximum value? Simply 0 and 1? 0.000 and 1.000? The reason I ask is that I use "substring(math:random(), 3, 2) mod 16" for finding random numbers between 0 and 15 and I need to apply a workaround if format is not always x.xxx. thanks, Martin ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] format of minimum and maximum value of math:random() in SLAX
idk if there’s a floor function but the general solution is floor(rand() * 16) when rand() produces values 0-1(exclusive) IE if random does not generate 1.0 - dunno implementation details for slax On Thu, Jul 5, 2018 at 13:43 Martin T wrote: > Hi! > > According to the documentation, math:random() function returns a > random number with a minimum value of 0 and a maximum value of 1. > Larger values than 0 and smaller values than 1 have a format similar > to 0.663341003779015. What is the format of minimum and maximum value? > Simply 0 and 1? 0.000 and 1.000? The reason I > ask is that I use "substring(math:random(), 3, 2) mod 16" for finding > random numbers between 0 and 15 and I need to apply a workaround if > format is not always x.xxx. > > > thanks, > Martin > ___ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp > -- "Genius might be described as a supreme capacity for getting its possessors into trouble of all kinds." -- Samuel Butler ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Segment Routing Real World Deployment (was: VPC mc-lag)
Hello James. Interesting feedback, thank you. //Gustav -Ursprungligt meddelande- Från: juniper-nsp För James Bensley Skickat: den 5 juli 2018 10:15 Till: juniper-nsp@puck.nether.net Ämne: Re: [j-nsp] Segment Routing Real World Deployment (was: VPC mc-lag) On 4 July 2018 at 18:13, Mark Tinka wrote: > > > On 4/Jul/18 18:28, James Bensley wrote: > > Also > > Clarence Filsfils from Cisco lists some of their customers who are > happy to be publicly named as running SR: > > https://www.youtube.com/watch?v=NJxtvNssgA8=youtu.be=11m50s > > > We've been struggling to get vendors to present deployments from their > customers when they submit talks around SR. So the SR talks end up > becoming updates on where SR is from a protocol development > standpoint, recaps for those that are new to SR, e.t.c. > > Perhaps those willing to talk about SR from the vendor community do > not have the in with their customers like folk like Clarence might, but I'm > not sure. > > I'll reach out to Clarence and see if we can get him to talk about > this with one or two of his customers at an upcoming meeting. Hi Mark, If you get any feedback you can publicly share I'm all ears! As far as a greenfield deployment goes I'm fairly convinced that SR would be a good idea now, it would future proof that deployment and for our use case it does actually bring some benefits. To explain further; we don't have one large contiguous AS or IGP, we build regional MPLS networks, each on a private AS (and with a stand alone IGP+LDP) and use Inter-AS services to provide end-to-end services over the core AS network between regional networks. If we built a new regional network tomorrow these are the benefits I see from SR over our existing IGP+LDP design: - Obviously remove LDP which is one less protocol in the network: This means less to configure, less for CoPPs/Lo0 filter, less for inter-op testing as we're mixed vendor, less for operations to support. - Easier to support: Now that labels are transported in the IGP I hope that it would be easier to train support staff and troubleshooting MPLS related issues.They don't need to check LDP is up, they should see the SID for a prefix inside the IGP along with the prefix. No prefix, then no SID, etc. I would ideally move all services into BGP (so no more LDP signaled pseudowires, BGP signaled only service to unify all services as BGP signaled [L3 VPN, L2 VPN VPWS/EVPN/VPLS/etc.]). - Go IPv6 native: If using ISIS as the IGP we should be able to go IPv4 free (untested and I haven't research that much!). - Bring label mapping into the IGP: No microloops during re-convergence as we heavily use IP FRR rLFA. - 100% rFLA coverage: TI-LA covers the "black spots" we currently have. - Remove LACP from the network: SR has some nice ECMP features, I'm not going to start an ECMP vs LAG discussion (war?) but ECMP means we don't need LACP which again is one less protocol for inter-op testing, less to configure, less to support etc.It also keeps our p-t-p links all they same instead of two kinds, p-t-p L3 or LAG bundle (also fewer config templates). - Remove microBFD sessions: In the case of LAGs in the worst case scenario we would have LACP, uBFD, IGP, LDP and BGP running over a set of links between PEs, we can chop that down to just BFD, IGP and BGP with SR. If we wish, we can still have visibility of the ECMP paths or we can use prefix-suppression and hide them (this goes against my IPv6 only item above as I think IS-IS is missing this feature?). The downsides that I know of are; - Need to up-skill staff: For NOC staff it should be easy, use this command "X" to check for prefix/label, this command "Y" to check for label neighborship. For design and senior engineers since we don't use MPLS-TE it shouldn't be difficult, we're typically deploying set-and-forget LDP regional networks so they don't need to know every single detail of SR (he said, naively). - New code: Obviously plenty of bugs exist, in the weekly emails I receive from Cisco and Juniper with the latest bug reports many relate to SR. But again, any established operator should have good testing procedures in place for new hardware and software, this is no different to all those times Sales sold something we don't actually do. We should all be well versed in testing new code and working out when it's low risk enough for us to deploy. Due to our lack of MPLS-TE I see SR as fairly low risk. I'd be very interested to hear yours or anyone else's views on the pros and cons of SR in a greenfield network (I don't really care about brownfield right now because we have no problems in that existing networks that only SR can fix). Cheers, James. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net
