Subject: couple of ldp questions

From: Vrishab Sikand <[email-masked]>
Date: Thu, 26 Aug 1999 12:09:24 -0400

1) FEC TLV in "No Route" Notification message

    When returning a "no route" notification to a peer (in response to a
label request)
     can the FEC TLV be a separate TLV, or does it have to be part of
the "returned pdu"
     or "returned msg" TLV's.  Can someone please illustrate the
"returned msg" and
     "returned tlv's" to me, I find the definitions in the LDP spec are
not super clear.

2) The LSR MIB allows  labels to be added through SNMP.
     Do you expect that people will be adding labels through SNMP on the
same
     interface at the same time, when dynamic label distribution
protocols like
     LDP and RSVP will be running?  If so what are the rules for
contention or
     is that a implementation choice?

thanks
Vrishab Sikand

---

From: [email-masked]
Date: Mon, 30 Aug 1999 13:08:37 +0800

Hi Vrishab,

Page 32 of LDP Draft-5 states
"Labels are bound to Forwarding Equivalence Classes (FECs).  a FEC is
a list of one or more FEC elements.  The FEC TLV encodes FEC items."

Also, In Page 33,

"Note that this version of LDP supports the use of multiple FEC
     Elements per FEC for the Label Mapping message only.  The use of
     multiple FEC Elements in other messages is not permitted in this
     version, and is a subject for future study."

Hence, there can be only one FEC element in the FEC TLV
which is contained within the Label Request Message.

And in page 70,

"This version of the protocol defines the following Status Codes for
   the Notification message that signals a request cannot be satisfied:

     No Route
       The FEC for which a label was requested includes a FEC Element
       for which the LSR does not have a route."

It does refer to the FEC in the Label request and not to the Notification

Hence, an FEC TLV need not be sent in the notification as the "Message Id"
of the label request suffices for a match while the notification is received
by the upstream peer

The question of sending an FEC TLV also in the notification message may arise
if the protocol allows "multiple" FEC elements in a single FEC TLV.
The receiver of the label request message may not have matching routing entries
in it's routing tables corresponding to a few of the FEC elements in the FEC TLV
of the Label Request message.
The Notification Message (NO ROUTE) will then include the "Message Id" of the Label
Request message in the Status TLV for transaction matching.
Additionally, an FEC TLV would be included that would include only those FEC
elements for which a matching route couldn't be found.

cheers,
chetan

Previous contents:
---------------------------------------------------------------------------------------------
[email-masked] wrote:

> Hi Vrishab,
>
> Regarding the first question,
>
> The "No Route" notification need not send the FEC TLV
> It uses the Status TLV "Message Id" field to indicate
> the label request that generated this notification.
> Hence, the FEC TLV may not be needed in the notification.
> But it needs the sender of the label request to store
> the Message Id which aids in simpler implementations.
>
> Correct me if I am wrong.
>

The Ldp draft has the following Lines about "no Route" notification.
page 70

" No Route
       The FEC for which a label was requested includes a FEC Element
       for which the LSR does not have a route."

Although the language is not super clear, i think it means that the no route notification MUST include
a FEC TLV.

I think it makes sense for this notification to include the FEC TLV, for the same reasons that
it is a required TLV in: Label Mapping, abort and withdraw messages

Can the authors please clarify

>
> Again, you are right in that the usage of
> Returned PDU and Returned Message TLVs are not
> illustrated
>
> cheers,
> chetan
>
> You wrote:
> --------------------------------------------------------------------------------------------------------

--
tx
Vrishab Sikand