Subject: Questions about merge-capability in LDP

From: David Charlap <[email-masked]>
Date: Wed, 18 Apr 2001 12:54:21 -0400

A rereading of the LDP RFC brings to mind some questions about how
different modes of operation (on-demand vs. unsolicited) work in
conjunction with merge-capable and non-merge-capable routers.

I've run through several scenarios.  If any of my assumptions are wrong,
please let me know.  I think I've got everything right for the
downstream-on-demand scenarios.  I don't know if I've got things right
for the downstream-unsolicited scenarios.

All of these scenarios involve 5 routers in a straight-line topology. 
All routers are IP-lookup and push capable, and are therefore capable of
acting as ingress rotuers.  There is a single FEC, for which which R5 is
egres..

-=-=-=-=-

Scenario 1:

	[R1]---{R2]---[R3]---[R4]---[R5]

All routers are merge-capable.  They are configured for downstream-on-
demand label distribution.  R1 sends a Label-request to R2, and it
propagates to R5.  R5 sends a Label-mapping to R4, and it propagates
back to R1.  The resulting LSP looks like this:

              ->-\   ->-\   ->-\
        ---------->------>------>------>
	[R1]---{R2]---[R3]---[R4]---[R5]

R1 pushes the label for incoming packets.  R2-R4 configure themselves
both to push the label for unlabeled packets, and to swap the label for
labeled packets.  R5 pops the label for labeled packets and simply
forwards unlabeled traffic

-=-=-=-=-

Scenario 2:

	[R1]---{R2]---[R3]---[R4]---[R5]

No routers are merge-capable. Downstream-on-demand distribution.

R1 sends a Label-request to R2.  R2 sends two Label-requests to R3 (one
for labeled traffic and one for unlabeled traffic).  R3 sends three
Label-requests to R4 (two for the two possible incoming labels and one
for unlabeled traffic.)  R4 sends four Label-requests to R5 (three for
the three possible incoming labels and one for unlabeled traffic.)

Label-mappings propagate back to satisfy all requests.  The resulting
LSPs look like:

                             ---------->
                      ----------------->
               ------------------------>
        ------------------------------->
	[R1]---{R2]---[R3]---[R4]---[R5]

-=-=-=-=-

Scenario 3:

	[R1]---{R2]---[R3]---[R4]---[R5]
                (M)           (M)

R2 and R4 are merge capable.  R1, R3 and R5 are not. 
Downstream-on-demand distribution.

R1 sends a Label-request to R2.  Since R2 can merge this request with
unlabeled traffic, it only sends one Label-request to R3.  R3 can not
merge this request with unlabeled traffic, so it sends two
Label-requests to R4.  R4 can merge both of these requests with each
other and with unlabeled traffic, so it sends one Label-Request to R5.

Label-mappings propagate back to satisfy all requests.  The resulting
LSP looks like:

              ->-\   ->--------\
        ---------->------------->------>
                            ->-/
	[R1]---{R2]---[R3]---[R4]---[R5]

-=-=-=-=-

Scenario 4:

	[R1]---{R2]---[R3]---[R4]---[R5]

All routers are merge-capable.  They are configured for downstream-
unsolicited label distribution.  R5 sends a Label-mapping to R4, and it
propagates to R1.  The resulting LSP looks just like it would with
on-demand distribution:

              ->-\   ->-\   ->-\
        ---------->------>------>------>
	[R1]---{R2]---[R3]---[R4]---[R5]

-=-=-=-=-

Scenario 5:

	[R1]---{R2]---[R3]---[R4]---[R5]

No routers are merge-capable. Downstream-unsolicited label distribution.

- R5 sends a Label-mapping to R4.
- R4 realizes that it needs two labels - one to send upstream and one
  to install for unlabeled traffic.  It uses one label and sends a
  Label-request message to R5 in order to get a second.
- R5 sends a second Label-mapping to R5
- R4 sends a Label-mapping message to R3.
- R3 realizes that it needs two labels - one to send upstream and one
  to install for unlabeled traffic.  It uses one label and sends a
  Label-request message to R4 in order to get a second.
- R4 sends a Label-request downstream to R5, since it now needs a
  third label (in order to satisfy the new request).
- R5 sends a third Label-mapping to R4
- R4 sends a second Label-mapping to R3
- R3 sends a Label-mapping to R2
- R2 realizes that it needs two labels - one to send upstream and one
  to install for unlabeled traffic.  It uses one label and sends a
  Label-request message to R3 in order to get a second.
