Subject: [mpls] draft-leymann-mpls-seamless-mpls-03 - Query 1) LDP DoD on AN, 2) IGP on AN, 3) MPLS L3 VPN on AN

From: Balaji KR <[email-masked]>
Date: Sat, 7 May 2011 17:52:21 +0200

Hi,

Query-1:
I am currently referring to this draft for identifying best way to design a
Converged Transport Network. The mail limitations comes, when positioning AN
nodes at Access where most of the products are capable to hold shared 8K
routes (global routing, VRF routing etc).

Considering LDP DoD, while AN send DoD request to AG nodes; AN must have
routing information of Remote AN before or after that particular LDP DoD -
if there is a service needs to be enabled for remote AN. This is for
Business service enabling case-2.

I am unclear on how this will happen as per draft. Might be I am not
understood the LDP DoD procedure - like /32 prefix not required to make LSP
between AN's or while LDP DoD request will populate /32 in the routing table
automatically...

Query-2:
There are cases, service providers planned to have multiple ANs in ring
connects ring end to any two AGN1x node. This will surely need a IGP (like
OSPF), for dynamic routing nature.
This means, we should have a controlled redistribution of Remote AN networks
into AN ring IGP - so required /32 prefix only will be able in the RIB.

I was thinking of, why AN IGP can request for a /32 prefix update from AGN1x
either automatically while a services needs to be enabled between Local AN
and Remote AN at another Domain.
Or
The provisioning tool need to have a option to update Control Redistribution
prefix-list/access-list as and when Services are enabled between local AN
and Remote AN.

Query-3:
Please note, I have not found this draft is discussed how we can enable MPLS
L3 VPN between local and remote AN's. Or as per this draft, AN is only
positioned for PW services?

MPLS L3 VPN nodes mostly prefer to configure Hub and Spoke to limit the size
of VRF table. In case multiple spoke need to communicate between, regional
AN's L3 VPN can receive one/two default routes from a central location (part
of same regional VRF), and there should be a routing nodes to enable
interconnecting regional VPN's.

Regards,

Balaji K R

---

From: Balaji KR <[email-masked]>
Date: Sun, 8 May 2011 09:29:11 +0200

> This means, we should have a controlled redistribution of Remote AN
> networks into AN ring IGP - so required /32 prefix only will be able in the
> RIB.
>
> I was thinking of, why AN IGP can request for a /32 prefix update from
> AGN1x either automatically while a services needs to be enabled between
> Local AN and Remote AN at another Domain.
> Or
> The provisioning tool need to have a option to update Control
> Redistribution prefix-list/access-list as and when Services are enabled
> between local AN and Remote AN.
>
> Query-3:
> Please note, I have not found this draft is discussed how we can enable
> MPLS L3 VPN between local and remote AN's. Or as per this draft, AN is only
> MPLS L3 VPN nodes mostly prefer to configure Hub and Spoke to limit the
> size of VRF table. In case multiple spoke need to communicate between,
> regional AN's L3 VPN can receive one/two default routes from a central
> location (part of same regional VRF), and there should be a routing nodes to
> enable interconnecting regional VPN's.
>
> Regards,
>
> Balaji K R
>
>
>
>
>
>
>
>
>

---

From: <[email-masked]>
Date: Fri, 13 May 2011 14:55:04 +0200

Hi,

Thanks for your interest and comments. More inline.

>From: Balaji KR
>
>Hi,
>
>Query-1:
>I am currently referring to this draft for identifying best way to design a Converged Transport
>Network. The mail limitations comes, when positioning AN nodes at Access where most of the products
>are capable to hold shared 8K routes (global routing, VRF routing etc).
>
>Considering LDP DoD, while AN send DoD request to AG nodes; AN must have routing information of Remote
>AN before or after that particular LDP DoD - if there is a service needs to be enabled for remote AN.
>This is for Business service enabling case-2.
>
>I am unclear on how this will happen as per draft. Might be I am not understood the LDP DoD procedure
>- like /32 prefix not required to make LSP between AN's or while LDP DoD request will populate /32 in
>the routing table automatically...

On the AN, you can either provision the /32 static IP route or use an aggregated / default route as per RFC 5283. Cf § "5.1.5. Access" of the draft.
(As a reminder, RFC 5283 relax the need for LDP to find in the RIB an exact match for the FEC.)

>Query-2:
>There are cases, service providers planned to have multiple ANs in ring connects ring end to any two
>AGN1x node. This will surely need a IGP (like OSPF), for dynamic routing nature.
>This means, we should have a controlled redistribution of Remote AN networks into AN ring IGP - so
>required /32 prefix only will be able in the RIB.

That's indeed an option.
Another would be for the AGN1x to advertise an aggregate / default route in the IGP of the AN rings and enable RFC 5283 on AN. In that case, an AN can dynamically setup MPLS LSP using LDP DoD with no need to request / change anything in the IGP.

>I was thinking of, why AN IGP can request for a /32 prefix update from AGN1x either automatically
>while a services needs to be enabled between Local AN and Remote AN at another Domain.
>Or
>The provisioning tool need to have a option to update Control Redistribution prefix-list/access-list
>as and when Services are enabled between local AN and Remote AN.
>
>Query-3:
>Please note, I have not found this draft is discussed how we can enable MPLS L3 VPN between local and
>remote AN's. Or as per this draft, AN is only positioned for PW services?

This draft mostly focus on setting up the MPLS LSP. MPLS services using these LSP are not discussed in details. They are not restricted to PW services. E.g. "§3 Requirements" refers to L3 VPN, § "2.3. Use Case #2" refers to 6PE.

>MPLS L3 VPN nodes mostly prefer to configure Hub and Spoke to limit the size of VRF table. In case
>multiple spoke need to communicate between, regional AN's L3 VPN can receive one/two default routes
>from a central location (part of same regional VRF), and there should be a routing nodes to enable

Regards,
Bruno