Subject: RE: [mpls] One LDP Implementation specific question ofreceive labelmapping for prefix FECs

From: "David Allan" <[email-masked]>
Date: Thu, 13 Apr 2006 10:28:58 -0400

FYI

It does go further, re-writing FEC stack processing for LSP ping to permit interpretation and matching of more specific to less specific prefixes and figuring out whether that was actually permissable in the local context (a.k.a. more specific prefix did not exist at the terminating LSR) could get truly ugly...

cheers
Dave

> -----Original Message-----
> From: Eric W Gray [mailto:[email-masked]] 
> Sent: Thursday, April 13, 2006 10:17 AM
> To: DECRAENE Bruno RD-CORE-ISS; [email-masked]
> Cc: [email-masked]
> Subject: Re: [mpls] One LDP Implementation specific question 
> ofreceive labelmapping for prefix FECs
> 
> 
> Bruno/Pranjal,
> 
>     One thing I would like to make perfectly clear in this 
> discussion is 
> that - if either or
> both of you would like to write an ID that proposes changing or 
> extending LDP to do
> what you suggest, you should do so.  The suggestions you make may be 
> well received
> by participants in the MPLS working group.
> 
>     However, you should not view this as something to 
> "correct" in the 
> current LDP
> specification.  The point of the current LDP specification work is to 
> document what is
> being done in current interoperable implementations, now. 
> 
>     I believe the point has been sufficiently well made by 
> now that the 
> text - as is -
> represents current implementation better than the changes 
> you've implied 
> or explicitly
> suggested should be made with respect to the exact match 
> requirement in 
> handling an
> arriving label distribution.
> 
> --
> Eric
> 
> 
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mpls
> 
> 

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

---

From: "DECRAENE Bruno RD-CORE-ISS" <[email-masked]>
Date: Thu, 13 Apr 2006 18:10:00 +0200

David,

Thanks for the feedback.

I'll need to re-read LSP Ping to check if there is a potential
interaction. Could you please be more specific on the LSP Ping section
that could be impacted?

However, please note that the LDP FEC is not changed on its way from
egress to ingress. In particular, the LDP FEC is not aggregated and all
LSRs on the way know the exact same FEC.

Cheers,
Bruno

> From: David Allan [mailto:[email-masked]]
> Sent: Thursday, April 13, 2006 4:29 PM
> To: [email-masked]; DECRAENE Bruno RD-CORE-ISS;
[email-masked]
> Cc: [email-masked]
> Subject: RE: [mpls] One LDP Implementation specific question ofreceive
labelmapping for prefix FECs
> 
> FYI
> 
> It does go further, re-writing FEC stack processing for LSP ping to
permit interpretation and
> matching of more specific to less specific prefixes and figuring out
whether that was actually
> permissable in the local context (a.k.a. more specific prefix did not
exist at the terminating LSR)
> could get truly ugly...

---

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

Hi Eric,

               Just one comment inlined.

Thanks,

Pranjal

________________________________

From: Eric W Gray [mailto:[email-masked]] 
Sent: Thursday, 13 April, 2006 7:33 PM
To: DECRAENE Bruno RD-CORE-ISS
Cc: [email-masked]
Subject: Re: [mpls] One LDP Implementation specific question ofreceive
labelmapping for prefix FECs

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.

[Pranjal] This is the very critical point. In this case Rd has more
specific entries, but it has decided that its not the egress for those 

FECs (specific entries), rather the egress for the summary FECs
(Prefixes) that it had advertised to Ru, If that is so than LDP has to

be more tightly coupled with Routing (specific IGP and needs to track
which Route got summarized across boundaries or so),right?

    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

---

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

Hi Eric,

Thanks,

Pranjal

Bruno,

--
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.