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 <mishra.ashesh@outlook.com>
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.
>
>
>
> I hope this adds clarity to the reason behind the approach in the draft.
>
>
>
> Regards,
>
> Ashesh
>
>
>
> *From: *Huub van Helvoort <huubatwork@gmail.com>
> *Reply-To: *"huubatwork@gmail.com" <huubatwork@gmail.com>
> *Date: *Monday, March 12, 2018 at 4:36 PM
> *To: *"draft-ama-mpls-fm-rdi@ietf.org" <draft-ama-mpls-fm-rdi@ietf.org>, "
> mpls@ietf.org" <mpls@ietf.org>
> *Subject: *Re: [mpls] RDI
> *Resent-From: *<alias-bounces@ietf.org>
> *Resent-To: *<mishra.ashesh@outlook.com>, Mahesh Jethanandani <
> mjethanandani@gmail.com>, <ankurpsaxena@gmail.com>
> *Resent-Date: *Monday, March 12, 2018 at 4:36 PM
>
>
>
> 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.
>
> ---------
>
> 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
>
>
>
> --
>
> ================================================================
>
> Always remember that you are unique...just like everyone else...
>
>
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
>
>