Subject: Re: [mpls] [mpls-tp] wg last call on draft-ietf-mpls-tp-fault-03

From: George Swallow <[email-masked]>
Date: Fri, 08 Jul 2011 15:47:37 -0400

Sasha -

On 3/1/11 7:36 AM, "Alexander Vainshtein" <[email-masked]>
wrote:

> Loa, and all,
> I have two LC comments on the draft. in question. They both refer to issues
> I've raised in private discussions with George and Matthew and which, to the
> best of my understanding, have not been resolved in the -03 version.
> 
> My first issue deals with potential dangers of sending fault OAM messages in
> conjunction with certain protection mechanisms.
> 
> The example I've presented to George and Matthew  deals with the situation
> when the LSP in question employs Facility FRR for node protection.
> 
> The topology is shown below:
> 
> 
> |------|     |-----|     |-----|     |-----|     |-----|
> |  A   |<--->|  B  |<--->|  C  |<--->|  D  |<--->|  E  |
> |------|     |-----|     |-----|     |-----|     |-----|
>                 \                      /
>                  \                    /
>                   \                  /
>                    \                /
>                     \              /
>                      \            /
>                       \ |------| /
>                        \|   C' |/
>                         |------|
> 
> The LSP runs A-->B-->C-->D-->E with LSP-level MEPs at A and D  and MIPs in the
> rest of the nodes.
> If the link BC is broken, the link-level MEP at C detects that and initiates
> (I'll skip the details) insertion of AIS (with LDI flag set after some
> stabilization) into the LSP. These AIS/LDI packets will be captured by the LSP
> MEP in D.
> 
I believe you mean E here.
> 
> Meanwhile, B could operate a node protection bypass (B-->C'-->D) for this LSP,
> starting at B and terminated at D, D would be the merge point. Note that C
> would not be aware of this action, and D would not aware of AIS insertion
> undertaken by C.
> As a consequence, E would receive both AIS/LDI generated by C and valid
> traffic coming thru bypass.
> 
The current draft is limited to the operation of PWs, bi-directional LSPs
and sections and LSP 1:1 and 1+1 protection as that is the current scope of
MPLS-TP.  The draft  states that action based on the receipt of an LDI flag
is optional.  In this situation you would clearly want to ignore the flag.
The only other affect is to suppress alarms.  But as there is no alarm to
suppress, that will have no effect.
> 
> This is definitely not healthy, and the draft does not define any ways to
> avoid that.
> 
If you would like to begin a draft on applying AIS to other types of LSPs,
that would be much appreciated.
> 
> The text in the draft that deals with protection seems to refer to link
> protection rather than to LSP protection.
> 
 I agree that that is not clear.  I¹ve updated section 2 para 3 with, ³When
a server layer, (e.g. a link or bidirectional LSP) used by the bidir-LSP
fails,....²
> 
> IMHO the same problem would appear in the case of segment protection if a link
> in the middle of a segment is broken, so this issue is not limited just to
> FRR.
> 
> My second issue deals with association between links and LSPs that pass thru
> these links. Ability to insert Fault OAM messages into all the LSPs crossing a
> certain link may be compromised IMHO in the case LSPs that use labels from the
> per-platform space. It is not clear from the draft how the LSR that has
> detected a link failure could decide whether Fault OAM messages should be
> inserted in a transit LSP (which it perceives as an ILM table entry) or not -
> because the actual LSP could be running thru a different link. The problem
> would presumably disappear if per-interface label space were used; but RFC
> 5960 does not restrict MPLS-TP from using per-platform label space.
> 
The issue is not per platform labels per se, but to the binding of PWs and
LSPs to specific links (which includes hierarchical LSPs).  I¹ve updated
section 2 para 3 with ³Fault OAM messages are generated by intermediate
nodes where a bidir-LSP is switched and bound to specific server layers
based upon static configuration or signaling.

...George 
> 
> I apologize for sending these comments so late in the LC.
> 
> Regards,
>      Sasha
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Loa Andersson
> Sent: Thursday, February 03, 2011 1:37 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: [mpls-tp] wg last call on draft-ietf-mpls-tp-fault-03
> 
> Working Group,
> 
> this is to start a four week working group last call
> on "MPLS Fault Management OAM" (draft-ietf-mpls-tp-fault-03).
> 
> Please send comments to the [email-masked] mailing list.
> 
> This working group last call ends on February 28, 2011.
> 
> 
> 
> Loa, George and Ross
> 
> MPLS wg co-chairs
> 
> --
> 
> Loa Andersson                         email: [email-masked]
> Sr Strategy and Standards Manager            [email-masked]
> Ericsson Inc                          phone: +46 10 717 52 13
>                                               +46 767 72 92 13
> 
> 
> 
> _______________________________________________
> mpls-tp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls-tp
>

---

From: Alexander Vainshtein <[email-masked]>
Date: Mon, 18 Jul 2011 18:15:14 +0300

George,
Lots of thanks for your response, and apologies for a delayed reaction.

I would like to present to you and the WG my reading of your responses, and my conclusions.

Regarding my comment about effect of FRR (or segment protection) on AIS/LDI, your response includes two statements:

1.       The draft only applies to "the operation of PWs, bi-directional LSPs and sections and LSP 1:1 and 1+1 protection as that is the current scope of MPLS-TP"

a.       This seems to imply that FRR and segment protection are out of scope.

b.      To the best of my understanding, the draft does not explicitly state that LSPs protected by FRR are out of scope.

c.       It only says "Fault OAM messages are applicable to Bidirectional Co-Routed LSPs and to Multi-Segment Pseudowires"

d.      One could possibly imply that any actions (like FRR in link-and-node protection mode) that break co-routed nature of a bidirectional LSP are beyond the scope of the draft (not sure about the scope MPLS-TP). However:

                                                               i.      It is not clear (at least, to me) why bi-directionality is so important for the draft which only defines downstream messages

                                                             ii.      IMHO an explicit statement of this kind (preferably in the Applicability Statement section) would make the life of a potential reader much easier.

2.       The draft states that "action based on the receipt of an LDI flag is optional":

a.       I've scanned the draft for the word "OPTIONAL", (case-insensitive) and did not find this statement. Did I miss something?

b.      The text that I've found in Section 2.3 of the draft  and that looks relevant states: "If the CC function is disabled, a MEP SHOULD generate AIS messages toward any client when either the AIS or LCK indication is  raised."  IMHO this is not OPTIONAL, it is RECOMMENDED

c.       The quoted text in the draft contains a couple of types (I've removed them).

Regarding my comment about association between links and LSPs that pass thru these links - I think that the text to which you refer clarifies this issue.

Regards,
     Sasha

From: George Swallow [mailto:[email-masked]]
Sent: Friday, July 08, 2011 10:48 PM
To: Alexander Vainshtein; Loa Andersson
Cc: [email-masked]; [email-masked]; BOCCI Matthew
Subject: Re: [mpls-tp] wg last call on draft-ietf-mpls-tp-fault-03

Sasha -

On 3/1/11 7:36 AM, "Alexander Vainshtein" <[email-masked]> wrote:
Loa, and all,
I have two LC comments on the draft. in question. They both refer to issues I've raised in private discussions with George and Matthew and which, to the best of my understanding, have not been resolved in the -03 version.

My first issue deals with potential dangers of sending fault OAM messages in conjunction with certain protection mechanisms.

The example I've presented to George and Matthew  deals with the situation when the LSP in question employs Facility FRR for node protection.

The LSP runs A-->B-->C-->D-->E with LSP-level MEPs at A and D  and MIPs in the rest of the nodes.
If the link BC is broken, the link-level MEP at C detects that and initiates (I'll skip the details) insertion of AIS (with LDI flag set after some stabilization) into the LSP. These AIS/LDI packets will be captured by the LSP MEP in D.
I believe you mean E here.

Meanwhile, B could operate a node protection bypass (B-->C'-->D) for this LSP, starting at B and terminated at D, D would be the merge point. Note that C would not be aware of this action, and D would not aware of AIS insertion undertaken by C.
As a consequence, E would receive both AIS/LDI generated by C and valid traffic coming thru bypass.
The current draft is limited to the operation of PWs, bi-directional LSPs and sections and LSP 1:1 and 1+1 protection as that is the current scope of MPLS-TP.  The draft  states that action based on the receipt of an LDI flag is optional.  In this situation you would clearly want to ignore the flag.  The only other affect is to suppress alarms.  But as there is no alarm to suppress, that will have no effect.

This is definitely not healthy, and the draft does not define any ways to avoid that.
If you would like to begin a draft on applying AIS to other types of LSPs, that would be much appreciated.

The text in the draft that deals with protection seems to refer to link protection rather than to LSP protection.
I agree that that is not clear.  I've updated section 2 para 3 with, "When a server layer, (e.g. a link or bidirectional LSP) used by the bidir-LSP fails,...."

IMHO the same problem would appear in the case of segment protection if a link in the middle of a segment is broken, so this issue is not limited just to FRR.

My second issue deals with association between links and LSPs that pass thru these links. Ability to insert Fault OAM messages into all the LSPs crossing a certain link may be compromised IMHO in the case LSPs that use labels from the per-platform space. It is not clear from the draft how the LSR that has detected a link failure could decide whether Fault OAM messages should be inserted in a transit LSP (which it perceives as an ILM table entry) or not - because the actual LSP could be running thru a different link. The problem would presumably disappear if per-interface label space were used; but RFC 5960 does not restrict MPLS-TP from using per-platform label space.
The issue is not per platform labels per se, but to the binding of PWs and LSPs to specific links (which includes hierarchical LSPs).  I've updated section 2 para 3 with "Fault OAM messages are generated by intermediate nodes where a bidir-LSP is switched and bound to specific server layers based upon static configuration or signaling.

...George

Regards,
     Sasha

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Loa Andersson
Sent: Thursday, February 03, 2011 1:37 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: [mpls-tp] wg last call on draft-ietf-mpls-tp-fault-03

Working Group,

Loa, George and Ross

MPLS wg co-chairs

--

This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof.