SRTE Traffic-Engineering SR-Policy candidate-path with example configuration

13.04 2020 | by massimiliano

---

SRTE Traffic-Engineering I vantaggi del Segment Routing per il Traffic Engineering sono diversi e riassunti in questa tabella: SRTE RSVP-TE […]

https://www.ingegnerianetworking.com/wp-content/uploads/2020/04/srte-steering-policy-14a.png

SRTE Traffic-Engineering

I vantaggi del Segment Routing per il Traffic Engineering sono diversi e riassunti in questa tabella:

SRTE	RSVP-TE
No Core State: state in the packet header	Core State in k x n^2
No Tunnel Interface: SR Policy	Tunnel Interface
Multi-Domain: SR PCE for compute path and BSID (Binding-SID) for scale	NO Inter-Domain (not scalable)
No head-end a priori configuration: on-demand policy instantiation
No head-end a priori steering: automated steering	complex steering with PBR, autoreroute
Designed to manage a lots of functionality

SR Policy Identification:

Una SR Policy è unicamente identificata da tre valori:

headend: dove la policy è implementata e inizializzata

color: un valore numerico che differenzia multiple SRTE Policies tra la stessa coppia di node

end-point: dove la SR policy termina (destination policy)

Una SR Policy in un nodo headend è configurata come:

policy < name-policy >

     color < number-color > end-point ipv4 < ip_address >   

Le regole dicono:

ogni SR Policy ha un colore che determina uno specifico trattamento

solo una SR Policy con un dato colore può esistere tra una coppia di nodi tra headend ed end-point (in pratica la policy è unica)

SR Policy Candidate Path:

Una SR Policy consiste di uno o più percorsi possibili chiamati CPATHS (Candidate Paths)

Quindi:

una SR Policy instanzia un singolo percorso nella RIB/FIB di un headend node

Un candidate path può essere di tipo dinamico oppure esplicito

Un candidate path è un singolo segment-list (SID-list) oppure un set di SID-list pesati (in genere una SR Policy contiene una singola SID-list)

DYNAMIC PATH:

Un percorso dinamico è espressione di una ottimizzazione del risultato finale con un set di vincoli

Un headend node calcola (computes) il miglior percorso possibile basandosi sulle informazioni di SID-list oppure attraverso un set di SID-list (SID = Segment ID)

Quando un headend node non ha abbastanza informazioni riguardo la topologia di rete link-state (ad esempio in un contesto multi-domain), è possibile delegare il calcolo del path migliore  ad un controller esterno conosciuto come PCE (Path Computation Element)

Qualora ci fossero dei change di rete, il path viene ricalcolato

Optimization Objective significa la possibilità di calcolare un path LSP-TE basato su determinati vincoli o constraints attraverso un algoritmo nativo.

SR-Native algorithm è stato sviluppato per provvedere a questa soluzione che fa leva su ECMP-aware viceversa ad esempio dalla computazione tradizionale di un LSP su base circuito (L2 ATM/FR/ETH) over IP mediante RSVP-TE (la possibilità in un sistema tradizionale di avere un load-sharing è quello di avere multipli circuiti o links)

Nella realtà pratica è sempre preferibile l’impiego del SR-Native algorithms, a parte alcuni casi in cui avere un calcolo del path basato a circuito dove presente multipli links può essere utile (ad esempio disaccoppiare due pseudowire in due percorsi distinti come in figura):

EXPLICIT PATH:

Un percorso esplicito consiste una una lista specifica di SID-list oppure un set di SID-list

CANDIDATE PATH:

Un candidate path è un singolo segment-list (SID-list) oppure un set di SID-list pesati

Un candidate path ha una preferenza

Un candidate path è associato con un singolo binding-SID

Un candidate path è valido se è utilizzabile ossia possiede delle regole di validazione

Un nodo headend può essere informato riguardo il candidate path attraverso differenti scenari possibili per una determinata SR Policy (headend, color,end-point) ed il percorso selezionato si basa sulla validità e la sua preferenza ha un ” high-value ” (preferita)

• – Local Configuration CLI
• – NETCONF
• – PCEP
• – BGP

Se un nuovo CPath è identificato come pure la validità di un esistente CPath cambia, il processo di selezione logica deve essere re-eseguito.

Cosa è un SID (Segment-ID) ?

