Subject: [mpls] Inter-Area LSP

From: "Vishwas Manral" <[email-masked]>
Date: Thu, 14 Feb 2008 15:28:36 -0800

Hi Folks,

I noticed that the reason to have the inter-area LSP extensions is
that specific host address of the PE (/32 for IPv4) are caught in the
Inter-Area summarization and are not injected Inter-Area. this prevent
us to have proper connectivity between the PE's.

I tried the some experiments using a Cisco router that we have. It
turned out that the solution to allow the summarization to happen, as
well as let the PE host specific routes to be injected is not very
complex.

To do the same, besides having the ranges for the current setup, I
added /32 ranges for each PE address. As summarization in OSPF happens
using the LPM match (the summary prefix having the longest mask
matches an address), we do not affect the summarization at all yet
allowing /32 prefixes to be distributed through out the domain.

Some could argue that this is the same as doing static routes injected
into the domain. However this is different as the static routes will
not be removed when the PE becomes unreachable but the summary routes
will.

Kireeti/ Yakov it will be great to get your views on the same.

Thanks,
Vishwas
_______________________________________________
mpls mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/mpls

---

From: "Wyatt S" <[email-masked]>
Date: Thu, 14 Feb 2008 21:41:10 -0600

Doesn't this defeat the purpose of route summarization?  You want fewer LSAs
in the end, not more.

---

From: "Wyatt S" <[email-masked]>
Date: Thu, 14 Feb 2008 21:48:04 -0600

Since I spoke up.  I do have a question.  What happens when an LEC attempts
to create an LSP to an LEC that's in a summary, but not active?  So the
source LEC FIB and its local area's LSR FIBs all see the summary route, but
the ABR LSR then sends the no route response back downstream.

How often should/does the source LEC reattempt to create the LSP, and should
something like that be covered in this RFC?

On 2/14/08, Wyatt S <[email-masked]> wrote:
>
> Doesn't this defeat the purpose of route summarization?  You want fewer
> LSAs in the end, not more.
>
>

---

From: "Vishwas Manral" <[email-masked]>
Date: Thu, 14 Feb 2008 20:07:22 -0800

Hi Wyatt,

By doing what we do now, we are injecting only PE router routes across
the domain, all other summarization will still happen fine.

The basic assumption however is that the PE routes make up only a
small portion of all the routes summarized. Thinking of it that should
not be too many routes, just the number of PE's, which in my view
should not be much at all compared to all the routes in the domain.

Thanks,
Vishwas

---

From: "Vishwas Manral" <[email-masked]>
Date: Thu, 14 Feb 2008 20:16:31 -0800

Hi Wyatt,

I do not know which RFC you talk about.

Look at the example given in the Inter-area draft to understand the detail.

If you are talking about the summarization idea, the summary LSP (for
the discard route) will be created till one Hop before the ABR (border
router between areas). The behavior is going to be the same like
normal IP routing. A packet not matching any of the constituent routes
of a summary will be discarded by the ABR.

Thanks,
Vishwas

---

From: "Wyatt S" <[email-masked]>
Date: Thu, 14 Feb 2008 22:31:18 -0600

The draft details the current options:

o set up the required MPLS LSPs between PEs in different IGP areas,
   services providers have currently three solutions: LDP with IGP route
   leaking, BGP [MPLS-BGP] over LDP with MPLS hierarchy, or also inter-
   area RSVP-TE [ID-RSVP-TE].

You're offering option 1: IGP route leaking

---

From: "Vishwas Manral" <[email-masked]>
Date: Thu, 14 Feb 2008 20:59:42 -0800

Hi Wyatt,

You are right in the problem statement section it talks about the
same. The draft talks about the same thing in the next paragraph,
after the paragraph you have pointed to.

I got confused reading Section 7.1. It states:

    If all IP prefixes are leaked in the IGP backbone area and only stub
   areas use IP aggregation, LSRs in the backbone area don't need to be
   compliant with this document.

I guess this should be changed to:

    If all PE router host addresses are leaked across the IGP areas
    using host specific(i.e. /32 for IPv4) summarization, LSRs in the domain
    need to be compliant with this document. .

Thanks,
Vishwas

---

From: <[email-masked]>
Date: Fri, 15 Feb 2008 10:09:05 +0100

Hi,

> De : Wyatt S [mailto:[email-masked]]
> 
> Since I spoke up.  I do have a question.  What happens when an LEC attempts to create an LSP to an
> LEC that's in a summary, but not active?  So the source LEC FIB and its local area's LSR FIBs all
> see the summary route, but the ABR LSR then sends the no route response back downstream.
> 
> How often should/does the source LEC reattempt to create the LSP, and should something like that be
> covered in this RFC?

As a first answer, usually for packet interfaces (i.e. all link types except ATM and frame relay), MPLS routers (LER/LSR) use the LDP downstream unsolicited mode. In this mode the FEC is advertised by the downstream LSR without any solicitation from its upstream neighbor. So your above case would not happen.

Now, in the general case, the LSR would behave as already described in RFC 5036. In the example you raised, it's described in section "A.1.10.  Receive Notification / No Route". In summary, it states: "The LSR either will take no further action, or it will defer the label request by starting a timer and send another Label Request message to the peer when the timer later expires."

Regards,
Bruno

> 	Doesn't this defeat the purpose of route summarization?  You want fewer LSAs in the end, not
> more.
> 
> 
> 
>

---

From: <[email-masked]>
Date: Fri, 15 Feb 2008 10:24:24 +0100

Hi Vishwas,

> De : Vishwas Manral [mailto:[email-masked]]
> 
> Hi Wyatt,
> 

This section 7.1 is about "Deployment considerations".
Basically, the sentence you refer to says that LSR need only be compliant with this document if route aggregation is used in the routing domain. So far this is fairly obvious so an example of such deployment is provided: if you use aggregation only in (some) (stub) edge areas (i.e. specific prefixes are leaked in other areas, including the backbone area), LSR in others areas don't need to be compliant with this document.

In short, this extension does not necessarily require an AS wide deployment but can use on a per area basis.

So to address your clarification comment, I propose to add the above sentence and to add "specific" before "IP prefixes".

---

From: "Wyatt S" <[email-masked]>
Date: Fri, 15 Feb 2008 08:33:07 -0600

s/LEC/LER/

Sorry, I meant LER everywhere I put LEC.

---

From: "Vishwas Manral" <[email-masked]>
Date: Fri, 15 Feb 2008 06:56:31 -0800

HI Bruno,

I am ok with the change.

Thanks,
Vishwas