- R3 sends a Label-request downstream to R4, since it now needs a
  third label (in order to satisfy the new request).
- R4 sends a Label-request downstream to R5, since it now needs a
  fourth label (in order to satisfy the new request)
- R5 sends a fourth Label-mapping to R4
- R4 sends a third Label-mapping to R3
- R3 sends a second Label-mapping to R2
- R2 sends a Label-mapping to R1

The resulting LSPs look just like they would with on-demand
distribution:

                             ---------->
                      ----------------->
               ------------------------>
        ------------------------------->
	[R1]---{R2]---[R3]---[R4]---[R5]

-=-=-=-=-

Scenario 6:

	[R1]---{R2]---[R3]---[R4]---[R5]
                (M)           (M)

R2 and R4 are merge capable.  R1, R3 and R5 are not. 
Downstream-unsolicited.

- R5 sends a Label-mapping to R4
- R4 sends a Label-mapping to R3
- R3 realizes that it needs two labels - one to send upstream and one
  to install for unlabeled traffic.  It uses one label and sends a
  Label-request message to R4 in order to get a second.
- R4, being merge-capable, does not propagate the Label-request, but
  sends a Label-mapping to R3
- R3 sends a Label-mappng to R2
- R2 sends a Label-mapping to R1

The resulting LSp looks just like it does with on-demand distribution.

              ->-\   ->--------\
        ---------->------------->------>
                            ->-/
	[R1]---{R2]---[R3]---[R4]---[R5]

-=-=-=-=-

Does all of this look right?  It seems good to me.  But I'm not certain
about scenarios 5 and 6.  The LDP RFC doesn't explicitly document the
behavior of non-merge-capable routers receiving unsolicited label
mappings.

Comments?

-- David

---

From: Eric Gray <[email-masked]>
Date: Wed, 18 Apr 2001 14:32:24 -0400

David,

    Near as I can tell, these are all right.  However, LDP does explicitly
describe the handling of 'unsolicited label mappings' in procedures for
receiving label mappings in Appendix A.  Look into the behaviors with
respect to getting a label mapping for which there is no outstanding
request - that's pretty much what it's all about.

    There are a great many more scenarios to worry about, as well.  You
might want to enjoy a thought experiment in which some of these routers
are using downstream on demand and other are using downstream
unsolicited.  Of course, that implies that one or more of the LSRs is able
to deal with one mode at one interface and another at another.

    One of the good news items about this is that the scenario mostly
applies to ATM where LSRs are effectively only required to support
DoD mode.  So, if the LSRs are ATM LSRs and none of them support
dual control mode operation and at least one of them only supports the
DoD mode, then label distribution will be all DoD.

--
Eric Gray

---

From: David Charlap <[email-masked]>
Date: Wed, 18 Apr 2001 14:53:18 -0400

Eric Gray wrote:
> 
>     Near as I can tell, these are all right.  However, LDP does
> explicitly describe the handling of 'unsolicited label mappings' in
> procedures for receiving label mappings in Appendix A.  Look into
> the behaviors with respect to getting a label mapping for which
> there is no outstanding request - that's pretty much what it's all
> about.

Yes, but the pseudocode there doesn't talk about non-merge-capable
routers requesting additional labels.  The only mention of merge-
capable vs. non-merge-capable in Appendix A is in the context of whether
or not to include a Path Vector TLV.

-- David

---

From: Eric Gray <[email-masked]>
Date: Wed, 18 Apr 2001 16:56:29 -0400

David,

    That's because - when the issue with handling merge capable
and non-merge capable label distributions came up during the last
call, the authors decided that the functionality required to handle
this was not specific to non-merging LSRs.  It is applicable to any
LSP for which the upstream LSR chooses not to merge - whether
or not it is merge capable.

    Therefore, if you were expecting there to be a call-out - of the
sort "if the LSR is non-merge capable", then you will continue to
be disappointed.  :-)

    If you look at the procedures for handling label mappings, you
will see that the notion of handling a requested label is dealt with
irrespective of the label distribution mode (DU/DoD).  You will
also see that there is nothing in the procedures for handling a
label request that prevents an LSR from responding to one even
if the mode of operation is supposed to be DU.

    If I can request a label - and get a distinct one - whenever I
want one (unless and until the peer runs out), then I can handle
both the case where the peer is merge capable and the case
when the peer is simply merge-averse.

