Subject: Few questions related to LDP

From: "Choudhury, Sanjaya" <[email-masked]>
Date: Fri, 1 Jun 2001 15:28:37 -0400

Hi! I have some basic questions on LDP LSPs. I will appreciate,
	if some one can help me with these. 

	Q1. What are the conditions that make a LSR an ingress for a 
	FEC ? (RFC3036, A.1.2 LMp14)

	Q2. If a LSR is an ingress for a FEC, then it is also an "LSP
Ingress"
	(RFC3031, 3.15 , 1) for the LSP associated with the above
	mentioned FEC.  Is my interpretation correct ?

	Q3. If an LSR is _not_ an ingress  for a FEC, can unlabelled IP 
	traffic (matching the FEC) be mapped into the LDP LSP corresponding
	to the above mentioned FEC ?
	For example:
		R1-----(FEC1 = L1) ------R2-------(FEC1 = L2)------R3
					|
					|
					R4

	R1: ingress for FEC1, R3: egress for FEC1

	Can/Should unlabelled IP traffic arriving at R2 (from R4 and
matching
	prefix) be "inserted" into the LSP _transiting_ through it ?

	Q4. If the answer to the previous question is 'yes', then doesn't
that
	make R2 ingress for that FEC ?

	Thanks,
	sanjay

---

From: "Osama Farrag" <[email-masked]>
Date: Fri, 1 Jun 2001 20:40:55 -0400

Unlabelled IP Traffic Matching FEC in your example, will not be mapped into
the LDP LSP by R2, It should not be inserted by R2.

R1 is Ingress of A FEC, assuming that it is the node that established the
MPLS LSP "tunnel" using LDP.

Regards,
Osama Farrag

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Choudhury, Sanjaya
Sent: Friday, June 01, 2001 3:29 PM
To: [email-masked]
Subject: Few questions related to LDP

	Thanks,
	sanjay

---

From: Abhijit Gadgil <[email-masked]>
Date: Wed, 6 Jun 2001 09:40:16 +0530 (IST)

sorry for a lateish reply..

 please follow inline..

 >the LDP LSP by R2, It should not be inserted by R2.

 Why is it so? As per my understanding, R2 can insert traffic on to the
 LSP, if it has an entry in the FTN points to the NHLFE that corrosponds
 to ILM for labelled packets that arrive from R1. (Assuming R2 merge
 capable). If it is not, it may request a label for traffic arriving on
 the interface to R4.

 Is it not a question of whether an implementation can do it, than whether
 standards support it?

 regards,

 -abhijit

---

From: Nagendra Singh Tomar <[email-masked]>
Date: Wed, 6 Jun 2001 17:59:59 +0530 (IST)

Abhijit,
	If there is an FTN entry in R2 that matches FEC1 then R2 _will_
insert labelled traffic, BUT in that case the statement that R2  is _not_
ingress for FEC1 is _not_ correct. 
     Only if R2 is an ingress LSR for FEC1 will it install such an FTN
entry. To understand how it is known whether an LSR is ingress for an FEC
refer section 3.5.7.1 RFC 3036.  In short an LSR is ingress for an FEC iff
there is a routing tabel entry that exactly matches that FEC.

cheers
tomar 

-- 

------------------------------------------------------------------------------
 Nagendra Singh Tomar
 
 Residence:
 369 KHB Colony
 5th Block Koramangala
 Bangalore 95
 INDIA
 Phone : 5524839
 email : [email-masked]

"Sometimes quantity becomes quality"                                          
                            --Gary Kasparov,                                  
 When he played against Deep Blue. He said this after looking at a           
 computer which found a forced mate in 249 in an endgame, after calculating   
 all the possible moves with only 5 pieces left on the board.                 
------------------------------------------------------------------------------

---

From: Abhijit Gadgil <[email-masked]>
Date: Wed, 6 Jun 2001 20:26:01 +0530 (IST)

>ingress for FEC1 is _not_ correct.

 If R2 does not recognize the FEC1, then when it receives label request
 for that FEC1, it will respond with "No Route" notification. So there is
 every reason to assume R2 has the FEC1 entry in its routing table. So it
 can potentially become _ingress_ for the FEC1. So it does not stop R2
 from putting packets on the LSP. The fact that whether it can do so or
 not is more of implementation choice.

 Any LSR which can receive unlabeled packet and can forward it can become
 _ingress_.

 -abhijit

---

From: Nagendra Singh Tomar <[email-masked]>
Date: Thu, 7 Jun 2001 08:56:23 +0530 (IST)

On Wed, 6 Jun 2001, Abhijit Gadgil wrote:

>  every reason to assume R2 has the FEC1 entry in its routing table. 

