Subject: RE: [mpls] Question on draft-mirsky-mpls-bfd-directed

From: Nobo Akiya <[email-masked]>
Date: Wed, 18 Feb 2015 08:21:07 -0500

+ BFD WG

Hi Loa,

> -----Original Message-----

> From: mpls [mailto:[email-masked] <[email-masked]>] On
Behalf Of Loa Andersson

> Sent: Monday, February 16, 2015 3:55 AM

> To: [email-masked]; [email-masked]

> Subject: [mpls] Question on draft-mirsky-mpls-bfd-directed

> Authors, Working Group,

> I started to review draft-mirsky-mpls-bfd-directed, but got stuck on the

> problem statement.

> If I understand you correctly, but I admit that I may have misunderstood,

> you are saying that the scope of the document are uni- directional
explicit

> routed LSPs. A typical example would be MPLS-TE LSPs, right?

That's not incorrect :)

AFAIK, technically correct scope is all BFD session types that are
bootstrapped with LSP Ping, with uni-directional traffic engineered paths
on SPRING based networks being the primary use case.

> You also say that for such an LSPs the egress would use the shortest path
for

> its control message, while the ingress will send control messages in-band.

> Now in Asynchronous mode the BFD session will form a loop ingress -

> egress - ingress, where ingress to egress is on the the monitored LSP,
while

> egress to ingress is out-of-band, right?

> You say that since the egress to ingress control message will follow the

> shortest path, which might not be co-routed with the ingress to egress
LSP,

> missing responses can't be taken as an indication of that the uni-
directional

> LSP needs to be re-routed.

> While I agree with that statement, I don't see that if you give the
egress an

> explicit return/reverse path that is co-routed with the monitored LSP you

> are really in a better shape to draw any conclusions.

> Failure to receive egress to ingress control messages does not necessarily

> tell you anything about the state of the monitored LSP.

You are absolutely right. The egress-to-ingress BFD session not being
co-routed is a motivation for this document, but what the proposed
mechanism is providing is an ability to bootstrap egress-to-ingress BFD
session to take a specific path. Whether such egress-to-ingress sessions
are co-routed or otherwise is a choice left to users, and is outside the
scope of this document. With SPRING based network, user choosing the
co-routed egress-to-ingress path is doable (i.e., it is possible for an
element computing the forward stack to compute the reverse stack), but,
again, that's outside the scope of this document. I believe you have
pointed out this these aspects are slightly confusing/misleading and need
to be clarified in the document, and I agree with that.

Additionally, I believe the premise is that it's better to take down the
uni-directional path based on the failure of user specified
egress-to-ingress path instead of an arbitrary egress-to-ingress path. If
the egress-to-ingress path can always be guaranteed [automatically] to be
co-routed in all cases, then that may be superior. However, I do think what
this document is describing is a reasonable improvement over what we have
today.

Thanks!

-Nobo

> /Loa

> --

> Loa Andersson                        email: [email-masked]

> Senior MPLS Expert                          [email-masked]

> Huawei Technologies (consultant)     phone: +46 739 81 21 64

> _______________________________________________

> mpls mailing list

> [email-masked]

> https://www.ietf.org/mailman/listinfo/mpls

---

From: Gregory Mirsky <[email-masked]>
Date: Thu, 19 Feb 2015 02:52:54 +0000

Hi Loa, Nobo, et. al,
many thanks for very thorough review and great discussion. Nobo pointed that investigation of BFD in Segment Routing network, both with MPLS and IPv6 data plane, was the main motivator for this proposal.
I agree that the document needs improvements in number of places and greatly appreciate your comments and suggestions. Hence the question, would “ingress”/”egress” be more intuitive than “near-end”/”far-end”?

                Regards,
                                Greg

From: Nobo Akiya [mailto:[email-masked]]
Sent: Wednesday, February 18, 2015 5:21 AM
To: Loa Andersson; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [mpls] Question on draft-mirsky-mpls-bfd-directed

+ BFD WG

