Sip Dect RFP45

DEFINICIÓN TECNOLÓGICA
DE SOLUCIÓN MARZO 2018

SERVICIO L3VPN PARA EL HL3/HL4
Edición 9ª
DTS.r.01.0004
ESTRATEGIA Y DESARROLLO DE RED USO INTERNO Página 1 de 54
FUSIÓN RED
ESTRATEGIA Y DESARROLLO DE RED
No está permitida la reproducción total o parcial del presente documento, ni su tratamiento

La entrega parcial o total a terceros de este
informático, ni la transmisión de ninguna forma o por cualquier medio, ya sea electrónico,
documento deberá ser autorizada por la Alta
mecánico, por fotocopia, por registro u otros métodos. Asimismo, queda prohibida toda
Dirección o por la Dirección de ESTRATEGIA Y
transformación y/o cesión de uso del documento, sin el consentimiento previo y por escrito de
DESARROLLO DE RED.
Telefónica de España, S.A.U.
Copyright  Telefónica de España, S.A.U., Gran Vía 28 Madrid.2018. Todos los derechos reser-
vados.
document_tecnica v.1.3
DEFINICIÓN
TECNOLÓGICA DE MARZO 2018
SERVICIO L3VPN PARA EL HL3/HL4 SOLUCIÓN
Edición 9ª
DTS.r.01.0004
Servicio L3VPN para el HL3/HL4
INDICE
1. INTRODUCCIÓN 5
1.1 OBJETO 5
1.2 DOCUMENTACIÓN DE REFERENCIA 5
1.2.1 Documentación TdE 5
1.2.2 Documentación externa 9
1.2.3 Documentación Suministradores 9
1.2.4 Referencias normativas 9
1.3 UNIDADES AFECTADAS 10
1.4 DEROGACIONES Y EFECTIVIDAD 10
1.5 UNIDAD RESPONSABLE 10
1.6 LISTA DE REVISIONES 10
2. RELACIÓN DE SERVICIOS L3VPN AFECTADOS 14

2.1 TAXONOMÍA 14
2.1.1 Servicios Vs PPEE 15
2.1.2 SVAs afectados 17
2.2 PLAN GENERAL DE MIGRACIÓN 17
3. DESCRIPCIÓN GENERAL 18
3.1 GESTIÓN 18
3.2 CONCURRENCIA 18
3.3 COS 18
3.3.1 Puertos de agregación de conexiones de cliente 20
3.4 ESTRATEGIA DE RESPALDO 21
3.5 IPV6 21
3.6 SEGURIDAD (BASTIONADO) 21
3.7 MODELO DE ESCALABILIDAD21
3.8 CONEXIONES PROCEDENTES DEL HL5 21
4. DESCRIPCIÓN DETALLADA 22
DEFINICIÓN
Edición 9ª
DTS.r.01.0004
4.1.1 Análisis opciones BGP: Impacto segmentación del core en múltiples ASs sobre
las sedes VPN con routing BGP 22
4.2 SOLUCIONES PARTICULARES 22
4.2.1 CSC para backup MPLS a la RTJAv3 22
4.2.2 Interconexiones con la NGN 23
4.2.3 Accesos ATM 23
4.2.4 HLC 24
4.2.5 PEs legacy24
4.2.6 Inter-AS VPN 25
4.2.7 DIBA full-routing, PHT 25
4.2.8 CdS 25
4.2.9 LAN’s de propósito específico 26
4.2.10 CG Empresas 27
5. ASPECTOS PARTICULARES POR SUMINISTRADOR 28

5.1 ALU 28
5.1.1 Limitaciones tarjetas MDA de 60 puertos 28
5.1.2 Soporte 6PE 28
5.1.3 IUM 28
5.1.4 Templates 30
5.1.5 BFD-RIP 30
5.2 JUNIPER 31
5.2.1 egress-shaping-overhead 31
5.2.2 Interface-specific 32
6. MIGRACIÓN DE CONEXIONES DE CLIENTE 33

6.1 AG12 33
6.1.1 Procedimiento de migración 34
6.2 PCM 35
6.2.1 PCMs de conexiones P2P 35
6.2.2 Procedimiento de migración DIBA 36
6.2.3 Procedimiento de migración macroLAN 37
6.3 FIBRA DIRECTA 38
6.4 DIRECCIONAMIENTO WAN 38
6.5 DIRECCIONAMIENTO DE GESTIÓN 38
DEFINICIÓN
Edición 9ª
DTS.r.01.0004
6.6 CONEXIONES EN HL5 38

6.7 PROYECTOS ESPECIALES 38
6.8 JALONAMIENTO DE LAS PRUEBAS 39
6.8.1 Bloque I 39
6.8.2 Bloque II 39
6.8.3 Bloque III 40
6.8.4 Excluidos 40
7. MIGRACIÓN DE LA RED A DOMINIOS DISJUNTOS DE IGP ENLAZADOS

MEDIANTE L-IBGP 41
7.1 INTEGRACIÓN DE LOS PE-LEGACY EN FUSIÓN 41
7.2 NECESIDADES DE VALIDACIÓN 42
8. IMPACTO EN OTROS PROYECTOS 43

8.1 RCU 43
9. Acrónimos 44
MARZO 2018
Edición 9ª
1. INTRODUCCIÓN
Dentro del marco general del proyecto de transformación de las redes MPLS de conectividad de
TdE “Fusión de Red” [21], es necesario definir y detallar cómo se van a prestar los servicios de
conectividad IP (L3) sobre dicha red, básicamente L3VPN, así como la estrategia de migración, y otras
consideraciones relativas a tener en cuenta.
1.1 OBJETO
Este documento define y detalla, con el suficiente nivel de concreción, la arquitectura e
implementación de dichos servicios L3VPN en los nodos HL3 y HL4 de la Red Fusión, ya que debe de
servir como referencia inequívoca para el resto de la documentación del proyecto, en lo que a L3VPN se
refiere (Planes de pruebas, plantillas de configuración, etc…)
1.2 DOCUMENTACIÓN DE REFERENCIA
1.2.1 DOCUMENTACIÓN TDE
Documentación previa
Documentación PEGGCC
[1] DTS: PE de Grandes Clientes

Tecnología de Redes IP para Empresas, Planificación y Tecnología, DTS.ip.0008
Work in progress
[2] Plan de Pruebas regresión actualización sistema operativo PE-GGCC

Tecnología de Redes IP, EyDR
PP.ip.0007
[3] Plan de Pruebas para tarjeta de línea (PEs GGCC)

Tecnología de Redes IP, EyDR
PP.ip.0006
[4] CSC para backup RTJAv3 por Red IP

Tecnología de Redes IP para Empresas, EyDR
DTS.ip.0013, 2015
MARZO 2018
Edición 9ª
[5] PE dedicado al Centro de Mitigaciones

EyDR, DTS.ip.0011
[6] Infraestructura de red del NPDE de Accesos y Respaldos móviles a VPN-IP

Tecnología de Red IP para Empresas, EyDR, DTS.ip.0010
[7] DTS: cifrador para MoviStar Intranet en Red IP Única

EyDR, Tecnología de red IP, DTS.ip.0007
[8] Control Hw/Sw: concentrador túneles GRE para Movistar Intranet

Tecnología de Redes IP, Empresas, PyT, MC.ip.0059
Mayo 2013
[9] Migración servicios móviles corporativos a Red IP Única

Tecnología de Red IP para Empresas, EyDR, DTS.ip.0009
[10] Uso de PHT para concentrar a los clientes DataInternet-FullRouting en un nodo central
Tecnología de Red IP para Empresas, EyDR
MC.r.01.0001
[11] Plantillas de Modelos de Conectividad MPLS sobre PE Juniper Serie M V2.9

Servicios Corporativos de Datos
[12] Pruebas y plantillas de Túneles Martini en PEs Juniper M

Ing. Red TData. 2006
[13] Informe de pruebas validación accesos QinQ, FTTH/VDSL a VPNIP en PEGGCC's Mx

IR.ip.0044
[14] Solución tecnológica de Red IP para el servicio de Respaldo móvil Conectividad

Empresas
Tecnología de Redes IP
MARZO 2018
Edición 9ª
Edición 3ª, febrero 2013

DTS.n0.0078
[15] Control HW/SW: LNS de Acceso & Respaldo móvil a VPN-IP

Jefatura de “Tecnología de Red IP para Empresas”, EyDR
MC.ip.0065
[16] Solución tecnológica de red para el proyecto Redes Limpias

Desarrollo de la Seguridad de la Red
DTS.n0.0060
[17] Solución de red para conexión de Centros de Servicios a RIMA

DTS.n0.0050
[18] Plantillas de conexión de Centros de Servicios sobre equipos Cisco 7600, Cisco CRS de
CICO, Juniper MX960 Y Ericsson SE1200 en Núcleo General de Red IP Única
MC.n0.0097
[19] (DTS) para la creación de centros agregadores de servicios en red

DTS-R-036 Edición 3ª
enero 2004
[20] Definición Tecnológica de la Solución WAN de la Nueva Red Corporativa Unificada

DTS.n0.0057
Documentación propia del proyecto “Fusión Red”
Diseño
[21] DTS general de “Fusión Red”

DTS.r.01.0005
Pendiente, ¿la redacta/compila Iván?
MARZO 2018
Edición 9ª
[22] Doc análogo GT ALU

¿?
¿?
[23] DTS BNG “Fusión Red”

DTS.r.01.00xx
Pruebas
[24] Plan de pruebas Arquitectura
Pendiente, ¿la redacta/compila Iván?
[25] Resultado pruebas sobre RFI agregacion ethernet núcleo IP fase 1.a (GT juniper)
Jefatura Tecnología de Acceso, TRIA, TCIP
IR.n0.0326
[26] Plan de pruebas L3VPN para el HL3/HL4

“Tecnología de Red IP para Empresas”, EyDR
PPR.r.01.0006
[27] Validación de BGP-lu en los PEGGCC para interconexión con HL4 Fusión
“Tecnología de Red IP para Empresas”, EyDR
IL.r.01.0005
Especificación de requisitos para Sistemas
[28] ESPECIFICACIÓNES DE NEGOCIO (QUÉ): Creación de red y provisión para servicios

de Empresas VPN IP (accesos ADSL y FTTH) en la red Fusión
Sin código1
TRIA, EyDR
1
Tienes una copia en
D:\Alonso\Telefonica\TecnologIa\Fusion de Red\L3VPN\NPDEs
MARZO 2018
Edición 9ª
1.2.2 DOCUMENTACIÓN EXTERNA
[29] Scaling MPLS seamlessly

Office of the CTO – Platform Systems Division, Juniper Networks
RIPE65 – Amsterdam, NL September 24, 2012
https://ripe65.ripe.net/presentations/68-RIPE_65_Seamless_MPLS.pdf
1.2.3 DOCUMENTACIÓN SUMINISTRADORES

ALU
Juniper
1.2.4 REFERENCIAS NORMATIVAS
IETF
[30] Carrying Label Information in BGP-4

IETF, Network Working Group
RFC#3107
https://tools.ietf.org/rfc/rfc3107.txt
[31] OSPF as the Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Private
Networks (VPNs)
Network WG, RFC#4577
https://tools.ietf.org/html/rfc4577
[32] BGP-MPLS IP Virtual Private Network (VPN) Extension for IPv6 VPN
IETF, RFC4659
Sept 2006
http://www.rfc-editor.org/rfc/rfc4659.txt
[33] Connecting IPv6 Islands over IPv4 MPLS Using IPv6 Provider Edge Routers (6PE)
MARZO 2018
Edición 9ª
IETF, RFC4798
http://www.rfc-editor.org/rfc/rfc4798.txt
[34] Bidirectional Forwarding Detection (BFD) for the Pseudowire Virtual Circuit Connectiv-
ity Verification (VCCV)
IETF, RFC5885
[35] The Accumulated IGP Metric Attribute for BGP

IETF, RFC7311
Drafts
[36] Seamless MPLS Architecture

IETF MPLS WG, 2014
https://tools.ietf.org/html/draft-ietf-mpls-seamless-mpls-07
IEEE
[37] Virtual Bridged Local Area Networks, Amendment 5: Connectivity Fault Management
IEEE Std 802.1ag-2007
http://standards.ieee.org/getieee802/download/802.1ag-2007.pdf
1.3 UNIDADES AFECTADAS

Como proyecto general de transformación de Red, esta documentación aplica a toda la dirección
de OyR, aunque, al ser un documento de diseño de alto nivel (HLD), la dirección que más directamente
se remitirá a este documento será la de EyDR, para generar la documentación de detalle (LLD) que
utilizarán el resto de las unidades de la dirección general
MARZO 2018
Edición 9ª
1.4 DEROGACIONES Y EFECTIVIDAD

Este documento se está redactando originalmente como herramienta para la coordinación de la
migración, pero, pudiera ser interesante mantenerlo tras esa fase, como registro de las funcionalidades
activadas en cada elemento de la red.
1.5 UNIDAD RESPONSABLE
1.6 LISTA DE REVISIONES
NÚMERO FECHA
APARTADOS REVISADOS CAMBIOS EFECTUADOS OBSERVACIONES
EDICIÓN EDICIÓN
Borrador0 Todos Creación del documento La que dejaste cuando
te fuiste de vacaciones
de verano
Borrador1 02/09/15 5.1.1 Limitaciones tarjetas MDA de 60 Revisión inbox a vuelta
puertos de ALU de vacaciones
3.5 Apunte parar IPv6
14/09/15 4.1.1 No impacto en routing de cliente

al usar iBGP-lu
4.2.1 CSC-RTJAv3 Vs. Red Fusión
4.2.2 Icx GGCC-NGN
Borrador 2 30/12/15 1.2 Reordenación de las referencias
25/01/16 4.2.3 & 4.2.4 HL4-ATM & HLC
6. Capítulo específico para el

proceso de migración
4.2.5 PEs legacy
27/01/16 6.8 Jalonamiento de las pruebas
Borrador3 27/01/16 2.1.2&5.1.3 IUM
28/01/16 2.2; 4.1.1; 4.2.3 No se excluye que los HL5 Revisión Miguel2
lleguen a tener servicios L3; el
eBGP está descartado entre
áreas; la RFQ contemplaba
escenarios con ATM en el HL4
2
Correo del mié 27/01/2016 20:54
MARZO 2018
Edición 9ª
29/01/16 4.2.3 Clientes con IP fija y estática (correo Miguel)
1/2/16 6.8.3 Conexiones procedentes de HL5 Reunión kickoff

en F3
Borrador4 2/2/16 5.1.4 Templates de TimOS Reunión kickoff
24/02/16 5.2.1 Egress-shaping-overhead
25/02/16 5.2.2 Eliminación de “interface-

specific”
01/03/16 7. BGP-lu en los PE-legacy
07/03/16 7.1 Asignación de código de (correo Javi Belando)

