Subject: RE: [mpls] One LDP Implementation specific question of receivelabelmapping for prefix FECs

From: "Dutta, Pranjal" <[email-masked]>
Date: Fri, 14 Apr 2006 11:18:10 +0530

Earlier mail got bounced..resending again...

Hi Eric,

                 This answers well to the concern. It would depend
whether we would like to have an all MPLS network spanning via LDP or
not.

It is well said that aggregation can be turned off or on based on the
whether we would like to have an inter-area LSP or not. At this point I
would 

like to go by that at Rd, LDP is unaware of whether the prefix entries
found in its route table for downstream has been summarized to Ru. As
David said 

it has a side effect with LSP-Ping.

Regards,

Pranjal

________________________________

From: Eric W Gray [mailto:[email-masked]] 
Sent: Thursday, 13 April, 2006 9:13 PM
To: Raveendra Torvi
Cc: DECRAENE Bruno RD-CORE-ISS; [email-masked]
Subject: Re: [mpls] One LDP Implementation specific question of
receivelabelmapping for prefix FECs

Let me answer just the first part of this and let the rest take care of
itself... :-)

LSPs are [terminated] at aggregation boundaries.  This may not be
desirable in case of
an all-MPLS network.

To some extent, every box needs to "make up its mind" whether it is a
router or a switch.
It is important in interoperating between boxes that they are each
self-consistent.

The aggregator router could decide not to aggregate routing information.
That way, it can
distribute more specific labels and not worry about inconsistencies
between the routes it
has advertised and the labels it distributes.

However, there are reasons why routers aggregate routing information,
and I think it may
be difficult to justify why those reasons would not apply equally well
to label distribution.

It may very well be the case that routing aggregation is not completely
justified in specific
deployment scenarios. In that case, perhaps it would simply be better to
"turn off" route
aggregation.

--
Eric

_______________________________________________
mpls mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mpls

---

From: "Dutta, Pranjal" <[email-masked]>
Date: Thu, 13 Apr 2006 23:47:04 +0530

Hi Eric,

Regards,

Pranjal

--
Eric

Raveendra Torvi wrote:

Eric,
According to your solution  LSPs are broken at the aggregation boundary
or IGP area boundary, which may not be desirable in case of all-MPLS
network. If main goal is to carry transit traffic by the way of LDP-MPLS
switching , In case of all-MPLS networks an operator would like to
inject only LDP-FECs in other areas (hence achieve the scalability) or
avoid summarization LDP-FECs at IGP area boundary .. Please help me
understand. 
Ravi.

On 4/13/06, Eric W Gray <[email-masked]> wrote: 

Bruno,

    No, if anything specific had to be said, it would be that Ru MUST
NOT advertise a more
specific FEC to an upstream peer (Ruu in this case) than it has
advertised in routing.

    I cannot speak - obviously - for every implementation out there, but
here's how I believe
they _should_ work when dealing with an ABR (or other sumarization
point):

    o   The ABR-LSR advertises summarized routes into an adjacent Area.
    o   The ABR-LSR distributes labels corresponding to those routes to
LDP
          peers adjacent to it in that same Area.
    o   The ABR-LSR is then the egress for the corresponding LSPs,  in
those 
          cases where it has downstream routing entries corresponding to
more 
          specific routes.
    o   The ABR-LSR MAY - at that point - inject arriving packets on
downstream 
          LSPs - after it performs a routing look-up and discovers an
FTN (thus
          determing an appropriate label and outgoing interface).

    As I mentioned to Pranjal, this is defined this way for scalability
reasons.  It is not the 
intention of MPLS generally to eliminate the need for routing capability
in the network at
a cost of introducing unscalably large numbers of label distributions
throughout the same
network.

    Just as an  opinion, a device that is incapable of making this kind
of routing decision,
has no business being in a position to summarize routes.

--

Eric

DECRAENE Bruno RD-CORE-ISS wrote:

Eric,
 
Thanks for your comments.
 
Additional discussions inlined.
 
