[c-nsp] Segment Routing (SR)

[Saku Ytti]

On (2013-08-12 14:38 +0200), Adam Vitkovsky wrote:

Hi Adam,

> What would be the drawbacks of using SPF/linkstate-based BGP for label
> propagation instead of ISIS or OSPF as IGP&LDP? 

I see no reason why it wouldn't work, however your iBGP sessions would be
unlabeled and routed natively. I personally prefer everything to be labeled
in my network.
 IGP is also always needed in SP network, but core in many instances can be
BGP free, if BGP is used for labels, you'll always need also BGP.

Philosophically speaking SR isn't about IGP, it's not even about labels,
it's abstract architecture supporting arbitrary control-plane (does not
need to be IGP) and arbitrary-forwarding plane (does not need to be MPLS).
 What actually gets implemented seems less than perfectly clear, and
certainly pure BGP environment could be viable technology, maybe in
use-case like draft-lapukhov-bgp-routing-large-dc

> But as soon as you start to migrate your access areas into MPLS, ISIS might
> start to get stuffed with high number of prefixes that it's not designed to
> cope with, so you might need to involve the RFC3017 based Unified/Seamless
> MPLS. 

This is certainly something that will be solved. Lot of people are
migrating legacy LAN metro networks into MPLS-to-the-edge and there you
have plenty of options what to do:

1) flat L2 - bit scary
2) metros as L1 - bit less scary
3) BGP border, RFC3107, BGP-LS, OptC? - I think I'd prefer this

> Also from the perspective of inter-AS MPLS backbones based on RFC3017 -these
> networks can only leverage SR within the single AS. 

BGP-LS could potentially give you full SR view in both islands without
IGP/LDP, and would retain the MPLS-TE capabilities between the islands.

> But still the end to end LSP would have to be built using a combination of
> SR & RFC3017. 

I can see potential benefits between separating the metro islands from core
with BGP-LS you might be able to aggregate/condense information and reduce
signalling. But I can see your POV completely.

-- 
  ++ytti