“provincia legacy”
5.2.1 overhead-accounting a –20
15/03/16 5.1.5 Reparo BFD-RIP ALU (correo Roberto

Manrique 11/03)
16/03/16 6.1; 6.2; 6.4 & 6.5 Revisión procedimiento (comentarios revisión
migración Fede)
21/03/16 5.1.3 Información sobre PIP
Borrador 5 25/04/16 Revisión otras migración otras

conectividades3:
4.2.4 HLC en HL2
4.2.8 CdSs
4.2.5 Migración CRRs
4.2.2 Migración de las icx NGN

GGCC
3.2 Bifurcadores -> HL4-Emp
MAD/BCN
8.1 Impacto en RCU
4.2.1 CSC RTJAv3 -> HL4
4.2.6 VPL VPN-INT -> HL4-ATM
4.2.9 LAN’s de propósito específico
3
Reunión 25/04/16 09:30 E1P8E53
MARZO 2018
Edición 9ª
26/04/16 6.2.1 Acerca de la doble VLAN P2P
6.8 Revisión contenido bloques

entregas.
Redenominamos las fases a
bloques para evitar confusiones
con otra segmentación de las
pruebas.
Borrador 6 27/04/16 5.1.5 Actualización estado reparo RIP-
BFD
4.2.10 CG Empresas -> HL4ATM4
28/04/16 4.2.5 Matiz entre HL4ATM y “PE

residual”
4.2.7 Reparos relativos a PWHT
2.1 Descripción catalogación

comercial accesos macroLAN
6.2.1 & 6.3 Convergencia VLAN-P2P y
Fibra Directa VPNIP en la
migración
6.2.3 Desarrollo estrategia migración
MacroLAN (L3VPN)
03/05/16 6.2.3 Migración MacroLAN -> VPNIP Reunión 03/05/16
(NPDS RPV2.0)
6.2.1 Redefinición VLAN P2P
04/05/16 6.8.2 DataInternet FTTH en bloque II
5.1.5 Cierre, desestimando el script de

BFD+RIP
Borrador 7 04/05/16 5.1.3 Análisis vida útil estimada para Hilo de correo con Javi
las Compact Flash, si se Martín
adquieren para IUM
6.2.3 Opción continuista de migración
de MacroLAN a Fusión (no
recomendada)
25/05/16 3.9 Sobre la MTU
17/06/16 2.1&4.2.7 Sobre el CoS L2 de DIBA
31/08/16 7.1 AIGP en los PEGGCC con 13.3
4
Correo Iván/Fede 27/04/16
MARZO 2018
Edición 9ª
7.2 Necesidades para el CRR
Borrador8 13/02/17 6.1 Revisión procedimiento

migración, tras las pruebas:
 En el HL4 no se puede
hacer disable, tiene que
estar en deactivate
 Es más propio decir que
hay que flapear en la
ONT el “puerto
Ethernet”, más que el
“puerto PON”
 El cambio de la
CVLAN se hace en la
ONT, no en la OLT
28/02/17 6.1.1 Aclaración paralelismo
microtareas sincronizadas
02/03/17 3.8 Desarrollo de la solución para
clientes conectados a través de
HL5
14/03/17 4.3 Nuevo apartado sobre la
traducción de plantillas PdS.
Caso concreto de H&S
12/04/17 3.8.1 & 3.8.2 Desarrollo CoS PWHT para HL5 A raíz de descubrir que
la VPE tiene “cos de
cliente” aunque no se
use.
17/04/17 4.2.7 Desarrollo caso concreto DIBA-
FR con acceso MLAN en HL5
Borrador9 25/04/17 3.8.2
08/06/17 6.1.1 Secuenciación microtareas en el

procedimiento
22/03/18 5.1.6 Consideración en CoS de MFE A raíz del desarrollo en
sistemas.
MARZO 2018
Edición 9ª
2. RELACIÓN DE SERVICIOS L3VPN AFECTADOS
Esta migración de red afecta a todos los servicios L3-GGCC cuyo acceso L2 se realiza a través de
la REM. Más detalle abajo
2.1 TAXONOMÍA
Para una clasificación general de todos los servicios, y Proyectos Especiales (PPEE) prestados
actualmente en el PEGGCC nos remitimos al apartado 3.1 de la DTS general [1]. Si nos centramos en
los que tienen accesos Ethernet a través de la REM:
 L2VPN. En este apartado sólo estarían los PWE que se utilizan bien para interconectar
VLANs de distintnas MANs, bien para otros usos particulares. En el primer caso, este
servicio perderá sentido, cuando los servicios L2VPN tengan extensión nacional tras la
fusión de las redes MAN y la red MPLS naciona (Red IP Única). En el segundo caso, la
migración consistirá en una simplificación. Actualmente estamos empalmando (stiching)
tres servicios L2VPN, dos VPLSs en dos MANs y un VLL en la red MPLS nacional,
mediante dos interfaces UNI 802.1q (el PCM), y pasaremos a poder dar el mismo servicio
con un PWE entre los dos HLn que el cliente utilice
 L3VPN
o Como servicio de presencia en Internet, estaría DIBA, la variante de DI con acceso
“Banda Ancha” (VLAN en la MAN). En este caso hay que distinguir entre clientes
“básicos” y clientes con “full-routing”. Los segundos utilizaran una configuración
especial (PHT) para llevarlos a un Service Node (SN) centralizado, según se
desarrolla en el apartado 4.2.7
 Hay una modalidad de DataInternet, “Redes Limpias” (RRLL), en la que la
conexión del cliente no está en TGR, sino en una VRF de una VPN que
lleva el tráfico al PERRLL.
El control de caudal se hace en el EDC y en el PE, pero no en la VLAN de la
MAN5.
o Servicios RPV (según modelo MPLS 2547):
 VPNIP. Se ven afectados los accesos QinQ y VLAN P2P. Aunque no
necesariamente se deberían de ver afectados, también migraremos las fibras
directas (GE). No se ven afectados los accesos móviles, RDSI, Frame
Relay… y, en general, todos los que se quedan en “PE-legacy”. En el caso
de los accesos ATM, la migración se hará en una fase posterior, según se
detalla en el apartado 4.2.3
 MacroLAN. Este servicio se ve afectado hasta el punto de que va a ser
necesario redefinirlo, porque ya no tiene sentido que haya una conectividad
5
Correo de Emilio Fdez Salinero del jue 09/06/2016 14:33: El control en la MAN se usaba cuando éramos “TDATA”
y solicitábamos el uso de la MAN para montar nuestros servicios, pudiéndose controlar tanto el Caudal total del Conjunto de
VLANs definidas sobre un acceso, como la propia VLAN. Ahora que todos somos TdE, ese control se ha eliminado y en el
caso del Datainternet, se deja el control de caudal al EDC y al PE.
MARZO 2018
Edición 9ª
L2 metropolitana y otra L3 nacional, una vez que la red es MPLS e2e y

permite completa flexibilidad de combinaciones de estos dos tipos de
servicio. Para la migración de este servicio a Fusión se va a requerir NPDS.
Comercialmente (BSS) se considera MacroLAN cualquier acceso Ethernet
nativo (no GPON ni VDSL), y dentro de Macrolan existen 4 tipos de
accesos funcionalmente6:
 Acceso con Vlan Unica, se trata de un acceso metropolitano
compartido por N Sedes, con los conceptos de Caudal Metro y
Caudal Agregado. Es el acceso más estándar por decirlo de algún
modo. Dentro de este tipo de acceso tengo diferentes
velocidades:10G, 1G, 100M, 10M, cobrelanes.
 Acceso con Vlan Exclusiva, se trata de un acceso metropolitano
para una sola sede, que tiene conexión a 2 PEs de Red IP, un único
concepto de Caudal Exclusivo. Dentro de este tipo de acceso tengo
las velocidades: 10G, 1G, 100M, 10M, cobrelanes.
 Acceso Fibra Directa, se trata de un acceso de Fibra que no usa la
red Metro, los conceptos de caudales son los de VPN IP, similares a
lo que es Caudal Exclusivo eliminando los caudales CDG. Las
velocidades soportadas son solo 10G y 1G.
 Acceso Vlan PaP, se trata de accesos metropolitanos para una sola
sede, que tiene conexión a 1 PE (para acceso a 2 PEs se provisionan
2 vlans), el concepto de caudal es como el de Fibra Directa, similar
a VPN IP y sin caudales CDG. Las velocidades soportadas son 10G,
1G, 100M, 10M.
Técnicamente los 2 primeros VLan Unica y Vlan exclusiva, en la Red IP se
incorporan en la Routing-Instance Macrolan. Y los 2 ultimos FD y Vlan
PaP en la Routing-Instance VPN IP.
Esta DTS se refiere a Red, y por tanto consideraremos VLAN P2P y Fibra
Directa como lo hacen los OSS y los routers: VPNIP, aunque
comercialmente se cataloguen como MacroLAN
 Conectividad Empresas. Su caso es equivalente al de los accesos QinQ a
VPNIP
Accesos que no se ven afectados por esta migración son todos los demás en general, por el motivo
indicado arriba de que el acceso no se hace por la REM, pero, por aclarar posibles confusiones,
excluimos explícitamente del alcance de este proyecto:
 Los servicios TIC que se prestan en el CdS y otros CPDs. Aunque en apariencia es un
acceso Ethernet/vlan más a VPN, estas VLANs son “LAN”, no están en la MAN. Además,
el PE de Servicio (aka CE Empresas) no forma parte de la Red IP Única, aunque esté
integrada en la nube MPLS de la misma
6
Extracto de correo de Javi Santayana del 28/04/16
MARZO 2018
Edición 9ª
 NetLAN. Este servicio está descontinuado y los accesos se quedarán en PEs-legacy hasta
que desaparezcan.
2.1.1 SERVICIOS VS PPEE

Si en vez de clasificar por la naturaleza del servicio de conectividad, clasificamos por el grado de
estandarización, de integración en sistemas, y de industrialización de los procedimientos, podemos hacer
tres categorías:
1. Servicios de catálogo, desarrollados por DSyS y, antiguamente, por DTS7. Existen sistemas
de tramitación y provisión automatizada que permiten la activación del servicio al cliente
sin necesidad de intervención manual ni rediseño alguno.
2. Proyectos especiales, pero que son tan habituales que se han convertido en un estándar de
facto, hay algún desarrollo para automatizar la provisión
3. Proyectos especiales particulares, sin documentación genérica asociada, ni sistemas. La
información relativa está en un soporte
Para los tipos 1 y 2, será necesaria la revisión de los sistemas y, si acaso, la modificación y
adaptación de los mismos. En el caso 2, primero hay que identificar qué desarrollos existen.
En el apdo. 3.3 de la DTS general del PEGGCC [1] disponemos de un registro de PPEE, que
podemos utilizar para revisar los que requieren revisión para la migración a Fusión:
 Los “túneles Martini” (VLL/PWE), que en los PEGGCC eran un proyecto especial, en los
HL4 ya no lo van a ser, ya que integran los servicios del catálogo de L2VPN
 Extranets. Su validación es directa, una vez que se chequea el uso de políticas de
importación/exportación “complejas” en la VRF
 Hub&spoke. No es exactamente el mismo caso, porque la implementación de servicios no
sólo se basa en importación/exportación de RTs, sino en FBF, para forzar a dos sedes
conectadas a la misma VRF spoke a que se conecten a través del hub
 DataInternet: Nos limitaremos a DIBA, los accesos ATM y frame-relay, si quedan, se
quedarán en los PE-legacy.
o El full-routing en los SN de Madrid, con desacoplamiento del borde MPLS
mediante PWHT, que en Red IP era una excepción, en Fusión, que es una
arquitectura “MPLS e2e”, es algo más connatural. En todo caso, también requerirá
una validación específica. Será necesaria una migración, porque el AN pasará de
ser el PEGGCC del PCM, al HL4/5 al que llegue la conexión del cliente.
o Subcaudales. Requerirá la comprobación de que se pueden aplicar policers
específicos basándose en ACL u otros mecanismos de discriminación de
direcciones. Para este caso son necesarios desarrollos en sistemas, ya que había
sistemas en Red IP (activación automática en SAS).
o La “fibra directa al PE”, que, en Red IP era un proyecto espacial, en Fusión, debido
al cambio de arquitectura, pasa a ser lo estándar, ya que nos llevamos el servicio al
borde. Excepción a lo anterior: full-routing. Para este caso son necesarios
7
Desarrollo Técnico de Servicios, Telefónica Data
MARZO 2018
Edición 9ª
desarrollos en sistemas, ya que había sistemas en Red IP (activación automática en

SAS), puede incluso que se pueda reutilizar aquel desarrollo para el nuevo “DIBA
en Fusión”
o Los pilotos de túneles IPv6oIPv4 no se deberían de trasladar a Fusión. Los clientes
que requieran IPv6, se servirán mediante 6PE y dualstack en el HL4
o Los PPEE que consisten en ajustes en las políticas de importación/exportación en la
conexión con el CPE, tendrán una validación directa, derivada de la revisión de la
políticas de importación/exportación eBGP que soporta el HL4
o De igual manera, en el caso de clientes en los que se ha ajustado es el filtro de
paquetes.
2.1.2 SVAS AFECTADOS

Existen otros servicios de GGCC, que no son de conectividad, sino de valor añadido que, sin
embargo, pueden verse afectados por una migración de la infraestructura de red que soporta la
conectividad. Casos identificados:
 IUM. Este SVA consiste en unos informes de tráfico, desglosados por CoS y por sede, que
se entregan al cliente para darle visibilidad del uso que efectivamente está haciendo del
servicio contratado, y como palanca comercial para proponer incrementos de caudal
contratado en las sedes que habitualmente están cargadas. En los PEGGCC este servicio
está implementado basándose en unos “ficheros de accounting”, que recopilan unos
contadores de los filtros de clasificación multifield del CoS integrados en los filtros de
servicios. Estos ficheros se recolectan por IUM, pero se generan en el propio PEGGCC,
haciendo uso de una funcionalidad propietaria. Será necesario buscar una solución para los
equipos de ALU (apdo 5.1.3)
2.2 PLAN GENERAL DE MIGRACIÓN

En general, la idea es trasladar el punto de servicio L3, la VRF, generalmente, al borde de la red
MPLS, donde se conecta directamente el EDC del cliente, o donde nos lo entrega la red de acceso
FTTH/ADSL, o sea, en la conexión con la OLT ó el DSLAM IP.
Las excepciones a esta regla se deben a que el nodo de acceso a la red Fusión no soporte el
servicio L3 del cliente. En estos casos, siguiendo la filosofía seamless/MPLS-e2e, el acceso de cliente se
transporta mediante un PWE desde el Access-Node (AN) hasta el Service Node (SN) correspondiente,
donde ya sí que hay capacidad para prestar el servicio. Ejemplos
 Los equipos HL5 no tienen, al menos en el arranque de la Red Fusión, capacidad para
prestar servicios L3, por lo que, en la migración desde el PEGGCC, estos servicios se
llevarán mediante un PWE al HL4 del que cuelgan, según se desarrolla en el apartado 6.6.
En este caso el HL5 funciona como AN y el HL4, como SN
MARZO 2018
Edición 9ª
 Los HL4 no van a tener el full-routing de Internet, en su lugar, para aquellos clientes que
