Subject: [mpls] Fault OAM configuration

From: George Swallow <[email-masked]>
Date: Wed, 17 Aug 2011 14:59:51 -0400

The current drafts on Fault OAM configurations,

draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-02 and
draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-06

allow for an extreme amount of control which I believe will not be
implemented in many cases and where implemented will not be used.

I think a much simple configuration model would be quite sufficient.

The current drafts allow:

MPLS OAM FMS sub-TLV

   The "MPLS OAM FMS sub-TLV" depicted below is carried as a sub-TLV of
   the "OAM Configuration sub-TLV".

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |           Type (5)  (IANA)    |        Length = 12            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |A|D|L|C|             Reserved   (set all to 0s)        |E| PHB |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      Refresh Timer                            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type: indicates a new type, the "MPLS OAM FMS sub-TLV" (IANA to
   define).

   Length: indicates the TLV total length in octets.

   Signal Flags: are used to enable the following signals:

      - A: Alarm Indication Signal (AIS) as described in [MPLS-FMS]

      - D: Link Down Indication (LDI) as described in [MPLS-FMS]

      - L: Locked Report (LKR) as described in [MPLS-FMS]

      - C: Client Signal Failure (CSF) as described in [MPLS-CSF]

      - Remaining bits: Reserved for future specification and set to 0.

   Configuration Flags:

      - E: used to enable/disable explicitly clearing faults

      - PHB: identifies the per-hop behavior of packets with fault
      management information

   Refresh Timer: indicates the refresh timer (in microseconds) of fault
   indication messages.  If the edge LSR receiving the Path message can
   not support such value, it can reply back with a higher interval.

(As a preface to the following three paragraphs, it is not clear if
draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-02 applies to midpoints.   There
are no procedures in the draft for sending and receiving these messages let
alone delivering them to midpoints).

One of the keys to scaling is to keep midpoints simple.  I do not want to be
running separate timers for every LSP that may need fault OAM.  I believe
that operators will be quite happy to configure a single timer per node (or
at most, per interface), and send all fault messages according to that
timer.  The same is true explicit clearing.  PHB,

Midpoints will also set the LDI flag when applicable, so this bit does not
apply at midpoints.  The draft needs to say that the bit only applies to
whether a receiver should react to the LDI flag.

I also cannot imagine an operator wanting to be informed of Alarms but not
Locks or vice versa.  So these two bits should be eliminated or it should be
made clear that they have no semantics at a midpoint.

Alternatively, these configuration flags could be used on and end to end
basis to say that the receiver SHOULD treat AIS or LKR as a hard failure
(LOC).  (This applies to the LSP-PING draft even if it is only an end to end
draft.)

Bottom line.

1. The refresh timer should be removed.
2. The E flag should be removed.
3. PHB should either be removed or said to apply only to CSF.
4. The semantics of the D flag should be clarified to be only end-to-end.
5. The A and L flags should be either eliminated or given and end-to-end
semantic of LOC. 
6. For RSVP at a midpoint, the presence of the FMS tlv should signal that
Fault OAM messages are desired.
7. Procedures for sending and receiving LSP Ping messages with OAM config
need to be added and (non-)applicability at midpoints needs to be made
clear.

...George

---

From: Thomas Nadeau <[email-masked]>
Date: Wed, 17 Aug 2011 15:49:30 -0400

I agree with your changes which narrow the scope of these "oam configuration" drafts, but I'd like to open up a wider discussion as to whether or not we should be doing this at all.
If you recall I raised this issue during the PWE3 meeting in Quebec when a related draft was presented. I raised this issue because I am very concerned about the recent proliferation of drafts allowing configuration via LSP ping (for MPLS-TP, GMPLS and otherwise). I totally understand the motivation for why this is desired - configuration of MIPs and MEPs is a royal pain. However, from an operational perspective, configuration of network element parameters is a real pain at best if allowed via multiple points too, which this draft effectively sets up.  In particular, for the OSS, NMS and operator there are issues like synchronization of configuration changes, capacity planning, etc… that this sort of mechanism seems to invite in.  Imagine a simple scenario where by two distant LSRs have operators sit down and enter LSP ping commands to configure, first a MIP point at an intermediate LSR where one creates the point and say one destroys it. What do we do now?

    This raises the other concern is with regard to security of such mechanisms. I understand that most devices require some form of authentication to gain access to the writable configuration; however, that notwithstanding, I thought the basic premise behind MPLS-TP was to obviate the use of the control plane for reasons pertaining to unauthorized tampering at unsecured nodes. This seems to violate that original tenant if allowed to be done based on the local authentication of an LSR, which might not necessarily match that of another LSR. Consider the case of a cable MSO with different operational domains, where one operator isn't authorized to make configuration changes in the other domain. In this case, they could accidentally make changes that would confuse (at best) the running configuration of an LSR in the other domain.  

	I think in the least, these documents should have some sort of filtering mechanism precluding a device from accepting configuration changes if so configured. Authentication of such requests is probably a good idea too.  This gets into your point about being specific around the actual operation of the packet processing of these messages defined in these drafts.
	
    Since this is just my opinion, what I’d suggest is that we have a bit of an architectural discussion as to whether or not this is a good idea in general.   That might be a good way to guide the WGs as to where to set the limits (if any) on this mode of configuration.

    --Tom