Regards,
Bruno

	-----Original Message-----
	...[SNIP]...

	<>presumably the only thing at issue is Ru should label an IP
packet that it receives. 

[Bruno D:] A subsequent issue, is that to continue the LSP further
upstream, Ru should allocate a new label and advertise the specific FEC
upstream to Ruu.

	What will happen is that  the IP packet gets sent unlabeled to
Rd
	which then labels it according to the specific route which is
the best

match

	to the packet's IP destination address.

[Bruno D:] That is indeed the current behavior but the problem is that
Rd may not be able to forward the IP packet (eg Ru is a VPN PE and Rd is
a P). And this may not be an IP packet BTW.

	The label imposition procedure here is:
	 
	- get the IP destination address
	- find  the prefix  in the routing  table which  is the best
match

(longest

	  match) for that destination address
	- use the label  which was assigned to that prefix by  the LSR
which

routing

	  says is the next hop for that prefix.
	 
	It  doesn't make sense  for Rd  to bind  labels to  prefixes
which

are more

	specific  than  the  one in  the  routing  table,  as the  label

imposition

	procedure will never make use of such labels.
	 
	I don't think we want to allow  LDP to put prefixes in the
routing

table, or

	else we'd  have to  treat it as  a second  routing algorithm and
that

would

	raise all kinds of issues.

[Bruno D:] Such procedure would not change the behavior of the IGP and
LDP.
LDP would definitely not act as a routing protocol and all routing
decisions (next-hop selection, recheability) would still rely on the
 
IGP. LDP would continue advertising labels for FECs and would entirely
rely on the RIB for setting up LSPs along the IP route.
 
However, as you very correctly pointed out, we would allow LDP to
"de-aggregate" the FIB and this may raise some issue. However, what is
 
the difference, from the FIB point of view, between one /30 pointing to
Rd and four /32 pointing to Rd? I believe some FIB implementation
already represent a /30 as four /32.
 
Besides, if populating the FTN with specific FEC is found to be an
 
issue, we can only populate the ILM on all P routers. For PE/ingress
router, all we really need is BGP to be aware of these LSPs and be able
to use them to reach the BGP Next Hops.

	It is possible though to imagine a different imposition
procedure:
	 
	- get the IP destination address, A
	 
	- find the prefix, P, in the routing table which is the best
match

(longest

	  match) for that destination address
	 
	- get the next hop, N, for P, as specified by routing
	 
	- if N has distributed any label bindings for prefixes which are

longer than

	  P but begin with the same sequence of  bits as P, and if any
of

these, say

	  Q, is a better match for A than  P, then use the label which N

assigned to

	  Q.
	 
	This is a complicated procedure, though.   You can't just match
A

against Q,

	because there might be some prefix  R in the routing table, with
a

different

	next hop, which is  a better match for A than P is, but  not as
good a

match

	as Q.  The above imposition procedure  says that the next hop
for the

packet

	is determined  by the  route to  R not  by the route  to P  (or
Q).

It's a

	complex matter  to keep  the forwarding tables  in proper shape,

given that

	prefixes like Q can come and go asynchronously.

[Bruno D:] I don't think there is a need to change the imposition
procedure at all. The modification of the label mapping procedure seems
enough. However, as pointing out by Dutta, an additional effort is
 
needed to sync LDP with the RIB because as you said, more specific
prefixes can come and go.

	There are other  complications as well.  For example, what do
you do

if you

	get a packet  which is labeled for Q,  but the next hop has
changed

and the

	new next hop has not distributed a label for Q?
	 
	I suppose we could figure all this out if there were an actual
problem

which

	didn't have a better solution.

	 
	 
	_______________________________________________
	mpls mailing list
	<mailto:[email-masked]> 
	[email-masked]
	https://www1.ietf.org/mailman/listinfo/mpls

 

-- 
101 Billerica Ave,
N.Billerica MA -01862

Hi Eric,

Regards,

Pranjal