requieran estas rutas, se llevarán a un SN, los actuales Mx de Madrid, utilizando PHT,
como ya se está haciendo actualmente [10], con la única diferencia de que el AN pasará de
ser el actual PEGGCC al HLn al que se conecte el cliente.
Para más detalle sobre el proceso y procedimiento de migración, nos remitimos al capítulo 6.
MARZO 2018
Edición 9ª
3. DESCRIPCIÓN GENERAL
3.1 GESTIÓN
3.2 CONCURRENCIA
En línea con la filosofía general de la red Fusión, los servicios de GGCC no van a estar en PEs
dedicados, sino que se provisionarán en equipos compartidos con otros servicios. Salvo excepciones, los
servicios GGCC se llevarán al nivel HL4. Excepciones:
 Servicios no desplegados en HL4:
o Aquellos que por su demanda relativamente pequeña, o porque tengan una
tecnología muy específica, merezca más la pena concentrarlos en un “Nodo de
Servicio” (SN):
 DIBA Full-Routing
 Accesos L2TP, como el LNS de AyRMVPNIP
 Equipos dedicados al acceso IPSec (cifradores de Movistar Intranet)
 Equipos dedicados al acceso móvil (concentradores Movistar Intranet)
o Interconexiones con otras redes:
 Inter-AS tipo A con TIWS, para el servicio VPN-INT
 Conexión con NGN para proporcionar servicios VoIP en las VPNs de los
GGCC
 Equipos dedicados. De manera excepcional, en Madrid y Barcelona, que hay muchas
conexiones corporativas, se pueden instalar equipos HL4 que sólo alojen servicios de
GGCC, sin convivir con otras funciones de residencial y L2VPN.
o En estos equipos también se pueden llevar las funciones de los actuales
“bifurcadores”. Esta parte queda fuera del ámbito de esta DTS8
o Están definidos códigos de zona HL3 para “Madrid Empresas” y “Barcelona
Empresas”. En principio, estos HL3s serán iguales que cualquier otro HL3, no
tienen configuración específica.
3.3 COS
Este apartado se remite al apdo. 4.4 de la DTS general [21]. En particular, para los servicios
L3VPN nos acogemos al modelo short-pipe-model, para dejar a los servicios en concreto libertad para
definir sus criterios de clasificación en salida, y garantizamos la transparencia de la red respecto a la
marca CoS del tráfico de cliente.
Las clases de los respectivos servicios, y el CoS de los puertos de cliente debería de mantenerse
igual que antes de la migración, ya que lo que estamos migrando es la infraestructura de red, no los
servicios. Sin embargo, como el CoS de los clientes está integrado en la red, para transportar cada clase
8
Se encarga Fran. Reunión 25/04/16 09:30 E1P8E53
MARZO 2018
Edición 9ª
de cliente dentro de la clase de red, con el código adecuado, es necesario hacer un mapeo. Este modelo
es lo que la RFC3270 denomina pipe-model. En realidad, es un “short-pipe-model”, porque en el egress-
PE se reclasifica el tráfico, con un “multifield classifier” (un filtro cuya acción es clasificar el flujo
definido en una clase en concreto), tras el clasisficador “behaviour aggregate” que se hace observando
el TClass de la etiqueta de la VPN.
Es necesario definir un mapeo, de las clases de los servicios, a las clases de red definidas en el
apartado 3.3.3 de la DTS DTS.r.01.0005 general [21]. La estrategia que seguiremos es mapear en el
HL4/HL3 las clases de cliente a la clase de red Fusión análoga a la de Red IP:
 El tráfico que en RIMA se mapeaba como “BestEffort”, en el HL3/HL4 lo mapearemos a
“BE”
 El tráfico que en RIMA se mapeaba como “ClienteCalidad/PLP-H” (Plata), en el HL3/HL4
lo mapearemos a “AF2”
 El tráfico que en RIMA se mapeaba como “ClienteCalidad/PLP-L” (Oro), en el HL3/HL4
lo mapearemos a “AF1”
 El tráfico que en RIMA se mapeaba como “VoIP” (Multimedia), en el HL3/HL4 lo
mapearemos a “EF0”, ya que normalmente sería VoIP. En algún caso concreto, como
MediaPro, si sabemos que es vídeo, podemos mapearlo a EF1 ó EF2
 En RIMA la gestión y el routing iban juntos, por la clase “Gestión”. En realidad, el routing,
era sólo el de red, porque el del EDC acaba en el PE. En Fusión, esta clase se desdobla en
dos, para proteger al plano de control (routing) de la gestión, que también incluye la
gestión de elementos externos a la red, como los EDCs. Así que el tráfico que antes se
mapeaba a “Gestion” ahora irá a MGNT. Aunque, si hay tráfico de routing (precedencia IP
0o6), se mapearía a “CTL”.
Aplicando la anterior estrategia a los principales servicios de L3:
 DataInterenet, DIBA incluido, cursa todo el tráfico de servicio por BE. La gestión iría por
MGNT. No hay plano de control en la red, el routing PE-CE acaba en el AC del servicio,
por lo que sólo le aplica el CoS de Cliente.
 En VPN-IP:
o El Oro se transporta en AF1
o La Plata se transporta en AF2
o El Bronce (excesos) se transporta en BE
o La gestión, tanto la de TIWS (0o2) como la interna (0o7), se transporta por MNGT
o Multimedia, que incluye la VoIP, se mapea a EF0, salvo que sepamos que el uso
efectivo que el cliente da a esta clase es Video u otra aplicación más pesada.
o Como la precedencia-IP 0o4 no se usa, los paquetes que lleguen con este marcado
(incorrecto) se mapean también a BestEffort
o No hay plano de control en la red, el routing PE-CE acaba en el AC del servicio,
MARZO 2018
Edición 9ª
 MacroLAN, es compatible con VPNIP, para facilitar la convivencia, aunque los

mecanismos de QoS aplicados en el AC sean distintos. Así que el mapeo es el mismo que
arriba, para VPNIP.
 Conectividad Empresas (aka MFE) es muy semejante a VPN-IP:
o El Oro se transporta en AF1
o La Plata se transporta en AF2
o El Bronce (excesos) se transporta en BE
o La gestión se transporta por MNGT
o Multimedia, que incluye la VoIP, se mapea a EF0.
o Como las precedencias-IP 0o4&0o2 no se usan, los paquetes que lleguen con este
marcado (incorrecto) se mapean también a BestEffort
o No hay plano de control en la red, el routing PE-CE acaba en el AC del servicio,
 En las VPNs de Infraestructura, las que conectan nodos de red, bajo control directo de
Telefónica, en principio cada una tiene sus necesidades de conectividad, que habrá que
atender. Pero, en general, lo que se requerirá es una garantía de protección del tráfico en
condiciones de congestión, por lo que, por defecto, se mapeará todo a AF1
3.3.1 PUERTOS DE AGREGACIÓN DE CONEXIONES DE CLIENTE

Este apartado no se refiere al CoS de cliente, el que se aplica en salida del HL4 hacia el AC de
conexión al EDC del cliente. El CoS de cliente pretendemos dejarlo igual, ya que esto es una
modificación de la infraestructura de red que soporta a los servicios, no una redefinición en los servicios.
La excepción a lo anterior es MacroLAN, ya que el servicio tenía una definición ligada a la
infraestructura de red. A lo que se refiere este apartado es a cómo se gestiona la concurrencia de tráfico
entre los distintos tráficos de diferentes servicios, sobre todo cuando el puerto físico está congestionado.
Hasta ahora, teníamos dos casos, en los PEGGCC:
 PCMs, en los que concurrían los DIBA y los macroLAN. Como DIBA es siempre
BestEffort, y MacroLAN tiene Oro/Plata, bien el scheduler-map-chassis de la FPC, bien el
“priority-propagation” del Mx, hacía que se primase al MacroLAN sobre el DIBA
 En los AG12 (conexiones QinQ a las OLT y DSLAMIP), como es todo VPNIP (…y
Conectividad Empresas, que viene a ser lo mismo), podíamos dejarlos concurrir en
igualdad de condiciones (proporcional al shaping-rate), con “per-unit-scheduler”. Algo
semejante ocurre con los OC3 y los E3 de ATM y Frame-Relay
Ahora, con el cambio de arquitectura, ocurren dos cambios:
 En el mismo puerto, por ejemplo en la conexión a la OLT, terminan servicios L3VPN (los
de GGCC, por ejemplo), y servicios L2VPN
 La conexión del HL4 ya va directa al cliente, no pasa por una MAN, que tiene su propio
tratamiento diferenciado
MARZO 2018
Edición 9ª
La solución más directa sería utilizar QoS jerárquico (H-CoS) para reservar, a nivel de puerto
físico, un CIR para cada conjunto de subinterfaces, correspondientes a un mismo servicio o grupo de
servicios.
En el caso de los PCMs, nos ocurre lo contrario, que, como pasamos a tener una conexión directa
con el EDC, desaparece un punto de congestión común a varios clientes concurrentes.
3.4 ESTRATEGIA DE RESPALDO
3.5 IPV6
Al igual que ya estaba previsto para los PEGGCC, y para la Red IP en general, la adaptación a
IPv6 se hará mediante la estrategia 6PE[33], de esta manera, el core de la red puede usar MPLS/IPv4
limpio, sin tener que hacer ninguna modificación para IPv6. Respecto a las VPNs, de manera análoga,
utilizaremos 6VPE[32].
3.6 SEGURIDAD (BASTIONADO)
3.7 MODELO DE ESCALABILIDAD
3.8 CONEXIONES PROCEDENTES DEL HL5

Los servicios de nivel 3 se van a dar en el HL4, o en otro nodo más central, ya sea un SN ó un
HL3/HLC. Para los clientes cuya conexión física o lógica (circuito) llegue a un HL5, esta conexión se
trasladará mediante un PWE, usando la tecnología PHT, hasta el HL4, que será donde se termine el túnel
MPLS y se ligue al punto de servicio L3.
Algo semejante se está ya haciendo en el ámbito de los PEGGCC, para los clientes full-routing de
DIBA en provincias sin Mx, según se explica en el apartado 4.2.4 de la DTS[1][10].
Según se indica en el apartado 3.5 de la DTS general de Fusión [21], las conexiones de clientes
L3VPN que llegue al HL5 agregadas a través de una interconexión con la red de acceso (AN), vendrán
agrupadas por SVLAN, y cada SVLAN se enviará en un PWE independiente al HL4 del que cuelga o
SN correspondiente. En el caso de las conexiones directas, con EDCs dedicados (macroLAN), será el
puerto entero, el que se envíe en un PWE con encapsulación de tipo “Ethernet” (“4”).
Se han definido cuatro tipologías de SVLAN de servicios L3VPN. No quiere esto decir que sólo
vaya a haber una SVLAN de cada tipo entre cada AN y el HL4/HL5 al que se conecta. Estos tipos son:
 SVLAN para Conectividad Empresas (MFE)
 SVLAN para VPNIP
 SVLAN para DI-FTTH sin Full-Routing
 SVLAN para DI-FTTH con Full-Routing (esta va al SN de FR, no al HL4 del que cuelga el
HL5)
Se descarta, explícitamente, que el acceso “fibra directa” de VPNIP se asigne sobre un HL5.
Cuando un cliente quiera, físicamente, eso, se le reconducirá a una conexión macrolan, que es eso
mismo, y se puede conectar a un HL5. Y, si se configura como un “VLAN P2P”, el CoS es equivalente.
En el QUE de VPNIP se va a indicar esta exclusión para que los sistemas de tramitación lo impidan
contratar.
MARZO 2018
Edición 9ª
3.8.1 QOS
Como ya se ha indicado en el apartado 3.5.2 de la DTS general de Fusión [21], los HL5 sólo van a
clasificar por la cabecera de trama Ethernet, ya sea por el 802.1p o por la VLAN-id.
En la arquitectura anterior, las VLANs de MacroLAN y de accesos QinQ a VPNIP/ConEmp se
transportaban en la MAN con “Calidad de cliente”. Eso quiere decir que se atendía al marcado 802.1p
tanto en las conexiones con el AN/CPE, como en las conexiones con el PEGGCC, y esto determinaba la
clase de red (TClass MPLS) con el que la trama VPLS viajaba por la MAN. Pero, en la práctica, sólo en
MLAN, tanto el CPE como el PE marcan el 802.1p de las tramas, con lo que sí que hay un tratamiento
diferenciado en la MAN, en caso de congestión. En el caso de VPNIP QinQ/ConEmp, como ni el
PEGGCC ni el CPE marcan el 1p, este se queda a cero y, en la práctica, el comportamiento es el mismo
que si tuviéramos “calidad de red=normal” en la MAN. En este caso de las VPE’s, aunque no se usase,
sí que Servicios asumía que podía empezar a usar 1p en cualquier momento, tanto en el EDC como en el
PE, y que tanto la MAN como el AN iban a ser transparentes a esa marca, que no la iban a reescribir, y
que la iban a replicar en la SVLAN, y que, al menos en el caso de la MAN, esa marca se iba a atender9.
En el modelo continuista, que es la política general que estamos siguiendo en este proyecto, ya que
es un proyecto de migración de servicios, no de redefinición de los mismos, tendríamos que trasladar la
lógica del anterior párrafo a Fusión. En el caso de AN’s conectados directamente a HL4, no tendría
sentido, porque la fibra directa entre AN y HL4 no puede tener congestión en su interior, y el AN no
tiene DiffServ. Pero, en el caso de AN conectado a HL5, sí que se puede trasladar el CoS del VPLS
entre PEGGCC y AN/CPE (VPE/VLNAC…) al CoS de red en el L2VPN P2P (PWE), en el troncal
HL5-HL4.
En subida, aunque el tráfico de los ANs venga todo con 802.1p a 0, lo vamos a clasificar, con el
mapa “CLIENTE-RESTO-VPNS”, con lo que en subida se puede gestionar la posible congestión en
salida del puerto uplink del HL5 hacia el HL4. En el caso de los CPEs MacroLAN, como sí que viene
diferenciado por 1p, sí que tendremos tratamiento diferenciado (DiffServ de red).
En bajada ocurre algo semejante. En el caso de AG12’s, el PS/PxC no tiene reescritura de 1p ni de
TClass en salida, como no lo tenía el puerto AG12 del PEGGCC ni el PEACC de la MAN al que se
concetaba, y el tráfico, de facto, va por la clase de red BE, con lo que en caso de congestión en salida del
puerto del HL4 hacia el uplink del HL5, este tráfico competirá en igualdad de condiciones con el
residencial (BNG/VINET). En el caso de HL4-NOK, en caso de congestión en salida del PxC
compartido con otros servicios, ocurriría lo mismo. Para conexiones MacroLAN en bajada, como se
hereda la regla de reescritura ieee802.1 “macrolan” del PEGGCC, sí que se impone una marca DSCP,
que se puede mapear al TClass, y priorizar y garantizar caudales, tanto en salida hacia el HL5 como en
salida del PxC del HL4-NOK.
En bajada, el CoS de cliente se implementa, de manera jerárquica, y atendiendo a información
(marcas) L3, en el HL4, y sale del HL4 conformado al caudal contratado para el acceso por el cliente,
sin que el HL5 tenga que hacer nada más ya. El tráfico baja al HL5 clasificado en la clase de red
correspondiente para que, en caso de congestión del uplink de HL5 en bajada, se descarte antes el tráfico
menos prioritario (BE/Bronce)
9
Correo de Carlos del martes, 11 de abril de 2017 13:49
MARZO 2018
Edición 9ª
3.8.2 ESPECÍFICO POR SUMINISTRADOR
Juniper
JunOS requiere ctl-word en sus PWEs para hacer PHT, lo que plantea un problema de
incompatibilidad con HL5s Huawei, que no lo soportan.
La entidad en la que se instancia el PWHT es el “ps” “Pseudowire Services (interface)”, y está
anclado mediante un lt- a los recursos de ¼ de MPC, lo podemos asimilar a la bahía de media-MIC.
Tenemos un ps por PWE, pero tenemos el problema de que no tenemos contadores y, sobre todo, de que
la caída del PWE no tira el PS. En cuanto a HCoS, disponemos, en principio, de los mismos mecanismos
que un puerto físico
Nokia
Utilizamos el PXC de tipo “hair-pin”, que, además, permite dar una solución homogénea a los
puertos que acaban en las tarjetas de 48/60puertos FE que sólo soportan L2VPN.
En Nokia el PxC es compartido entre todos los PWEs que comparten recursos físicos. Los recursos
físicos salen de “condenar” uno o varios (LAG) puertos. Al compartir el anclaje con el PWE con otros
PWEs de otros servicios que también hacen PWHT, el HCoS tiene que ser compartido con ellos, lo que
complica la solución. Puede que el PxC esté congestionado, aunque no haya congestión en el puerto del
HL5 o viceversa, puede que al HL5 le llegue, agregado por varios PWEs más tráfico que la velocidad de
línea. Pdte propuesta NOK
Otro problema que tenemos con Nokia es que, cuando cae el PxC, si eso es posible (interfaz
interno, supongo que se refieren a caída de las tarjetas de línea de las que toma recursos), se tira el PWE,
pero no ocurre en sentido contrario: la caída del PWE no te tira el PxC. Para suplir esta carencia, se
apuntan dos opciones:
 BFD, pero se desestima, porque requiere interoperabilidad con el CPE, si es L3, y cambiar