Hi Loa,

> From: mpls [mailto:[email-masked]] On Behalf Of Loa Andersson

> To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

> you are saying that the scope of the document are uni- directional explicit

That's not incorrect :)

AFAIK, technically correct scope is all BFD session types that are bootstrapped with LSP Ping, with uni-directional traffic engineered paths on SPRING based networks being the primary use case.

> You also say that for such an LSPs the egress would use the shortest path for

> egress - ingress, where ingress to egress is on the the monitored LSP, while

> shortest path, which might not be co-routed with the ingress to egress LSP,

> missing responses can't be taken as an indication of that the uni- directional

> While I agree with that statement, I don't see that if you give the egress an

> tell you anything about the state of the monitored LSP.

You are absolutely right. The egress-to-ingress BFD session not being co-routed is a motivation for this document, but what the proposed mechanism is providing is an ability to bootstrap egress-to-ingress BFD session to take a specific path. Whether such egress-to-ingress sessions are co-routed or otherwise is a choice left to users, and is outside the scope of this document. With SPRING based network, user choosing the co-routed egress-to-ingress path is doable (i.e., it is possible for an element computing the forward stack to compute the reverse stack), but, again, that's outside the scope of this document. I believe you have pointed out this these aspects are slightly confusing/misleading and need to be clarified in the document, and I agree with that.

Additionally, I believe the premise is that it's better to take down the uni-directional path based on the failure of user specified egress-to-ingress path instead of an arbitrary egress-to-ingress path. If the egress-to-ingress path can always be guaranteed [automatically] to be co-routed in all cases, then that may be superior. However, I do think what this document is describing is a reasonable improvement over what we have today.

Thanks!

-Nobo

> Loa Andersson                        email: [email-masked]<mailto:[email-masked]>

> Senior MPLS Expert                          [email-masked]<mailto:[email-masked]>

> [email-masked]<mailto:[email-masked]>

---

From: Loa Andersson <[email-masked]>
Date: Thu, 19 Feb 2015 12:33:50 +0800

Greg and Nobo,

On 2015-02-19 10:52, Gregory Mirsky wrote:
> Hi Loa, Nobo, et. al,
>
> many thanks for very thorough review and great discussion. Nobo pointed
> that investigation of BFD in Segment Routing network, both with MPLS and
> IPv6 data plane, was the main motivator for this proposal.
>
> I agree that the document needs improvements in number of places and
> greatly appreciate your comments and suggestions. Hence the question,
> would “ingress”/”egress” be more intuitive than “near-end”/”far-end”?

Since we are talking explicitly routed LSPs "ingress/egress" is more
intuitive for me.

However, there is one question that I don't really grok.

If you have a bi-directional co-routed and you are not receiving the
egress to ingress control messages, you know that one direction is
broken and since you have the requirement that the bi-directional LSP
shall be "co-routed" you need to swap over to a stand-by or re-route,
for both directions.

If you have a uni-directional a co-route the control back from the
egress to the ingress, and you are not receiving the egress to ingress
control messages, you know that either the uni-directional LSP is broken
or that the control channel is. Do you have a way to tell which it is?

Do you really want to swap to a stand-by or re-route because the egress
to ingress control channel is broken, while the explicit routed LSP is
working just fine?

/Loa