un SID = label value 

un SID descriptor = può essere ad esempio un IP address; un SID descriptor presente in un inter-domain (non nello stesso dominio) non può essere risolto da un headend node e pertanto deve essere indicato (expressed) come una “resolved label”.

un headend node riguardo una SR Policy aggiorna la validazione delle SID-list a seguito di un chande della topologia di rete.

Una SID-list è invalida nelle seguenti condizioni:

è vuota

il nodo headend non è in grado di risolvere il primo (first) SID per una o più delle sue interfacce outgoing e next-hop

il nodo headend non è in grado di risolvere qualsiasi non-first SID che è indicato come SID descriptor (IP address)

una SR Policy CPath è invalida quando non ha almeno una valida SID-list

una SR Policy quando tutti i CPath sono invalidi

Esempio Grafico:

se una SR Policy diventa invalida, il comportamento è applicato come di seguito:

• – by default: SR Policy forwarding entries sono rimosse ed il traffico è soggetto a seguire il suo percorso di default come ad esempio per IGP shortest path
• – in caso di ” invalidation drop ” la SR Policy forwarding entry (binding-SID) è comunque mantenuta seppur modificata per scartare tutto il traffico che è governato dalla SR Policy stessa

Una buona progettazione deve prevedere, quindi, una BSID stabile associata ad una SR Policy per tutti i CPaths, indipendente da changes del path selezionato e che indentifica la SR Policy stessa, anche se ricordiamo una SR Policy è identificata dalla tripla headend, color, endpoint. (Un BSID, comunque, può variare durante il periodo di una SR Policy) 

Quando un SR Policy è attiva:

quando un headend node conosce un CPath valido per la stessa policy

quando un headend installa un BSID-keyed entry nella sua forwarding table attraverso un’azione che governi un pacchetto a seguire questa entry verso la corretta SID-list

Esempio:

Se ad esempio vogliamo realizzare un SRTE associata ad una Policy in modo pesato (weighted) su base ECMP (WECMP) abbiamo il seguente diagramma:

EXAMPLE CONFIGURATION:

# enable SRTE DB on headend and SR Policy compute:

router isis < process >

 distribute link-state

router ospf < process >

 distribuite link-state

!

! 

segment-routing

 traffic-eng

   policy < name-policy >

     color 20 end-point ipv4 10.255.255.22         

     binding-sid mpls < incoming-label >             

candidate-paths                                           

        preference 100

          dynamic

            metric type te

          constraints

            affinity

              exclude-any color red

!

        preference 200

          explicit segment-list SID_LIST-1

   !

   segment-list name SID_LIST-1

     index 10 mpls label < label-value >

     index 20 mpls label < label-value >

     index 30 mpls label < label-value >

   !

   segment-routing

     traffic-eng

       affinity-map

         color red bit-position 0

Nella suddetta configurazione abbiamo settato due possibili CPath, di cui uno dinamico con preferenza 100 e l’altro esplicito con preferenza 200 (preferito avedo un valore più alto).

NOTA:

Il nodo headend può ricevere altre infomazioni relative a candidate paths da altri protocolli sorgenti come ad esempio:

Path received via BGP signaling:

preference 150

binding-sid mpls < incoming-label >

weight 1 SID-list < 16003, 16022 >

weight 2 SID-list < 16022 >

Path received via PCEP signaling

preference 120

binding-sid mpls < incoming-label >

SID-list < 16003, 16022

Path received via NETCONF signaling

preference 80

binding-sid mpls < incoming-label >

SID-list < 16003, 16022 >

Il protocollo sorgente non è considerato per la selezione del path, ma ovviamente la preferenza indicata in SR Policy (high-value is better)

WECMP Config Example (vedi diagramma sopra):

segment-routing

  traffic-eng

    policy EXAMPLE

      color 20 end-point ipv4 10.255.255.22

      binding-sod mpls 1000

      candidate-paths

        preference 200

          explicit segment-list SID_LIST-20

          weight 1

          !

          explicit segment-list SID_LIST-80

          weight 4

          !

  segment-list name SID_LIST-20

    index 10 mpls 16003

    index 20 mpls 16022

  !

  segment-list name SID_LIST-80

    index 10 address ipv4 10.255.255.22

La suddetta configurazione è a titolo di esempio come pure le seguenti explicit path:

su base ip address:

segment-routing

  traffic-eng

    policy POLICY

      color 20 end-point 10.255.255.22

      candidate-paths

        preference 100

          explicit segment-list SID_LIST-1

!

segment-list name SID_LIST-1

  index 10 address 10.255.255.2           # prefix-sid = 16002

  index 20  address 1.1.1.6                    # adj-sid = 20203

  index 30 address 10.255.255.22         # prefix-sid = 16022

oppure su base labels:

segment-list name SID_LIST-1

  index 10 mpls label 16002                   # prefix-sid = node P2

  index 20 mpls label 20203                   # adj-sid = adjacency P2-P3

  index 30 mpls label 16022                   # prefix-sid = node PE2

NOTA.

L’adiacenza SID 20203 significa che il pacchetto transita dal nodo P2 al nodo P3; in altre parole in assenza di una prefix-SID un nodo di rete utilizza adj-sid per trasportare il pacchetto sino a destinazione lungo il percorso

Cosa significa Min-Metric Optimization ?

Un head-end calcola una SID-List che è espressione di un best-Path in accordo alle metric configurate:

Min-Metric with Margin and max SID-list significa che un headend calcola una SID-List per un determinato flusso di traffico, in modo che questo non utilizzi il percorso che ha accumulato una optimized-metric più largo rispetto ad un best-path con optimized-metric + margin.

Il valore di margn è assoluti oppure relativo come percentuale.

Esempio di configurazione:

CONSTRAINTS:

Vediamo ora una serie di configurazioni su base vincoli o contraints:

TE Affinity:

I links possono essere “colorati” ed un SRTE Policy ha la facoltà di calcolare un percorso che possa includere o escludere links che hanno uno specifico colore o una loro combinazione

I color links/interface sono assegnati attraverso un affinity bit-maps

Esempio di Configurazione:

1) Add colors to links:

 2) SR Policy Path Affinity:

 3) SR Policy IP Address Constraint:

 4) SR Policy SRLG Constraint:

 5) SR Policy Maximum-Metric Constraint:

 5) SR Policy Maximum-Limit-SID Constraint:

segment-routing

 traffic-eng

  policy POLICY1

    color 20 end-point 10.255.255.22

    candidate-paths

      preference 100

        dynamic

          metric type igp

      constraints

        bounds

          cumulative

            type sid 4

 L’importanza del Binding-SID (BSID): 

Il BSID di una SR Policy è installata nella forwarding table e ha le seguenti funzioni:

Remote Steering

 un pacchetto entrante presso un nodo headend con un BSID come active-segment on top label stack è gestito (steer) all’interno della SR Policy associata con il valore di BSID

Local Steering

 un pacchetto che incontra (matches) una forwarding entry risolta da un BSID di una SR Policy è gestita (steer) all’interno della SR Policy stessa

BGP può gestire in modo automatico il traffico all’interno di una SR Policy basata su BGP next-hop e color della route; il color della route è specificato dal color extended community attribute.

Di default, se il BGP next-hop e color della route match l’end-point ed il color presenti nella SR Policy, il BGP protocol installa la route risolto dal BSID della SR Policy stessa; l’end-point e color identificano in modo univoco una SR Policy in un headend nodo.

Il color extended community attribute (RFC 5512) ha la seguente struttura:

Color-Only CO bits significa:

di default CO bits = 00 e specifica il default automated steering su base del colore e del next-hop

e’ gestito dall’atributo extended community

in casi come ad esempio l’utilizzo di un SDN Controller, è possibile cercare di governare (steering) il traffico all’interno di una SR Policy su base coloro solo

Solo in caso di una SR Policy valida vi è il trasporto del traffico/packets

IGP to N significa che è il protocollo IGP shortest path to N

SR Policy (null, C) significa che abbiamo un null end-point, per cui:

   null (AFN) rappresenta il null end-point per una determinata address-family di N

null (any) rappresenta il null end-point per qualsiasi address-family

   null (IPv4) = 0.0.0.0

   null (IPv6) = ::0

SR Policy (<any>, C) significa che una qualsiasi SR Policy con color C, per cui:

any (AFN) rappresenta qualsiasi end-point per una determinata address-family di N

   any (any) rappresenta qualsiasi end-point di qualsiasi address-family

