Subject: RE: Static LSP Configuration

From: [email-masked]
Date: Tue, 7 May 2002 13:45:55 +0100

Sounds very reasonable to me Gary.  I mean LSPs supporting VPNs should not
be changing very often should they?.....they will usually be long-holding
and ought to be decoupled from any arbitrary routing changes (or indeed any
control-plane misbehaviour) by design.

regards, Neil

> -----Original Message-----
> From: Gary Tam [mailto:[email-masked]]
> Sent: 06 May 2002 15:00
> To: Ron Bonica; Brijesh Kumar; 'Curtis Villamizar '; 'Ajay Simha '
> Cc: [email-masked]; 'gary tam '; [email-masked]
> Subject: RE: Static LSP Configuration
> 
> 
> Thanks all, 
> 
> I think I get my answer that Cisco is not supporting
> static LSP configuration. 
> 
> Oh well, ... 
> 
> Don't you think static LSP will be useful for L2 VPN
> in stitching two access domains together. In most
> case, the L2 Access network does not have to support
> any of the complicated signaling procotocls, but still
> enjoy the benifit of utilizing MPLS. See the following
> example: 
> 
>    (Access1) 1 - 2 (Core) 3 - 4 (Access2)
> 
> In this example, the network operator needs only to
> setup the L2 FEC at ingress LSP, assign and maintain
> labels on 1,2,3,&4 as to setup the static LSP between
> the two access doamins and the core network. 
> 
> In the core network ( between port 2 and 3), it can be
> nested LSP trunking setup by CR-LDP/RSVP-TE. This will
> not change anything in case of failure between 2 and 3
> with the obvious exception of port 2 and 3. 
> 
> The static LSP (1,2,3,4) will likely be
> Martini-encapsulated Tunnel for some L2 VLAN/MPLS VCs
> as well. The L2 FEC can be either MAC DA, VLAN,
> Coustomer ID, and ATM VC, etc. 
> 
> Gary
>         
> 
> --- Ron Bonica <[email-masked]> wrote:
> > >
> > > Also, on your:
> > > >>btw- retorical question - with static LSPs, what
> > happens when a link
> > > goes down?
> > >
> > > Should the expected behaviour  need to be any
> > different than when someone
> > > routes with static routes?
> > >
> > > Cheers,
> > >
> > > --brijesh
> > >
> > >
> > 
> > Brijesh,
> > 
> > Statically configured LSPs blackhole traffic when a
> > link in the middle of
> > the LSP fails.
> > 
> > The LSR immediately upstream of the failure discards
> > all traffic belonging
> > to the LSP. This is because that LSR may not look
> > beyond the MPLS label to
> > forward the traffic. See RFC 3031 Sections 3.18 and
> > 3.22 for details.
> > 
> >                                                   
> > Ron
> > 
> 
> 
> ______________________________________________________________
> ________ 
> Games, Movies, Music & Sports! http://entertainment.yahoo.ca
>

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 08 May 2002 14:11:36 -0400

> control-plane misbehaviour) by design.

When a fiber gets chopped or a laser goes dead the LSP should affected
as little as possible, with the path change as transparent as possible
to the end user.  That is different from disallowing path change.  By
decoupled, I'm hoping you mean that path changes due to failure should
be expected to occur (and very rapidly) and should be transparent.

Curtis