I think you missed the keyword "exactly" in the definition of an ingress
node. Assume that the FEC in question is 144.16.72.0/24 . Suppose R1
requests a label mapping for this FEC from R2, and suppose that the entry
in R2 routing table is 144.16.0.0./16 for which the nexthop is R3. Note
that here R2's routing table has an entry that suggests reachability to
FEC 144.16.72.0/24 (hence it won't send a NO ROUTE notification) but since
the routing table entry does not _exactly_
match the FEC, R2 will _not_ install an FTN entry for FEC 144.16.72.0/24
(after it gets a mapping from R3) and hence it will not be an ingress for
that FEC.
 
-- tomar

>  So it

-- 

 Residence:
 369 KHB Colony
 5th Block Koramangala
 Bangalore 95
 INDIA
 Phone : 5524839

---

From: Abhijit Gadgil <[email-masked]>
Date: Thu, 7 Jun 2001 04:58:57 +0530 (IST)

>(after it gets a mapping from R3) and hence it will not be an ingress for

 In this case R2 is acting _over-smart_ and shd be prepared for the
 consequences of doing so...

 When R2 receives a request for 144.16.72.0/24 and it has no entry in the
 routing table exactly matching 144.16.72.0/24 it MUST respond with a No
 Route Notification... (refer section 3.5.8 Label Request Procedures)
 So R2 can indeed send a mapping for 144.16.0.0/16 to R1 unsolicitedly. If
 R1 prefers to use it for 144.16.72.0/24 he's doing so at his own
 risk... So its implementation dependent. And there is nothing hard and
 fast that can prevent R2 from being ingress...

 In general there can be multiple ingress routers for a given FEC. This is
 how multi-point to point LSPs can be created. The case being discussed
 here is precisely a case of multipoint to point LSP.

 -abhijit

---

From: Eric Gray <[email-masked]>
Date: Thu, 07 Jun 2001 13:59:55 -0400

Abhijit/Nagendra,

    Assume the simple topology -

   --- R1 --- R2 --- R3 ---

R1 shows R2 as the nexthop for FEC p.q.r.0/24.  R2 shows R3 as nexthop
for FEC p.q.0.0/16.  This is a de-personalized version of the scenario you
are both working with.  It is a little strange, because it would seem that R2
is not the next hop (from R1's perspective) for (p.q.0.0/16 - p.q.r.0/24) but
this could be the case if the rest of the topology were shown.

If R1 requests a label from R2 for the FEC p.q.r.0/24, R2 could return the
IPv4 explicit NULL label (indicating that it will egress packets destined
for addresses matching this FEC.  In any case, R1's requesting a label
R2 was not intended to cause R2 to ingress packets for this FEC (so an
FTN would not be created for this FEC, but for different reasons than are
indicated in Abhijit's reply).  R2's giving R1 an implicit NULL label for
FEC p.q.r.0/24 allows R2 to examine unlabled packets for this FEC and
- possibly - assign those packets to an LSP corresponding to the FEC
p.q.0.0/16.  For this LSP, R2 could have an FTN and ingress packets.

--
Eric Gray

---

From: Abhijit Gadgil <[email-masked]>
Date: Fri, 8 Jun 2001 05:28:08 +0530 (IST)

Eric,

If R2 is distributing bindings unsolicitedly, it will always distribute
bindings for p.q.0.0/16 and won't distribute for p.q.r.0/24 as it does not
have entry for that FEC in its routing table.

And R2 can send Mapping for label request p.q.r.0/24 when it receives
explicitely such request and in that case it MUST send a No Route
Notification.(according to rfc3036 section 3.5.8).. I accept it is bit
harsh on R2's part in doing so, but this is what the RFC says....

The original question was Whether R2 can put packets from some other guy
R4(pls see below), onto the LSP R1-R2-R3. To which someone has pointed out
that no it can't do so. IMO R2 can do so.. whether it does or not is
implementation choice and standards don't prevent that.

                 |
                 R4

btw there  is a syntax error in ur mail in follwing para. "No matching
brackets". :-)

regards,

-abhijit

---

From: Eric Gray <[email-masked]>
Date: Fri, 08 Jun 2001 09:59:23 -0400

Abhijit,

    Sorry, forgot to 'lint' my email message.

    I believe your premise may be incorrect below: R2 is likely not to
distribute a label mapping for p.q.0.0/16 since it may know what the
routing topology looks like from R1's perspective.  Even if R2 does
distribute this mapping, R1 is free to release the one it can't use and
ask for a different one it can use (with p.q.r.0/24).

    The use of the word 'exact' in section 3.5.8 seems problematic.  I
believe the word 'unambiguous' would have been better.  If you look
at the procedures for handling a label request, the test (LRq.2, page
97) only checks if there is a next hop for the requested FEC, and there
is.  Okay, so you have to work a little harder to figure that out.  So?

    Note that this would not be the case if R1 and R2 had these route
entries in reverse (i.e. R1 shows R2 as the next hop for p.q.0.0/16 and
R2 shows R3 as the next hop for p.q.r.0/24).  In that case, R2 could not
find an unambiguous next hop for the FEC p.q.0.0/16 requested by R1.

--
Eric Gray

---

From: Abhijit Gadgil <[email-masked]>
Date: Fri, 8 Jun 2001 20:27:39 +0530 (IST)

Eric,

If I understand what u have stated correctly, R2 would send mapping for
p.q.r.0/24 only when R1 _requests_ so. Will it not be best on R2s part to
send NO_ROUTE notification in that case?

But I am still not quite clear why R2 won't send mapping for p.q.0.0/16
unsolicitedly as u have pointed out?

regards,

-abhijit

---

From: "Vijayanand C" <[email-masked]>
Date: Mon, 11 Jun 2001 10:29:44 +0530

Eric,
The idea of your unambiguos match as against the usual exact match(or even
the prefix match) is a little confusing.How can p.q.r.0/24 be a match for
p.q.0.0/16 ? It is neither a prefix nor an exact match.

Please correct me if I am wrong.

Vijay

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Eric Gray
Sent: Friday, June 08, 2001 7:29 PM
To: Abhijit Gadgil
Cc: Nagendra Singh Tomar; [email-masked]
Subject: Re: Few questions related to LDP

Abhijit,

--
Eric Gray