Solo una SR policy (N, C) esiste in uno specifico nodo di rete

Solo una SR Policy [null (AF), C] per ogni address-family esiste in uno specifico nodo di rete

La gestione/guida/steering ha un comportamento indipendente dal tipo/sorgente di una SR Policy, cioè essa può essere preconfigurata, oppure appresa via netconf, PCEP, BGP oppure on-demand gestita dal BGP o altri servizi (ad esempio LISP)

Una volta che una SR Policy esiste, è valida e qundi vi è possibilità di governare il traffico (steer), allora il BGP applica una preferenza sulla base delle regole color-value e CO-bits

Se una route/prefix R con next-hop ha multipli colori, il BGP può governare il traffico di R all’interno della SR Policy con un valore numerico basato su “highest color”

La possibilità di avere multipli color trova impiego anche la funzionalità di active-standby di una SR Policy e come nel caso sopra, il BGP risolve R attraverso una SR Policy che ha un valore numerico più alto rispetto ad una SR policy con valore più basso, ma nel caso la prima SR Policy selezionata diventasse invalida, il BGP può re-risolvere la route/prefix  R attraverso la seconda SR Policy

E’ possibile disabilitare in modo automatico via configurazione lo steering di un traffico

Esempio config:

segment-routing

  traffic-eng

    policy PIPPO1

      color 20 end-point ipv4 10.255.255.22

      steering bgp disable

      candidate-paths

        preference 100

          dynamic

            metric

              type te 

Setting color route:

Il colore di una BGP route/prefix è settato nel nodo di egress PE attraverso la colorazione espressa come extended community della route

il color extended community è propagato verso il nodo di ingress PE

il traffico viene governato dal nodo di ingress PE sulla base del colore settato (no route-policy è richiesta; anche se Il traffico può essere influenzato dal nodo di ingress PE attraverso un color extended community per una route/prefix utilizzandone il suo impiego)

Esempio grafico con color assegnato on Egress PE:

Esempio grafico con color assegnato on Ingress PE:

Setting pseudowire preferred path:

Una SR policy è utilizzata per trasportare traffico via pseudowire attraverso un preferred-path configuration.

Se il protocollo LDP è in uso per la segnalazione PW, allora il neighbor address deve essere raggiungibile via SR Policy oppure un’altro percorso.

Esempio config

l2vpn

  pw-class EoMPLS-PW

    encapsulation mpls

      preferred-path sr-te policy POLICYPW

!

xconnect group GRP-PW

  p2p XCON

    interface Te0/0/0/0

    neighbor ipv4 10.255.255.22 pw-id 10

    mpls static label local < local-label > remote < remote-label >   # questo comando è da usare solo se non si sta usando LDP come segnalazione

pw-class EOMPLS-PW

On-Demand Next-Hop:

Un headend node inizializza una SR Policy verso un BGP next-hop quando richiesto (on-demand)

Color community è usata come uno SLA indicator

Una SR Policy è sempre definita con ” color, end-point ” dove il color è il BGP color community e l’end-point è il BGP next-hop

Esempio

Un servizio (ad esempio una VPN) può essere governata (steering) automaticamente sulla base di un corretto SLA path e questo è conosciuto come SR Policy based on color and next-hop of service route.

Color community di un service route è utilizzata come uno SLA indicator

Esempio:

I benefici possono essere riassunti in:

no ad un full-mesh a priori per una SR Policy configuration ( color –> optimization objective)

nessuna complessità di governare il traffico via configuration

steering automatico di BGP routes attraverso il corretto SLA path

 BGP PIC FRR data plan protection è garantito

 BGP NHT fast control plane convergence è garantito

On-Demand Next-Hop Multi-Domain:

La stessa funzionalità di On-Demand NH e Automated Steering è applicato anche in un contesto Multi-Domain

il nodo headend utilizza un SR-PCE per provvedere in modo automatico ad un SR Policy path verso il dominio remoto dove la destinazione risiede

inter-domain utilizza per la raggiungibilità un push-model per dare compatibilità in termini di scalabilità in realtà molto grandi 

Esempio:

Per ulteriori informazioni su SR data-plane e control-plane vedi anche: https://www.massimilianosbaraglia.it/routing/segment-routing/segment-routing-teoria/segment-routing-funzionalita