Subject: RE: LDP-09 - Receive Label Mapping

From: Eric Gray <[email-masked]>
Date: Thu, 10 Aug 2000 13:58:04 -0700

Bob/Jim,

	I have to disagree with both of you.  Sorry.

	This needs a closer look.  When we had discussed
this in trying to cover the non-merge upstream peer case,
I had proposed the wording pretty much as it is.  Naturally,
I think it should stay that way.  :-)

	The reason for this is that step LMp.29(DU)-3 says 
to go to step LMp.30 if there are no further outstanding
Label Requests.  In that case, you have no need to delete
further Label Requests.

	If there are further Label Requests, you "fall thru"
to step LMp.29(DoD) and process any that apply.  This will
be necessary, for instance, when the local peer is merging,
the upstream peer is not and the local peer has waited for
a Label Mapping from downstream before sending Mappings to
its upstream peers for the LSP that it will merge.  If the
LSR procedure is followed in this way, the outstanding Label
Requests will be deleted as they are responded to.

	If you add a step LMp.29(DU)-4 to delete outstanding
Label Requests, you will have sent only one Label Mapping
for this peer - regardless of how many Labels were asked
for.

	For completeness, it would have made sense to delete 
the one Label Request that is being processed, except that 
you are in LMp.29(DU) - which (by default) means you may
not be processing an Label Requests.

	To clarify one potential point of confusion, in the
non-merge LSP case, it is quite possible to have multiple
outstanding Label Requests - even when operating in DU
mode.

> -----Original Message-----
> From: Bob Thomas [mailto:[email-masked]]
> Sent: Thursday, August 10, 2000 12:29 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: LDP-09 - Receive Label Mapping 
> 
> 
> Jim,
> 
> > Thanks for the clarification.  I have one additional question.
> > 
> > On Thu, Aug 10, 2000 at 01:47:07PM -0400, Bob Thomas wrote:
> > <snip>
> > > LMp.29-DU handles the situation where there are outstanding label
> > > requests from the peer (which won't be the case if LMp.20+LMp,21
> > 
> > Shouldn't the record of these requests be deleted then in LMp.29-DU?
> > LMp.29-DoD has the line "4.  Delete record of pending request."
> 
> Yes.
> 
> A difficulty in generating these procedures (in addition to trying to
> get them right) was keeping them short enough so that they could be
> read/understood yet detailed enough to cover the important actions.
> 
> Doing this involved numerous judgements as to what could be omitted.
> In this case (and probably others), we were inconsistent.
> 
> 
> Bob
> 
> 
> 
> 
> > > This procedure is complex because the number of 
> combinations of modes
> > > that must be handled (DU/DoD advertisement, 
> liberal/conservative retention,
> > > ordered/independent control).  There are no doubt ways to 
> re-arrange
> > > it to achieve the desired effect.
> 
>

---

From: Eric Gray <[email-masked]>
Date: Thu, 10 Aug 2000 14:13:59 -0700

Bob/Jim,

	Actually, in re-reading this, the thing that 
first bothered me about Jim's comment came to the
front again.  In LMp.29(DU), you are _not_ handling
an outstanding Label Request.  When you fall thru 
to LMp.29(DoD), you would process all pending Label 
Requests that can be satisfied by merging onto the
Label Mapping that was received.

	In the DU mode, it is possible that this might
result in sending one more Label Mapping than was 
asked for.  But this is dealt with by the upstream
peer which will Release extraneous Label Mappings it
receives.  If the upstream peer is behaving itself
in supporting the DU, non-merge, case - this will not
occur.

	Hence it would no make sense to delete pending
Label Requests in step LMp.29(DU).  Which is intuitive
when you think about it. 

> From: Eric Gray [mailto:[email-masked]]
> Sent: Thursday, August 10, 2000 1:58 PM
> To: 'Bob Thomas'; [email-masked]
> Cc: [email-masked]
> Subject: RE: LDP-09 - Receive Label Mapping 
> 
> 
> Bob/Jim,
>