Re: [c-nsp] Unicast as Anycast
Hi, On Tue, Nov 26, 2013 at 02:49:56AM +0100, JJ wrote: It´s strange to me that carriers like Cogent, Level3... are saying something like what are you talking about?. Cogent = you get what you pay for. You pay almost nothing, so what do you expect? Level(3) = well, we're too big to fail, who needs customers anyway. Both are not exactly examples of upstreams we'd be happy to buy from (so we don't). gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025g...@net.informatik.tu-muenchen.de pgpwVoOZVW0WQ.pgp Description: PGP signature ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] MPLS-TP on CPT platform vs IP/MPLS core on ASR with TE
Hi On Tue, Nov 26, 2013 at 04:52:49AM +0200, Mark Tinka wrote: Our side is also not standing still - the vendors have been plugging DWDM ports into routers for a while now. The model hasn't been successful (you can see how IPoDWDM was a total disaster), Care to go into more detail here? If we're talking about the same thing, I think it's a great idea, and the only problem is that vendors charging extra for using it (and thus, many people are not using it even if their hardware could)... gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025g...@net.informatik.tu-muenchen.de pgpyy7Ja_GG4i.pgp Description: PGP signature ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Partitioned-MDT MP2MP with BGP-AD/mLDP in XR 4.3
Hi Jason, I'd love to see the working config as the Partitioned-MDT MP2MP with BGP-AD/mLDP is what I plan to roll out once me3600 will support that as well. I don't understand how come pim rpf topol is not the attach point for c-multicast-routing command where else would I use a policy-map with this parameter? And regarding the mdt default mldp ipv4 Thinking about it again the mp2mp LSP for the default tree can be build towards any PE(s) if it'll be mp2mp it has the same effect as if there was a central point(s). adam -Original Message- From: Jason Lixfeld [mailto:ja...@lixfeld.ca] Sent: Monday, November 25, 2013 4:12 PM To: Adam Vitkovsky Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Partitioned-MDT MP2MP with BGP-AD/mLDP in XR 4.3 Hi Adam, I saw the same slide deck. I based some of my configs off of it initially. I tried those two options previously and neither passed the commit. There seems to be so much conflicting information on what's supported in what mode and what's not that I can't really get a firm grasp. My brain doesn't absorb all the info in the RFCs well enough to really be able to determine what's what either. I've reached out to TAC and my SE anyway, but I thought I'd check here to see what's going on in the real world. In any event, here are the errors associated with both commands: RP/0/RSP0/CPU0:bfr01.905KingStW01.YYZ(config)#show configuration failed Mon Nov 25 09:21:40.899 EST !! SEMANTIC ERRORS: This configuration was rejected by !! the system due to semantic errors. The individual !! errors with each failed configuration command can be !! found below. ! route-policy MLDP-TV set core-tree mldp-partitioned-p2mp set c-multicast-routing bgp end-policy ! !!% Policy [MLDP-TV] uses the 'c-multicast-routing' attribute. There is no 'c-multicast-routing' attribute at the pim rpf-topology attach point. end .. RP/0/RSP0/CPU0:bfr01.905KingStW01.YYZ(config)#show configuration failed Mon Nov 25 09:22:57.235 EST !! SEMANTIC ERRORS: This configuration was rejected by !! the system due to semantic errors. The individual !! errors with each failed configuration command can be !! found below. multicast-routing vrf tv address-family ipv4 mdt default mldp ipv4 172.16.0.32 !!% Invalid MLDP MDT type: MDT Default MLDP (Rosen MLDP) cannot co-exist with In-Band MLDP, Partitioned MDT MLDP, or MDT Default MLDP P2MP ! ! ! end On Nov 25, 2013, at 4:22 AM, Adam Vitkovsky adam.vitkov...@swan.sk wrote: Hi Jason, Just shooting in the dark, I'd try adding these: route-policy MLDP-TV set c-multicast-routing bgp multicast-routing vrf tv address-family ipv4 interface TenGigE0/0/0/15 enable ! mdt default mldp ipv4 x.x.x.x mdt data 100 I find this presentation useful: NG (Next Gen) MVPN Webinar -I have found it on slideshare, it has 90 slides. adam -Original Message- From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Jason Lixfeld Sent: Friday, November 22, 2013 8:35 PM To: cisco-nsp@puck.nether.net Subject: [c-nsp] Partitioned-MDT MP2MP with BGP-AD/mLDP in XR 4.3 Hi all, I've been working on trying to get LSM working between a couple of A9Ks to support a SSM based IPTV application. After ingesting a bunch of content on the subject, I think what I want is Partitioned MDT, MP2MP with BGP-AD/mLDP (PIM-free core). I'm wondering if anyone has any links to working configuration examples for this type of MVPN or some good troubleshooting guides for this type of MVPN specifically. The XR 4.3 configuration guide seems to provide either a broken or an incomplete example, so what I've managed to work out from it, doesn't seem to work. By 'doesn't seem to work', I mean I have a SSM based join-group configured on a CE with a PIM adjacency to XR PE1. XR PE1 sees the (S,G) from the CE, but the adjacent XR PE2 (config below) doesn't see it. Thanks in advance for any pointers. ! interface Loopback0 ipv4 address 72.15.48.4 255.255.255.255 ! interface Loopback2022 vrf tv ipv4 address 172.16.0.32 255.255.255.255 ! interface TenGigE0/0/0/15 description Facing Source vrf tv ipv4 address 172.16.1.1 255.255.255.0 ! interface TenGigE0/0/0/0 description Facing Core cdp mtu 9216 ipv4 address 72.15.49.80 255.255.255.254 carrier-delay up 0 down 0 dampening ! router bgp 21949 address-family ipv4 unicast ! address-family vpnv4 unicast ! address-family ipv4 mvpn ! neighbor-group P-MVPN remote-as 21949 update-source Loopback0 address-family vpnv4 unicast ! address-family vpnv6 unicast ! address-family ipv4 mvpn ! neighbor 72.15.48.10 use neighbor-group P-MVPN ! vrf tv rd 21949:2022 address-family ipv4 unicast redistribute connected route-policy SOURCE--INTERNAL-CONNECTED redistribute static route-policy SOURCE--INTERNAL-STATIC ! address-family ipv4 mvpn ! ! ! multicast-routing address-family ipv4 interface
Re: [c-nsp] MPLS-TP on CPT platform vs IP/MPLS core on ASR with TE
Our side is also not standing still - the vendors have been plugging DWDM ports into routers for a while now. The model hasn't been successful (you can see how IPoDWDM was a total disaster), Care to go into more detail here? If we're talking about the same thing, I think it's a great idea, and the only problem is that vendors charging extra for using it (and thus, many people are not using it even if their hardware could)... What do you folks mean by IPoDWDM? I always think of G.709 (OUT; ODU type of framing). I don't really think of it as OTN or GMPLS aka multiprotocol lambda switching where PEs or PCEs provisions the optical switches/ optical path end to end. adam ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] %BGP-6-MSGDUMP_LIMIT: unsupported or mal-formatted message
Hello,
if I set the maxas-limit, whenever the router receives a longer path, it
complains:
020250: Nov 26 12:09:52: %BGP-6-MSGDUMP_LIMIT: unsupported or
mal-formatted message received from xx.xx.xxx.243:
007A 0200 1C18 67F5 0C16 C773
C412 2966
4011 2966 8016 67F0 E812 2965 C018 C03A E800 4340 0101 0040 022E 020B
0CC5
1A6A 00D1 02D1 69B8 179D 6A02 6A02
6A02
6A02 69AB 4003 043E 5676 F3C0 0804 1A6A 001F 18D6 068F
platform: Cisco 7204VXR (NPE-G2) processor (revision A) with
1966080K/65536K bytes of memory
ios: c7200p-spservicesk9-mz.152-4.S4.bin
It doesn't seem harmful, I mean no session reset or flap.
Anyone else is experiencing the same?
thank you
--
antonio
___
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] MPLS-TP on CPT platform vs IP/MPLS core on ASR with TE
Hi Yham, Maybe the following URLs can be helpful: http://www.cisco.com/en/US/technologies/tk436/tk428/white_paper_c11-562013.html https://www.dfn.de/fileadmin/3Beratung/DFN-Forum2/118.pdf http://www.ecitele.com/CampaignDocuments/MPLS-TP-IP-MPLS.pdf MPLS-TP is more an alternative for network access; its main purpose is to compete with Metro Ethernet technologies. Alberto -Original Message- From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Yham Sent: November-25-13 6:33 PM To: cisco-nsp@puck.nether.net NSP; juniper-...@puck.nether.net List Subject: [c-nsp] MPLS-TP on CPT platform vs IP/MPLS core on ASR with TE Hi Guys, If a provider already have ciena as transport with ip/mpls core on cisco ASR, why would they want to deploy CPT with mpls-tp? Can we compare mpls-te vs mpls-tp or is this comparison of apples and oranges? I am new to mpls-tp and trying to understand in which area mpls-tp really help. it is said that mpls-tp has better oam features, its ipless but whats wrong if i have ip/mpls core, i have TE that provide all redundancy, can configure diverse paths, reserve bandwidth, all maintenance features like local repair. I will be thankful if you share your thoughts Regards ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] 7600 and NAT in vrf
Any chance some of you have further insight on this issue? Still not having any luck. Thanks, db On Nov 22, 2013, at 11:52 AM, Peter Persson wrote: Just curios... Why are you using a 6500 firm for a 7600? 2013/11/22 Dan Benson dben...@swingpad.com All, From reading it seems the 7600 does not support NAT in vrf (without an FWSM) but I thought I would ask the question. I have two interfaces in the same VRF (inside and outside) and I am able to static translate inbound but I am unable to overload with TCP and udp packets. ICMP packets traverse the interfaces but nothing else. Will this work if I don’t have the VRF? I am running s72033-adventerprisek9-mz.151-1.SY.bin. Thanks in advance for your insight. db ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] %BGP-6-MSGDUMP_LIMIT: unsupported or mal-formatted message
On (2013-11-26 12:16 +0100), Antonio Prado wrote: if I set the maxas-limit, whenever the router receives a longer path, it complains: 020250: Nov 26 12:09:52: %BGP-6-MSGDUMP_LIMIT: unsupported or mal-formatted message received from xx.xx.xxx.243: I'm guessing this might happen because max-prefix bites while packet is being received. So remaining packet is incomplete and thus invalid. I'm not 100% sure about this, but if you put that hexdump through 'text2pcap', I'm betting it won't be recognized as BGP until you fix the 'size' bytes. Interestingly, I don't believe this behaviour could be seen in IOS-XR or JunOS or such, since it's quite untypical for userland process to start processing packet before it's received. But IOS specifically has dedicated TCP/IP implementation for BGP and another implementation for rest of the system. -- ++ytti ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] ASR 9K nV
Hi, We want to implement nV Clustering functionality for two ASR 9k`s. Any pros and cons? We meet all the requirements (line cards,etc...) and we do not need CGNfeature. Any information will be useful ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] ASR 9K nV
Hello Jure, With Cisco ASR 9000 Series nV Edge you can double the bandwidth capacity of single nodes and eliminate the need for complex protocol-based high-availability schemes. Hence, you can achieve failover times of less than 50 milliseconds for even the most demanding services and scalability needs. · Increase node capacity by clustering physical chassis together · Single control and management plane, without introducing operational complexity · Super network resiliency, capacity, GE density, Simple operation and single software feature set · Single control plane, single management plane, fully distributed data plane across multiple* physical chassis -- one virtual nV system the white paper: http://www.cisco.com/en/US/solutions/collateral/ns341/ns524/ns562/ns592/asr_nv_100611.pdf For any questions on ASR 9K you can reach Cisco PDI Help Desk http://www.cisco.com/go/pdihelpdesk This is a free service avilable to Cisco partners and service providers. Best regards, -Sarala -Original Message- From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of jure brkljacic Sent: Tuesday, November 26, 2013 12:47 PM To: cisco-nsp@puck.nether.net Subject: [c-nsp] ASR 9K nV Hi, We want to implement nV Clustering functionality for two ASR 9k`s. Any pros and cons? We meet all the requirements (line cards,etc...) and we do not need CGNfeature. Any information will be useful ___ cisco-nsp mailing list cisco-nsp@puck.nether.netmailto:cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] 7600 and NAT in vrf
The question is will basic NAT overload work without VRFs on SX code? Yes, given the endless list of 6k NAT limitations. On Fri, Nov 22, 2013 at 10:37 AM, Dan Benson dben...@swingpad.com wrote: All, From reading it seems the 7600 does not support NAT in vrf (without an FWSM) but I thought I would ask the question. I have two interfaces in the same VRF (inside and outside) and I am able to static translate inbound but I am unable to overload with TCP and udp packets. ICMP packets traverse the interfaces but nothing else. Will this work if I don’t have the VRF? I am running s72033-adventerprisek9-mz.151-1.SY.bin. Thanks in advance for your insight. db ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Unicast as Anycast
On Tuesday, November 26, 2013 03:49:56 AM JJ wrote: It´s strange to me that carriers like Cogent, Level3... are saying something like what are you talking about?. With large ISP's, it's hard to find consistent clue. But there is clue, depending on where connect to, and how diligent your account manager is. Mark. signature.asc Description: This is a digitally signed message part. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] EIGRP reality check
On Monday, November 25, 2013 04:55:08 AM Jeff Kell wrote: We have been using EIGRP in the most recent generation of our campus network, a choice that was largely made on the fact that it could load-share across equal-cost paths, and take the path of least resistance to the target. I'm guessing you meant unequal cost :-). Have you seen this: http://www.cisco.com/en/US/docs/routers/crs/software/crs_r4.3/routing/configuration/guide/b_routing_cg43xcrs_chapter_0101.html#concept_6F7168EEB2D343CCBA82BB223B311E7B I haven't tried it, so don't know if it actually does what it says on the tin. Anyone? Oli? Mark. signature.asc Description: This is a digitally signed message part. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] MPLS-TP on CPT platform vs IP/MPLS core on ASR with TE
On Tuesday, November 26, 2013 10:37:29 AM Gert Doering wrote: If we're talking about the same thing, I think it's a great idea, and the only problem is that vendors charging extra for using it (and thus, many people are not using it even if their hardware could)... IPoDWDM's issues were less about its technology: - Several DWDM vendors didn't (and hardly, today,) support alien wavelengths. Those that did supported it only for the line side, so port density was poor. - IPoDWDM only made sense if you owned both the Transmission and IP networks. Trying to lease a colored wave from a telco doesn't generally go down well, in most parts. - There is a real concern when IP and Optical teams need to give up their network to one another. GMPLS visibility into either domain was meant to solve this, but people are protective of their jobs. This is all coming back now under the SDN (yuck!) guise, so we'll see. Cisco are pushing this hard on the NCS, as are Juniper on the PTX (particularly after all the work Juniper and Adva have done in incorporating optics on their router). Mark. signature.asc Description: This is a digitally signed message part. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] MPLS-TP on CPT platform vs IP/MPLS core on ASR with TE
On Tuesday, November 26, 2013 12:16:38 PM Adam Vitkovsky wrote: What do you folks mean by IPoDWDM? I always think of G.709 (OUT; ODU type of framing). Yes, that one. Basically, moving the ROADM functionality out of the optical domain and into the router line card. One of the best applications for me, for this, would be visibility into the fibre, and proactive failover when a certain fibre error-rate is reached, prior to complete service failure. I don't really think of it as OTN or GMPLS aka multiprotocol lambda switching where PEs or PCEs provisions the optical switches/ optical path end to end. SDN will polish your nails also :-). Mark. signature.asc Description: This is a digitally signed message part. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] MPLS-TP on CPT platform vs IP/MPLS core on ASR with TE
On Tuesday, November 26, 2013 03:28:56 PM Alberto Cruz wrote: MPLS-TP is more an alternative for network access; its main purpose is to compete with Metro Ethernet technologies. That's what they'll have you believe. Personally, I say it's main purpose is for the ITU to save face. Ethernet is Ethernet, whether it's being driven by vanilla MPLS, MPLS-TE or DWDM. Mark. signature.asc Description: This is a digitally signed message part. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] EIGRP reality check
Actually, I would have entertained equal cost even without the unequal variance options, but the latter would be even better. To answer some other questions others have asked... back to the original diagram... +--A-\ | | \ | B---D | | / +--C-/ These are layer-2 paths. We have a rather unusual network topology that would take too long to explain without sounding like a raving lunatic :) Which still may be the case, but doesn't help :) There are three layer-3 backbone rings in play here... A-B-C-D is on one common /22 subnet. B-D-others are on another. And C-D-others are on a third. From the perspective of D there are three paths to B, each one layer-3 hop away (same /22 subnet). Each of the three somehow works out to equivalent EIGRP paths in topology... despite A-D and B-D being 10G and D-C and C-A being gigabit channels. This I suspect is due to not using wide EIGRP metrics. These are all Catalysts (6500 at A, various 3750 models at B-C-D) so nothing new and bleeding edge here. Jeff On 11/26/2013 10:10 PM, Mark Tinka wrote: On Monday, November 25, 2013 04:55:08 AM Jeff Kell wrote: We have been using EIGRP in the most recent generation of our campus network, a choice that was largely made on the fact that it could load-share across equal-cost paths, and take the path of least resistance to the target. I'm guessing you meant unequal cost :-). Have you seen this: http://www.cisco.com/en/US/docs/routers/crs/software/crs_r4.3/routing/configuration/guide/b_routing_cg43xcrs_chapter_0101.html#concept_6F7168EEB2D343CCBA82BB223B311E7B I haven't tried it, so don't know if it actually does what it says on the tin. Anyone? Oli? Mark. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] %BGP-6-MSGDUMP_LIMIT: unsupported or mal-formatted message
On Tuesday, November 26, 2013 10:11:20 PM Saku Ytti wrote: Interestingly, I don't believe this behaviour could be seen in IOS-XR or JunOS or such, since it's quite untypical for userland process to start processing packet before it's received. But IOS specifically has dedicated TCP/IP implementation for BGP and another implementation for rest of the system. While we're on the subject: tinka@hmmh# run show route 193.105.15.0 inet.0: 466528 destinations, 467107 routes (466496 active, 31 holddown, 1 hidden) Restart Complete + = Active Route, - = Last Active, * = Both 193.105.15.0/24*[BGP/170] 4d 21:28:09, MED 90, localpref 110 AS path: 3257 50404 50404 50404 50404 50404 50404 50404 50404 50404 50404 50404 50404 50404 50404 50404 50404 50404 50404 50404 50404 50404 50404 50404 50404 50404 50404 50404 50404 50404 50404 50404 50404 50404 50404 50404 50404 50404 50404 50404 50404 50404 50404 50404 50404 50404 50404 50404 50404 50404 50404 50404 50404 50404 50404 50404 50404 50404 50404 50404 50404 50404 50404 50404 50404 50404 50404 50404 50404 50404 50404 50404 50404 50404 50404 50404 50404 50404 50404 50404 50404 50404 50404 50404 50404 50404 50404 50404 50404 50404 50404 50404 50404 50404 50404 50404 50404 50404 50404 50404 50404 50404 I to a.b.c.d via xe-0/0/2.0 [edit] tinka@hmmh# Reeks of Mikrotik to me. Mark. signature.asc Description: This is a digitally signed message part. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] ASR 9K nV
On Tuesday, November 26, 2013 11:17:35 PM Sarala Akella (sakella) wrote: With Cisco ASR 9000 Series nV Edge you can double the bandwidth capacity of single nodes and eliminate the need for complex protocol-based high-availability schemes. You mean like IS-IS, OSPF, (r)LFA and IP :-)? Mark. signature.asc Description: This is a digitally signed message part. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] EIGRP reality check
On Wednesday, November 27, 2013 05:21:45 AM Jeff Kell wrote: These are all Catalysts (6500 at A, various 3750 models at B-C-D) so nothing new and bleeding edge here. I'll admit my EIGRP skills here suck a little; well, a lot, sorry :-). Maybe Gert or other Cisco EIGRP experts lurking can help. Mark. signature.asc Description: This is a digitally signed message part. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] MPLS-TP on CPT platform vs IP/MPLS core on ASR with TE
On Tuesday, November 26, 2013 10:37:29 AM Gert Doering wrote: If we're talking about the same thing, I think it's a great idea, and the only problem is that vendors charging extra for using it (and thus, many people are not using it even if their hardware could)... IPoDWDM's issues were less about its technology: - Several DWDM vendors didn't (and hardly, today,) support alien wavelengths. Those that did supported it only for the line side, so port density was poor. - IPoDWDM only made sense if you owned both the Transmission and IP networks. Trying to lease a colored wave from a telco doesn't generally go down well, in most parts. - There is a real concern when IP and Optical teams need to give up their network to one another. GMPLS visibility into either domain was meant to solve this, but people are protective of their jobs. This is all coming back now under the SDN (yuck!) guise, so we'll see. Cisco are pushing this hard on the NCS, as are Juniper on the PTX (particularly after all the work Juniper and Adva have done in incorporating optics on their router). Mark. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
