Re: [mpls] PSC: draft-dj-mpls-tp-exer-psc

[Yaacov Weingarten <[e-mail]>]

Hi,

I would like to point out two things about the definition given in G.870
for the EXER function, as given in the text quoted by Eric -

1. The definition clearly states that EXER is optional!
2. It seems clear (at least to me) that the real reason for the command was
to test the selectors that were present in the SDH hardware, (i.e. "switch
is not actually completed, i.e., the selector is released by an exercise
request") and therefore its relevance to packet switch networks seems
questionable.

just my 2c,
yaacov


On Thu, May 2, 2013 at 5:30 PM, Eric Osborne (eosborne)
<[e-mail]>wrote:

> Hi Yuji-
>
>   Yes, I agree we have different opinons.  I'd like to better understand
> your perspective on it.  Please see inline.
>
> > -----Original Message-----
> > From: Yuji Tochio [mailto:[e-mail]]
> > Sent: Wednesday, May 01, 2013 7:32 PM
> > To: Eric Osborne (eosborne)
> > Cc: [e-mail]
> > Subject: Re: [mpls] PSC: draft-dj-mpls-tp-exer-psc
> >
> > Hi Eric
> >
> > I think we (Eric and me) have different opnions for item #3 in LS
> (...1234)..
> >
> >
> > (2013/05/02 1:47), Eric Osborne (eosborne) wrote:
> > > Hi Yuji-
> > >
> > >   R84a says "84  It MUST be possible to test and validate any
> protection/
> > >        restoration mechanisms and protocols:
> > >
> > >        A.  Including the integrity of the protection/recovery transport
> > >            path."
> > >
> > >
> > > To me, the 'transport path' is the set of links and nodes between the
> > endpoints of a protection domain, and this function is best served by
> something
> > like CC/CV.  Clearly we disagree here.
> >
> > So far, both without disturbing the transport path that includes the
> bahaviour of
> > CC/CV and with validating the linear protection protocol, we have (need)
> EXR.
> > # See 3.2.26 of G.870, please
>
> I looked at G.870 3.2.26.  For those following along at home, the entire
> text is:
>
> ---
> 3.2.26 exercise signal #i (EX): Issues an exercise request for that signal
> (null signal, normal
> traffic signal, extra traffic signal) and checks responses on APS
> messages, unless the protection
> transport entity is in use. The switch is not actually completed, i.e.,
> the selector is released by an
> exercise request. The exercise functionality is optional.
> ---
>
> None of that says that it checks the integrity of the protection/recovery
> transport path, which is what R84a wants.
>
> As far as I can tell, EXER's job is to validate that the PSC state machine
> is still running, and that it is able to respond correctly to a command.
>  My understanding, gathered from conversations at the IETF and with others,
> is that EXER is run every so often (once a day?) as some sort of liveness
> mechanism.  Is that right?
>
> draft-dj-mpls-tp-exer-psc says
> "More specifically, the Exercise is to test and validate
>    the linear protection mechanism and PSC protocol including the
>    aliveness of the Local Request logic, the PSC state machine and the
>    PSC message generation and reception, and the integrity of the
>    protection path, without triggering the actual traffic switching"
>
> I buy all of that except for the 'integrity of the protection path' bit.
>  Are you saying that if we had EXER we wouldn't need CC/CV?
>
> I have not commented on the two bits below because I want to make sure I
> understand your interpretation of R84a before talking about whether EXER is
> the best and only way to address it.
>
>
>
>
> eric
>
>
> >
> > >
> > > Can you help me understand why EXER
> > >   a) meets the requirement in R84a
> > >  AND
> > >  b) is the best way to meet this requirement ?
> >
> > For b), Yes as in item#3 in the LS
> >
> > Regards, Yuji
> >
> >
> > >
> > >
> > >
> > >
> > > eric
> > >
> > >> -----Original Message-----
> > >> From: [e-mail] [mailto:[e-mail]] On Behalf
> > >> Of Yuji Tochio
> > >> Sent: Monday, April 29, 2013 7:52 PM
> > >> To: [e-mail]
> > >> Subject: Re: [mpls] PSC: draft-dj-mpls-tp-exer-psc
> > >>
> > >> Hi Eric O and all,
> > >>
> > >> As to the first bullet to the question below, my opinion is YES.
> > >> The reason is it is align with #84 (84A) in RFC 5654.
> > >>
> > >> Just my 2c,
> > >> Yuji
> > >>
> > >> (2013/04/17 21:21), Eric Osborne (eosborne) wrote:
> > >>> This thread is for discussing draft-dj-mpls-tp-exer-psc.  We started
> > >>> with -00,
> > >> but there is now a -01.
> > >>> The draft proposes adding the EXER/RR commands found in some ITU
> > >>> linear
> > >> protection protocols to PSC.
> > >>> I have also posted an alternative approach,
> draft-osborne-mpls-psc-alive-
> > 00.
> > >>> Briefly, EXER is a mechanism designed to check the responsiveness of
> > >>> the far-
> > >> end state machine.  My proposal, ALIVE, is for a similar mechanism.
> > >> It works differently and thus may be more or less acceptable.
> > >>> The big questions here are:
> > >>>
> > >>> - do we need any sort of EXER-type function at all?
> > >>> - if so, are either of the two proposals sufficient?  Is there a
> better way?
> > >>> - if not, is it possible to provide the same kind of testing and
> > >>> awareness
> > >> through existing mechanisms?  is this testing and awareness desirable
> > >> or necessary?
> > >>> but of course any and all discussion is welcome.
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>> eric
> > >>> _______________________________________________
> > >>> mpls mailing list
> > >>> [e-mail]
> > >>> https://www.ietf.org/mailman/listinfo/mpls
> > >>>
> > >>
> > >> _______________________________________________
> > >> mpls mailing list
> > >> [e-mail]
> > >> https://www.ietf.org/mailman/listinfo/mpls
> >
>
> _______________________________________________
> mpls mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls
>



-- 
Thanx and BR,
yaacov

*Still looking for new opportunity*