[mpls-tp] Comments to MPLS-TP Surv Fwk (was Re: Demultiplexing to BFD sessions)

[Greg Mirsky <[e-mail]>]

Dear Adrian,
thank you for reminding of importance of using consistent terminology. Can
not agree more.
I've put my notes below, some of them will likely repeat comments by others:

   - Section 1.1 phrase"...; unidirectional implies that protection
   switching is performed independently for each direction of a bidirectional
   transport path" overemphasizes bidirectional paths. Perhaps the mentioning
   of obvious applicability to unidirectional paths can be added like "...
   Unidirectional applies to p2p and p2mp unidirectional transport paths and
   can be applied to bidirectional p2p paths as well. In case of bidirectional
   transport path unidirectional protection switching or unidirectional
   restoration imply that each appropriate action being performed independently
   for each direction of the affected path".
   - You will note that I've added reference to restoration as I see it
   lacking in this context even though it is mentioned two paragraphs further.
   I think that similar reference to restoration might be added to explanation
   of bidirectional nature.
   - "Co-routed bidirectional MPLS-TP LSPs are defined in a way that allows
   both directions ... I think that "requires" instead of "allows" would be
   more precise
   - Section 1.4 in the last paragraph on p.7 introduces "level of
   protection" that is discussed later in Section 4.3. Perhaps cross-reference
   to Section 4.3 will be useful.
   - Definition of Restoration in Section 2 listed twice
   - Section 2 in the bullet that defines "Survivability Actions". I wonder
   if actions of an operator might be considered here as well, particularly to
   facilitate switching traffic off the affected path(s) as indicated in
   section 4.1.1
   - Section 4.2.1, third bullet about parallel links. I think that it
   confuses things by introducing protected at lower layer link. I think that
   it might be changed to:


   - A set of parallel data links in the same layer, presented either as a
      bundle of TE links.

TE link can be unprotected or protected by its server layer or lower layer
of MPLS-TP network.

   - In Section 4.2.2 when describing operation of a Segment Recovery
   (second paragraph on p.13) I think that references to "other end of the
   segment" or "far end of the protected segment" are too limiting. As in FRR
   node protection, the MP of Segment protection might not be the end of
   protected segment. I think that indicates that bidirectional (coordinated)
   or unidirectional (independent) segment recovery can be set differently, at
   least in regard to where protection segment is terminated, merges with
   protected.
   - In the last paragraph of Section 4.3.4 it might be noted that
   activation of pre-planned restoration path might fail and that will require
   re-signaling of the restoration path to recover affected services.
   - In Section 4.4 in regard to scope of the document only LSP segment and
   LSPs (as a whole) listed. I think that links should be added to that list.
   - In Section 4.4.1 I found reference to protection of "edge node"
   "End-to-end or segment protection should be used in conjunction with
   link-level protection to protect against a failure of the edge nodes." What
   is understood as "edge node"? Is it end-points of a link? But even in
   combination with segment or end-to-end protection path termination points
   are not protected in the protection domain on that particular layer. Perhaps
   reference to Section 4.5 would be useful.
    - The last sentence refers to in-band communication channels that might
   be used not only to monitor health of the protected link but to coordinate,
   if necessary, protection states. I think this need clarification since
   monitoring channel and PSC channel for a protected link should over
   different links different. Monitoring - over protected link, PSC - over
   protecting.
   - I feel that three paragraphs (p.24) at the very end of Section 4.7 are
   either out of place or need some re-wording. Issues of bidirectional and
   unidirectional protection, revertive vs. non-revertive addressed earlier.
   -  Second paragraph on p.25 of Section 4.7.1 seems out of place. Perhaps
   it might be moved further down after description of PSC actions.
   - In the third paragraph on the same page protection is described with
   references to "source", "sink", "bridge" and "selector". It might be
   consistent to use this object in the following paragraphs as well when
   describing protection switchover. the the first sentence of the next
   paragraph might be as following:

