I removed sections answered already...questions inline.
> > > >
> > > [Javier Antich]
> > > First of all I would say that there are no "real" bandwidth
> > > reservations for LSPs unless you police at the entry point.
> >
> >
> > [Bala S Venkata]--->
> > So what happens when I create an LSP using the "label-switched-path"
> > statement under the "[edit protocols mpls]" hierarchy in a
> Juniper device
> > ?
> > I can specify a bandwidth for the LSP (in addition to my primpary and
> > secondary named paths) correct? What is this bandwidth ?
> [Javier Antich] Is a scalar value that is decremented at each hop
> of the LSP or RSVP-TE session in the admission process of the LSP
[Bala S Venkata]--->
That seems different (?) from what Juniper docs for MPLS apps
(http://www.juniper.net/techpubs/software/junos44/swconfig44-mpls-apps/html/
mpls-signaled-config25.html#1014861) says. Quoting the specific section for
"bandwidth" statement in the hierarchy "[edit protocols mpls
label-switched-path lsp-path-name]"
"Each LSP has a bandwidth value. This value is included in the sender’s
Tspec field
in RSVP path setup messages....[snip]......A nonzero bandwidth requires
transit routers
to reserve capacity along the outbound links for the path. This is done
using RSVP’s
reservation scheme. Any failure in bandwidth reservation (such as failures
at RSVP
policy control or admission control) might cause the LSP setup to fail."
This does not seem to imply the "bandwidth" being a decremented scalar. Does
this happen during the RSVP-TE path setup ?
>
> > And I assume that when you say "police at the entry point" you
> are talking
> > about schemes like rate limiting or access control ? How can this
> > guarantee
> > a bandwidth for an LSP ?
> [Javier Antich] I mean that the current implementations of Traffic
> Engineering using
> RSVP-TE only make reservations in the control plane, not in the
> forwarding plane. That is, you can make a reservation of 1 Mbps
> for one LSP
> but there is no implicit mechanism that prevents you from sending 10 Mbps
> through the LSP unless you limit it at the ingress point. The only way to
> guarantee bandwitdh is limiting the resources others can use.
>
>
[Bala S Venkata]--->
What is the point in making reservations in the control plane that are not
satisifed during forwarding ? It looks to me that the reservation made in
the control plane
are not used at all...am I right ?
> > > However, probably this does not scale too much. Well, maybe even
> > > does not work (can someone test it?).
> > > > Also what happens if PE3 and PE4 now decide to be part of that
> > > VPN ? Do I
> > > > need to do the same between all the PEs if I want to steer the
> > > VPN traffic
> > > > between them into one of the LSPs between them ??
> > > >
> > > [Javier Antich]
> > > And what if there are lots of VPNs?? Probably it is not a good idea
> > > to have per-VPN LSPs between PEs.
> >
> >
> > [Bala S Venkata]--->
> > How else do you think a Service Provider can offer
> "differentiated" VPN ?
> > Looke like he/she can use the LSP for that since LSPs seem to have that
> > level of differentiation (in terms of say bandwidth..)
> [Javier Antich] No they do not have it. In terms of QoS, packets
> are not treated according to the LSP they belong to but according
> to the CoS
> field they carry (exp bits). Maybe new MPLS implementations will do it.
[Bala S Venkata]--->
Which also seem to imply to me that the exp bits classification is the only
"differentiation" that MPLS can offer ? And this is also not something that
a service running on top of MPLS like the VPN can make use of directly ?
TIA
/bala
This archive was generated by hypermail 2b29 : Mon Aug 05 2002 - 10:42:38 EDT