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

["Eric Osborne (eosborne)" <[e-mail]>]

Hi Maarten-

  Inline....

> -----Original Message-----
> From: Maarten Vissers [mailto:[e-mail]]
> Sent: Thursday, December 02, 2010 10:02 AM
> To: Eric Osborne (eosborne); [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
> 
> 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)

What client layers of MPLS-TP do not have some form of fast failure
detection defined?

It also seems likely that if we come up with some new, ubiquitous client
layer that it will have its own particular set of requirements for
failure detection that may not be met by a generic mechanism such as the
proposed 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.

Are there really network operators out there who would not find out that
a circuit has silently failed until they make a phone call?  Is this
where the "IP converges in O(minutes)" thing comes from?  




eric


> 
> 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]
52
> > 13
> > > > >> > >                                              +46 767 72
92
> > 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