Subject: [mpls] RDI

From: Greg Mirsky <[email-masked]>
Date: Mon, 12 Mar 2018 11:24:18 -0700

Dear Authors,
I've read the new draft and have couple questions:

   - what you see missing in RFC 6428 that motivated you to start this new
   document;
   - in Introduction you refer to BFD base specification RFC 5880. I think
   that references to RFC 5884 and RFC 6428 are more appropriate for MPLS-TP
   scenario you consider
   - I believe that RDI already has been defined in Section 3.2 of RFC 6428
   as:

   RDI is communicated via the BFD diagnostic field in BFD CC messages,
   and the diagnostic code field in CV messages MUST be ignored.  It is
   not a distinct PDU.  As per [4], a sink MEP SHOULD encode a
   diagnostic code of "1 - Control Detection Time Expired" when the time
   since the last received BFD control packet exceeds the detection
   time, which is equal to the remote system's Transmit Interval
   multiplied by the remote system's Detect Multiplier (which is set to
   3 in this document).

Regards,
Greg

---

From: Huub van Helvoort <[email-masked]>
Date: Mon, 12 Mar 2018 21:36:05 +0100

Dear authors,

In addition to the questions from Greg I have the following

questions:

1) Are you aware of the fact that In other technologies the

Remote Defect Indication (RDI) is defined in
order to support

single-ended operation, the defect status at the downstream

LER shall be conveyed back to the upstream LER (via the RDI

signal). Hence, in the case where the LERs lie in the domains
of

different operators, the operations systems (OSs) in both
networks

will have access to performance information
from both LSP ends,

without the need for OS-to-OS information exchange.

2) in the introduction you claim: "This allows the two MPLS-TP

LERs to coordinate failover to backup LSPs."

Are you aware of RFC 6378 MPLS-TP linear protection which

describes already a protocol to coordinate failover?

Best regards, Huub.

---------

what you see missing in RFC 6428 that motivated you to
start this new document;

in Introduction you refer to BFD base specification RFC
5880. I think that references to RFC 5884 and RFC 6428 are
more appropriate for MPLS-TP scenario you consider

I believe that RDI already has been defined in Section
3.2 of RFC 6428 as:

RDI is communicated via the BFD diagnostic field in
BFD CC messages,

and the diagnostic code field in CV messages MUST be
ignored.  It is

not a distinct PDU.  As per [4], a sink MEP SHOULD
encode a

diagnostic code of "1 - Control Detection Time
Expired" when the time

since the last received BFD control packet exceeds the
detection

time, which is equal to the remote system's Transmit
Interval

multiplied by the remote system's Detect Multiplier
(which is set to

3 in this document).

Regards,

Greg

--
================================================================
Always remember that you are unique...just like everyone else...

---

From: Ashesh Mishra <[email-masked]>
Date: Thu, 15 Mar 2018 03:06:31 +0000

Huub and Greg,

Replying to both emails together as both present similar concerns. Also, thanks for taking the time to read the document!

While PSC (6378) and BFD (6428) offer a mechanism to propagate faults across a bi-directional LSP, there are efficiencies to be gained by using a method that doesn’t significantly change the behavior defined in 6427.

  1.  Some systems don’t have the capability to run enough BFD at a fast enough rate for every LSP. Using fast BFD only for IP next-hop and feeding it to AIS, the detection is very fast and mpls-fm-oam engine can burst for a short interval to synchronize the fault across both LSP end-points. It’s easy to implement and doesn’t require BFD-level of resources.
  2.  If 6427, with small modifications, can achieve bidirectional fault coordination, then the systems can avoid running an additional protocol engine (6428 PSC). This may not matter much in a big router, but makes a ton of difference in a small system (for example, failing over 100 LSPs in under 50ms on a <$500 box). It’s also easier to interoperate with by virtue of being one less protocol and also by being quite simple.

I will admit that I like the 6428 method as it delivers more than just an RDI (using BFD is out of the question for anything that’s not a router) but it’s just a lot of complexity for enabling bi-directional operation of 6427. 6428 will, in all likelihood, require more development than all of 6427.

I hope this adds clarity to the reason behind the approach in the draft.

Regards,
Ashesh

From: Huub van Helvoort <[email-masked]>
Reply-To: "[email-masked]" <[email-masked]>
Date: Monday, March 12, 2018 at 4:36 PM
To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [mpls] RDI
Resent-From: <[email-masked]>
Resent-To: <[email-masked]>, Mahesh Jethanandani <[email-masked]>, <[email-masked]>
Resent-Date: Monday, March 12, 2018 at 4:36 PM

