Subject: Re: Questions about merge-capability in LDP

From: [email-masked]
Date: Thu, 19 Apr 2001 13:27:14 +0530

hi bhushana!
      a few points here from me!

regards
-sumit

"Nagabhushana Ramaswamy Nadig" <[email-masked]> on 04/19/2001
05:27:06 PM

Please respond to [email-masked]

To:   David Charlap <[email-masked]>
cc:   [email-masked] (bcc: Sumit Chauhan/HSS)

Subject:  Re: Questions about merge-capability in LDP

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.
****sumit****
In this case would it not make sense to retain the label with you and you might
be the start of that LSP then and above/before this upstream router, maybe we
are getting either unlabeled packets or this can be an aggregating router for
packets to same destination from multiple sources(interfaces or peers). I guess
that is the idea behind merging.
*************

regards
Bhushana

> A rereading of the LDP RFC brings to mind some questions abouthow
> 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: "Davide Careglio" <[email-masked]>
Date: Thu, 19 Apr 2001 11:53:50 +0200

Dear All,

I found a virus in a previous mail with subject: Re: Questions about
merge-capability in LDP.
I don't know who sent it. So, I notify all checking the mail before reading.

Regards,
Davide

_______________________________________
Davide Careglio

UPC Universitat Politècnica de Catalunya
Departament d'Arquitectura de Computadores
Jordi Girona, 1-3, D6 008 (Campus Nord)
08034 Barcelona (Spain)

Phone: +34 93 4017182      Fax: +34 93 4017055
E-Mail: [email-masked]