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

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 1 Mar 2011 13:36:39 +0200

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.
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.

This is definitely not healthy, and the draft does not define any ways to avoid that.

The text in the draft that deals with protection seems to refer to link protection rather than to LSP protection.

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.

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