Dear authors,

1) Are you aware of the fact that In other technologies the
    Remote Defect Indication (RDI) is defined in order to support
    single-ended operation, the defect status at the downstream
    LER shall be conveyed back to the upstream LER (via the RDI
    signal). Hence, in the case where the LERs lie in the domains of
    different operators, the operations systems (OSs) in both networks
    will have access to performance information from both LSP ends,
    without the need for OS-to-OS information exchange.

Best regards, Huub.

---------

  *   what you see missing in RFC 6428 that motivated you to start this new document;
  *   in Introduction you refer to BFD base specification RFC 5880. I think that references to RFC 5884 and RFC 6428 are more appropriate for MPLS-TP scenario you consider
  *   I believe that RDI already has been defined in Section 3.2 of RFC 6428 as:
   RDI is communicated via the BFD diagnostic field in BFD CC messages,
   and the diagnostic code field in CV messages MUST be ignored.  It is
   not a distinct PDU.  As per [4], a sink MEP SHOULD encode a
   diagnostic code of "1 - Control Detection Time Expired" when the time
   since the last received BFD control packet exceeds the detection
   time, which is equal to the remote system's Transmit Interval
   multiplied by the remote system's Detect Multiplier (which is set to
   3 in this document).

Regards,
Greg

--

---

From: Huub van Helvoort <[email-masked]>
Date: Mon, 19 Mar 2018 11:33:44 +0100

Hello Ashesh,

In your response you do not address my concern that you are adding

functionality to Remote Defect Indication by using it to
coordinate

failover. RDI should be used for single-ended and/or far-end

performance monitoring only.

Also note that rfc6378 provides much more functionality (disable

switching, forced switch, manual switch, signal fail, signal
degrade,

revertive switching). Moving this to the management plane will add

complexity.

Even a small modification of rfc6427 will add complexity to the
network

management.

Best regards, Huub.

----------------

Huub and Greg,

Replying to both emails together as both
present similar concerns. Also, thanks for taking the time to
read the document!

While PSC (6378) and BFD (6428) offer a
mechanism to propagate faults across a bi-directional LSP,
there are efficiencies to be gained by using a method that
doesn’t significantly change the behavior defined in 6427.

Some systems
don’t have the capability to run enough BFD at a fast enough
rate for every LSP. Using fast BFD only for IP next-hop and
feeding it to AIS, the detection is very fast and
mpls-fm-oam engine can burst for a short interval to
synchronize the fault across both LSP end-points. It’s easy
to implement and doesn’t require BFD-level of resources.

If 6427,
with small modifications, can achieve bidirectional fault
coordination, then the systems can avoid running an
additional protocol engine (6428 PSC). This may not matter
much in a big router, but makes a ton of difference in a
small system (for example, failing over 100 LSPs in under
50ms on a <$500 box). It’s also easier to interoperate
with by virtue of being one less protocol and also by being
quite simple.

I will admit that I like the 6428 method as
it delivers more than just an RDI (using BFD is out of the
question for anything that’s not a router) but it’s just a lot
of complexity for enabling bi-directional operation of 6427.
6428 will, in all likelihood, require more development than
all of 6427.

I hope this adds clarity to the reason
behind the approach in the draft.

Regards,

Ashesh

From: Huub van Helvoort
<[email-masked]>

Reply-To: "[email-masked]"
<[email-masked]>

To: "[email-masked]"
<[email-masked]>, "[email-masked]"
<[email-masked]>

Subject: Re: [mpls] RDI

Resent-To: <[email-masked]>,
Mahesh Jethanandani <[email-masked]>,
<[email-masked]>

Dear authors,

In addition to the questions from Greg I have the
following

questions:

1) Are you aware of the fact that In other technologies
the

Remote Defect Indication (RDI) is
defined in order to support

single-ended operation, the defect status at the
downstream

LER shall be conveyed back to the upstream LER (via
the RDI

signal). Hence, in the case where the LERs lie in the
domains of

different operators, the operations systems (OSs) in
both networks

2) in the introduction you claim: "This allows the two
MPLS-TP

Are you aware of RFC 6378 MPLS-TP linear protection
which

Best regards, Huub.

---------

I've read the new
draft and have couple questions:

what you
see missing in RFC 6428 that motivated you to start
this new document;

