Re: [mpls-tp] [mpls] [PWE3] [AHMPLS-TP] Re: pollondraft-he-mpls-tp-csf-03.txt

[Maarten Vissers <[e-mail]>]

Eric,

CSF is used 
- in cases where the client does not have an AIS defined and it is necessary
to forward a client SF condition to the far end [when there is no control
plane] (rationale for GFP-CSF, ETH-CSF)
- in cases where the operator has two admin domains with NMSs that do not
exchange ingress failure information (rationale for OPUk-CSF); when customer
calls MNS B helpdesk, this helpdesk will be able to inform the customer that
the UNI at the other end has failed.

Regards,
Maarten

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of Eric Osborne (eosborne)
> Sent: 2 December 2010 12:18
> To: Yuanlong Jiang; John E Drake; Sprecher, Nurit (NSN - IL/Hod
> HaSharon); Loa Andersson; [e-mail]; [e-mail];
> [e-mail]; MPLS-TP ad hoc team
> Subject: Re: [mpls-tp] [mpls] [PWE3] [AHMPLS-TP] Re: pollondraft-he-
> mpls-tp-csf-03.txt
> 
> Inline with EO#
> 
> ...
> 
> > >
> > > John,
> > >
> > > Typically, IP will only detect a failure in a time scale of
> minutes.
> >
> > I must not understand the point you're making.  For one thing, BFD is
> > quite often configured to detect failures in significantly less than
> a
> > minute.
> > [JYL] The question is: Can we assume BFD is universally deployed for
> IP
> > and PW?
> > If the answer is yes, then CSF is not needed, even for the PW
> application.
> 
> 
> EO#  There are three things that end users are going to carry over TP:
> IP, MPLS and L2VPN.  L2VPN, as I understand it, has its own mechanism.
> BFD implementations are stable and widely available for IP and MPLS and
> interoperate across multiple vendors.  I would not say that BFD is
> universally deployed, but that it is easily and universally deployable
> for those who want it.
> 
> It does seem that we agree that CSF and BFD solve the same problem -
> right?
> 
> >
> > > That is one reason why MPLS-TP OAM and Protection & Switching is
> > needed.
> >
> > What are others?
> > [JYL] Maybe you'd better refer to RFC 5654 for a comprehensive reqs
> :)
> 
> EO#  My mistake, I read your email as "That is one reason why CSF is
> needed"...that'll teach me to read too quickly. :)
> I agree that OAM and Survivability (encompassing both protection and
> restoration) are needed.  It is not obvious to me why this need for
> OAM+S translates into an obvious and undeniable need for CSF.
> 
> Please note that I am neither for nor against CSF at this point - I'm
> trying to understand what problem it solves that cannot already be
> solved by tools which already exist.  So far it seems like we agree
> that
> BFD is an appropriate tool for IP and MPLS networks - correct?
> 
> >
> > > I am not sure which mechanism in MPLS provides the CSF-like
> > capability,
> > > could you give more hints?
> >
> > Even regular IGP/LDP hellos (no special tuning, no BFD) very
> frequently
> > are configured to detect failures in far less than "minutes".
> > [JYL] Not sure this can be used to indicate the failure of  IP
> service.
> > Even so, do we need to firstly determine what protocol is carried and
> then
> > decide which mechanism could be used?
> 
> 
> EO#  Not to get all layer-model-crazy, but if the client wants to
> detect
> a failure the provider doesn't need to determine anything about the
> carried protocol in order to allow them to do so.  In my experience no
> matter what the provider tries to do for the client, the client will
> always want to run their own liveness protocol over the provider's
> network anyways.
> 
> Trust, but verify.  Or perhaps "trust, but not very much".
> 
> 
> 
> 
> 
> eric
> 
> 
> >
> >
> > eric
> >
> > >
> > > Thanks
> > > Yuanlong
> > >
> > > ----- Original Message -----
> > > From: "John E Drake" <[e-mail]>
> > > To: "Sprecher, Nurit (NSN - IL/Hod HaSharon)"
> > <[e-mail]>om>;
> > > "Yuanlong Jiang" <[e-mail]>om>; "Loa Andersson" <[e-mail]>nu>;
> > > <[e-mail]>rg>; <[e-mail]>rg>; <[e-mail]>rg>; "MPLS-TP ad
> hoc
> > > team"
> > > <[e-mail]>
> > > Sent: Wednesday, December 01, 2010 9:29 PM
> > > Subject: RE: [PWE3] [AHMPLS-TP] Re: [mpls-tp] poll
> > ondraft-he-mpls-tp-csf-
> > > 03.txt
> > >
> > >
> > > > Nurit,
> > > >
> > > > As I understand the original requirement from Malcolm Betts, this
> > > > capability is required for those cases in which a client is
> unable
> > to
> > > > detect the failure of its peer.  In MPLS-TP, we have three
> clients,
> > > > PW, IP, and MPLS, and I am quite sure that IP and MPLS clients
> can
> > > > take care of themselves wrt detecting peer failure.
> > > >
> > > > Thanks,
> > > >
> > > > John
> > > >
> > > > Sent from my iPhone
> > > >
> > > >> -----Original Message-----
> > > >> From: Sprecher, Nurit (NSN - IL/Hod HaSharon)
> > > >> [mailto:[e-mail]]
> > > >> Sent: Wednesday, December 01, 2010 4:47 AM
> > > >> To: John E Drake; Yuanlong Jiang; Loa Andersson; [e-mail];
> > mpls-
> > > >> [e-mail]; [e-mail]; MPLS-TP ad hoc team
> > > >> Subject: RE: [PWE3] [AHMPLS-TP] Re: [mpls-tp] poll
> > > >> ondraft-he-mpls-tp- csf-03.txt
> > > >>
> > > >> But what about other client services... e.g. adapted by
> service-LSP
> > > >> and not by PWE3?
> > > >>
> > > >> -----Original Message-----
> > > >> From: [e-mail] [mailto:[e-mail]] On
> > Behalf
> > > >> Of ext John E Drake
> > > >> Sent: Wednesday, December 01, 2010 2:35 PM
> > > >> To: Yuanlong Jiang; Loa Andersson; [e-mail];
> [e-mail];
> > > >> [e-mail]; MPLS-TP ad hoc team
> > > >> Subject: Re: [PWE3] [AHMPLS-TP] Re: [mpls-tp] poll
> > > >> ondraft-he-mpls-tp-csf-03.txt
> > > >>
> > > >> I am not convinced.  It seems like it belongs in the Pseudo Wire
> > > >> application, which already has this capability.
> > > >>
> > > >> Sent from my iPhone
> > > >>
> > > >>
> > > >> > -----Original Message-----
> > > >> > From: Yuanlong Jiang [mailto:[e-mail]]
> > > >> > Sent: Wednesday, December 01, 2010 1:07 AM
> > > >> > To: Loa Andersson; [e-mail]; [e-mail];
> > [e-mail];
> > > >> > MPLS-TP ad hoc team
> > > >> > Subject: [AHMPLS-TP] Re: [mpls-tp] poll on
> draft-he-mpls-tp-csf-
> > > >> 03.txt
> > > >> >
> > > >> > Support.
> > > >> >
> > > >> > I believe this mechanism is needed in MPLS-TP.
> > > >> >
> > > >> > Thanks
> > > >> > Yuanlong
> > > >> >
> > > >> > ----- Original Message -----
> > > >> > From: "Loa Andersson" <[e-mail]>
> > > >> > To: <[e-mail]>rg>; <[e-mail]>rg>; <[e-mail]>rg>;
> > "MPLS-TP
> > > >> > ad hoc team" <[e-mail]>
> > > >> > Sent: Thursday, November 18, 2010 7:56 PM
> > > >> > Subject: [mpls-tp] poll on draft-he-mpls-tp-csf-03.txt
> > > >> >
> > > >> >
> > > >> > > all,
> > > >> > >
> > > >> > > this is to start a two week poll on making
> > > >> > >
> > > >> > >
> http://www.ietf.org/internet-drafts/draft-he-mpls-tp-csf-03.txt
> > > >> > >
> > > >> > > a mpls working group document.
> > > >> > >
> > > >> > > Please send comments support/not support to the mpls-tp
> > maililng
> > > >> > list.
> > > >> > >
> > > >> > > The poll ends Thursday Dec 2, 2010.
> > > >> > >
> > > >> > > /Loa
> > > >> > > --
> > > >> > >
> > > >> > >
> > > >> > > Loa Andersson                         email:
> > > >> > [e-mail]
> > > >> > > Sr Strategy and Standards Manager            [e-mail]
> > > >> > > Ericsson Inc                          phone: [phone]
> 13
> > > >> > >                                              [phone]
> 13
> > > >> > > _______________________________________________
> > > >> > > mpls-tp mailing list
> > > >> > > [e-mail]
> > > >> > > https://www.ietf.org/mailman/listinfo/mpls-tp
> > > >>
> > > >> _______________________________________________
> > > >> pwe3 mailing list
> > > >> [e-mail]
> > > >> https://www.ietf.org/mailman/listinfo/pwe3
> > > >
> > >
> > > _______________________________________________
> > > mpls mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/mpls
> 
> _______________________________________________
> mpls-tp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls-tp