[j-nsp] Limit on interfaces in bundle

[Michael Hare]

Thanks much for the replies, I better understand your dilemma.

Assume your P/PE support RFC 6790, isn't RFC 6790 essentially a superset of RFC 6391?  If you configure RFC 6790 network wide for all LDP FECs [again, we're homogenous], you wouldn't need FAT-PW?

-Michael

> -----Original Message-----
> From: Mark Tinka [mailto:mark.tinka at seacom.mu]
> Sent: Friday, October 30, 2015 11:36 AM
> To: Michael Hare <michael.hare at wisc.edu>; Adam Vitkovsky
> <Adam.Vitkovsky at gamma.co.uk>; Saku Ytti <saku at ytti.fi>
> Cc: juniper-nsp at puck.nether.net
> Subject: Re: [j-nsp] Limit on interfaces in bundle
> 
> 
> 
> On 30/Oct/15 15:49, Michael Hare wrote:
> 
> > I see that 14.1 [we're going there for E-VPN] also supports RFC 6391 and RFC
> 6790, so I probably need to take a closer look.  Anyone have experience with
> either in JunOS yet?  Mark, was it you that was on 14.2 for ingress CoS
> purposes?
> >
> > Sorry if this has been discussed before on list
> >
> >
> https://www.juniper.net/documentation/en_US/junos14.1/topics/reference/con
> figuration-statement/flow-label-transmit-static-edit-protocols-l2circuit.html
> >
> http://www.juniper.net/documentation/en_US/junos14.1/topics/task/configurat
> ion/mpls-entopy-label-configuring.html
> 
> If you're going to Junos 14, I'd suggest 14.2R4.9. It has the new Policy
> Map feature (ingress QoS support for 802.1p, IPP, DSCP and EXP), and
> also fixes the LAG policing issue I described a few months back.
> 
> We have the "Entropy Label for LSP's" feature enabled on our Juniper
> routing devices. This mostly helps for upstream routers that can
> understand this capability. However, be careful if you're running IOS XR
> 5.3.0 on a Cisco router deploying RSVP with a Juniper box running this
> feature. The signaling of this capability was broken by Cisco when they
> got to 5.3.0, which breaks the RSVP session; but this was fixed in IOS
> XR 5.3.1 and later.
> 
> We have not yet enabled FAT-PW because our issue was downstream of the
> MX boxes, not upstream into the core. We are more likely to move to
> 100Gbps faster on the core-facing links compared to the downstream
> links, so FAT-PW is not as critical there. However, we are looking into
> it and have not yet made the decision whether to go 100Gbps or FAT-PW
> for the particular data centre in question.
> 
> FAT-PW would not help in the case where we went with per-packet sprays
> as the downstreams switches are pure Layer 2 devices.
> 
> Mark.