Subject: Section A.1.2 RFC 3036 concerns!

From: [email-masked]
Date: Tue, 12 Jun 2001 13:15:37 +0530

Hi!
     I have a few concerns regarding the algo defined in this section

1. LMp.10 - In this case should we not consider this as a dual purpose message
for the release of the previous label and installing the new label generated by
the same downstream LSR. I strongly think it gives a better logic to the
situation here as we have confirmed already that this is from our current
next-hop for that FEC.

2. LMp.14 - How do we actually define a Ingress LSR? In my opinion any LSR
should be able to act as Ingress atleast till the point the network IGP comes
into stable state as till that point packets to the same destination may be
coming from different Ingress routers. I would probably use something like - For
the LMp.14 case we should have a FTN entry created and then time it out using
say LRU algorithm to keep the size of FTN in check. Am I correct?

3. LMp.17 - Why do we need to send this also to the Peer LSR fro which the
mapping has been learnt? Someone has raised the question earlier as well but I
am still not convinced about the right approach here.

4. LMp.21 - In the message sent should not "PrevAdvLabel" be just "Label". We
are only sending the current mapping and not the previous one here.

5. Lmp.28 - Should this not be done before LMp.20 so that we may not have to
resend to the same peer twice (once because we are in DU mode and again when we
realise we also have an outstanding request for a label from the same peer). I
know this will not cause a problem as the peer will reject the second mapping
but seems an awful waste of processing and network bandwidth (same as in point 1
above).

regards
sumit

---

From: Eric Gray <[email-masked]>
Date: Tue, 12 Jun 2001 10:22:51 -0400

> situation here as we have confirmed already that this is from our current

No. See "http://cell.onecall.net/mhonarc/mpls/current/msg00004.html",
second paragraph in particular.

> say LRU algorithm to keep the size of FTN in check. Am I correct?

Out of scope for specification.   This falls under the heading of 'figure it out or
find
another line of work'.  :-)

(Your opinion on who must be an Ingress is not technically correct.  Apply the
same reasoning to who must be an egress, and you may find some satisfaction)

See any of about a thousand postings on Label Edge Router functionality, over
the last 2 years.

> am still not convinced about the right approach here.

See note 7 - as it already says.

> are only sending the current mapping and not the previous one here.

No.  We are re-advertising the same label - in case there is a change in
hop count or path vector.

> but seems an awful waste of processing and network bandwidth (same as in point 1

No. Assume we are operating in DU advertisement, ordered control, mode.  If we have
an
outstanding request from an LSR peer that is upstream with respect to a particular
FEC,
then it MUST be because the upstream LSR is looking for at least two labels.  The
label
advertisement mode is negotiated between peers and both must use the mode
negotiated.
Therefore, for an LSR that is operating in DU mode to send a label request, it must
expect
at least two label mappings.

The current procedure arrives at the correct behavior.

---

From: "Eric Gray" <[email-masked]>
Date: Thu, 21 Jun 2001 17:03:11 -0700