"In bidirectional protection switching, both bridge at source and selector
at sink in each end-point of the protection domain are switched to the
protection entity (even when the fault is unidirectional)."

   - A reference to SONET/SDH 10 ms fault detection might be added in first
   bullet of Section 4.7.4 (p. 27) to explain why 3.3 ms interval for proactive
   CCV is common.
   - Section 4.7.5 Are Editors planning to switch from Path Segment Tunnel
   (PST) to our new terminology?
   - In Section 4.9 pointer to coordination between protection mechanisms of
   either multi-layer network or nested protection domains. At the same time we
   use coordination in reference to protection switching. In the latter case,
   as I understand, the coordination implies signaling between end-points of
   protection domain. I don't think that in the former case, in reference to
   protection mechanisms use of signaling implied. If my understanding is
   correct perhaps "coordinated" might be changed to "planned" or similar.
   - In third paragraph of Section 4.9.1 stated that inherited link
   protection saves network resources. I don't agree with this conclusion as it
   was shown that protection on the server layer at best is not better then
   protection on client layer in regard to network resource utilization (server
   resource used for protection is not available to client layer in most
   scenarios).
   - Section 6.4.1 in its second bullet refers to MPLS-TP Performance
   Monitoring (or should it be Performance Management?) as only proactive
   action. I think that PM is likely to be used as on-demand tool and document
   might mention that PM could be both proactive and on-demand activated.
   - Last paragraph of Section 6.5 (p.45) - typo s/t1he/the

Kind regards,
Greg

On Sat, Jun 12, 2010 at 12:31 AM, Adrian Farrel <[e-mail]> wrote:

> Greg'n'Shahram,
>
> Please do check the terminology with the Survivability Framework.
> It is (just) not too late to tweak if we have got something wrong or left
> something out.
>
> cheers,
> Adrian
> ----- Original Message ----- From: "Greg Mirsky" <[e-mail]>
> To: "Shahram Davari" <[e-mail]>
> Cc: "Mukund Mani" <[e-mail]>om>; <[e-mail]>
> Sent: Friday, June 11, 2010 8:02 PM
>
> Subject: Re: [mpls-tp] Demultiplexing to BFD sessions
>
>
>  Hi Shahram,
>> yes, we need to settle on terminology related to protection.
>> It was discussed and presented at the last IETF meeting how bi-directional
>> BFD session easily can operate in, effectively, unidirectional mode. I
>> think
>> that operating BFD session in this mode is applicable to unidirectional
>> and
>> associated bi-directional p2p LSPs.
>>
>> Regards,
>> Greg
>>
>> On Fri, Jun 11, 2010 at 11:54 AM, Shahram Davari <[e-mail]
>> >wrote:
>>
>>   Hi Greg,
>>>
>>>
>>>
>>> I assume by independent protection mode you mean unidirectional
>>> protection.
>>> If unidirectional protection is required, then it is simpler to not use
>>>  bidirectional BFD session.
>>>
>>>
>>>
>>> Regards,
>>>
>>> Shahram
>>>
>>>
>>>
>>> *From:* Greg Mirsky [mailto:[e-mail]]
>>> *Sent:* Friday, June 11, 2010 11:18 AM
>>> *To:* Shahram Davari
>>> *Cc:* Mach Chen; Mukund Mani; [e-mail]
>>>
>>> *Subject:* Re: [mpls-tp] Demultiplexing to BFD sessions
>>>
>>>
>>>
>>> Dear Shahram,
>>> assume one BFD session is applied to an associated bi-directional LSP.
>>> Then
>>> failure in one direction will bring the session in Down state which is
>>> not
>>> desired behavior for independent protection mode. Thus, I think, need for
>>> two BFD, in essence unidirectional, sessions.
>>>
>>> Regards,
>>> Greg
>>>
>>> On Fri, Jun 11, 2010 at 11:03 AM, Shahram Davari <[e-mail]>
>>> wrote:
>>>
>>> Hi,
>>>
>>> Why would one need to run more than one BFD session over an LSP?
>>>
>>> Thanks,
>>> Shahram
>>>
>>>
>>> -----Original Message-----
>>> From: [e-mail] [mailto:[e-mail]] On
>>> Behalf
>>> Of Mach Chen
>>> Sent: Friday, June 11, 2010 3:05 AM
>>> To: Mukund Mani; [e-mail]
>>> Subject: Re: [mpls-tp] Demultiplexing to BFD sessions
>>>
>>> Hi Mukund,
>>>
>>> I also have the same question about this.
>>>
>>> As to the BFD discriminator, IMHO, we should keep using it as it be,
>>> because
>>> it may not be enough to demultiplex the BFD session only based on the
>>> label,
>>> this is especially true when there are more than two BFD sessions over
>>> the
>>> LSP.
>>>
>>> BTW, it seems that explicit null label distribution is not excluded (and
>>> IMHO it should be excluded as PHP) in MPLS-TP (do I miss something?) ,
>>> and
>>> it is one of the issues that LSP-Ping for BFD session bootstrap is trying
>>> to
>>> reslove.
>>>
>>> Best regards,
>>> Mach
>>>
>>> --------------------------------------------------
>>> From: "Mukund Mani" <[e-mail]>
>>> Sent: Friday, June 11, 2010 2:24 PM
>>> To: <[e-mail]>
>>> Subject: [mpls-tp] Demultiplexing to BFD sessions
>>>
>>> > Hi TP-Group
>>> > **
>>> > *draft-ietf-mpls-tp-lsp-ping-bfd-procedures-00 *states in Section 3
>>> >
>>> > "When using BFD over MPLS-TP LSPs, the BFD discriminator MUST either be
>>> > signaled via LSP-Ping or be statically configured."
>>> >
>>> > *draft-ietf-mpls-tp-bfd-cc-cv-00 *states in Section 3.5.6
>>> >
>>> > "MPLS labels at peer MEPs are used to provide context for the received
>>> BFD
>>> > packets."
>>> >
>>> > As I understand from the statement in the CC/CV draft, since
>>> discriminator
>>> > values are not required for demultiplexing to the BFD session anymore,
>>> > we
>>> > will not need LSP Ping to bootstrap BFD session for TP LSP.
>>> >
>>> > But *draft-ietf-mpls-tp-lsp-ping-bfd-procedures-00 *specifies that LSP
>>> > Ping
>>> > can also be used to signal BFD discriminator.
>>> >
>>> > So is LSP Ping still really needed in the context of BFD over MPLS-TP?
>>> >
>>> > Also as a part of MPLS-TP OAM could somebody explain why such a >
>>> deviation
>>> > is
>>> > taken from the BFD-BASE mode of demultiplexing which even BFD-MPLS uses
>>> > (discriminator values instead of MPLS labels), but MPLS-TP goes in for
>>> > demultiplexing using labels....
>>> >
>>> > Could somebody please clarify this..?
>>> >
>>> >
>>> > With Regards
>>> > Mukund
>>> > <http://tools.ietf.org/html/draft-ietf-mpls-tp-bfd-cc-cv-00>
>>> >
>>>
>>>
>>>
>>> > _______________________________________________
>>> > mpls-tp mailing list
>>> > [e-mail]
>>> > https://www.ietf.org/mailman/listinfo/mpls-tp
>>> >
>>> _______________________________________________
>>> mpls-tp mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/mpls-tp
>>>
>>>
>>> _______________________________________________
>>> mpls-tp mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/mpls-tp
>>>
>>>
>>>
>>>
>>
>
>
> --------------------------------------------------------------------------------
>
>
>
>  _______________________________________________
>> mpls-tp mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mpls-tp
>>
>>
>