--
Eric Gray

---

From: Eric Gray <[email-masked]>
Date: Wed, 18 Apr 2001 17:08:18 -0400

David,

    The last sentence was supposed to read:

" ... I can handle both the case where the peer is not merge
capable and the case when the peer is simply merge-averse.

--
Eric Gray

---

From: David Charlap <[email-masked]>
Date: Thu, 19 Apr 2001 11:33:47 -0400

Nagabhushana Ramaswamy Nadig wrote:
> 
> 1. Particularly the way you have mentioned of raising the internal
> label requests for the FECs. How far does it make sense to wait for
> a label request from a peer LSR and take the same as a trigger for
> learning a new FEC. What I think is, as each of these LSR's would
> be running a L3 routing protocol the moment I learn a new route at
> L3 should be the trigger for me to make a new request to the next
> hop peer (Ideally we will be populating our FTN table in this case
> and ILM in the former).

You should not assume that a switch will automatically use every prefix
in its routing table as an LDP FEC.  Depending on the topology, this
could lead to excessive and unnecessary memory usage.

Yes, the FEC might already be known at the time the unsolicited mapping
arrives.  Or it might not be.  If a label-request/label-mapping message
arrives with an unknown FEC that is in the IGP, it makes sense to use
this as a "detected new FEC" trigger.

>         Depending upon this I would say the sequence of message flow
> changes in your below discussions.

Yes, but this doesn't change very much.  I'm not trying to exhaustively
decribe every possible combination of configurations.  That would take
several megabytes of documentation and would be of very little
additional value.

Take my examples as they are intended - as examples - and not as a
complete enumeration of an implementation.

> 2. Scenario 5. I really doubt such a configuration will work for
> you. A non-merge capable LSR cofigured for Unsolicited distribution
> (there by to also to receive unsolicited messages). In this case if
> you receive an Unsolicited mapping msg, what will you do with that?
> To which upstream peer are you going to distribute this? I think
> because of this only the architecture has wisely avoided the DU
> mode for non-merge LSRs.

I don't see how it matters which upstream you distribute it to.  If you
have two, or twenty, or a million labels for a single FEC, they are all
equivalent and should be interchangeable.

The important thing is that the router needs more labels than it has. 
So it will use the ones it has and request any additional ones it may
need.  While the order may be of importance to an operator, it doesn't
affect the protocol's operation.  This can safely be a matter of local
configuration.

As for the architecutre, this is part of my question.  Section 5.2.2 of
RFC 3031 seems to state that unsolicited operation is illegal for
non-merge-capable routers.  But I'm not completely sure of that.  I fail
to see a reason for any such prohibition.  As far as I can tell, label
distribution works fine in this mode.

-- David

>> - R4 realizes that it needs two labels - one to send upstream and
>>   one to install for unlabeled traffic.  It uses one label and
>>   sends a Label-request message to R5 in order to get a second.
>> - R3 realizes that it needs two labels - one to send upstream and
>>   one to install for unlabeled traffic.  It uses one label and
>>   sends a Label-request message to R4 in order to get a second.
>> - R2 realizes that it needs two labels - one to send upstream and
>>   one to install for unlabeled traffic.  It uses one label and
>>   sends a Label-request message to R3 in order to get a second.

---

From: "Nagabhushana Ramaswamy Nadig" <[email-masked]>
Date: Thu, 19 Apr 2001 11:57:06 +0000 (Local time zone must be set--see zic manual page)

Hello,
	I have a few observations from your mail. 
1. Particularly the way you have mentioned of raising the internal label
requests for the FECs. How far does it make sense to wait for a label
request from a peer LSR and take the same as a trigger for learning a new
FEC. What I think is, as each of these LSR's would be running a L3
routing protocol the moment I learn a new route at L3 should be the 
trigger for me to make a new request to the next hop peer (Ideally we will
be populating our FTN table in this case and ILM in the former).
	Depending upon this I would say the sequence of message flow
changes in your below discussions.

2. Scenario 5. I really doubt such a configuration will work for you. A
non-merge capable LSR cofigured for Unsolicited distribution (there by to 
also to receive unsolicited messages). In this case if you receive an
Unsolicited mapping msg, what will you do with that? To which upstream
peer are you going to distribute this? I think because of this only the
architecture has wisely avoided the DU mode for non-merge LSRs.

regards
Bhushana

> A rereading of the LDP RFC brings to mind some questions abouthow