However, there are reasons why routers aggregate routingavior of the IGP and<o:p></o:p></span></font></pre><pre><font
size=2 color=black face="Courier New"><span style='font-size:10.0pt'>LDP.<o:p></o:p></span></font></pre><pre><font
size=2 color=black face="Courier New"><span style='font-size:10.0pt'>LDP would definitely not act as a routing protocol and all routing<o:p></o:p></span></font></pre><pre><font
size=2 color=black face="Courier New"><span style='font-size:10.0pt'>decisions (next-hop selection, recheability) would still rely on the<o:p></o:p></span></font></pre><pre><font
size=2 color=black face="Courier New"><span style='font-size:10.0pt'><o:p>&nbsp;</o:p></span></font></pre><pre><font
size=2 color=black face="Courier New"><span style='font-size:10.0pt'>IGP. LDP would continue advertising labels for FECs and would entirely<o:p></o:p></span></font></pre><pre><font
size=2 color=black face="Courier New"><span style='font-size:10.0pt'>rely on the RIB for setting up LSPs along the IP route.<o:p></o:p></span></font></pre><pre><font
size=2 color=black face="Courier New"><span style='font-size:10.0pt'><o:p>&nbsp;</o:p></span></font></pre><pre><font
size=2 color=black face="Courier New"><span style='font-size:10.0pt'>However, as you very correctly pointed out, we would allow LDP to<o:p></o:p></span></font></pre><pre><font
size=2 color=black face="Courier New"><span style='font-size:10.0pt'>&quot;de-aggregate&quot; the FIB and this may raise some issue. However, what is<o:p></o:p></span></font></pre><pre><font
size=2 color=black face="Courier New"><span style='font-size:10.0pt'><o:p>&nbsp;</o:p></span></font></pre><pre><font
size=2 color=black face="Courier New"><span style='font-size:10.0pt'>the difference, from the FIB point of view, between one /30 pointing to<o:p></o:p></span></font></pre><pre><font
size=2 color=black face="Courier New"><span style='font-size:10.0pt'>Rd and four /32 pointing to Rd? I believe some FIB implementation<o:p></o:p></span></font></pre><pre><font
size=2 color=black face="Courier New"><span style='font-size:10.0pt'>already represent a /30 as four /32.<o:p></o:p></span></font></pre><pre><font
size=2 color=black face="Courier New"><span style='font-size:10.0pt'><o:p>&nbsp;</o:p></span></font></pre><pre><font
size=2 color=black face="Courier New"><span style='font-size:10.0pt'>Besides, if populating the FTN with specific FEC is found to be an<o:p></o:p></span></font></pre><pre><font
size=2 color=black face="Courier New"><span style='font-size:10.0pt'><o:p>&nbsp;</o:p></span></font></pre><pre><font
size=2 color=black face="Courier New"><span style='font-size:10.0pt'>issue, we can only populate the ILM on all P routers. For PE/ingress<o:p></o:p></span></font></pre><pre><font
size=2 color=black face="Courier New"><span style='font-size:10.0pt'>router, all we really need is BGP to be aware of these LSPs and be able<o:p></o:p></span></font></pre><pre><font
size=2 color=black face="Courier New"><span style='font-size:10.0pt'>to use them to reach the BGP Next Hops.<o:p></o:p></span></font></pre><pre><font
size=2 color=black face="Courier New"><span style='font-size:10.0pt'><o:p>&nbsp;</o:p></span></font></pre><pre><font
size=2 color=black face="Courier New"><span style='font-size:10.0pt'>&nbsp; <o:p></o:p></span></font></pre>

<blockquote style='margin-top:5.0pt;margin-bottom:5.0pt' type=cite><pre><font
size=2 color=black face="Courier New"><span style='font-size:10.0pt'>It is possible though to imagine a different imposition procedure:<o:p></o:p></span></font></pre><pre><font
size=2 color=black face="Courier New"><span style='font-size:10.0pt'><o:p>&nbsp;</o:p></span></font></pre><pre><font
size=2 color=black face="Courier New"><span style='font-size:10.0pt'>- get the IP destination address, A<o:p></o:p></span></font></pre><pre><font
size=2 color=black face="Cour information,
and I think it may
be difficult to justify why those reasons would not apply equally well
to label distribution.

