Subject: Questions on Loop Detection (Cra.1, etc.,)

From: "kishan" <[email-masked]>
Date: Sat, 18 Aug 2001 22:45:40 -0700

Q1::

Section 3.4.5.1.2 LDP RFC 3036 states that, when a label mapping message 
is received with a pathvector TLV and loop is detected, the LSR should transmit
 a label release message carrying a Status TLV to the sending LSR to signal
"Loop Detected".

 But,the Label release message(3.5.11) does not include a status TLV in it's
optional List of TLVs? So, what is the way to inform downstream that the 
label release was a result of loop detected by the upstream??

*****

Q2::

    Check_Received_Attributes (A.2.6) algorithm is in such a way that the 
 Path Vector TLV will be processed only when HopCount TLV is present 
in the Label Request/Mapping message. ( CRa.1)

Does that mean Loop Detection can be used only along with HopCount
and it can't be used independently ( without HopCount )?? I know that
sometimes (for ATM/FR LSRs) HopCount is a MUST in Label Request
messages and HC may or may not be present in Label mapping messages
based on the Merge type of the LSR.

The LDP MIB  "draft-ietf-mpls-ldp-mib-07.txt" has the following
loop detection capabilities.
" mplsLdpLsrLoopDetectionCapable OBJECT-TYPE

SYNTAX INTEGER {

none(1),

other(2),

hopCount(3),

pathVector(4),

hopCountAndPathVector(5)

}"

which implies that pathVector(4) should be configurable independent 

of anyother loop detection mechanism ( like HopCount). This contradicts

with the description of Check_Received_Attributes (Cra.1) Algorithm 

in RFC 3036 which states that PathVector TLV will not be processed

if there is no HopCount TLV in the received message.

*******

Thanks,
HariKishan

---

From: Bob Thomas <[email-masked]>
Date: Mon, 20 Aug 2001 16:19:17 -0400

Harikishan,

> Q1::
> 
> Section 3.4.5.1.2 LDP RFC 3036 states that, when a label mapping message > 
> is received with a pathvector TLV and loop is detected, the LSR should > transmit
>  a label release message carrying a Status TLV to the sending LSR to > signal
> "Loop Detected".
> 
>  But,the Label release message(3.5.11) does not include a status TLV in > it's
> optional List of TLVs? So, what is the way to inform downstream that the > 

Please refer to RFC3036, Section 3.4.6 - Status TLV, page 45:

   Note that use of the Status TLV is not limited to Notification
   messages.  A message other than a Notification message may carry a
   Status TLV as an Optional Parameter.  When a message other than a
   Notification carries a Status TLV the U-bit of the Status TLV should
   be set to 1 to indicate that the receiver should silently discard the
   TLV if unprepared to handle it.

> Q2::
> 
>     Check_Received_Attributes (A.2.6) algorithm is in such a way that > the 

Yes.

Please refer to RFC 3035, Section 2.8 - Loop Detction, particularly
the bullets in Section 2.8.1 - Label Request Message, pages 24 and 25, and
Section 2.8.2 - Label Mapping Message, page 26:

   The rules that govern use of the Hop Count TLV in Label Request
   messages by LSR R when Loop Detection is enabled are the following:

   -  The Label Request message MUST include a Hop Count TLV.

and

   The rules that govern the use of the Hop Count TLV in Label Mapping
   messages sent by an LSR R when Loop Detection is enabled are the
   following:

   -  R MUST include a Hop Count TLV.

Bob