Subject: label map procedures

From: [email-masked] (Prem Shankar Sharma)
Date: Fri, 21 Jan 2000 17:29:07 -0800

Hi All,

   There seems to be some confusion around steps LMp.4 and LMp.5 in
   label map procedures in ldp specs.

   My interpretation was that the LSR was receiving many label maps for
   the same label request. The first label map is received and the label
   is made use of. The subsequent labels maps are just to inform/update the 
   LSR abt. the change in the attributes for the lsp. BUT THE ONLY THING
   GOING AGAINST THAT WAS : How would LSR determine whether it is an
   update of the already issued (and satisfied) label request when LSR
   has already deleted the record of the outstanding label request as per
   LMp2? IF we had somehow maintained that record (or some other minimal 
   info.) and would have used the msgId (or some other means) of the label 
   req. msg. in the subsequent label maps, things would have solved.
   [If message id is used, then the same couldn't be re-used till that 
    LSP goes away.]

   The current description of the label map, I feel, could not support the 
   operation of non-merging LSRs.

   If the LMp 5. is considered in the context of the LSP than it could make
   sense. Even then it would require that the label request record or 
   some minimal info. is maintained. 

   Would like to hear your thoughts in this regard.

   Please let me know, if I missed something.

Regards.
Prem

---

From: Eric Gray <[email-masked]>
Date: Sat, 22 Jan 2000 08:47:01 -0500

Prem,

	We have been looking at this.  Using the Message ID would
work, but is not necessary.  Worse than that, implementations are
out there that already assume they can re-use the Message ID once
the Label Request and Label Mapping transaction is complete.  If
we adopt a suggestion to use Message ID, we break implementations
that are compliant with the current LDP specification.  Since the
current LDP specification is beyond last call, this is not a very
good idea.

	To determine if a Label Mapping is an update of parameters
received previously, simply look at the LABEL.  If you've already
been assigned this LABEL, then the Label Mapping is an update.  It
really is that simple.  An LSR that attempts to re-use a LABEL for
some other purpose (a different FEC, for example) without having
sent a Label Withdraw and received a corresponding Label Release
is in blatant violation of the protocol.  Period.

	Note that you do not get to LMp.4 and LMp.5 unless you've
detected a loop.  If you've detected a loop, then some one or more
of the parameters must have changed.

	The current issue with the entire LMp section is that it
does not effectively support the case where more than one Label
Request is outstanding at a time.  Several of us (within Lucent)
have been in touch with the members of the LDP design team and
we are trying to work out a minimal delta to the specification
to allow for this support.

	Support for multiple outstanding Label Requests MUST be
provided in order to support non-merging LSRs.  This support is
absolutely required in a first version of LDP.

	Hopefully, we can count on the LDP design team to work
with us a little more closely in trying to resolve this issue.

Thanks!
--
Eric Gray