--
Eric

Raveendra Torvi wrote:

Eric,
According to your solution  LSPs are broken at the aggregation boundary
or IGP area boundary, which may not be desirable in case of all-MPLS
network. If main goal is to carry transit traffic by the way of LDP-MPLS
switching , In case of all-MPLS networks an operator would like to
inject only LDP-FECs in other areas (hence achieve the scalability) or
avoid summarization LDP-FECs at IGP area boundary .. Please help me
understand. 
Ravi.

On 4/13/06, Eric W Gray <[email-masked]> wrote: 

Bruno,

    No, if anything specific had to be said, it would be that Ru MUST
NOT advertise a more
specific FEC to an upstream peer (Ruu in this case) than it has
advertised in routing.

    I cannot speak - obviously - for every implementation out there, but
here's how I believe
they _should_ work when dealing with an ABR (or other sumarization
point):

    o   The ABR-LSR advertises summarized routes into an adjacent Area.
    o   The ABR-LSR distributes labels corresponding to those routes to
LDP
          peers adjacent to it in that same Area.
    o   The ABR-LSR is then the egress for the corresponding LSPs,  in
those 
          cases where it has downstream routing entries corresponding to
more 
          specific routes.
    o   The ABR-LSR MAY - at that point - inject arriving packets on
downstream 
          LSPs - after it performs a routing look-up and discovers an
FTN (thus
          determing an appropriate label and outgoing interface).

    As I mentioned to Pranjal, this is defined this way for scalability
reasons.  It is not the 
intention of MPLS generally to eliminate the need for routing capability
in the network at
a cost of introducing unscalably large numbers of label distributions
throughout the same
network.

    Just as an  opinion, a device that is incapable of making this kind
of routing decision,
has no business being in a position to summarize routes.

--

Eric

DECRAENE Bruno RD-CORE-ISS wrote:

Eric,
 
Thanks for your comments.
 
Additional discussions inlined.
 
Regards,
Bruno

	-----Original Message-----
	...[SNIP]...

	<>presumably the only thing at issue is Ru should label an IP
packet that it receives. 

[Bruno D:] A subsequent issue, is that to continue the LSP further
upstream, Ru should allocate a new label and advertise the specific FEC
upstream to Ruu.

	What will happen is that  the IP packet gets sent unlabeled to
Rd
	which then labels it according to the specific route which is
the best

match

	to the packet's IP destination address.

[Bruno D:] That is indeed the current behavior but the problem is that
Rd may not be able to forward the IP packet (eg Ru is a VPN PE and Rd is
a P). And this may not be an IP packet BTW.

	The label imposition procedure here is:
	 
	- get the IP destination address
	- find  the prefix  in the routing  table which  is the best
match

(longest

	  match) for that destination address
	- use the label  which was assigned to that prefix by  the LSR
which

routing

	  says is the next hop for that prefix.
	 
	It  doesn't make sense  for Rd  to bind  labels to  prefixes
which

are more

	specific  than  the  one in  the  routing  table,  as the  label

imposition

	procedure will never make use of such labels.
	 
	I don't think we want to allow  LDP to put prefixes in the
routing

table, or

	else we'd  have to  treat it as  a second  routing algorithm and
that

would

	raise all kinds of issues.

[Bruno D:] Such procedure would not change the behavior of the IGP and
LDP.
LDP would definitely not act as a routing protocol and all routing
decisions (next-hop selection, recheability) would still rely on the
 
IGP. LDP would continue advertising labels for FECs and would entirely
rely on the RIB for setting up LSPs along the IP route.
 
However, as you very correctly pointed out, we would allow LDP to
"de-aggregate" the FIB and this may raise some issue. However, what is
 
the difference, from the FIB point of view, between one /30 pointing to
Rd and four /32 pointing to Rd? I believe some FIB implementation
already represent a /30 as four /32.
 
