Up until I believe Junos 11.4, Junos did not use the GMPLS IGP extensions to distribute SRLG information. All of the SRLG information was statically configured via the routing-options->fate-sharing configuration. The entire database is generally configured on every node if you are using link or link-node protection, but if you are using active/standby LSPs you could get away with only confuring it on the head-end nodes. However I think it is only consulted when computing the ERO to the ASBR, not after it say received the RESV RRO, so it is probably not much help.
I don't think using the IGP method will work either, I doubt the ABR node will take into account any SRLG information from the primary LSP path since there is nothing which tells it the standby LSP is actually a standby LSP, it doesn't contain the state of the first path to tell it to compare the second path to. The original plan to do inter-area RSVP LSPs with the ability to use completely diverse paths was to add an "exclude" object to the Path setup message along with the already defined "include" so each node along the line would know which links were to be excluded. I don't think that ever made it into Junos though... On another platform we use MS-PW for P2P L2VPN because it scaled much higher than RSVP inter-area LSPs, and our very edge nodes did not support LDPoRSVP or BGP-LU. For redundancy it requires stitching the service at potentially four total nodes but you can do 10s of thousands of those. I would use the same method for multipoint and point-to-point, there is no difference between the two except another endpoint. Phil On 5/20/12 4:36 AM, "Łukasz Dudziński" <luk...@dudzinscy.org> wrote: >Hi, > >I didn't know that option before. It seems, it can be very useful in >hierarchic networks. It's a pity that it is poor documented. But it >should be possible to use SRLG since ERO extension is calculated by the >ABR and the ABR has access to TED in both areas. Please, share your lab >results. > >Lukasz > >On 2012-05-20 08:10, Caillin Bathern wrote: >> Hi Lukasz, >> >> Thanks for your response. >> >> I agree that the TED is restricted to an ospf area for CSPF calculation >>however using the expand-loose-hop option on the ABRs should enable a >>cspf LSP to be set up to the remote area assuming that the ABRs are >>loose hops. The problem I am having is I am not yet sure if the CSPF >>conditions (admin groups, SRLGs, etc) will be applied when that >>loose-hop expansion (cspf calculation by the ABR to reach the next ABR) >>is made by the ABR. >> >> BGP-LU and the use of NHS attribute for scaling beyond a single area >>are definitely in play for multi-point VPNs however for any >>point-to-point L2VPNs we feel it would be much easier to generate an >>end-to-end dynamic LSP instead. >> >> I am hoping to try this in the lab soon but I was hoping for any >>insight list members might have for this. >> >> Cheers, >> Caillin >> >> -----Original Message----- >> From: juniper-nsp-boun...@puck.nether.net >>[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Lukasz >>Dudzinski >> Sent: Sunday, 20 May 2012 7:22 AM >> To: juniper-nsp@puck.nether.net >> Subject: Re: [j-nsp] SRLGs in Inter-Area LSPs >> >> Hi, >> >> I do not have an experience in multi-area MPLS techniques, so I'm not >>able to help you too much in that matter. But I'm sure that typically >>MPLS Traffic Engineering is restricted to single area of IGP protocol. >> If I understood your mail correctly you try to create a CSPF-based RSVP >>LSP between different IGP areas, which is not possible "just like that". >> That is because MPLS TE relies on IGP TE database, which (like the link >>state database) is restricted to single IGP area. TE-DB is an extension >>of link state DB. Such information like Admin Groups, SRLG membership or >>BW reservation are stored in TE database. If size of your network force >>you to use IGP hierarchy I suggest you to take a look on such things >>like LDP-over-RSVP, Seamless MPLS or BGP Labelled Unicast. >> >> Lukasz >> >> >> On 2012-05-18 09:17, Caillin Bathern wrote: >>> Hi All, >>> >>> >>> >>> I posted this to the J-Net forums but no luck. >>> >>> >>> >>> Just wondering if SRLGs are carried through between IGP areas, both >>> for OSPF and for IS-IS? >>> >>> >>> >>> The scenario for this would be passing a cspf routed RSVP LSP from PE1 >>> in Area 1 through to PE2 in Area 2. We would maintain a secondary >>> standby LSP path for this traffic with exclude-srlg enabled. >>> >>> Assuming that the primary path takes the IGP routed path PE1 - ABR1 - >>> ABR3 - PE2 then the secondary path will take the path PE1 - ABR2 - >>> where? >>> >>> If SRLGs are carried through by the IGP then then the path should go >>> PE1 >>> - ABR2 - ABR4 - PE2, however if the SRLGs are not carried through then >>> the IGP could in make the secondary path PE1 - ABR2 - ABR3 - PE2 which >>> obviously is not a great standby secondary path... >>> >>> >>> >>> /--- ABR1 ---| |--- ABR3 ---\ >>> >>> PE1 (Area1) | Area 0 | (Area2) PE2 >>> >>> \--- ABR2 ---| |--- ABR4 ---/ >>> >>> >>> >>> >>> >>> If anybody knows this scenario and can shed some insight it would be >>> greatly appreciated. >>> >>> Cheers, >>> >>> Caillin >>> >>> >>> >>> _______________________________________________ >>> 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 >> -- >> Message protected by MailGuard: e-mail anti-virus, anti-spam and >>content filtering.http://www.mailguard.com.au/mg >> > >_______________________________________________ >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