plantillas de servicio, o soporte por parte del HL5, si es MPLS [34].
 802.1ag [37], aka CFM (Y1731), también de improbable integración con el HL5
Por lo que se opta por una tecnología propietaria de Nokia, pero que es local al HL4, igual que
PxC: “operational groups”, que es una especie de script, suponemos que análogo a los event-script de
JunOS, que realiza una opción, en este caso tirar el PxC, cuando ocurre un evento, en este caso la caída
del PWE asociado. Pdte propuesta NOK
3.9 MTU (Y MRU)

La política general de MTU de Fusión está recogida en el apartado 3.4 de la DTS general de red
[21], que este apartado desarrolla y concreta para L3VPN/GGCC.
Todos los circuitos de acceso a servicios GGCC, ya sean VPNIP, Conectividad Empresas ó
DataInternet, ya sean 802.1q ó QinQ, Fibra directa o a través de OLT/DSLAM, tendrán una ip-mtu de
1500. Cuando el puerto físico, en previsión de futuras necesidades, tenga la MTU subida, habrá que fijar
explícitamente a 1500 la MTU del subinterfaz en provisión.
MARZO 2018
Edición 9ª
La MRU, en JNPR es indefinida. Lo mismo ocurre con ALU, al menos en lo que a L3 se refiere,
cuando hay un tramo L2, hay que tener en cuenta también la “service-mtu”10.
10
Correo de Hugo del 26/05/16
MARZO 2018
Edición 9ª
4. DESCRIPCIÓN DETALLADA
4.1.1 ANÁLISIS OPCIONES BGP: IMPACTO SEGMENTACIÓN DEL CORE EN MÚLTIPLES ASS
SOBRE LAS SEDES VPN CON ROUTING BGP
Nota: este apartado no aplica al diseño final elegido para la red Fusión. La red Fusión va a constar
de un único AS. Se mantiene este apartado como justificación del uso de iBGP en las sesiones entre
áreas, para que no se pierda el histórico.
El impacto dependerá de la opción elegida para estructurar la distribución de etiquetas de
transporte mediante BGP-lu:
 En el caso de utilizar iBGP, la migración sería transparente para los clientes, ya que
seguirían viendo toda la infraestructura de Telefónica como un único AS público (3352)
 En el caso de utilizar confederaciones y eBGP, tampoco esta opción se reflejaría en el
AS_PATH de las rutas del cliente, siempre y cuando el AS del cliente no fuera uno de los
confederados, de los utilizados para las “zonas HL3”
 Si utilizásemos eBGP, con AS’s públicos, el routing de cliente, aunque fuera a pasar por un
adress fámily distinto, tendría que saltar entre varios AS’s, el de la zona HL3 del egress-PE
de la VRF que anuncia la ruta, el del tránsito, y el de la zona HL3 que recibe la ruta. Y
estos tres AS’s se observarían en el AS_PATH de las rutas de cliente que pasásemos al CE.
En la arquitectura definitiva, esto no supondría problema en la práctica, ya que todos los
AS-PATH tendrían igual longitud, pero, durante la migración, los EDCs tenderían a utilizar
la infraestructura sin migrar, por tener un AS-PATH más corto.
Dado que la opción finalmente elegida para la distribución de etiquetas por BGP es iBGP, cabe
esperar que el impacto sea nulo.
4.2 SOLUCIONES PARTICULARES

Este apartado recogerá el análisis de la integración en la Red Fusión de soluciones no estándar y
que no estaban contempladas directamente en el modelo de red MPLS e2e de la RFQ
4.2.1 CSC PARA BACKUP MPLS A LA RTJAV3

Nos referimos a la solución para dotar de redundancia a la red de transporte MPLS que se implantó
en RTJAv3, y las interconexiones de los LAAC&LABC en 2015 [4].
La solución automática sería llevar la VPN de CSC, como el resto de las VPNs de JdA conectadas
a las interconexiones, inter-AS tipo A, a la RTJAv3, a los HL4. Pero, por volumen de tráfico, y por el
carácter centralizado a nivel de provincia, tendría más sentido llevarlo al HL3, aunque fuera una
solución técnicamente más heterogénea con el resto del modelo de Fusión de Red. En principio, esta era
la opción que se iba a intentar: dejar las ICX con los LAAC&LABC en los HL3, que son equipos que ya
van a tener que soportar L3VPN para Infraestructuras. Sin embargo, finalmente, Planificación decidió 11,
por homogeneidad, llevar estas interconexiones al HL4 como cualquier otra VPN.
11
Reunión 25/04/16 09:30 E1P8E53
MARZO 2018
Edición 9ª
4.2.2 INTERCONEXIONES CON LA NGN

La interconexión de GGCC con NGN, para proporcionar servicios centralizados de SBC a las
VPNs de los GGCC, está montada en una serie de conexiones duplicadas en Madrid; Barcelona, Sevilla
y Málaga.
Al igual que ocurre con RTJAv3, estas VRFs de GGCC no están distribuidas geográficamente,
sino centralizadas en unos puertos específicos, de unos nodos en concreto, y reciben tráfico del resto de
la red. Alternativas posibles:
 Solución automática: dejarlos en un HL4. El problema de esta solución es que te llevas
mucho tráfico MM a un equipo que no es tan grande.
 Dejar las interconexiones en equipos HL3. En el caso de Madrid y Barna, sería el “HL3 de
Empresas”.
 Dejar estas interconexiones en “Service Nodes” especializados, dentro del área de tránsito.
Esta opción puede ser menos eficiente económicamente, pero está más alineada con la
arquitectura de referencia “seamles MPLS e2e” [29]&[36] que se está usando en esta red.
Finalmente12, se ha decidido que estas conexiones, que son puertos agregados con poco tráfico,
vayan a un “PE Residual” (aka HL4-ATM)
4.2.3 ACCESOS ATM

Los nodos HL4 del escenario 1 de la RFQ –que es el que finalmente se escogió- no contemplaban
accesos no-ethernet, ya que se consideran legacy. En principio, esos accesos se van a quedar en “PE’s
legacy”.
Sin embargo, también se está planteando la opción, para 2017 de meter equipos “HL4-ATM”, que
sólo tendrían conexiones de cliente ATM. Estos equipos no están contemplados en el plan inicial de
Fusión, por lo que no forman parte de la validación original, serían un desarrollo posterior.
A estos equipos ATM también irán los usuarios residenciales, ADSL/ATM (DSLAM clásico) 13. La
excepción son los clientes con IP estática e IP fija (PPPoA con IP permanente), que se quedan en los
CANGs actuales, en nuevas S-VLANs dedicadas 14, aunque esa ya es una cuestión a tratar en la DTS de
BNG[23].
Todos los HL3 van a tener un HL4-ATM coubicado, pero puede que también haya HL4-ATMs no
coubicados
Estado a 25/04/1615: no está claro si los HL4-ATM (aka “PEs residuales”) van a ser compartidos
con BNG, en cuyo caso habría que validar una JunOS convergente para LAC y GGCC, o van a ser
12
Reunión 25/04/16 09:30 E1P8E53
13
Según correo de migración “Acta reunión migración conexiones a Red Fusión” del lunes, 25 de enero de 2016 11:32
14
Según correo de Miguel del jue 28/01/2016 19:13
15
Reunión 25/04/16 09:30 E1P8E53
MARZO 2018
Edición 9ª
dedicados. Se aparca este tema hasta que se tome una decisión, pero, no parece que se aborde este tema
hasta 2017
4.2.4 HLC
Se está planteando, para ciertas “conectividades sensibles”, como RADIUS ó DNS, montar unos
equipos especiales, llamados “HL-C” (HL-Control). Habrá alrededor de una pareja de estos equipos por
área HL2. Y funcionan como una pareja, no sólo es que haya dos.
Los HL-C se conectan sólo a HL2 y sólo con BGP etiquetado, porque no queremos que hagan
tránsito.
4.2.5 PES LEGACY

Ciertos accesos que por su obsolescencia, poco número de clientes o complejidad no merezcan la
pena ser migrados a Fusión, se mantendrán en los PEs de la Red IP original sin modificar. Lo único que
habrá que hacer es meter BGP-lu en esos equipos, para que se puedan conectar con la red Fusión. A
estos equipos se les ha dado en llamar “HL4-ATM”, o “PE residual”, aunque no tienen Hw, ni Sw, ni
configuración, ni sistemas de HL4 de Fusión. El matiz entre HL4ATM y el “PE residual” es que el
primero sólo puede ser un Mx, mientras que el segundo puede ser cualquier modelo/fabricante de los
preexistentes en Red IP Única
Una lista no exhaustiva de estos equipos sería:
 Los equipos PEGGCC, serie M, Frame-Relay. Está previsto concentrar todos los DLCIs de
España en dos parejas de nodos, uno en Barcelona y otro en Madrid16.
 El PE-CM [5]
 Los LNSs de Accesos y Respaldos Móviles a VPNIP [6]
 Los equipos de acceso para Movistar Intranet, en concreto:
o Los “cifradores” [7]
o Los “concentradores GRE” [8][9]
 Los equipos de acceso para NetLAN y, en general, todos los que ahora están en el CRR.
 Los PEGGCCs dedicados a un cliente, como el de Acens o el de la Generalitat de
Catalunya
CRR
En los “CERBAs de Empresas” [19] permiten la conexión de routers de propósito específico
(NAT NetLAN, IPSec, LNS, etc…) a la red a través de una “VLAN MPLS”. En estos centros se
conectan muchos de los PE-legacy a los que se refiere este apartado 4.2.5.
Estado a 25/04/1617: Pendiente de decisión a dónde se migran estos centros, o si se dejan en los
actuales SRRAs
16
MARZO 2018
Edición 9ª
4.2.6 INTER-AS VPN

El “POI” de VPN-INT se llevará a un HL4 coubicado con un HL3 18. Este HL4 será un “HL4-
ATM” (aka “PE Residual”) 19. Por tanto, no es necesario realizar pruebas de HL4 “normal”, y se queda
con las plantillas y sistemas actuales en los equipos actuales donde está el POI VPN-INT. Se elimina
pues, la entrada correspondiente que había en borradores anteriores de este documento, en el apartado
del bloque III de pruebas (6.8.3)
4.2.7 DIBA FULL-ROUTING, PHT

La actual solución para permitir la prestación del servicio full-routing a clientes DIBA ubicados en
provincias sin PEGGCC Mx, descrita en el apartado 4.2.4 de la DTS del PEGGCC [1], está ya bastante
alineada con la filosofía MPLS-E2E de la red Fusión, por lo que la migración será bastante directa.
Únicamente hay que montar el PWE directamente desde el HLn al que se conecte el cliente, en vez de
empalmar dos servicios L2VPN, uno en la MAN y otro en Red IP Única, como se hace actualmente.
Parece20 que este SN no va a ser un equipo dedicado sino una de las funciones del “PE Residual”
(aka “HL4-ATM”). Por tanto, los SN de DIBA-FR van a ser monovendor, JNPR, como los PEGGCC.
Se heredan, por tanto, en este (sub)proyecto, los reparos que ya se indicaban en la AIP de PWHT:
 Dado que el mismo PE termina el PWE y lo liga a un interfaz de servicio (PS) sobre el que presta
el servicio de nivel 3 (DIBA), cabría esperar que, cuando caiga el túnel Martini, arrastre consigo
al interfaz lógico sobre el que se establece la sesión BGP, y a la propia sesión, pero se ha com-
probado en maqueta que no es así. Esto no supone una degradación respecto a la arquitectura ac-
tual, aunque sí con respecto a lo que se esperaba lograr con este cambio de diseño, por lo que se
ha abierto al suministrador el reparo PR1008809. ¿Sev 2?
 Otro reparo, que afecta a los informes de prestaciones y de “alta carga”, consiste en que los con-
tadores de tráfico del interfaz de túnel interno, lt-<mpc>/<bahía>/0 no computan el tráfico de los
interfaces ps que lo utilizan como “anchor-point”. Pendiente de asignar código por el suministra-
dor. ¿Sev 3?
Estos reparos no sólo aplican a DIBA-FR, sino a cualquiera otro de los casos de uso de
desacoplamiento del servicio L3VPN del borde MPLS, como, por ejemplo, las conexiones procedentes
de HL5, del apartado 3.8.
Respecto al QoS de este servicio: por continuidad con la arquitectura actual, serán el EDC y el SN
los que controlen el caudal, en el AN, que hace funciones análogas a las del actual PE de la MAN del
acceso del cliente, no se aplicará ninguna limitación. Lo único que hay que hacer es marcar los paquetes
MPLS correspondientes a este PWE con TClass de AF1, para protegerlos en tránsito.
17
Reunión 25/04/16 09:30 E1P8E53
18
19
Reunión 25/04/16 09:30 E1P8E53
20
Reunión 25/04/16 09:30 E1P8E53
MARZO 2018
Edición 9ª
DIBA-FR sobre acceso MLAN