>
>                  Regards,
>
>                                  Greg
>
> *From:*Nobo Akiya [mailto:[email-masked]]
> *Sent:* Wednesday, February 18, 2015 5:21 AM
> *To:* Loa Andersson; [email-masked];
> [email-masked]
> *Cc:* [email-masked]
> *Subject:* RE: [mpls] Question on draft-mirsky-mpls-bfd-directed
>
> + BFD WG
>
> Hi Loa,
>
>> To:  [email-masked] <mailto:[email-masked]>;
> [email-masked]
> <mailto:[email-masked]>
>
> bootstrapped with LSP Ping, with uni-directional traffic engineered
> paths on SPRING based networks being the primary use case.
>
>>
>
> pointed out this these aspects are slightly confusing/misleading and
> need to be clarified in the document, and I agree with that.
>
> egress-to-ingress path instead of an arbitrary egress-to-ingress path.
> If the egress-to-ingress path can always be guaranteed [automatically]
> to be co-routed in all cases, then that may be superior. However, I do
> think what this document is describing is a reasonable improvement over
> what we have today.
>
> Thanks!
>
> -Nobo
>
>>
>
>> /Loa
>
>> --
>
>>
>
>>
>
>> Loa Andersson                        email:  [email-masked] <mailto:[email-masked]>
>
>> Senior MPLS [email-masked] <mailto:[email-masked]>
>
>>  [email-masked] <mailto:[email-masked]>
>

--

---

From: Gregory Mirsky <[email-masked]>
Date: Thu, 19 Feb 2015 05:49:45 +0000

Hi Loa,
your scenario perfectly illustrates the dilemma operator would face when trying to provide n:m  protection for uni-directional transport. If only 1+1 protection required, then it is the egress node that would detect a defect and flip the switch. But if n:m (1:1 and 1:n are special cases) required we have to make certain assumptions. Obviously we always try to minimize them but as, for example, with use of SPME for Segment OAM in MPLS-TP, cannot eliminate completely. Yes, failure of egress-to-ingress OAM channel may happen while ingress-to-egress flow is fully operational even though both are co-routed.

	Regards,
		Greg

-----Original Message-----
From: Loa Andersson [mailto:[email-masked]] 
Sent: Wednesday, February 18, 2015 8:34 PM
To: Gregory Mirsky; Nobo Akiya; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [mpls] Question on draft-mirsky-mpls-bfd-directed

Greg and Nobo,

On 2015-02-19 10:52, Gregory Mirsky wrote:
> Hi Loa, Nobo, et. al,
>
> many thanks for very thorough review and great discussion. Nobo 
> pointed that investigation of BFD in Segment Routing network, both 
> with MPLS and

Since we are talking explicitly routed LSPs "ingress/egress" is more intuitive for me.

If you have a bi-directional co-routed and you are not receiving the egress to ingress control messages, you know that one direction is broken and since you have the requirement that the bi-directional LSP shall be "co-routed" you need to swap over to a stand-by or re-route, for both directions.

If you have a uni-directional a co-route the control back from the egress to the ingress, and you are not receiving the egress to ingress control messages, you know that either the uni-directional LSP is broken or that the control channel is. Do you have a way to tell which it is?

Do you really want to swap to a stand-by or re-route because the egress to ingress control channel is broken, while the explicit routed LSP is working just fine?

/Loa

> mechanism is providing is an ability to bootstrap egress-to-ingress 
> BFD session to take a specific path. Whether such egress-to-ingress 
> sessions are co-routed or otherwise is a choice left to users, and is 
> outside the scope of this document. With SPRING based network, user 
> choosing the co-routed egress-to-ingress path is doable (i.e., it is 
> possible for an element computing the forward stack to compute the 
> reverse stack), but, again, that's outside the scope of this document. 
> I believe you have pointed out this these aspects are slightly 
> confusing/misleading and need to be clarified in the document, and I agree with that.
>
> Additionally, I believe the premise is that it's better to take down 
> the uni-directional path based on the failure of user specified 
> think what this document is describing is a reasonable improvement 
> over what we have today.
>
> Thanks!
>
> -Nobo
>
>>
>
>> /Loa
>
>> --
>
>>
>
>>
>

--

---

From: Loa Andersson <[email-masked]>
Date: Thu, 19 Feb 2015 15:13:28 +0800

Greg,

> your scenario perfectly illustrates the dilemma operator would face when trying to provide n:m  protection for uni-directional transport. If only 1+1 protection required, then it is the egress node…

I understand that we are able to quite easily co-route the explicitly
route LSP, and the the egress to ingress control channel. Can you more
precisely describe the assumptions you make and what problem you solve?

/Loa

--