[c-nsp] IS-IS as PE-CE protocol

[James Bensley]

On Thu, 21 Mar 2019 at 02:31, Victor Sudakov <vas at mpeks.tomsk.su> wrote:
>
> Dear Colleagues,
>
> OSPF as a PE-CE protocol has some useful features: the "DN bit" for loop
> prevention and sham links for route optimization.
>
> Does IS-IS have similar features?

Hi Victor,

Someone has already mentioned that IS-IS has a similar feature.
Assuming your PE is a L1/L2 IS and the CE is a L1 IS the PE will set
the Down bit on all LSPs it originates to the L1 CE device. If the CE
reflects any of those routes back to the PE it will ignore them
because of the Down bit. Equally LSPs originated by the CE will have
the UP bit sit.

You can't disable the setting of the UP bit on Junos/IOS/IOS-XR.
Redistribution from L2 into L1 isn't enabled by default (this is
called "Route Leaking" in ISIS terminology). See my comments below,
you have to explicitly redistribute/leak routes between areas, and
then they'll have the Down bit set.


> Mark Tinka wrote:
> > A protocol designed to speak between 2 different autonomous systems.
> >
> > If that is not an option, not using a routing protocol is also a good
> > idea, i.e., static routing.

Same here: every ISP I've ever worked at, we offer eBGP or static
routing. OSPF has only been for exceptional cases (e.g. the remote
device simple didn't support BGP). See next comment...


On Thu, 21 Mar 2019 at 15:00, <adamv0025 at netconsultings.com> wrote:
> > So, in the case of BGP as PE-CE
> > protocol and a small client AS, do you all in the provider space require
> > multiple private ASNs per VPN?
> >
> That's one of the options.
> The other is to use the same private as on all your sites connected to the
> L3VPN -we'd then do as-override on our end to allow routes to propagate
> end-to-end.

This ^. If you use the same AS number for every CPE of a L3 VPN then
we'd use as-override on the PE side and a SoO value. Another tactic
(personally less preferred) is to use a unique AS number per CP, this
works fine and scales, there are thousands of private AS numbers but
it's just another think you have to keep track of.



On Thu, 21 Mar 2019 at 15:46, Victor Sudakov <vas at mpeks.tomsk.su> wrote:
> Well, the Internet is full of examples and recommendations of an IGP
> (most often OSPF) being used between PE and CE, so it must be common
> practice. In fact, OSPF even has special enhancements for this very
> purpose.

Right, lots of examples doesn't make it "right" or "good" though.
Design choices are always tough. Off the top of my head, here's a
bunch of reasons why we don't use protocols considered as IGP
protocols (OSPF, IS-IS, EGIRP, RIPng) for PE-CE connections:

BGP has many features specifically for the PE-CE use case and/or
vendors have made certain features standard within their BGP
functionality. OSPF and ISIS have had features added on over the years
to provide the same functionality tha was already in BGP, e.g.

- prefix filters and maximum prefix limits (some vendors implement
these features for IGPs but not all vendors and not all protocols,
virtually all vendors have these features in BGP)
- traffic engineering with MED, Local-Pref and AS prepends (instead of
just "metric")
- Loop prevention ( admittedly, exits in OSPF and ISIS too)
- Authentication ( admittedly, exits in OSPF and ISIS too)
- Timers (defaults to higher values)
- Scalability (many vendor implementations don't allow multiple ISIS
or OSPF processes to run, so your customers flapping is impacting that
same ISIS process as your core, also features like route flap
dampening)
- Redistribution (in my experience it's much harder to create a
redistribution loop using purely BGP compared to a mix of OSPF and BGP
unless you create some crazy config, also by using BGP between CE and
PE, when we redistribute into a L3 VPN which is BGP signalled we don't
loose the AS path, community values, local pref etc. which is all lost
information when using OSPF/ISIS for PE-CE)

IGP protocols have a bunch of features for tuning them to support
rapid reconvergence which BGP isn't best suited for. Every time a
customer link flaps OSPF will run a full SFP because IP prefixes are
tied to LSAs, unlike ISIS which uses TVLs to  disassociate IP
connectivity from topology.

There are more reasons but I'm out of time, I think I'm going to have
to make a list!


On Fri, 22 Mar 2019 at 03:40, Victor Sudakov <vas at mpeks.tomsk.su> wrote:
>
> Robert Raszuk wrote:
> > Hi Victor,
> >
> > ISIS has analogy to OSPF down bit integrated if this was your question.
>
> Hopefully it is.
>
> > But
> > do check with your implementation to make sure if it supports ISIS leaking.
> >
> > PE-CE ISIS is inheriting loop prevention which was defined for ISIS route
> > leaking between levels in RFC2966
>
> Looks like it. Thank you for the hint!
> >
> > " This document redefines this high-order bit in the default metric
> >
> >    field in TLVs 128 and 130 to be the up/down bit."
>
> What would be the Cisco command to enable/disable this feature in IS-IS ?
> That would be the easiest way to check if the implementation supports it.

If wide metrics are used then TLV 128 (the narrow metric Internal IP
Reachability TLV) and TLV 130 (the narrow metric External IP
Reachability TLV) are both replaced with TLV 135 the Extended IP
Reachability TLV for L1 and L2 routes. TLV 135 has a 32 bit metric
field however, there is no differentiation between internal and
external routes now that the same TLV is sent for both route types.
Also TLV 2, the narrow 6 bit metic IS Reachability TLV is replaced
with TLV 22 the Extended IS Reachability with 24 bit metric field. So
route leaking and extended metrics can be confusing to troubleshoot.
The command I think you're looking for on IOS:

redistribute isis ip { level-1 | level-2 } into { level-2 | level-1 }
[ [ distribute-list list-number ] | [ route-map map-tag ] ]

Use at your own peril.


Cheers,
James.