Subject: Re: virus alert!

From: [email-masked]
Date: Thu, 19 Apr 2001 15:21:42 +0530

hi!
     thanx a lot for the info. are u sure there is not a problem at your end as
I have not seen any such problem here at my end. I have VirusScan 4.1.40
installed here.

ciao
sumit

"Davide Careglio" <[email-masked]> on 04/19/2001 03:23:50 PM

To:   [email-masked]
cc:    (bcc: Sumit Chauhan/HSS)

Subject:  virus alert!

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]

----- Original Message -----
From: <[email-masked]>
To: <[email-masked]>
Cc: "David Charlap" <[email-masked]>; <[email-masked]>
Sent: Thursday, April 19, 2001 9:57 AM
Subject: Re: Questions about merge-capability in LDP

>
>
> 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
> >
>
>
>
>
>
>
>