> allow for an extreme amount of control which I believe will not be implemented in many cases and where implemented will not be used.
> 
> (As a preface to the following three paragraphs, it is not clear if draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-02 applies to midpoints.   There are no procedures in the draft for sending and receiving these messages let alone delivering them to midpoints).
> 
> One of the keys to scaling is to keep midpoints simple.  I do not want to be running separate timers for every LSP that may need fault OAM.  I believe that operators will be quite happy to configure a single timer per node (or at most, per interface), and send all fault messages according to that timer.  The same is true explicit clearing.  PHB, 
> 
> Midpoints will also set the LDI flag when applicable, so this bit does not apply at midpoints.  The draft needs to say that the bit only applies to whether a receiver should react to the LDI flag.
> 
> I also cannot imagine an operator wanting to be informed of Alarms but not Locks or vice versa.  So these two bits should be eliminated or it should be made clear that they have no semantics at a midpoint.
> 
> Alternatively, these configuration flags could be used on and end to end basis to say that the receiver SHOULD treat AIS or LKR as a hard failure (LOC).  (This applies to the LSP-PING draft even if it is only an end to end draft.)
> 
> Bottom line.
> 
> The refresh timer should be removed.
> The E flag should be removed.
> PHB should either be removed or said to apply only to CSF.
> The semantics of the D flag should be clarified to be only end-to-end.
> The A and L flags should be either eliminated or given and end-to-end semantic of LOC.
> For RSVP at a midpoint, the presence of the FMS tlv should signal that Fault OAM messages are desired.
> Procedures for sending and receiving LSP Ping messages with OAM config need to be added and (non-)applicability at midpoints needs to be made clear.
> 
> ...George
> 
> 
> 
> 
> 
> _______________________________________________
> CCAMP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ccamp

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 17 Aug 2011 13:16:30 -0700

Dear George,
you've asked:
(As a preface to the following three paragraphs, it is not clear if
draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-02 applies to midpoints.
There are no procedures in the draft for sending and receiving these
messages let alone delivering them to midpoints).
I'm not an author and can only assume that defined in RFC 4379
traceroute procedure will be used to signal to MIP, i.e. controlling
MSE's TTL.

Regards,
Greg

On Wed, Aug 17, 2011 at 11:59 AM, George Swallow <[email-masked]> wrote:
> Procedures for sending and receiving LSP Ping messages with OAM config need
> to be added and (non-)applicability at midpoints needs to be made clear.
>
> ...George
>
>
>
>
>
>

---

From: George Swallow <[email-masked]>
Date: Wed, 17 Aug 2011 18:19:58 -0400

Greg -

I'm an author of 4379.  This draft needs to spell out what to do one way or
the other.  If the plan is to go hop by hop, then you have to trace to the
end first to get the max TTL and then send the OAM config.  Otherwise you
cannot tell if you are at the end if you get a return code of (suggested
value) 16.

And I don't know what you do with that return code, since it is not clear
how the unsupported OAM function is identified.

...George

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 17 Aug 2011 18:41:49 -0700

Dear George,
I'm not sure that there's only one way to slice the proverbial bread
in this case to put it in as standard. I think that one can implement
by following your suggestion (probe connection first, then distribute
OAM configuration). Or OAM configuration TLV can be combined with
DSMAP TLV in order to detect the end of a connection.

Regards,
Greg