Besides, if populating the FTN with specific FEC is found to be an
 
issue, we can only populate the ILM on all P routers. For PE/ingress
router, all we really need is BGP to be aware of these LSPs and be able
to use them to reach the BGP Next Hops.

	It is possible though to imagine a different imposition
procedure:
	 
	- get the IP destination address, A
	 
	- find the prefix, P, in the routing table which is the best
match

(longest

	  match) for that destination address
	 
	- get the next hop, N, for P, as specified by routing
	 
	- if N has distributed any label bindings for prefixes which are

longer than

	  P but begin with the same sequence of  bits as P, and if any
of

these, say

	  Q, is a better match for A than  P, then use the label which N

assigned to

	  Q.
	 
	This is a complicated procedure, though.   You can't just match
A

against Q,

	because there might be some prefix  R in the routing table, with
a

different

	next hop, which is  a better match for A than P is, but  not as
good a

match

	as Q.  The above imposition procedure  says that the next hop
for the

packet

	is determined  by the  route to  R not  by the route  to P  (or
Q).

It's a

	complex matter  to keep  the forwarding tables  in proper shape,

given that

	prefixes like Q can come and go asynchronously.

[Bruno D:] I don't think there is a need to change the imposition
procedure at all. The modification of the label mapping procedure seems
enough. However, as pointing out by Dutta, an additional effort is
 
needed to sync LDP with the RIB because as you said, more specific
prefixes can come and go.

	There are other  complications as well.  For example, what do
you do

if you

	get a packet  which is labeled for Q,  but the next hop has
changed

and the

	new next hop has not distributed a label for Q?
	 
	I suppose we could figure all this out if there were an actual
problem

which

	didn't have a better solution.

	 
	 
	_______________________________________________
	mpls mailing list
	<mailto:[email-masked]> 
	[email-masked]
	https://www1.ietf.org/mailman/listinfo/mpls

 

-- 
101 Billerica Ave,
N.Billerica MA -01862

---

From: "Dutta, Pranjal" <[email-masked]>
Date: Fri, 14 Apr 2006 11:14:39 +0530

Hi Eric,

Regards,

Pranjal

--
Eric

Raveendra Torvi wrote:

Eric,

Bruno,

--

Eric

Eric,

 
Regards,
Bruno

	-----Original Message-----
	...[SNIP]...

match

	 

