[j-nsp] Limit on interfaces in bundle

[Mark Tinka]

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/configuration-statement/flow-label-transmit-static-edit-protocols-l2circuit.html
> http://www.juniper.net/documentation/en_US/junos14.1/topics/task/configuration/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.