En una gran mayoría de los casos, DataInternet no tiene su acceso dedicado, sino que reutiliza el
acceso MacroLAN que se utiliza para acceder al servicio L3VPN homónimo. En este caso, la migración
de este servicio va ligada al NDPS que se ha abierto para redefinir ese servicio (MacroLAN).
Existe un caso peculiar, que es cuando un acceso conectado a un HL5 hay que llevarlo en un PWE
agregado de puerto, hasta el HL4, donde se “despeina” en VLANs, y, la VLAN de DIBA, si este es full-
routing, se vuelve a meter en otro PWE, ya este de VLAN, que se reenvía al SN de Full-routing. De esta
manera, el conformado del tráfico DIBA se hace en el HL4, concurriendo con el resto del tráfico del
acceso MLAN del cliente, pero el servicio L3 se da en el SN.
4.2.8 CDS
Los Centros de Servicio son CPDs donde se ubican plataformas que proporcionan un servicio a los
clientes RPV de GGCC. En ocasiones, estos servidores tienen que ser accesibles desde la VPN del
cliente, por lo que se requiere un acceso desagregado a las VPNs de GGCC. Para ello, tiene que existir
un PE de servicios (aka “CE Empresas”) en el que se instancien VRFs de las VPNs de los GGCC. Para
proporcionar conectividad MPLS a las VRFs hay que pasar al CdS etiquetas de transporte hacia los PEs
de GGCC, para lo que se establece una sesión BGP-lu entre un CANG y el “CE del CdS” [17][18].
Los CdS, y eso incluye a los “PEs de Servicios” y los “CEs del CdS”, están, en el momento de
edición de esta DTS, fuera del ámbito de responsabilidad de Tecnología de Red IP & Agregación, por lo
que trataremos de migrar la conexión con el mínimo impacto en la configuración del CE-CdS.
En principio21, la intención es migrar estas interconexiones al nivel HL4. Nos conectaríamos a 2
HL4 por redundancia. No hay interés por subirlo al HL3, porque parece que no mueven mucho tráfico.
No se descarta la opción de conectarlo a HL3 en un futuro, pero, de momento, no hay que desarrollar esa
opción.
4.2.9 LAN’S DE PROPÓSITO ESPECÍFICO

La plantilla del PEGGCC contempla una serie de conexiones LAN (Ethernet, normalmente sin
802.1Q). Estas conexiones no son conexiones directamente de clientes, pero son necesarias para prestar
los servicios a los GGCC
LAN de conmutados
También llamada “LAN de servicio”. Está enrutada en la tabla de routing global (TRG), y
originalmente se montó para conectar a Internet a los usuarios conmutados (dial-up) que entraban por
los RAS22. Esta LAN se implementaba, normalmente, en un “catalyst de servicio”. Posteriormente se
reutilizaron para conexión a la TRG de una serie de equipos variopintos, como sondas, servidores,
colectoras…
Esta LAN se va a llevar al “HL4 coubicado” 23 (coubicado con los servidores, no con el HL3). No
se mantiene el "catalyst de servicios", se conecta directamente al HL4, que tendrá que implementar la
21
Reunión 25/04/16 09:30 E1P8E53
22
Aka “Servidores de Terminales”: Ascend, 3Com, Lucent TNT…
23
Reunión 25/04/16 09:30 E1P8E53. Iván se encarga de validar IRB
MARZO 2018
Edición 9ª
LAN, y dar la conectividad L3, o sea, tendrá que hacer IRB. La validación de IRB está fuera del ámbito
de L3VPN.
LAN de servidores
Para dar conexión a la TGR a las estaciones de trabajo que alojaban los servidores RADIUS, DNS,
etc… que se requerían para los servicios GGCC, existe una “LAN de servidores” en algunas provincias
principales (Madrid, Barcelona, Valencia…).
Existe en curso un proyecto, por parte de “Planificación de Control”, para la compactación de los
servidores repartidos por la red en una serie de LANs, del que está pendiente el desarrollo de este punto.
Si esta LAN se mantuviera, su destino natural sería el HL-C
LAN de gestión
Los PEGGCC aún mantienen conectadas, al menos en muchos centros, LANs de gestión
procendentes de NURIA. Estas subredes están metidas en la “VPN de gestión” (“vpn1”). En algunos
centros hay un “switch de gestión”, y en otros, esta VLAN es una más del switch del centro. Los routers
de consolas para acceso fuera de banda a los equipos están conectados a estas VLANs, pero tienen
conexión redundante por Frame-Relay
En fusión se contempla la necesidad de contar con VLANs de gestión, pero, por criterio de
seguridad, los routers de consolas no pueden estar en esa VLAN, sino en otra, de nueva creación: la
“VLAN de emergencias”. La conexión fuera de banda al router de consolas se hará por satélite, aunque
ese proyecto está fuera del alcance de esta DTS.
En principio, lo previsto es mover las conexiones de gestión conectadas a las LANs de gestión de
los PEGGCC a las nuevas LANs de gestión del HL4, y las conexiones de consola, a los routers de
consola en la LAN de emergencia.
4.2.10 CG EMPRESAS
Van al HL4ATM, aunque se migren a GE
4.3 TRADUCCIÓN DE LAS PLANTILLAS DE PROVISIÓN DE SERVICIOS L3VPN

Al contrario de lo que ocurre en otros ámbitos, en GGCC, las plantillas de provisión de servicios
en el PEGGCC las proporcionaba DSyS, ya que en Tecnología de Red nos limitábamos a la
infraestructura común de red sobre la que se prestan los servicios. Seguramente esto cambie, una vez
migrados los clientes al HL4, pero eso es una cuestión organizativa, que excede del alcance de este
documento, que es técnico. Si lo indicamos aquí es sólo por contexto.
Dentro del alcance de este proyecto de Fusión de Red, asumimos en Tecnología de Red IP &
Agregación la tarea y responsabilidad de la traducción y/o adaptación de estas plantillas de PdS 24. El
planteamiento es que los entregables de las plantillas traducidas han de estar preparadas para volverlas a
transferir a DSyS, o a otra unidad, una vez completado el proceso. En particular, trataremos de hacer una
traducción directa, sin reestructurar ni reinterpretar las plantillas ni el servicio. Aun así, el ejercicio no
siempre es una recodificación a la sintaxis del OS del HL4 nuevo. Bien por inequivalencias de
24
“Provisión de Servicio”
MARZO 2018
Edición 9ª
funcionalidades, bien por motivos documentales. En este apartado compilaremos las aclaraciones
necesarias a la traducción de las plantillas
4.3.1 HUB & SPOKE

Originalmente había un documento incompleto con indicaciones para la establecer “Modelos
conectividad VPN MPLS”25. Ese fue el primer documento que se pasó a los suministradores para que lo
tradujesen a HL4. Posteriormente DSyS generó otras plantillas más completas 26 para automatizar y
sistematizar esta opción del servicio VPNIP, y tuvimos que pedir a los suministradores que revisasen sus
plantillas de H&S en HL4 para comprobar la consistencia con el nuevo documento de plantillas de DSyS
cuya existencia no conocíamos cuando se lo pedimos a los suministradores.
En el documento de plantillas que DSyS último, se definen dos modelos: estrella y
“estrella+malla”. La configuración es incremental: a todos los clientes se les configura la parte de
“estrella” y, los que también quieran “+malla”, se les añade la configuración del apartado
“estrella+malla”. Sin embargo, cuando se indica el resultado neto final, no coincide con lo que procedía
del modelo “estrella”, porque faltan los términos “VPNIP_Rutas_RIPyESTATICAS” &
“VPNIP_Rutas_BGP”, y porque el término final es un “accept-all”, en vez de un “deny-all”. Aunque en
la práctica el comportamiento es el mismo, la configuración es distinta. Para corregir esta situación, las
plantillas traducidas tienen un accept-all al final de la política, y obvían los términos que redistribuyen
explícitamente las rutas aprendidas por BGP; RIP y estáticas desde el CE
25
D:\Alonso\Telefonica\Servicios\Empresas\Hub and Spoke\Modelos conectividad VPN MPLS.doc
D:\Alonso\Telefonica\Servicios\Empresas\Hub and Spoke\Plantillas Topología en Estrella para PE Juniper series M
26
y MX v1.1.doc
MARZO 2018
Edición 9ª
5. ASPECTOS PARTICULARES POR SUMINISTRADOR
En este capítulo recogeremos lo específico de las implementaciones de cada suministrador, para

que el resto de la DTS sea lo más genérica posible
5.1 ALU
5.1.1 LIMITACIONES TARJETAS MDA DE 60 PUERTOS

Las tarjetas MDA de 60 puertos son tarjetas que están actualmente desplegadas en red, pero que
están en fase-out y por tanto no se incluyen dentro de la RFQ. Sin embargo, Planificación quiere seguir
usando estas tarjetas, tanto en las MTUs que se quedan como HL5 como en las MTUs que se convierten
en HL4.27
Estas tarjetas no pueden funcionar a nivel tres, por lo que las conexiones macroLAN que se lleven
ahí, tendrán que mantener el VPLS, y conectarse a la L3VPN, bien mediante un PWE, cuando sea un
HL5, hacia el HL4 del que cuelga, bien mediante un hair-pin, cuando sea un HL4, hacia otra tarjeta del
mismo nodo, de las que sí que soportan servicios L3.
La solución que finalmente se ha optado, consistente con la solución de los HL5, es conectarlos a
una IOM con capacidad L3VPN, mediante PXC-hairpin (véase apartado 3.8). En este sentido, la tarjeta
va a ser como un HL5 incrustado en el HL4, a efectos de L3VPN.
Pdte desarrollar y analizar
5.1.2 SOPORTE 6PE

No es completo hasta R14
Pdte concretar
5.1.3 IUM
TimOS no implementa la funcionalidad de contadores por término/línea de ACL, ni la de ficheros
de accounting.
Nokia ha propuesto un método alternativo, con scripts que vuelcan sobre una compact-flash, que
habría que adquirir aparte.
Compact Flash externa

Se ha seguido un proceso de consulta 28 sobre la longevidad de estas memorias (CF ó SSD), ya que
existe experiencia con degradación prematura de memorias de estado sólido sujetas a escrituras
27
Correo de JMCrespo del lun 27/07/2015 12:28
28
Preguntado el jue 17/03/2016 17:27
Pdte respuesta (se lo han pasado a Fco Javier Martín Gcía, de "producto")
MARZO 2018
Edición 9ª
constantes29. De hecho, si ALU ha implementado esta funcionalidad en una CF externa es para proteger
al a CF de sistema. Podemos resumir el debate con los siguientes resultados:
 La tecnología de la tarjeta es Compact Flash, al menos en los 7750/7450. Los 7950 (HL3)
sí que tienen SSD, pero en esos equipos no va a haber servicios L3VPN.
 Respecto a la fiabilidad y longevidad de la CF que suministra Nokia:
o Es una CF de 2GB, con formato FAT32 y estructurada en sectores de 128KB
o Cada sector tiene una vida estimada de >100.000 ciclos de escritura
o Para evitar que algún sector crítico se degrade prematuramente, por estar sujeto a
muchas reescrituras, que era un problema clásico de estas tarjetas, dependiendo del
sistema de ficheros usado, “Las CF implementan un mecanismo de desgaste
dinámico para repartir la escritura de forma homogénea”30
Se ha comprobado en maqueta 31 el tamaño de los ficheros que se generan, ó el tamaño
medio por registro, para calcular cuántos años tardaríamos en hacer 1.6e+09 escrituras de
bloque32. Supongamos que tenemos 4K conexiones en un HL4 (valor de referencia en la
RFQ), y que la mitad de esas conexiones son MFE, por lo que no se recogen contadores.
Recopilando 10 contadores cada 5’ para cada una de las otras 2000 conexiones, nos salen
240000 contadores recopilados por hora.
 El MTBF durante la “vida útil”33 es de 296.84 años, lo que hemos de interpretar como 3.4
errores de escritura, de media, por cada mil CFs en uso y año
29
Logs del ArrowPoint
30
Dynamic wear leveling
31
T.356
32
En una CF de 2GB tenemos 16k sectores de 128KB.
1.6e+04 sectores * 1e+05 ciclos de escritura/sector = 1.6e+09 ciclos de escritura a lo largo de la vida útil de la CF
33
No llega a quedar claro sin la vida útil son 15años o 1.6 miles de millones de escrituras de bloque, pero nos
quedaremos con el menor de los dos
MARZO 2018
Edición 9ª
Ilustración 1: “curva de la bañera” de la frecuencia de fallos en función del tiempo34
 “La vida útil esperada de la CF serían 15 años en condiciones estándar de trabajo (25ºC y
régimen nominal de escritura/borrado). Es la información que proporciona el fabricante.”
De los resultados de maqueta, parece que, en el peor de los casos, no se generan más de 50MB/h
de datos, con lo que no parece que haya riesgo de que agotemos el número máximo de reescrituras de
sector a lo largo de la vida útil de la tarjeta.
400*24*365*15=52560000<<1.6e+9
En los CSC de Imagenio se está usando también la CF. Pdte informe caso de uso
Hay que tener en cuenta que los ficheros se generan primero en crudo, y después se comprimen,
con lo que las escrituras son dos, y el número total corresponde a la suma de los correspondientes al
tamaño del fichero comprimido y sin comprimir
Servicios
Por suerte, VPNIP no usa IUM, los PIP sólo se pasan a MacroLAN, lo que nos da tiempo para
articular una solución. Además, los eventuales desarrollos necesarios en IUM/SGI, se podrían integrar
en el NPDS de MacroLAN. De todas formas, PIP hubiera tenido que cambiar, si las sedes MacroLAN se
integran en RPV2.0, porque en VPNIP los excesos de oro se reclasifican, y en macroLAN, se tiran, con
lo que el cómputo de los contadores varía.
34
Ilustración procedente del hilo de correo con Nokia
MARZO 2018
Edición 9ª
5.1.4 TEMPLATES
TimOS dispone de la opción de definir partes genéricas de configuración, templates, que se
pueden aplicar a cada instancia particular de un cliente, con lo que se reduce el tamaño total de las
configuraciones, al reutilizar segmentos. De manera análoga a los apply-groups de JunOS. Solicitamos a
ALU que aproveche esta funcionalidad en las plantillas que entregue de los servicios L3VPN
5.1.5 BFD-RIP
TimOS no incluye soporte para BFD en RIP, ni se solicitaba explícitamente en la RFQ.
En consulta a Servicios, nos confirman que sólo se usa para un caso de backup de Conectividad
Empresas, y que están de acuerdo en considerarlo “reparo no bloqueante”35.
A Nokia se le solicita:
 Que abran reparo, para solicitar que se incluya la funcionalidad en roadmap.