(longest

routing

are more

imposition

	I don't think we want to allow  LDP to put pr><font size=2 color=black face="Courier New"><span style='font-size:10.0pt'>[Bruno D:] I don't think there is a need to change the imposition<o:p></o:p></span></font></pre><pre><font
size=2 color=black face="Courier New"><span style='font-size:10.0pt'>procedure at all. The modification of the label mapping procedure seems<o:p></o:p></span></font></pre><pre><font
size=2 color=black face="Courier New"><span style='font-size:10.0pt'>enough. However, as pointing out by Dutta, an additional effort is<o:p></o:p></span></font></pre><pre><font
size=2 color=black face="Courier New"><span style='font-size:10.0pt'><o:p>&nbsp;</o:p></span></font></pre><pre><font
size=2 color=black face="Courier New"><span style='font-size:10.0pt'>needed to sync LDP with the RIB because as you said, more specific<o:p></o:p></span></font></pre><pre><font
size=2 color=black face="Courier New"><span style='font-size:10.0pt'>prefixes can come and go.<o:p></o:p></span></font></pre><pre><font
size=2 color=black face="Courier New"><span style='font-size:10.0pt'><o:p>&nbsp;</o:p></span></font></pre><pre><font
size=2 color=black face="Courier New"><span style='font-size:10.0pt'> <o:p></o:p></span></font></pre><pre><font
size=2 color=black face="Courier New"><span style='font-size:10.0pt'>&nbsp;&nbsp;<o:p></o:p></span></font></pre>

<blockquote style='margin-top:5.0pt;margin-bottom:5.0pt' type=cite><pre><font
size=2 color=black face="Courier New"><span style='font-size:10.0pt'>There are other&nbsp; complications as well.&nbsp; For example, what do&nbsp; you do<o:p></o:p></span></font></pre><pre><font
size=2 color=black face="Courier New"><span style='font-size:10.0pt'>&nbsp;&nbsp;&nbsp; <o:p></o:p></span></font></pre></blockquote>

<pre><font size=2 color=black face="Courier New"><span style='font-size:10.0pt'>if you<o:p></o:p></span></font></pre><pre><font
size=2 color=black face="Courier New"><span style='font-size:10.0pt'>&nbsp; <o:p></o:p></span></font></pre>

<blockquote style='margin-top:5.0pt;margin-bottom:5.0pt' type=cite><pre><font
size=2 color=black face="Courier New"><span style='font-size:10.0pt'>get a packet&nbsp; which is labeled for Q,&nbsp; but the next hop has&nbsp; changed<o:p></o:p></span></font></pre><pre><font
size=2 color=black face="Courier New"><span style='font-size:10.0pt'>&nbsp;&nbsp;&nbsp; <o:p></o:p></span></font></pre></blockquote>

<pre><font size=2 color=black face="Courier New"><span style='font-size:10.0pt'>and the<o:p></o:p></span></font></pre><pre><font
size=2 color=black face="Courier New"><span style='font-size:10.0pt'>&nbsp; <o:p></o:p></span></font></pre>

<blockquote style='margin-top:5.0pt;margin-bottom:5.0pt' type=cite><pre><font
size=2 color=black face="Courier New"><span style='font-size:10.0pt'>new next hop has not distributed a label for Q?<o:p></o:p></span></font></pre><pre><font
size=2 color=black face="Courier New"><span style='font-size:10.0pt'><o:p>&nbsp;</o:p></span></font></pre><pre><font
size=2 color=black face="Courier New"><span style='font-size:10.0pt'>I suppose we could figure all this out if there were an actual problem<o:p></o:p></span></font></pre><pre><font
size=2 color=black face="Courier New"><span style='font-size:10.0pt'>&nbsp;&nbsp;&nbsp; <o:p></o:p></span></font></pre></blockquote>

<pre><font size=2 color=black face="Courier New"><span style='font-size:10.0pt'>which<o:p></o:p></span></font></pre><pre><font
size=2 color=black face="Courier New"><span style='font-size:10.0pt'>&nbsp; <o:p></o:p></span></font></pre>

<blockquote style='margin-top:5.0pt;margin-bottom:5.0pt' type=cite><pre><font
size=2 color=black face="Courier New"><span style='font-size:10.0pt'>didn't have a better solution.<o:p></o:p></span></font></pre><pre><font
size=2 color=black face="Courier New"><span style='fonefixes in the
routing

table, or

would

 

 

	 

(longest

	 

longer than

these, say

assigned to

	  Q.

against Q,

different

match

packet

It's a

given that

 

if you

and the

which

	 

	 

 

-- 
101 Billerica Ave,
N.Billerica MA -01862

---

From: "Dutta, Pranjal" <[email-masked]>
Date: Fri, 14 Apr 2006 11:14:39 +0530

Hi Eric,

Regards,

Pranjal

To some extent, every box needs to "make up its mind" whether it is a
router or a switch.
It is important in interoperating between boxp></span></font></p>

<div>

<div class=MsoNormal align=center style='text-align:center'><font size=3
color=black face="Times New Roman"><span style='font-size:12.0pt;color:windowtext'>

<hr size=2 width="100%" align=center tabindex=-1>

</span></font></div>

<p class=MsoNormal><b><font size=2 color=black face=Tahoma><span
style='font-size:10.0pt;font-family:Tahoma;color:windowtext;font-weight:bold'>From:</span></font></b><font
size=2 color=black face=Tahoma><span style='font-size:10.0pt;font-family:Tahoma;
color:windowtext'> Eric W Gray [mailto:[email-masked]] <br>
<b><span style='font-weight:bold'>Sent:</span></b> Thursday, 13 April, 2006
9:13 PM<br>
<b><span style='font-weight:bold'>To:</span></b> Raveendra Torvi<br>
<b><span style='font-weight:bold'>Cc:</span></b> DECRAENE Bruno RD-CORE-ISS;
[email-masked]<br>
<b><span style='font-weight:bold'>Subject:</span></b> Re: [mpls] One LDP
Implementation specific question of receivelabelmapping for prefix FECs</span></font><font
color=black><span style='color:windowtext'><o:p></o:p></span></font></p>

</div>

<p class=MsoNormal><font size=3 color=black face="Times New Roman"><span
style='font-size:12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=3 color=black face="Times New Roman"><span
style='font-size:12.0pt'>Let me answer just the first part of this and let the
rest take care of itself... :-)<br>
<br>
</span></font><font color="#000099"><span style='color:#000099'>LSPs are
[terminated] at aggregation boundaries.&nbsp; This may not be desirable in case
of<br>
an all-MPLS network.</span></font><br>
<br>
To some extent, every box needs to &quot;make up its mind&quot; whether it is a
router or a switch.<br>
It is important in interoperating between boxes that they are each
self-consistent.<br>
<br>
The aggregator router could decide not to aggregate routing information.&nbsp;
That way, it can<br>
distribute more specific labels and not worry about inconsistencies between the
routes it<br>
has advertised and the labels it distributes.<br>
<br>
However, there are reasons why routers aggregate routing information, and I
think it may<br>
be difficult to justify why those reasons would not apply equally well to label
distribution.<br>
<br>
It may very well be the case that routing aggregation is not completely
justified in specific<br>
deployment scenarios. In that case, perhaps it would simply be better to
&quot;turn off&quot; route<br>
aggregation.<br>
<br>
--<br>
Eric<br>
<br>
Raveendra Torvi wrote:<br>
<br>
<o:p></o:p></p>

<p class=MsoNormal style='margin-bottom:12.0pt'><font size=3 color=black
face="Times New Roman"><span style='font-size:12.0pt'>Eric,<br>
According to your solution&nbsp; LSPs are broken at the aggregation boundary or
IGP area boundary, which may not be desirable in case of all-MPLS network. If
main goal is to carry transit traffic by the way of LDP-MPLS switching , In
case of all-MPLS networks an operator would like to inject only LDP-FECs in
other areas (hence achieve the scalability) or avoid summarization LDP-FECs at
IGP area boundary .. Please help me understand. <br>
<st1:place w:st="on">Ravi</st1:place>.<br>
<br>
<o:p></o:p></span></font></p>

<div>

<p class=MsoNormal><span class=gmailquote><font size=3 color=black
face="Times New Roman"><span style='font-size:12.0pt'>On 4/13/06, <b><span
style='font-weight:bold'>Eric W Gray</span></b> &lt;<a
href="mailto:[email-masked]">[email-masked]</a>&gt; wrote:</span></font></span>
<o:p></o:p></p>

<div>

<p class=MsoNormal><font size=3 color=black face="Times New Roman"><span
style='font-size:12.0pt'>Bruno,<br>
<br>
&nbsp;&nbsp;&nbsp; No, if anything specific had to be said, it would be that Ru
MUST NOT advertise a more<br>
specific FEC to an upstream peer (Ruu in this case) than it has advertised in
routing.<br>
<br>
&nbsp;&nbsp;&nbsp; I cannot speak - obviously - for every implementationes that they are each
self-consistent.

--
Eric

Raveendra Torvi wrote:

Eric,

Bruno,

--

Eric

Eric,

 
Regards,
Bruno

	-----Original Message-----
	...[SNIP]...

match

	 

(longest

routing

are more

imposition

table, or

would

 

 

	 

(longest

	 

longer than

these, say

assigned to

	  Q.

against Q,

different

match

packet

It's a

given that

 

if you

and the

which

	 

	 

 

-- 
101 Billerica Ave,
N.Billerica MA -01862