Re: [mpls] RDI

[Huub van Helvoort <[e-mail]>]

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.

 

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 <[e-mail]>
Reply-To: "[e-mail]" <[e-mail]>
Date: Monday, March 12, 2018 at 4:36 PM
To: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Re: [mpls] RDI
Resent-From: <[e-mail]>
Resent-To: <[e-mail]>, Mahesh Jethanandani <[e-mail]>, <[e-mail]>
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...

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