o La petición que redactó ALU y dimos el visto bueno fue:
Objetivo:
Dotar a RIP de una rápida detección de caída del peer que evite los largos timeouts de RIP.
Funcionalidad:
Las sesiones quedarían configuradas en un modo passivo o similar de forma que los primeros up-
dates intercambiados disparen la sesión BFD entre el router y el peer.
Ante caída de la sesión BFD, el peer se considera caído y se retiran las rutas aprendidas por dicho
peer.
La funcionalidad BFD se configura bajo el contexto del protocolo RIP de forma similar a como se
configura en cualquier otro protocolo (bfd-enable).
Medidas de seguridad:
Para evitar activar sesiones BFD no deseadas, se podrá establecer una política en la que se listen
los peers permitidos contra los que abrir sesión BFD.
O&M:
Al igual que con el resto de las sesiones BFD sobre otros protocolos, deberá poderse monitorear el
estado.
o Pendiente código
o “No estará en R15 y está por ver si estará en R16”36
Definitivamente37, desestimamos la opción de utilizar scripts para enganchar RIP a BFD. En
principio, lo quitamos sólo en el HL4-NOK, pero o dejamos en el HL4-JNPR, aunque no sea
35
Correo de Carlos García del mié 09/03/2016 9:27
36
Dicho en la reunión de seguimiento de NOK del 27/04/16
37
Reunión de seguimiento NOK del 04/05/16
MARZO 2018
Edición 9ª
homegéneo, así se queda más fácil para cuando despleguemos la versión de TimOS que implemente la
“nueva funcionalidad”38.
5.1.6 MFE
Para el servicio MFE o conectividad empresas el modelo de CoS que se ha aplicado a las
situaciones de contratación con/sin voz (traducido a nuestras plantillas es considerar o no la clase de
multimedia) no se ha seguido el mismo modelo que el seguido para Juniper. En Nokia hemos aplicado
siempre el modelo con voz (con multimedia) y en caso de que no se quiera el servicio de voz, lo que se
va a hacer es no importar esa community en las políticas de importación.
5.2 JUNIPER
5.2.1 EGRESS-SHAPING-OVERHEAD
Cuando hacemos shaping, hay que descontar una serie de créditos del token-bucket, cada vez que
se envía un paquete, pero, si el caudal permitido por el circuito tiene en cuenta todo el entramado, hay
que tener en cuenta el overhead de trama, con el encapsulado de nivel 2 (Ethernet + 802Q), y el de línea,
como el “interframing-gap” (IFG) y el preámbulo (estamos hablando de Ethernet). Las tarjetas IQ2
suman sistemáticamente 26 octetos: 14 de Ethernet, 8 de QinQ y 4 de FCS. En las pruebas del Mx [13],
se comprobó que Trio (Mx), contaba también con los 20 octetos de IFG+preamble. En aquel momento,
para poder reutilizar los desarrollos de sistemas, que tenían el cálculo del overhead ajustado para la IQ2,
se decidió ajustar este cálculo, configurando
chassis fpc x pic x traffic-manager
…con lo que modificábamos el valor por defecto del byte_adjust, de 24 a 4, y así aparece
actualmente en las plantillas del PEGGCC.
Este comando es común para toda la MIC, pero en los PEGGCC no nos afecta, porque todos los
puertos que hacen shaping son AG12’s. Sin embargo, para el HL4, que el puerto es compartido con otros
servicios, y la MIC es compartida con otros puertos, no podemos contar con este ajuste, de manera que
las plantillas de provisión de L3VPN, para MFE y VPNIP, no podrían limitarse a trasladar la
configuración shaping-rate del PEGGCC, sino que tendrían que ajustar el overhead, para compensar por
el cambio del byte_adjust, que sube en 20 octetos, lo que obligaría a subir el shaping-rate para
compensar.
Existe un comando equivalente, “overhead-accounting”, que se puede configurar en el traffic-
control-profile, y que permite hacer lo mismo con granularidad de ifl. El equivalente a “egress-shaping-
overhead 0” es “overhead-accounting –20”, y en ambos casos el overhead resultante son los 4 octetos de
CRC.
5.2.2 INTERFACE-SPECIFIC
Actualmente, los servicios RPV de GGCC, en sus filtros, incluyen el comando “interface-
specific”, para que se genere una instancia del filtro cada vez que se aplica a un interfaz. Sin embargo,
38
Acordado con Carlos Gcía Gcía, correo del mié 04/05/2016 13:01
MARZO 2018
Edición 9ª
como ya el filtro se configura específico para cada interfaz, esta configuración es redundante. Esto
ocurre para todos los servicios RPV-GGCC, pero no para DataInternet.
Juniper nos ha informado39 de que esta configuración redundante, aparte de un pequeño
incremento en uso de memoria, por la reinstanciación de los filtros, provoca un sensible incremento en el
tiempo de commit. Por este motivo, aparte de otras acciones de mejora, fuera del alcance de este
proyecto, se ha decidido que, al trasladar la plantilla de los servicios GGCC al HL4, se haga sin
“interface-specific” cuando no sea necesario.
Es necesario mantener “interface-specific” en los siguientes casos:
 Cuando el cliente contrate IPv6 con dual-stack, para poder utilizar “logical-interface-
policer”
 En los Conectividad Empresas, porque se hace uso del “logical-bandwidth-policer”
Otro impacto de la eliminación de “interface-specific” es IUM, porque los contadores dejarán de

traer, sufijados, el nombre del interfaz y el sentido. Debido al comando “interface-specific”, el nombre
de los contadores, tal cual aparecen en un “show firewall filter …” o en un fichero de accounting, trae
sufijado el interfaz y el sentido. Por ejemplo
plata_cur -> plata_cur-ge-3/2/1.702-i
Cuando quitamos interface-specific los contadores de dos filtros distintos siguen siendo
independientes, aunque tengan el mismo nombre, porque cuelgan de filtros distintos. Si el formato de los
ficheros de accounting cambia, habría que avisar a IUM y no sé si a alguna otra herramienta o
procedimiento que se base en el “show firewall filter …”
39
Correo de José Cid del lun 15/02/2016 12:23, con código de referencia [fusion/107357]
MARZO 2018
Edición 9ª
6. MIGRACIÓN DE CONEXIONES DE CLIENTE
En ningún caso un PEGGCC, ni un CANG-J, se van a convertir en un HLn. De manera que las
migraciones de los clientes se realizarán llevando el servicio al HL4 correspondiente, que será la MTU ó
PEAcc a la que esté conectado el circuito del cliente.
Partimos de un escenario en el que la conexión de un cliente llega a un puerto de un equipo de la
MAN, y este lo transporta, mediante L2VPN, a otro equipo de la MAN, normalmente un PE-ACC,
directamente conectado a un PEGGCC, al que le pasa, a través de un interfaz UNI, 802.1q, el conjunto
de conexiones de cliente correspondientes a esa interconexión.
La primera fase de la interconexión consistirá en establecer conectividad MPLS entre los nuevos
equipos HLn, ó los equipos de la MAN que se reconviertan en HLn, mediante una “pasarela”, según se
explica en el documento general [21]. Una vez el HLn al que llegue la conexión de cliente, tenga
conectividad con la nube MPLS, se podrá desactivar su servicio L2VPN hacia el PEGGCC, y activar el
servicio L3VPN en local.
Aunque se hubiera podido plantear una migración de clientes agregada de todos los clientes de un
puerto del PEGGCC, la estrategia que vamos a seguir es más conservadora: ir migrando clientes uno a
uno, y no desmontar el enlace entre el PEGGCC y el PE-ACC hasta que esté vacío de conexiones de
cliente. Esta lógica se seguirá tanto para los clientes QinQ, que entran por los AG12, para los servicios
MFE & VPNIP, como para los clientes 802.1q, que entran por el PCM, para los servicios MacroLAN y
DIBA
6.1 AG12
Actualmente, los clientes que llegan por una conexión ADSL de un DSMAMIP, o por GPON, a
través de una OLT, se entregan a la REM en QinQ, con una S-VLAN que identifica la asociación entre
equipos de acceso y PEGGCC, y una C-VLAN que identifica la conexión del cliente en concreto.
Para la MAN, sólo existe la VLAN externa, la S-VLAN, que se transporta mediante L2VPN hasta
el PE-ACC conectado al PEGGCC que va a prestar el servicio de nivel 3. Aunque originalmente, en la
FOA de Zaragoza, esta L2VPN se implementó mediante VLL, en la práctica, en todos los demás sitios,
se ha montado como VPLS.
Se va a definir una nueva S-VLAN, entre la OLT y el HL4, para ir metiendo ahí todas las
CVLANs de los clientes que se vayan migrando. De manera que será necesario operar en la OLT para
migrar a los clientes. Pero la ventaja es que así se podrán agrupar a todos los clientes de una OLT en
unas pocas SVLANs. Cuando la SVLAN original se vacíe, se podrá eliminar. Y, cuando en un AG12 no
quede ninguna SVLAN, se podrá desmontar.
Aunque en ALU existe la posibilidad de “despeinar” una CVLAN y servirla en un SAP local, y
enviar el resto de la SVLAN, por un SAP L2, hacia el nodo remoto, se desestima esta posibilidad,
porque40:
 A “Definición de Recursos de la Red” le merece más la pena cambiar de SVLAN, aunque
requiera operar sobre la OLT ó el DSLAMIP, porque así puede compactar la provisión en
unas pocas SVLANs por OLT/DSLAMIP
40
Correo de Jose Roman Parralejo del mié 27/01/2016 14:18
MARZO 2018
Edición 9ª
o Habría que valorar si merece la pena aprovechar para meter a todos los clientes de
VPNIP en una SVLAN, y a todos los de MFE en otra, por si ello pudiera facilitar
una eventual, futura, migración de MFE al CANG
 Se trata de evitar tener una solución diferente para cada tecnología
 La asignación se hace en el nodo de servicio de nivel 3. Si, durante el intervalo de
migración, se asignasen, en la misma SVLAN, CVLANS en el HL4 y en el PEGGCC,
habría que coordinar a ambos asignadores para evitar el riesgo de que la misma CVLAN se
asignase en el PEGGCC y en el HL4
6.1.1 PROCEDIMIENTO DE MIGRACIÓN

Si desglosamos en una secuencia de “tareas atómicas”
1. De partida, el cliente está en la S-VLAN “A” y la C-VLAN “B”
2. Prerrequisitos:
a. La pasarela o el HL3 de la provincia tiene que estar operativa
b. La MTU ó PE-Acc al que se conecta, físicamente, la OLT o el DSLAM tiene que
estar habilitada como HL4. O, en su lugar, la conexión física de la OLT/DSLAMIP
ya se ha movido al HL4 de nueva creación, aunque el servicio que se esté dando sea
una L2VPN hacia el PE-ACC del PEGGCC.
c. La OLT/DSLAM IP ya tiene creada la S-VLAN A’ a la que se van a migrar todos
los clientes cuando se lleven a Fusión
3. En primer lugar, se asigna una nueva C-VLAN, B’, para el cliente. Normalmente, el valor
de B’ puede ser el valor original de B, para simplificar los cambios en la OLT/DSLAMIP.
Sólo es necesario cambiar el valor cuando la CVLAN se solape con la de otro cliente,
procedente de otro PEGGCC u otra SVLAN.
4. Se provisiona, sin activar (deactivate 41/shutdown), al cliente, con la plantilla nueva, en el
HL4, con los mismos parámetros de provisión que tenía en el PEGGCC, pero con la
SVLAN/CVLAN A’/B’
5. En el menor tiempo posible, pero de manera secuencial, se realizan las tres microtareas
siguientes:
a. En el PEGGCC, se desactiva (disable), el circuito de acceso (subinterfaz)
b. En el HL4, se activa (activate/no shutdown), el circuito de acceso (subinterfaz)
c. En el DSLAMIP/ONT se migra el acceso GPON del cliente a la nueva dupla
SVLAN/CVLAN A’/B’
Conviene que el punto c incluya un flapeo del “puerto Ethernet”, para forzar a que el EDC
refresque el ARP de la IPWAN del PE, ya que la MAC ha cambiado (a la del HL4). En un
primer momento pensamos en realizar las tareas a; b & c en paralelo, pero:
41
Si pones “disable” en el HL4-JNPR, no progresa el tráfico L2 hacia el PEGGCC por el VPLS de la SVLAN, según
se vio en las pruebas (T441)
MARZO 2018
Edición 9ª
 Los tiempos de commit en los PEGGCC son muy largos, y puede ocurrir que el
corte sea muy largo si hacemos las otras dos tareas sin esperar a esta.
 El EDC tiene que refrescar la caché de ARP tras el cambio, y esto lo hace
aprovechando el flapeo del puerto, al reiniciar la ONT. Si la microtarea “c” no es la
última de las tres, puede ocurrir que quien responda a esta consulta ARP sea aún el
PEGGCC, y no recuperemos el servicio hasta que expire en el EDC la entrada en la
caché de ARP correspondiente a la IPWAN remota, y la actualice ya sí con la MAC
del HL4.
6. Comprobación del servicio de la sede de cliente
7. La marcha atrás, caso de que la comprobación resultase negativa, consistiría en hacer al
revés el punto 5.:
a. En el PEGGCC, se activa (delete disable/activate), el circuito de acceso
(subinterfaz)
b. En el HL4, se desactiva (disable/deactivate/shutdown), el circuito de acceso
(subinterfaz)
c. En el DSLAMIP/OLT se migra el acceso GPON del cliente a la antigua dupla A/B
Conviene que el punto c incluya un flapeo del acceso GPON, para forzar a que el EDC
refresque el ARP de la IPWAN del PE, ya que la MAC ha cambiado (a la del PEGGCC)
8. Una vez confirmada la correcta migración en el punto 6., se puede solicitar la baja de la
conexión del cliente en el PEGGCC
El corte de servicio durante la migración tendría la duración del intervalo en el que se realicen las
microtareas a; b & c del punto 5.. En el caso de sedes con routing dinámico, o BFD, menos aún, lo que
dure la micro-tarea 5..c.
6.2 PCM
En este caso, los clientes, que se entregan como una VLAN en la conexión con el PEGGCC,
entran a la MTU o al PE de Acceso de la MAN como un puerto físico.
En este caso, la migración del servicio al HL4 será directa: pasaremos de meter el puerto en una
VLAN/”servicio” y enviarlo por L2VPN/VPLS a un puerto de interconexión con un PEGGCC (PCM), a
darle un servicio de nivel tres, ya sea metiéndolo en una VRF, en el caso de MacroLAN, ya sea
estableciendo una conexión con Internet, en el caso de DIBA. En el caso de EDCs con dos servicios
(DIBA y MacroLAN) sobre el mismo enlace de acceso, cada VLAN se migrará independientemente.
Gracias a que tenemos HCoS en el puerto, se puede gestionar la concurrencia entre la VLAN de
MacroLAN y la de DIBA en caso de congestión.
6.2.1 PCMS DE CONEXIONES P2P

