Subject: Loop Detection doubts !!

From: Manoj Dutta <[email-masked]>
Date: Mon, 02 Jul 2001 19:04:02 -0700

Hi,

I have the following doubts in RFC 3036.

1) In LMp.6 and LMP.7, what happens if the label being deleted maps to
one or more upstream labels ?  If those labels are not withdrawn, then
the LSR in question would end up  discarding all the incoming packets
bearing those labels.

2) In LMp.23 (Note 9), only path vector attribute is considered.  Is
there a reason for not considering hop count attribute.

4) How should an LSR handle the case when a label release  bearing a
loop detection information arrives.  Taking the same action as is done
for "No Route" case doesn't seem right.

5) When a loop detection notification arrives in response to a request
message,  the LSR receiving this message defers this request and sends
it repeatedly with the same attributes. Now, if the request attributes
cause the nexthop to send a loop detction message (maybe due to path
vector or hop count attributes),
then what is the use of sending the same message again.

thanks in advance
manoj

---

From: Abhijit Gadgil <[email-masked]>
Date: Tue, 3 Jul 2001 15:56:23 +0530 (IST)

>the LSR in question would end up  discarding all the incoming packets

Sending withdraw message is not required here, as we _do have_ outgoing
label for all those incoming upstream labels. What basically is being
tried to achieve here is to stop an attempt to create multiple bindings.
The newly learned label is perhaps _better_ so use it instead of the old
label. Why would u send withdraw. If u send withdraw u will also have to
send another mapping perhaps unsolicitedly.

If the attributes of newly received label are different than those of
previously received one, that will be taken care of in subsequent
processing. (LMp. 17 loop)

 >there a reason for not considering hop count attribute.

It does not explicitely prevents from checking Hop Count. On the other
hand hop-count should be checked. Note 9 is illustrating on what to do
with path vectors.

 >for "No Route" case doesn't seem right.

can u please point, where it is stated so, I am not able to find it out in
the rfc. Perhaps you are refering to A.1.11., it is not stating actions
pertaining to label release message, so I think the section A.1.4 should
be followed.

I think a note at the end of A.1.11 can be added to point out label
handeling case if at all or the note at the end of A.1.11 can be appended
with following sentence.
If the Loop Detected Status Code comes in Label Release message, follow
the algorithm for the Label Release message instead of No Route
notification. (I don't think this is even necessary as it is obvious)

 >then what is the use of sending the same message again.

hmm thats interesting. Sorry, I cannot think of any good answer. The only
reason why the attributes are resent is that one does not know the exact
reason for loop detection. So the attributes are sent in the hope that
this time they will be correct. Implementation can take care of such
things where it makes a check at outgoing Path Vector while sending the
message, and stop it from delievering if it indeed finds the address of
the LSR to which it is being sent.( Thanks Eric for similar explaination
in some previous mail. )

 >manoj

-abhijit

-- 
Abhijit Gadgil
Graduate Student,
Dept. of Electrical Engineering,
IIT, Bombay.

---

From: Eric Gray <[email-masked]>
Date: Tue, 03 Jul 2001 09:40:45 -0400

Manoj,

    See comments in line...

> the LSR in question would end up  discarding all the incoming packets

Maybe.  The procedure specification should be silent on this point
because whether or not the packets are dropped may be either an
implementation or a deployment choice.

Consider this: if the LSR has no choice but to drop the packets, then
why would the ingress to the LSP for these packets have a choice?
So, there may be a trade off between wasting network resources to
get packets to this LSR - only to have them dropped - and taking a
bit longer to re-establish an LSP once the loop is resolved.  And, if
the LSR has a choice between dropping the packets or forwarding
them as IP packets, then the LSP is still useful - if a bit shorter.

> there a reason for not considering hop count attribute.

I think Note 9 could include Hop Count.  The issue seems to be that
considering the Path Vector is more complicated since it is likely that
the previous Path Vector was not stored.  Moreover, it is likely that an
LSR would not perform a check of the Path Vector - even if the earlier
Path Vector was retained - because the check is somewhat harder to
do than it is to simply forward the message including the Path Vector.

It may simply be that the authors felt that checking the Hop Count was
obvious.  There is no implication in Note 9 that Path Vector is the only
thing checked, and the need to check Hop Count is described elsewhere
(see, for instance, the 3rd bullet on page 27, 1st paragraph on page 28
and the entirety of section 3.4.4.1 starting on page 40).

> for "No Route" case doesn't seem right.

Not sure where you get this from.  The LSR should handle a Label Release
using the procedures described in Appendix section A.1.4.

> then what is the use of sending the same message again.

The analogy between "Loop Detected" and "No Route" is a good one.
Both are presumed to be temporary conditions resulting from a routing
transient.  Where the presumption is wrong for one, it is likely wrong
for the other.  For this reason, the implementor should provide some
indication to the network operator when some number of retries have
failed.

--
Eric Gray