Re: [mpls] Proposed response to Liaison on Linear Protection Switching

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

Hi Yoshinori-

  The MIB certainly is a management document.  In my experience the MIB is about all the IETF tends to standardize for management documents of protocols.  However, given the unique shared nature of the MPLS-TP work, if the ITU feels it would like more equipment-specific recommendations it seems to be well within their purview to write them, and if others in the IETF feel additional management documents are necessary, there is no restriction on submitting a draft.  I'm not sure if this answers your question - does it help?

  Also, are you referring to a specific document or to a hypothetical future document?  I could not find draft-ietf-mpls-tp-psc-mib.  Perhaps you mean draft-smiler-mpls-tp-linear-protection-mib?




eric


> -----Original Message-----
> From: Yoshinori Koike [mailto:[e-mail]]
> Sent: Tuesday, August 07, 2012 12:18 AM
> To: Eric Osborne (eosborne)
> Cc: [e-mail]; [e-mail]
> Subject: Re: [mpls] Proposed response to Liaison on Linear Protection
> Switching
> 
> Hi Eric,
> 
> My apology for being late to reply to you. Thank you very much for the
> clarification and detailed explanations.
> 
> I'm sorry for my previous ambiguous question but I have one more
> question for clarification on A4). Is it correct that "one management
> document" is referring to an IETF document such as
> draft-ietf-mpls-tp-psc-mib-xx.txt which will be made in IETF in near
> future for RFC6378(PSC) based on RFC6639?
> 
> Thank you for your confirmation in advance.
> 
> Best regards,
> 
> Yoshinori
> 
> (2012/07/31 20:17), Eric Osborne (eosborne) wrote:
> > Hi Yoshinori-
> >
> >   Thank you for your questions, I believe you've identified some confusing
> language in our original proposed response.  I have included both your
> questions and our answers below.  Please let us know whether these answer
> your questions or whether you require further clarification, and we will
> update the LS response as necessary.
> >
> >
> >
> > eric
> >
> >> -----Original Message-----
> >> From: [e-mail] [mailto:[e-mail]] On Behalf
> Of
> >> Yoshinori Koike
> >> Sent: Friday, July 27, 2012 8:28 AM
> >> To: [e-mail]
> >> Subject: Re: [mpls] Proposed response to Liaison on Linear Protection
> >> Switching
> >>
> >> Hello Yacoov and Mr. Osborne,
> >>
> >> Thank you very much for preparing the draft liaison to ITU-T.
> >>
> >> I'm sorry for these late questions, but I have a few questions for
> >> clarification on the draft liaison.
> >>
> >> Q1) According to the item 1, it is written that the priority order "FS
> >> over SF-P" was defined also for consistency with the IETF Recovery
> >> terminology in RFC 4427. Could you be more specific about which part of
> >> the document can be referred, please?
> >>
> >> I have checked RFC4427 and I thought it might refer to the following
> >> part, but if "command" means internal command(not external command),
> it
> >> may imply that SF-P(internal command) could be prioritized.
> >>
> >> --------------
> >> D. Forced switch-over for normal traffic:
> >>
> >> A switch-over action, initiated externally, that switches normal
> >> traffic to the recovery LSP/span, unless an equal or higher priority
> >> switch-over command is in effect.
> >> ---------------
> >>
> >
> > A1) Please refer to RFC4427, section 4.13 parts D/E.  In particular:
> >
> > - part D defines "Forced switch-over for normal traffic", which is executed "
> unless an equal or higher priority switch-over command is in effect"
> > - part E defines " Manual switch-over for normal traffic", which is executed
> " unless a fault condition exists  ... or an equal or higher priority switch-over
> command is in effect."
> >
> > Thus, RFC4427 differentiates between switch-over commands, i.e. lockout
> of  protection, forced switch, manual switch, etc, and fault conditions, i.e. SF-
> W, SF-P, etc.  Since an FS is executed unless there is a precluding switch-over
> command, and since MS is executed unless there is a precluding switch-over
> command or a fault condition, the FS must be executed even in the face of a
> fault condition.  This requires that FS take precedence over SF-P.
> >
> >> Q2) Regarding item 1, there is a description that 'we note that in PSC
> >> the FS can be reverted provided one of the paths is active'. Could you
> >> explain more details about the meaning of this sentence, please? Does
> >> this mean that, for example, SF-P(with a working path is active)
> >> overrides FS depending on an implementation, which isn't compliant with
> >> the priority order of PSC?
> >>
> >
> > A2) We agree that the wording is perhaps unclear.  It may make sense to
> simply remove that sentence, or we could rephrase it.
> >
> > The logic behind FS and SF-P priorities doesn't change.  When an FS is
> removed, a node processes its remaining inputs and acts accordingly.
> >
> > First consider the case where FS is active but no other inputs are present.
> When FS is active, traffic is switched from W to P.  When FS is removed,
> traffic reverts to W.
> >
> > Now consider the case where both FS and SF-P are active.  There are two
> ways this can happen: the operator configures FS and then sees SF-P from
> the network, or the operator sees SF-P from the network and then
> configures FS.  The outcome is the same in either case but the latter case
> seems far less likely, so let's examine the first case.  When the operator
> configures FS, traffic is bridged into P.  When P fails, the traffic is simply
> dropped, as it cannot be transmitted.  This obeys the logic of prioritizing FS
> over SF-P.  Should the operator wish to avoid this case, they should configure
> MS rather than FS.
> >
> > Given that explanation, do you have any suggestions about how to handle
> the text?  Should we remove the sentence, or rewrite it?
> >
> >> Q3) Regarding the description in item 2, 'This feature may be used for
> >> future optimizations by different implementations.', could you be more
> >> specific about this sentence, please? I would like to know what kind of
> >> optimization will be achieved and how differently PSC will be
> implemented.
> >>
> >
> > A3) We believe that changing the text to state - "this behavior may be used
> by the operators to optimize their network operations, based on more
> complete status information..." would more clearly state the intention.
> >
> > We had no intention of implying that there would be different
> implementations of PSC, but rather that the more complete network status
> information provided by PSC, would allow the systems to react in a more
> efficient manner to protection switching situations.'
> >
> >> Q4) Regarding the description 'because it was felt that this be best
> >> specified in a management document' in item 6, does the "a management
> >> document" include both characteristics of equipment functional blocks
> >> and equipment management aspect?
> >>
> >
> > A4) The IETF tends to standardize management behaviors which are
> required for interoperability between devices.  This differs from the ITU,
> which publishes "equipment recommendations" that provide equipment
> functional blocks and management commands and messages that are
> generated.  If the ITU feels that these definitions are necessary for their
> equipment definitions then it is their prerogative to document them there.  I
> believe that this is in keeping with the spirit of the work-split between the
> IETF and the ITU on MPLS-TP.
> >
> >> Just a very minor comment is, regarding Annex B of RFC6378, it is
> >> written on page 43 actually, although the table of contents point to
> >> page 44.
> >>
> >
> > Thank you for this.  We will remove explicit page number references and
> simply refer to sections, including this reference to Appendix (not Annex) B.
> >
> 
> 
> --
> Yoshinori Koike
> [e-mail]