Dentro del NPDS de multicast se han definido un nuevo tipo de conexiones VPNIP, que son
VLANs “punto a punto”, establecidas sobre la MAN, igual que las de MacroLAN, pero con la
particularidad de que sólo hay un EDC, de manera que desaparece el concepto de “caudal nacional”. En
estas conexiones se hace un conformado de tráfico, de manera que, a nivel de configuración, esta
MARZO 2018
Edición 9ª
conexión es mucho más parecida a la de una fibra directa, con la única particularidad es que se agregan
circuitos de distintos clientes.
Los clientes de esta modalidad, cuando se migren a un HL4, serán equivalentes a una fibra directa,
por lo que se les podrá tratar como a aquellos. Existen algunos matices a lo anterior:
 El CoS no es exactamente igual: para evitar problemas de throughput TCP que se
provocaba en el antiguo modelo de CoS de VPNIP, en el esquema moderno de CoS VPNIP
los excesos no se cambian de cola, sino que únicamente se les aplica un perfil de WRED
más agresivo
o En el nuevo modelo de QoS para Vlan PaP, la Clase Oro se cursa en salida
exclusivamente por la cola Cliente Calidad, y en caso de que exceda lo contratado
se marca el PLP a High mejorando el comportamiento del tráfico Oro. La Plata
(reservada) y la no reservada (Bronce) se cursan por la cola BestEffort, en caso de
que se excedan los caudales contratados se marca el PLP a High. Este modelo de
QoS se ha definido42 de manera conjunta con Validación Técnica con el objeto de
mejorar el comportamiento de las clases de tráfico.
o En el modelo de Fibra Directa los excesos de Oro y Plata (Reservada) se
mapeaban a la cola Best Effort con PLP Low y esto provocaba la llegada de
paquete desordenados con la consecuente reducción de las garantías de ancho de
banda.
Aunque suponga una ligera modificación en la definición del servicio, consideramos, de
acuerdo con DSS e IdSS43, que el QoS de VLAN P2P no sólo es más moderno sino mejor,
y que resulta conveniente que a los clientes FD-VPNIP, al ser migrados al HL4, se les
cambie el esquema de CoS al de VLAN-P2P. Para ello, tenemos que solicitar a Sistemas,
en el QUE, que las plantillas de VPNIP-FD usen el modelo de CoS de VLAN-P2P en vez
del original.
En el EDC el QoS es el mismo para FD y VLAN-P2P, de manera que ahí no hay que tocar
nada, al pasar del uno al otro44.
 En VLAN P2P existe la opción de BFD en el BGP, y cuando se definió FD esa opción no
existía y no se recogió en plantillas.
 Fibra Directa contempla la opción de routing RIP, y VLAN P2P sólo está definido con
BGP.
 Las plantillas de VLAN-P2P hacen uso de logical-interface-policer (IPv6), y en FD no.
Esta configuración se eliminará, para poder eliminar el “interface-specific” de los filtros
que no lo requieran.
Aunque estas conexiones son VPNIP, cuando se empezaron a usar, por analogía con MacroLAN,
se decidió provisionarlas en dos PEGGCC. Cuando un cliente contrata una VLAN MacroLAN, la sede
se conecta a dos PEGGCCs conectados a la VLAN. De esa manera tiene redundancia de PEGGCC,
42
(por DSS), este párrafo es extracto de un correo de Javi Santayana del 28/04, en el que hablaba en primera persona,
desde el punto de vista de DSS.
43
Correo de Óscar Soria del jue 28/04/2016 15:40
44
Correo de Javi Santayana del jue 28/04/2016 12:52
MARZO 2018
Edición 9ª
aunque no tenga redundancia de acceso (entre el CPE y el nodo de la MAN). En una VLAN P2P, como
sólo hay un PEGGCC, al otro extremo del CPE, se consideraba que esto era una merma respecto a
MacroLAN y, para suplir esta carencia –respecto a macroLAN, que no respecto a VPNIP- se decidió
provisionar en el acceso del cliente dos VLAN P2P, contra dos PEGGCCs distintos.
Cuando el servicio se baje al HL4, la conexión física estará en el propio HL4, y ya no tendrá
sentido tratar de redundar al HL4 con otra VLAN que vaya a otro HL4, pero que, inevitablemente, tenga
que pasar por el HL4 que queremos respaldar. Por tanto, en esta migración, una de las VLANs tendrá
que darse de baja. Igual que ha pasado con DIBA, habrá que avisar a marketing de este cambio, porque
se incluyó en la definición del servicio, aunque ya se sabía que en la futura red Fusión no se iba a poder
mantener en el HL4
6.2.2 PROCEDIMIENTO DE MIGRACIÓN DIBA

Desglosando en una secuencia de “tareas atómicas”:
1. Partimos de un cliente provisionado en la VLAN “A” del puerto “P” en el PEGGCC “M”
2. Prerrequisitos:
a. La pasarela o el HL3 de la provincia tiene que estar operativa
b. La MTU ó PE-Acc al que se conecta, físicamente, la fibra del cliente, el EDC, tiene
que estar habilitada como HL4. O, en su lugar, la conexión física del EDC tiene que
haberse migrado a un HL4 de nueva creación, aunque el servicio que se esté dando
sea una L2VPN hacia el PE-ACC del PEGGCC.
3. En el HL4, se desactiva, si es posible, o se borra, si no, la definición del servicio L2VPN
que metía el puerto del cliente en una VLAN y lo enviaba al PEACC coubicado con el
PCM. Se provisiona, según las nuevas plantillas de servicio, el DIBA en el HL4, con los
mismos parámetros de provisión: subred WAN, filtros, caudales… incluida la VLAN.
Incluido la VLAN, porque el EDC se conecta a la MAN en 802.1Q, aunque lo normal sea
que haya sólo una VLAN, así se deja preparado para casos de multiVRF, o convivencia
DIBA/MacroLAN, etc…
4. Flapeamos el puerto del HL4 hacia el EDC, para que el EDC refresque la MAC de la
IPWAN-PE, y se aprenda la del HL4. Este flapeo va a ser disruptivo para todos los
servicios del EDC, no sólo el que se está migrando
5. Pasados unos segundos tras desactivar el servicio L2VPN en el HL4 (punto 3.), la sesión de
routing L3VPN PE-CE cae, y las rutas se retiran de la tabla de rutas, con lo que el
PEGGCC deja de atraer tráfico, sin necesidad de provisionar nada por sistemas.
6. Comprobación del servicio de la sede de cliente
7. La marcha atrás, caso de que la comprobación resultase negativa, consistiría en deshacer el
punto 3. en el HL4:
a. Baja de la provisión del DIBA (servicio L3)
b. Reactivación, si se pudo desactivar, o configuración desde cero, del servicio
L2VPN original
MARZO 2018
Edición 9ª
c. Flapeo del puerto del HL4 hacia el EDC, para que el EDC refresque la MAC de la
IPWAN-PE, y se aprenda la del PEGGCC
8. Una vez confirmada la satisfactoria migración del servicio, se puede solicitar la baja de la
configuración en el PEGGCC, para ir liberando al PCM de conexiones y, eventualmente,
darlo de baja.
Si tuviéramos varios servicios/VLANs en el acceso del EDC, cada uno se podría migrar de manera
independiente. Aunque, por minimizar el impacto, convendría planificar la migración de todas las
conexiones en la misma actuación.
La duración máxima del corte de servicio, asociadas a una migración satisfactoria, depende de los
temporizadores del protocolo PE-CE que use el cliente:
 90” con BGP “estándar”
 3” con BFD (y los parámetros estándar de servicios)
 180” con RIP (sin BFD)
6.2.3 PROCEDIMIENTO DE MIGRACIÓN MACROLAN

En principio, será muy semejante al de DIBA, aunque habría que esperar a la redefinición de
macroLAN, en el NPDS correspondiente.
El NPDS en el que se va a tratar este tema es RPV2.0, y en principio, “lo propuesto es crear unos
nuevos accesos en el servicio comercial VPN IP”45, y migrar las sedes MacroLAN, desde la VLAN
Metropolitana y el PEGGCC, a este nuevo acceso en el HL4.
Dado que hay redefinición del servicio, va a ser necesario renegociar con el cliente un nuevo
contrato.
El objetivo del NPDS es que no haya que cambiar el EDC, y hacer una migración sin corte. Como
en RPV2.0 se requiere multiVRF con caudal por acceso, tendremos que utilizar HCoS en el puerto del
cliente, para hacer un conformado agregado a todos (o a varios de) los subinterfaces lógicos del puerto.
Opción continuista
Existe una opción, que debería de estar desestimada desde la RFI, pero que reflejamos aquí,
porque se sigue haciendo referencia a ella en diversos foros. Esta opción no es la estrategia promovida
desde Tecnología de Red, pero es cierto que es la única que permite migrar al cliente a HL4 sin tocar el
EDC y sin cambiarle de servicio.
La opción consiste en montar un VPLS en la zona HL3 de la provincia o área metropolitana. En
este VPLS, se meterían las conexiones del cliente en esa provincia, como ahora. En un par de HL4 de la
provincia, en los que esté instanciada la VPLS del cliente, se instancia, en una VRF, la L3VPN del
cliente. Mediante IRB46, se enlaza la L2VPN provincial del cliente con la L3VPN del cliente,
reutilizando directamente las plantillas y concentos contratables del servicio actual.
45
Correo Marta Jiménez del “jueves, 28 de abril de 2016 16:34”
46
También existe otra alternativa, en JNPR, utilizando interfaces “lt-“ en vez de irb
MARZO 2018
Edición 9ª
Por sintetizar los problemas que vemos a esta arquitectura:

 Es muy ineficiente en consumo de recursos
 Mantiene la necesidad de múltiples puntos de provisión
 …con carácter general, va en contra de la arquitectura de Fusión. Para terminar
manteniendo esta arquitectura de servicio, no merece la pena cambiar la arquitectura de la
red
Migración de las sedes a VPNIP en HL4
6.3 FIBRA DIRECTA

Las fibras directas, GE, que terminaban el un puerto de un PEGGCC, sin pasar por la MAN,
tendrán se ser movidas físicamente, durante el proceso de migración, a un puerto de un HL4.
En el cambio, el CoS se modificará, pasando a uno más moderno y mejor, procedente de las
plantillas de VLAN-P2P, como ya hemos explicado en el apartado 6.2.1, no se activará BFD para BGP,
que no es una opción en VPNIP-FD, al menos no estándar de servicio, salvo que sea como PPEE
6.4 DIRECCIONAMIENTO WAN

Siempre que sea posible, que lo será en la práctica totalidad de los casos, se mantendrá el
direccionamiento WAN de las conexiones PE-CE. La asignación de direccionamiento WAN se hace
reutilizando las subredes entre PEGGCCs, pero sin repetirlas en un mismo PEGGCC, aunque estén en
VRFs distintas. Pero existe la posibilidad de que dos conexiones que se migran al mismo HL4,
provengan de distintos PEGGCC, que tengan la misma subred WAN, y que se metan en la misma VRF,
o ambas en la TGR. En ese improbable caso, fallaría la provisión, y sería necesario cambiar el
direccionamiento WAN, lo que implica reasignación de direccionamiento y provisión en el EDC y el
HL4
6.5 DIRECCIONAMIENTO DE GESTIÓN

El direccionamiento de gestión de EDCs se asigna de manera global, no se reutiliza, por lo que se
puede migrar a los HL4 sin preocuparnos de la posibilidad de colisión.
6.6 CONEXIONES EN HL5

En el caso particular de clientes cuya conexión termine en el HL5, según se ha indicado ya en el
apartado 3.8, la migración consistirá en mantener el servicio L2VPN de transporte hacia un equipo
remoto, pero acercando el equipo remoto, que será el HL4 del que cuelga el HL5, y configurando el
servicio L3 en el HL4, pero no ligado a un interfaz externo del nodo, sino a uno interno, asociado al
PWE que llega desde el HL5.
La migración de los clientes conectados a HL5’s comenzará después que la de los directamente
conectados al HL4. De esta manera, cuando se haga la primera conexión, ya estará comprobada la
prestación de servicios L3, y sólo haya de novedoso PHT.
MARZO 2018
Edición 9ª
De esta manera, estamos, efectivamente, desligando el servicio L3 del borde MPLS, según la
arquitectura seamless,
6.7 PROYECTOS ESPECIALES

La migración de estos clientes, aunque también es responsabilidad de los suministradores, no se
podrá hacer con un procedimiento automático, agregado, sino que requerirá su estudio caso a caso, en
colaboración con Ingeniería de Servicios.
También está la cuestión de identificar a los clientes que son PPEE, porque no está claro que esa
circunstancia esté reflejada en sistemas.
6.8 JALONAMIENTO DE LAS PRUEBAS

Para estructurar y escalonar la realización de las pruebas se definen una serie de “fases” 47: I; II &
III
Como el objetivo es poder comenzar lo antes posible con los servicios más masivos y/o sencillos,
traemos a la fase I los básicos.
6.8.1 FASE I
En una primera fase se validarán:
 Los accesos QinQ y fibra directa a VPNIP. En este punto se incluyen las sedes VPNIP que
funcionan como backup de MacroLAN
o También se incluyen las plantillas de “Sede VPN-INT mod. Prestadora”, que se
provisionan en los PEGGCC “normales”, no en los POI-TIWS.
 Sedes de usuario de Conectividad Empresas (MFE)
 DIBA (estándar)
En este primer bloque también se intentará incluir el “Lote I” de Proyectos Especiales (PPEE):
 Desacoplamiento del borde de clientes DIBA con full-routing [10]. Las plantillas
entregadas en Fase I, tanto NOK como JNPR, sólo incluyen la plantilla del AN, el equipo
que inicia el PWE, que es el HL4, no la del SN. La configuración del SN, que será un “PE
residual” (~”HL4-ATM”), tendrá que ir en Fase II
 Etc…
Es de esperar que, una vez realizada la FOA de estos tres tipos de clientes, ya la maquinaria de
migración se pueda poner a funcionar, sin estar esperando a nuevas validaciones, ya que dispondrá de
mucha planta pendiente y disponible para migrar.
6.8.2 FASE II
En un segundo bloque añadiríamos:
47
Durante un periodo de este proyecto, se han llamado “bloques”, pero son el mismo concepto
MARZO 2018
Edición 9ª
 Como hemos indicado en el apartado 6.2.1, los clientes de “VPNIP-VLAN-P2P”, se

migran al HL4 como una fibra directa. En esta fase no hace falta repetir esas pruebas
funcionales, pero sí chequear el procedimiento de migración
 DIBA-RRLL
 mVPN. Existe un NPDS en curso, pero todavía no se ha hecho FUT. En todo caso, lo que
se va a validar en HL4/Fusión son las plantillas ya entregadas para el piloto y el desarrollo
de sistemas.
 IPv6:
o 6VPE: VPNIP & MacroLAN
o 6PE DIBA
 DI-FTTH:
o Plantillas para el SN de Full-Routing
o Pruebas en el HL4
6.8.3 FASE III

En este bloque irían:
 Los PPEE del “Lote II”
o VLL (aka “túneles Martini”)[12]
o Hub & Spoke[11] y Extranets
 Etc… (pendiente de definir)
 CSC (RTJAv3) [4]
 La extensión de los servicios de los bloques I y II a conexiones procedentes de HL5, con
servicio L3 en el HL4, mediante PHT
6.8.4 EXCLUIDOS
Quedan explícitamente excluidos de la migración y, por tanto, de las necesidades de validación:
 Los accesos y servicios que se prestan sobre “PEs legacy” (apdo. 4.2.5) o sea:
o Los accesos móviles, RDSI y Frame-Relay a VPNIP
o Los accesos móviles e IPSec a Movistar Intranet. O sea, todos los accesos
específicos de Movistar Intranet, porque los accesos fijos se reutiliza el equivalente
de VPNIP
o El AntiDDoS del PE-CM [5]
 El servicio Redes Limpias, pendiente de migrar al CdS
 La salida agregada a Internet de MFE, que también se presta actualmente sobre el PERRLL
y también está pendiente de migrar al CdS
MARZO 2018
Edición 9ª
 NetLAN
 En general, todo lo que se manda al “PE Residual” (aka HL4-ATM), como, por ejemplo:
o el ATM (apdo. 4.2.3)
o las interconexiones con NGN (apdo. 4.2.2)
MARZO 2018
Edición 9ª
7. MIGRACIÓN DE LA RED A DOMINIOS DISJUNTOS DE IGP ENLAZADOS MEDIANTE

L-IBGP
Según se indica en ¿[21]?, en el escenario objetivo, los HL4s de zonas HL3 distintas, se conectan
entre sí, y con los PE-legacy, a través de BGP-lu[30]. Existirá un periodo de transición, en el que la
conectividad entre lo nuevo y lo viejo se hará mediante ISIS, redistribuyendo entre el HL2 y el HL3,
pero, en un momento dado, se pasará a activar la conmutación por BGP-lu, marcando la community de
preferencia, y, posteriormente, se desactivará el ISIS en el enlace HL2-HL3. En ese momento, será
necesario que los PE-legacy que tengan VRFs que se conecten con VRFs ya migradas a HL4s de estas
zonas con ISIS aislado, tengan BGP-lu.
Los PE-legacy, que prestan servicios a GGCC, y en los que habrá que activar BGP-lu contra los
reflectores de etiquetas de Fusión son:
 Los propios PEGGCC[1]. Se supone que estos equipos se terminarán apagando, pero,
mientras se realiza la migración de sedes, tienen que tener conectividad con lo ya migrado,
para lo que requerirán BGP-lu durante esta fase transitoria y final.
 Los LNSs de AyRMVPNIP[6][15]
 Los LNSs de MFE[14]. Estos equipos se están migrando a ASR1006, y en estas pruebas de
validación de este nuevo modelo de LNS ya se incluye48 esta validación correspondiente a
Fusión.
 Los equipos específicos para Movistar Intranet[9]: los concentradores[8] y los cifradores[7]
 El PE-CM[5]
Equipos en los que no es necesaria esta validación:
 Los POI-TME49. Los clientes de AyRMVPNIP que aún están en estos equipos lo que
tienen es que migrarse a los LNSs. Estos nodos están descontinuados hace años, y no se
hacen nuevos desarrollos sobre ellos.
 Los PE-RRLL[16], que se van a migrar al CdS
7.1 INTEGRACIÓN DE LOS PE-LEGACY EN FUSIÓN

La actual Red IP no es que se vaya a conectar, como una zona HL3 más, al tránsito de la red
Fusión. Sino que el tránsito de red IP va a asumir progresivamente las funciones de la zona HL1-HL2 de
Fusión. De manera que, de partida, los PE-legacy van a tener en su IGP las rutas hacia Fusión,
redistribuidas a través del HL2. Aunque estas rutas desaparecerán con el tiempo y pasará a ser necesario
el BGP-lu.
Los PE-legacy montarán una sesión BGP-lu con los reflectores de etiquetas de transporte, y estos
les pasarán las rutas, procedentes de los HL2, correspondientes a los HLn que cuelguen de cada uno de
ellos.
48
Acordado con Antonio Sanz el 01/03/16
49
Acordado con Fede
MARZO 2018
Edición 9ª
Como muchos PE-legacy, como su propio nombre indica, no soportarán funcionalidades

modernas, como AIGP[35], tendremos que apoyarnos en el HL2 que será el que tenga que imponer este
atributo, e inicializarlo, en sus anuncios hacia el HL3, con la métrica IGP que él tenga hacia el PE-
legacy. Los PEGGCC sí que soportan AIGP, porque están en JunOS 13.3 y se soporta desde 12.1, así
que estos equipos en concreto, sí que van de partida con AIGP
Igual que en el caso de Fusión, para controlar cuando empiezan a utilizarse las etiquetas de BGP-
lu, se define una community de preferencia 50. Al parecer, aunque habrá que comprobarlo en las pruebas,
IOS no permite fijar la admin-dist por community. Alternativa: poner una prefix-list para la FOA y nada
para después.
En Fusión, se define una community de zona, que identifica la zona HL3 de la que procede una
ruta. Para los PE-legacy se ha pedido una community de este rango, que identifica la “zona legacy”. De
momento no tiene un uso concreto, pero la dejamos marcada para futuro uso. Planificación 51 asigna el
valor 53 a la “provincia legacy”. Por tanto la community con la que exportarán sus rutas será la
3352:10531
Los HL2 cisco, debido al bug CSCul65297, no pueden hacer doble-pop en combinación con BGP-
PIC. Como estamos haciendo PHP en LDP, anunciando la etiqueta implicit-null (3) para la loopback, si,
además, anunciásemos el mismo mapeo FEC<->etiqueta (3) por BGP-lu, tráfico proveniente de un HL3
que colgase del mismo HL2 que el PEGGCC, obligaría al CRS a hacer doble-pop, y forzaríamos el fallo.
Como workaround para este problema, vamos a usar explicit-null (0) de IPv4 en los anuncios de BGP-lu
para la etiqueta de la propia loopback del PEGGCC. Pendiente consulta a sas-te52 implicaciones con vrf-
table-label.
También los 7950 de Nokia tienen problemas con el doble-pop, pendiente código reparo.
En el caso del CRR, pendiente de consensuar, habría que montar una pseudo-zona HL3, en el
CERBA, y los c76xx que están haciendo de SRRA, pueden hacerlo
7.2 NECESIDADES DE VALIDACIÓN

Los PE-legacy sólo tienen que montar iBGP-lu[30] con los reflectores. Y tendrán que ser capaces
de utilizar LSPs de transporte MPLS jerárquicos, apilando la etiqueta BGP-lu del HL2 para llegar al
HL4 sobre la etiqueta LDP de la ruta ISIS para alcanzar al HL2. Y, sobre ello, imponer la etiqueta de
servicio (VPN, por ejemplo).
Las funcionalidades correspondientes a AIGP se descargan al HL2, por lo que tendrán que
validarse allí. Pero, si un PE-legacy, como el PE-GGCC sí que lo soporta, lo utilizaremos, según se ha
acordado con tránsito.
Aprovecharemos los escenarios de pruebas no sólo para comprobar BGP-lu contra el reflector, que
es el escenario estándar, sino para comprobar BGP-lu contra un HL3, del que quieren colgar al PE-
legacy residual para ATM (aka HL-ATM, véase apdo. 4.2.3)
50
3352:10000
51
Correo de Javi Belando del vie 04/03/2016 8:46
52
Correo a sas-te del mié 09/03/2016 10:37
MARZO 2018
Edición 9ª
Otra funcionalidad que habría que comprobar es la capacidad de rebajar la “distancia

administrativa” (aka Preference, en Juniper) de las rutas BGP-lu, en base a la community de preferencia.
Todas estas pruebas se documentarán en el Informe de Pruebas Error: Reference source not found
MARZO 2018
Edición 9ª
8. IMPACTO EN OTROS PROYECTOS
Aunque no forme parte directamente del alcance de este proyecto, recogemos en este capítulo el
impacto que esta transformación de la red tiene en el diseño de otras redes y soluciones de conectividad
responsabilidad de TRIA.
8.1 RCU
La red corporativa propia de TdE es un macroLAN en autoprestación [20]. Aunque, básicamente,
RCU es un cliente más, y se migrará como cualquier otra red de cliente, tenemos que tener en cuenta
algunos de los impactos que tendremos en el diseño:
 Como cualquier otro cliente de MacroLAN, dejará de haber conectividad L2 metropolitana
entre sedes. Cada sede tendrá su conexión dedicada (y redundada en dos CRWs) a HL4.
 En el caso de las sedes de tipo 0, la VLAN subtendida se implementará como un VPLS
(L2VPN)
 En el caso de las sedes de 4, existen fibras directas (VPNIP) para redundar la conexión
MAN de los CRWs con los PEs. Tras la previsible evolución de las conexiones
macroLAN, pasaríamos a tener 4 fibras, dos desde cada CRW, a dos HL4s distintos. Parece
un nivel excesivo de redundancia cuando ya no haya MAN que redundar 53, por lo que se
podría reconsiderar la necesidad de las fibras directas (VPNIP) una vez migradas las sedes
a Fusión
53
Reunión 25/04/16 09:30 E1P8E53
MARZO 2018
Edición 9ª
9. ACRÓNIMOS
No es la siguiente una revisión exhaustiva de todos los acrónimos utilizados en este documento,
sino sólo aquellos que puedan suscitar duda:
AAPP: Administraciones Públicas
AyRMVPNIP: Accesos y Respaldos Móviles a VPNIP
CdR: Creación de Red (Fusión de Red)
HL: Hierarchical Level (Fusión Red)
HLn: HL de nivel n
HLC: HL de Control
IFG: Inter-Framing Gap (Ethernet)
IUM: Informes de Uso MacroLAN
NPBC: Nodo Periférico de Baja Capacidad (Fusión Red)
PHT: Pseudowire Head-End Termination (aka PWHT)
PIP: Plataforma de Informes Personalizados (SdR; IUM; SGI)
PPEE: Proyectos Especiales (GGCC)
PWHT: PseudoWire Head-End Termination
PXC: Port Cross Connect (Nokia/PWHT)
RRLL: Redes Limpias (Servicio GGCC)
SGI: (Sub)Sistema de Gestión de Informes (SdR, Telefónica)
SN: Service Node (seamless MPLS)

Sip Dect RFP45

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Sip Dect RFP45

Cargado por

Copyright:

Formatos disponibles

DEFINICIÓN TECNOLÓGICA

DE SOLUCIÓN MARZO 2018

SERVICIO L3VPN PARA EL HL3/HL4

ESTRATEGIA Y DESARROLLO DE RED

No está permitida la reproducción total o parcial del presente documento, ni su tratamiento

Servicio L3VPN para el HL3/HL4

2. RELACIÓN DE SERVICIOS L3VPN AFECTADOS 14

5. ASPECTOS PARTICULARES POR SUMINISTRADOR 28

6. MIGRACIÓN DE CONEXIONES DE CLIENTE 33

6.6 CONEXIONES EN HL5 38

7. MIGRACIÓN DE LA RED A DOMINIOS DISJUNTOS DE IGP ENLAZADOS

8. IMPACTO EN OTROS PROYECTOS 43

ESTRATEGIA Y DESARROLLO DE RED USO INTERNO Página 5 de 54

1.2 DOCUMENTACIÓN DE REFERENCIA

1.2.1 DOCUMENTACIÓN TDE

[1] DTS: PE de Grandes Clientes

[2] Plan de Pruebas regresión actualización sistema operativo PE-GGCC

[3] Plan de Pruebas para tarjeta de línea (PEs GGCC)

[4] CSC para backup RTJAv3 por Red IP

ESTRATEGIA Y DESARROLLO DE RED USO INTERNO Página 6 de 54

[5] PE dedicado al Centro de Mitigaciones

[6] Infraestructura de red del NPDE de Accesos y Respaldos móviles a VPN-IP

[7] DTS: cifrador para MoviStar Intranet en Red IP Única

[8] Control Hw/Sw: concentrador túneles GRE para Movistar Intranet

[9] Migración servicios móviles corporativos a Red IP Única

[11] Plantillas de Modelos de Conectividad MPLS sobre PE Juniper Serie M V2.9

[12] Pruebas y plantillas de Túneles Martini en PEs Juniper M

[13] Informe de pruebas validación accesos QinQ, FTTH/VDSL a VPNIP en PEGGCC's Mx

[14] Solución tecnológica de Red IP para el servicio de Respaldo móvil Conectividad

ESTRATEGIA Y DESARROLLO DE RED USO INTERNO Página 7 de 54

Edición 3ª, febrero 2013

[15] Control HW/SW: LNS de Acceso & Respaldo móvil a VPN-IP

[16] Solución tecnológica de red para el proyecto Redes Limpias

[17] Solución de red para conexión de Centros de Servicios a RIMA

[19] (DTS) para la creación de centros agregadores de servicios en red

[20] Definición Tecnológica de la Solución WAN de la Nueva Red Corporativa Unificada

Documentación propia del proyecto “Fusión Red”

[21] DTS general de “Fusión Red”

ESTRATEGIA Y DESARROLLO DE RED USO INTERNO Página 8 de 54

[22] Doc análogo GT ALU

[23] DTS BNG “Fusión Red”

[26] Plan de pruebas L3VPN para el HL3/HL4

Especificación de requisitos para Sistemas

[28] ESPECIFICACIÓNES DE NEGOCIO (QUÉ): Creación de red y provisión para servicios

ESTRATEGIA Y DESARROLLO DE RED USO INTERNO Página 9 de 54

1.2.2 DOCUMENTACIÓN EXTERNA

[29] Scaling MPLS seamlessly

1.2.3 DOCUMENTACIÓN SUMINISTRADORES

1.2.4 REFERENCIAS NORMATIVAS

[30] Carrying Label Information in BGP-4

ESTRATEGIA Y DESARROLLO DE RED USO INTERNO Página 10 de 54

[35] The Accumulated IGP Metric Attribute for BGP

[36] Seamless MPLS Architecture

1.3 UNIDADES AFECTADAS

ESTRATEGIA Y DESARROLLO DE RED USO INTERNO Página 11 de 54

1.4 DEROGACIONES Y EFECTIVIDAD

1.5 UNIDAD RESPONSABLE

1.6 LISTA DE REVISIONES

14/09/15 4.1.1 No impacto en routing de cliente

4.2.2 Icx GGCC-NGN

Borrador 2 30/12/15 1.2 Reordenación de las referencias

25/01/16 4.2.3 & 4.2.4 HL4-ATM & HLC

6. Capítulo específico para el