in
Introduction you refer to BFD base specification RFC
5880. I think that references to RFC 5884 and RFC
6428 are more appropriate for MPLS-TP scenario you
consider

I believe
that RDI already has been defined in Section 3.2 of
RFC 6428 as:

RDI is
communicated via the BFD diagnostic field in BFD CC
messages,

and the
diagnostic code field in CV messages MUST be
ignored.  It is

not a
distinct PDU.  As per [4], a sink MEP SHOULD encode
a

diagnostic
code of "1 - Control Detection Time Expired" when
the time

since the
last received BFD control packet exceeds the
detection

time,
which is equal to the remote system's Transmit
Interval

multiplied
by the remote system's Detect Multiplier (which is
set to

3 in this
document).

Regards,

Greg

--

---

From: Ashesh Mishra <[email-masked]>
Date: Mon, 19 Mar 2018 14:47:26 +0000

Huub,

I’m not sure I understand the question. RDI is a fault propagation function. It is not used, as far as I’m aware, for performance monitoring (not sure how one would go about doing that with just RDI).

The draft only suggests single-ended RDI. It is generated by the upstream LER (LER-B in the draft) and intended for LER-A.

The draft is also not disputing the value of RFC6428. The proposed mechanism is specifically valuable in low-power and low-cost systems with very constrained software and hardware resources. Fewer protocols help conserve space that allows for higher scale. It’s not the perfect MPLS deployment, but it is very valuable in certain use-cases in some markets.

Can you please elaborate on why the RDI would add complexity to network management? We were able to deploy it without any change to the network management system (besides turning the function on globally on the LERs). If there is network automation that takes action on the fault notifications on the network/element manager/controller, then it will need to be updated to understand that the notification corresponds to an RDI (since the identifier in the TLV will be of a node that’s upstream from the LER reporting the notification and not downstream – as it is the case of normal AIS/LKR message).

Regards,
Ashesh

From: Huub van Helvoort <[email-masked]>
Reply-To: "[email-masked]" <[email-masked]>
Date: Monday, March 19, 2018 at 6:33 AM
To: Ashesh Mishra <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [mpls] RDI

Hello Ashesh,

In your response you do not address my concern that you are adding
functionality to Remote Defect Indication by using it to coordinate
failover. RDI should be used for single-ended and/or far-end
performance monitoring only.

Also note that rfc6378 provides much more functionality (disable
switching, forced switch, manual switch, signal fail, signal degrade,
revertive switching). Moving this to the management plane will add
complexity.

Even a small modification of rfc6427 will add complexity to the network
management.

Best regards, Huub.
----------------
Huub and Greg,

Regards,
Ashesh

From: Huub van Helvoort <[email-masked]><mailto:[email-masked]>
Reply-To: "[email-masked]"<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>
Date: Monday, March 12, 2018 at 4:36 PM
To: "[email-masked]"<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>, "[email-masked]"<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>
Subject: Re: [mpls] RDI
Resent-From: <[email-masked]><mailto:[email-masked]>
Resent-To: <[email-masked]><mailto:[email-masked]>, Mahesh Jethanandani <[email-masked]><mailto:[email-masked]>, <[email-masked]><mailto:[email-masked]>
Resent-Date: Monday, March 12, 2018 at 4:36 PM

Dear authors,

Best regards, Huub.

---------

Regards,
Greg

--

--

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 19 Mar 2018 15:02:08 +0000

Hi Ashesh,
RFC 6427 describes MPLS FM OAM mechanism to communicate OAM information
from MEP of the server layer to MEP of the client layer. Remote Defect
Indication (RDI) is to be communicated between MEPs of the same layer.
Hence I fail to see why you propose to propagate RDI from server MEP to
client MEP. I believe that RFC 6428 is sufficient and nothing more in
regard to RDI needs to be done.

Regards,
Greg

On Thu, Mar 15, 2018 at 3:06 AM, Ashesh Mishra <[email-masked]>
wrote:

> Huub and Greg,
>
>
>
> Replying to both emails together as both present similar concerns. Also,
> thanks for taking the time to read the document!
>
>
>
> While PSC (6378) and BFD (6428) offer a mechanism to propagate faults
> across a bi-directional LSP, there are efficiencies to be gained by using a
> method that doesn’t significantly change the behavior defined in 6427.
>
>
>
>    1. Some systems don’t have the capability to run enough BFD at a fast
>    enough rate for every LSP. Using fast BFD only for IP next-hop and feeding
>    it to AIS, the detection is very fast and mpls-fm-oam engine can burst for
>    a short interval to synchronize the fault across both LSP end-points. It’s
>    easy to implement and doesn’t require BFD-level of resources.
>    2. If 6427, with small modifications, can achieve bidirectional fault
>    coordination, then the systems can avoid running an additional protocol
>    engine (6428 PSC). This may not matter much in a big router, but makes a
>    ton of difference in a small system (for example, failing over 100 LSPs in
>    under 50ms on a <$500 box). It’s also easier to interoperate with by virtue
>    of being one less protocol and also by being quite simple.
>
>
>
> I will admit that I like the 6428 method as it delivers more than just an
> RDI (using BFD is out of the question for anything that’s not a router) but
> it’s just a lot of complexity for enabling bi-directional operation of
> 6427. 6428 will, in all likelihood, require more development than all of
> 6427.
>
>
>
> *From: *Huub van Helvoort <[email-masked]>
> *Reply-To: *"[email-masked]" <[email-masked]>
> *Date: *Monday, March 12, 2018 at 4:36 PM
> *To: *"[email-masked]" <[email-masked]>, "
> [email-masked]" <[email-masked]>
> *Subject: *Re: [mpls] RDI
> *Resent-From: *<[email-masked]>
> *Resent-To: *<[email-masked]>, Mahesh Jethanandani <
> [email-masked]>, <[email-masked]>
> *Resent-Date: *Monday, March 12, 2018 at 4:36 PM
>
>
>
> Dear authors,
>
>     *Remote* Defect Indication (RDI) is defined in order to support
>     will have access to *performance information* from both LSP ends,
> 2) in the introduction you claim: "
> *This allows the two MPLS-TP     LERs to coordinate failover to backup
> LSPs.*"
>    - what you see missing in RFC 6428 that motivated you to start this
>    new document;
>    - in Introduction you refer to BFD base specification RFC 5880. I
>    think that references to RFC 5884 and RFC 6428 are more appropriate for
>    MPLS-TP scenario you consider
>    - I believe that RDI already has been defined in Section 3.2 of RFC
>    6428 as:
>
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls
>
>

---

From: Italo Busi <[email-masked]>
Date: Mon, 19 Mar 2018 18:26:31 +0000

Ashesh,

I have read the draft and agree with the concerns from Greg and Huub.

As far as I have understood, FM (6427) has been designed to suppress alarm reporting when fast-rate BFD (6428) is used or to speed-up detection of LSP failures caused by failures in the server layer when slow-rate BFD (6428) is used. At the time RFC 6427 was developed there were no intention expressed to use it without BFD.

BFD (6428) allows detecting more failure conditions affecting an LSP including silent failures (any condition that would cause packets not being delivered to the receive LER) and misconnections.

As mentioned by Huub, PSC (6378 and/or 7271) has been designed for protection switching coordination. This protocol allows coordinating protection switching between the two LERs not only in case of unidirectional failures (the case in your draft) but also in case of operators’ commands.

In a nutshell, I think the draft is applicable only when neither detection of “hidden” failures nor operator’s control of protection switching are required.

Is this a realistic network scenario?

Italo

From: Greg Mirsky [mailto:[email-masked]]
Sent: Monday, March 19, 2018 3:02 PM
To: Ashesh Mishra <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [mpls] RDI

Hi Ashesh,
RFC 6427 describes MPLS FM OAM mechanism to communicate OAM information from MEP of the server layer to MEP of the client layer. Remote Defect Indication (RDI) is to be communicated between MEPs of the same layer. Hence I fail to see why you propose to propagate RDI from server MEP to client MEP. I believe that RFC 6428 is sufficient and nothing more in regard to RDI needs to be done.

Regards,
Greg

On Thu, Mar 15, 2018 at 3:06 AM, Ashesh Mishra <[email-masked]<mailto:[email-masked]>> wrote:
Huub and Greg,

Regards,
Ashesh

From: Huub van Helvoort <[email-masked]<mailto:[email-masked]>>
Reply-To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:huubatwork@gmail..com>>
Date: Monday, March 12, 2018 at 4:36 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [mpls] RDI
Resent-From: <[email-masked]<mailto:[email-masked]>>
Resent-To: <[email-masked]<mailto:[email-masked]>>, Mahesh Jethanandani <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>
Resent-Date: Monday, March 12, 2018 at 4:36 PM

Dear authors,

Best regards, Huub.

---------

Regards,
Greg

--

_______________________________________________
mpls mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mpls