Subject: RE: RE: Is PWE a layer?

From: "Thomas D. Nadeau" <[email-masked]>
Date: Thu, 22 May 2003 19:23:53 -0400

> -----Original Message-----
> From: Mustapha Aissaoui [mailto:[email-masked]] 
> Sent: Thursday, May 22, 2003 4:16 PM
> To: [email-masked]
> Cc: 'Busschbach, Peter B (Peter)'; 'Shahram Davari'; 'Yaakov 
> Stein'; 'Mark Seery'; [email-masked]
> Subject: Re: [PWE3] RE: Is PWE a layer?
> 
> 
> Tom,
> 
> "Thomas D. Nadeau" wrote:
> > 
> > > -----Original Message-----
> > > From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of 
> > > Mustapha Aissaoui
> > > Sent: Wednesday, May 21, 2003 4:36 PM
> > > To: Busschbach, Peter B (Peter)
> > > Cc: 'Shahram Davari'; 'Yaakov Stein'; Mark Seery; [email-masked]
> > > Subject: Re: [PWE3] RE: Is PWE a layer?
> > >
> > >
> > > Peter,
> > >
> > > "Busschbach, Peter B (Peter)" wrote:
> > > >
> > > > > -----Original Message-----
> > > > > From: Shahram Davari [mailto:[email-masked]]
> > > > > Sent: Wednesday, May 21, 2003 2:43 PM
> > > > > To: 'Busschbach, Peter B (Peter)'; 'Yaakov Stein'; Mark Seery
> > > > > Cc: [email-masked]
> > > > > Subject: RE: [PWE3] RE: Is PWE a layer?
> > > > >
> > > > >
> > > > > >a) TTL > 2
> > > > > >Eric Rosen made the point that there are cases in which it 
> > > > > >makes sense to splice PWs together and switch based on the PW
> > > label. IMO,
> > > > > >that turns the "PW layer" into an MPLS layer. (It makes
> > > you wonder
> > > > > >why there is a PW layer in the first place. Why not
> > > define how to
> > > > > >adapt client traffic to MPLS (i.e. remove the demultiplexing 
> > > > > >function from PWE) and leave it to the service provider
> > > to decide
> > > > > >whether there is a need for additional aggregation via
> > > MPLS label
> > > > > >stacking.)
> > > > >
> > > > > If PW labels could be switched like MPLS labels, then 
> why can't 
> > > > > MPLS-ping be used to test it?
> > > > >
> > > >
> > > > Shahram,
> > > >
> > > > My statement should be read in the context of the question:
> > > is PW an
> > > > adaptation function or a network layer in itself. My point
> > > was: if you
> > > > use intermediate nodes to switch based on the PW Label, then it 
> > > > becomes a network layer in itself.
> > > >
> > > > Can one use Ping to test it? Yes, of course. Was there
> > > anything in my
> > > > mail that gave you the impression that I thought one couldn't?
> > > >
> > > > I still have a question about Ping, though. Is it the
> > > intention that
> > > > >Ping messages be sent periodically? The vccv draft doesn't 
> > > > >specify
> > > > this. >IMO, for fault management you need a periodic 
> connectivity 
> > > > check and you >need to define how you determine that there is a 
> > > > defect. Is it when you >miss one reply or only after
> > > missing multiple
> > > > replies? Frankly, you need >a state machine as defined 
> in Y.1711.
> > >
> > > A Ping mechanism is similar to a connectivity verification 
> > > mechanism. This is not suited for alarm 
> indication/suppression. It 
> > > is intended to be mostly proactive and can have a significant 
> > > processing impact on the node for monitoring a large number of 
> > > entities.
> > 
> >         Not necessarily. The triggering of CV (whether
> > VCCV, ICMP ping or LSP ping) can be automated on a device, and this 
> > can be done in such a way as to have minimal impact on the device's 
> > CPU. This same device can also be programmed to trigger or suppress 
> > alarms based on the status of such actions.
> 
> Sure. Nontheless, a ping mechanism is a query mechanism. You 
> need to turn it on continously on LSPs in order to catch a 
> fault. 

	That is only true if you are interested in catching
faults just as they happen.

> Fault detection should be automatic and OAM messages 
> are only generated at the detection of a fault for the 
> impacted LSPs only.

	And that is what you get using the existing tools
depending on how you use them.
 
> Though connectivity verification is important for detecting 
> discontinuity in the user plane which are not the result of a 
> physical layer fault or which are not detected through the 
> control plane.

	Connectivity verification is useful for several
things, including what you point out.

	--Tom

> >         But arguing about this in theory is a waste of
> > time. The proof is in the pudding, so check the 
> implementations that 
> > have implemented these tools and see how scalable they are.
> 
> Good for you :-)
> 
> >As usual, the market
> > will decide which solutions are most appropriate.
> 
> > > Let us consider again the scenario of ATM-MPLS-FR service 
> > > interworking, with local termination of ATM and FR at each PE. If 
> > > the ATM port in the ingress PE fails, you need to generate a 
> > > reactive alarm indication on all PWs which are sourced on 
> this port 
> > > to inform the remote PE of the defect. You need to be able to do 
> > > that without injecting connectivity verification traffic. A 
> > > lightweight mechanism such as I.610 AIS/RDI or Y.1711 FDI/BDI is 
> > > more suitable.
> > 
> >         Since Y.1711 only works for MPLS
> > as the PSN, this doesn't seem appropriate for PWE3 which
> > must have solutions that work for both L2TPv3 and MPLS.
> > BTW, VCCV works for both L2TPv3 and MPLS as of the next draft, and 
> > provides a consistent interface for operators regardless of the 
> > underlying PSN or VC type being tested.
> > 
> >         --Tom
> > 
> > > _______________________________________________
> > > pwe3 mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/pwe3
> > >
>

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Tue, 27 May 2003 08:42:35 -0400

> Behalf Of Mustapha Aissaoui
> fault. Fault detection should be automatic and OAM messages 

	Although I agree with you that a ping/CV mechanism
must be configured to function, so does any other fault
detection mechanism that would arrive at the same conclusion.

	--Tom