Subject: Re: Questions on BFD for MPLS LSP

From: Vishwas Manral <[email-masked]>
Date: Tue, 9 Feb 2010 05:38:07 -0800

Hi Mach,

I think there is value in the draft for clamping forward and backward
direction of an LSP.

With BFD-MPLS a BFD session down means an FEC down and not an LSP down as a
different BFD session is established per FEC, do we want to change this rule
instead. Your draft seems to have a BFD session per LSP and not per FEC.
Further comments below:

1. BFD-MPLS assumes that detection of failure is only in the forward
direction. We are making a change in the assumption, so we must specify the
same in the draft. This is particularly useful for GMPLS signalled LSP's
which can be bidirectional (like MPLS-TP etc).

2. One thing I think we can add is that at the ingress BFD needs to be
started in the passive mode. This is because packet send starts happening if
the BFD session is added but is in default (active mode even though the BFD
session at the other end is not established yet)

3. It is not clear what needs to be done in case of BFD failure when
unidirectional LSP's are there. Failure in one direction will lead to
failure in the other which may not be the desired behavior of unidirectional
LSP's.

4. You talk about Optical networks, what/ how are the FEC's in the case of
Optical networks defined?

5. You mention
"For each direction of a LSP, a separate BFD session is required
        to be established."

However BFD-MPLS allows the return packet to be MPLS encapsulated. This
however is a choice of the receiver and this point could be made clearer.

6. I think for bidirectional LSP there is no ingress or egress there is
signalling initiator.

7. I think point 3 section 3 needs to be further clarified. When we do not
want an association between forward and reverse direction LSP's we should
not use these extensions. As switchover in this case will happen as a unit.

8. The FEC for the forward and backward direction of the LSP will be
different. As a different BFD session is established per FEC (I would have
prefered it was not) how do we map the forward and backward direction FEC's.

9. Also as the extension is for MPLs LSP encapsulated reply, we need to
mention the port number used for BFD is restricted to single hop.

10. What happens when the ingress supports this extension and egress does
not and vice versa.

11. Let us not use the word backward but instead use the words reverse for
LSP's.

12. How do we make sure of the case of larger IP address, especially because
there are multiple addresses configured on a device.

Thanks,
Vishwas
On Tue, Feb 9, 2010 at 2:13 AM, Mach Chen <[email-masked]> wrote:

> Hi Vishwas,
>
> How are you doing?
>
> Remember that you promised to read and comment my draft, and I'm still
> looking forward to receive your comments and suggestions.
>
> Here are the pointers of the draft and relevant sildes:
>
> Slides:
> http://tools.ietf.org/agenda/76/slides/mpls-2.ppt
> Draft:
> http://tools.ietf.org/html?draft=draft-chen-mpls-bfd-enhancement-00
>
>
> Best regards,
> Mach
>
> --------------------------------------------------
> From: "Mach Chen" <[email-masked]>
> Sent: Thursday, November 19, 2009 8:51 AM
> To: "Vishwas Manral" <[email-masked]>
> Cc: "Sunil C Gutlapalli" <[email-masked]>; "So Ning" <
> [email-masked]>; <[email-masked]>
>
> Subject: Re: Questions on BFD for MPLS LSP
>
> Hi Vishwas,
>>
>> Looking forward to receive you comments!
>>
>> Thanks,
>> Mach
>>
>> --------------------------------------------------
>> From: "Vishwas Manral" <[email-masked]>
>> Sent: Wednesday, November 18, 2009 1:59 AM
>> To: "Mach Chen" <[email-masked]>
>> Cc: "Sunil C Gutlapalli" <[email-masked]>; <[email-masked]>; "So
>> Ning" <[email-masked]>
>> Subject: Re: Questions on BFD for MPLS LSP
>>
>> Hi Mach,
>>>
>>> Though I have not yet read through the draft, it seems that the draft
>>> could be of interest. LEt me read the draft and get back to you with
>>> comments.
>>>
>>> Thanks,
>>> Vishwas
>>>
>>> On Tue, Nov 17, 2009 at 1:06 AM, Mach Chen <[email-masked]> wrote:
>>>
>>>> Hi Sunil,
>>>>
>>>> Regarding to your questions, especially for the question 2 and 3,  we
>>>> also
>>>> had the same doubts couple months ago.
>>>>
>>>> Since the reverse direction of a "BFD for MPLS LSPs" sesssion follows
>>>> routing and the return path is "randomly" detetermined by the egress
>>>> LSR,
>>>> the failures in return path may lead to false positives.
>>>>
>>>> In addition to that, for bidirectional LSP or a pair of unidirectional
>>>> LSP,
>>>> there will be two separate BFD sessions( one for each direction)
>>>> established, and these two BFD sessions have no any inherent
>>>> relationship,
>>>> it will result in not double the BFD sessions over the LSP, but failing
>>>> to
>>>> perform protection and switching when the bidirectional LSP or the pair
>>>> of
>>>> undirectional LSPs are desired to operated as a single entity.
>>>>
>>>> We submitted a draft that is intended to reslove these
>>>> issues/limitation.
>>>> This draft was just presented at MPLS WG, Hiroshima.
>>>>
>>>>
>>>> Any comments and sugguestions are appreciated!
>>>>
>>>>
>>>> PS:
>>>>
>>>> The links:
>>>>
>>>> Slides:
>>>> http://tools.ietf.org/agenda/76/slides/mpls-2.ppt
>>>>
>>>> Draft:
>>>> http://tools.ietf.org/html?draft=draft-chen-mpls-bfd-enhancement-00
>>>>
>>>>
>>>> Best regards,
>>>> Mach
>>>>
>>>> --------------------------------------------------
>>>> From: "Sunil C Gutlapalli" <[email-masked]>
>>>> Sent: Tuesday, November 17, 2009 6:59 AM
>>>> To: <[email-masked]>
>>>> Subject: Questions on BFD for MPLS LSP
>>>>
>>>> Hi
>>>>>
>>>>>
>>>>>
>>>>> I have some question on BFD for MPLS LSP's
>>>>>
>>>>>
>>>>>
>>>>> 1. MPLS LSP's are uni-directional and BFD sessions are for
>>>>> Bi-directional failure detection. If we have an LSP from Ingress to
>>>>> Egress,
>>>>> BFD control packets are sent to UDP port 3784 (BFD single hop session
>>>>> port)
>>>>> from ingress to egress. Control packets from Egress to ingress are sent
>>>>> to
>>>>> UDP port 4784 (multi hop session port). So does the session is single
>>>>> hop
>>>>> session or multi hop session? What is the session behavior in ingress
>>>>> and
>>>>> egress?
>>>>> 2. If LSP takes path1 from ingress to egress and the shortest path from
>>>>> egress to ingress is path2, control packets takes different paths, if
>>>>> path2
>>>>> fails then BFD session goes down. But LSP path is still up. How this
>>>>> case
>>>>> will be handled?
>>>>> 3. If we have LSP from Ingress to egress and another LSP from egress to
>>>>> ingress, do we need to create two BFD sessions or one session?
>>>>>
>>>>> If both LSP's take same path, then link failure causes both LSP's down,
>>>>> but
>>>>> if they take different paths, one link failure causes both LSP's down.
>>>>>
>>>>>
>>>>>
>>>>> Sunil
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>

---

From: Mach Chen <[email-masked]>
Date: Wed, 10 Feb 2010 14:56:55 +0800

Hi Vishwas,

Thanks for you valuable comments!

Please see inline...
Sent: Tuesday, February 09, 2010 9:38 PM
Cc: <[email-masked]>

> I think there is value in the draft for clamping forward and backward
Thanks!

> instead. Your draft seems to have a BFD session per LSP and not per FEC.

We just relax the "rule", means except for "one BFD session per FEC", we 
could have a BFD session per LSP or per a group of LSPs(e.g., a pair of 
LSPs, one for each direction). One BFD session per LSP(s) is very useful for 
bidirectional LSP(e.g., GMPLS, MPLS-TP).

> which can be bidirectional (like MPLS-TP etc).

OK, will clarify it in the next revision.

And agree that this is particularly useful for GMPLS LSP and MPLS-TP LSP.

> session at the other end is not established yet)

With the extension defined in the draft, a BFD session will not be 
established before the echo reply received, and if the echo the echo reply 
received, the session at the other end should have been already established.

> failure in the other which may not be the desired behavior of 

If you want each of the two unidirectional LSPs to be operated separately, 
two seperate BFD sessions should be provisioned, just as is in current 
BFD-MPLS.

If you provision a single BFD session for a pair unidirectional LSPs, that 
means you want the two LSPs to be operated as a single entity. So when one 
direction failed, no matter what the other direction is OK or not, it should 
switch to the protection path.

We will add some text to clarify this in the next revision.

> Optical networks defined?

Although the word "Optical" is mentioned in the draft, actually this draft 
is mainly about packet switching network. Maybe we should remove the word to 
avoid confusion.

> however is a choice of the receiver and this point could be made clearer.

OK.

> 6. I think for bidirectional LSP there is no ingress or egress there is

Agree.

> not use these extensions. As switchover in this case will happen as a 

OK, will clarify it in the next revision.

> prefered it was not) how do we map the forward and backward direction 

In the draft, it uses the RPS(Return Path Specified) LSP Ping mechansims 
that are defined in 
http://tools.ietf.org/id/draft-chen-mpls-return-path-specified-lsp-ping-01.txt 
for forward and backward direction FECs mapping. In short, the specific FEC 
(or the FEC selection policy) of the reply path is explicitly specified in 
the echo request message.

PS:
RPS Ping defines extensions to LSP Ping [RFC4379] that allows specifying an 
LSP as the return path of an echo reply.

> mention the port number used for BFD is restricted to single hop.
OK.

> 10. What happens when the ingress supports this extension and egress does
This draft is based on the RPS mechanisms, in RPS draft, it defines a new 
reply mode: "Reply via specified return path". So when a node receive an 
echo request with reply mode set to "Reply via specified return path" and it 
does not know it, an echo reply with the return code set to "Malformed echo 
request" should be sent back to the sender. This error prcessing is defined 
in the RPS draft.

And of cause, when this happen, the BFD session will not be estalished, we 
will add some text to clarify this in the next revision.

> 11. Let us not use the word backward but instead use the words reverse for

OK.

> there are multiple addresses configured on a device.

We could simply use the Router ID for comparison. But I have to think over 
about it.

Thanks again for your valuable comments and suggesions!

Best regards,
Mach

---

From: Vishwas Manral <[email-masked]>
Date: Wed, 10 Feb 2010 04:59:05 -0800

Hi Mach,

> bidirectional LSP(e.g., GMPLS, MPLS-TP).

I think this should be the first and the most important extension to the
draft.

> And agree that this is particularly useful for GMPLS LSP and MPLS-TP LSP.

This is one of the main changes to draft of making the detection from
unidirectional to bidirectional and should be clarified.

> received, the session at the other end should have been already established.
Am not sure, may be you can clarify this in the draft.

> We will add some text to clarify this in the next revision.

Your explanation is correct. This is the reason this is an optional
extension, however this reason has not been mentioned about why the
extension is optional.

> I agree you should just remove Optical etc. The term has been loosly used
in the draft.

> http://tools.ietf.org/id/draft-chen-mpls-return-path-specified-lsp-ping-01.txtfor forward and backward direction FECs mapping. In short, the specific FEC
Ok need to have a look at these extensions.

> Great!!!.

> Yes this sounds correct.

Thanks,
Vishwas

---

From: "Shahram Davari" <[email-masked]>
Date: Wed, 10 Feb 2010 12:38:20 -0800

Hi,

I support extending BFD to monitor only LSP regardless of the FEC. This is very useful for MPLS and MPLS-TP protection switching.

Regards,
Shahram

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Vishwas Manral
Sent: Wednesday, February 10, 2010 4:59 AM
To: Mach Chen
Cc: [email-masked]; So Ning
Subject: Re: Questions on BFD for MPLS LSP

Hi Mach,

We just relax the "rule", means except for "one BFD session per FEC", we could have a BFD session per LSP or per a group of LSPs(e.g., a pair of LSPs, one for each direction). One BFD session per LSP(s) is very useful for bidirectional LSP(e.g., GMPLS, MPLS-TP).
I think this should be the first and the most important extension to the draft.

Further comments below:

And agree that this is particularly useful for GMPLS LSP and MPLS-TP LSP.
This is one of the main changes to draft of making the detection from unidirectional to bidirectional and should be clarified.

With the extension defined in the draft, a BFD session will not be established before the echo reply received, and if the echo the echo reply received, the session at the other end should have been already established.
Am not sure, may be you can clarify this in the draft.

If you want each of the two unidirectional LSPs to be operated separately, two seperate BFD sessions should be provisioned, just as is in current BFD-MPLS.

If you provision a single BFD session for a pair unidirectional LSPs, that means you want the two LSPs to be operated as a single entity. So when one direction failed, no matter what the other direction is OK or not, it should switch to the protection path.

We will add some text to clarify this in the next revision.
Your explanation is correct. This is the reason this is an optional extension, however this reason has not been mentioned about why the extension is optional.

Although the word "Optical" is mentioned in the draft, actually this draft is mainly about packet switching network. Maybe we should remove the word to avoid confusion.

I agree you should just remove Optical etc. The term has been loosly used in the draft.

5. You mention

OK.

Agree.

In the draft, it uses the RPS(Return Path Specified) LSP Ping mechansims that are defined in http://tools.ietf.org/id/draft-chen-mpls-return-path-specified-lsp-ping-01.txt for forward and backward direction FECs mapping. In short, the specific FEC (or the FEC selection policy) of the reply path is explicitly specified in the echo request message.

PS:
RPS Ping defines extensions to LSP Ping [RFC4379] that allows specifying an LSP as the return path of an echo reply.
Ok need to have a look at these extensions.

10. What happens when the ingress supports this extension and egress does
not and vice versa.
This draft is based on the RPS mechanisms, in RPS draft, it defines a new reply mode: "Reply via specified return path". So when a node receive an echo request with reply mode set to "Reply via specified return path" and it does not know it, an echo reply with the return code set to "Malformed echo request" should be sent back to the sender. This error prcessing is defined in the RPS draft.

And of cause, when this happen, the BFD session will not be estalished, we will add some text to clarify this in the next revision.

Great!!!.

We could simply use the Router ID for comparison. But I have to think over about it.

Yes this sounds correct.

Best regards,
Mach

Thanks,
Vishwas

Thanks,
Vishwas
On Tue, Feb 9, 2010 at 2:13 AM, Mach Chen <[email-masked]<mailto:[email-masked]>> wrote:

Hi Vishwas,

How are you doing?

Slides:

Best regards,
Mach

--------------------------------------------------
From: "Mach Chen" <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, November 19, 2009 8:51 AM
To: "Vishwas Manral" <[email-masked]<mailto:[email-masked]>>
Cc: "Sunil C Gutlapalli" <[email-masked]<mailto:[email-masked]>>; "So Ning" <
[email-masked]<mailto:[email-masked]>>; <[email-masked]<mailto:[email-masked]>>

Hi Vishwas,

Thanks,
Mach

--------------------------------------------------
From: "Vishwas Manral" <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, November 18, 2009 1:59 AM
To: "Mach Chen" <[email-masked]<mailto:[email-masked]>>
Cc: "Sunil C Gutlapalli" <[email-masked]<mailto:[email-masked]>>; <[email-masked]<mailto:[email-masked]>>; "So
Ning" <[email-masked]<mailto:[email-masked]>>
Subject: Re: Questions on BFD for MPLS LSP

Hi Mach,

Thanks,
Vishwas

On Tue, Nov 17, 2009 at 1:06 AM, Mach Chen <[email-masked]<mailto:[email-masked]>> wrote:

Hi Sunil,

PS:

The links:

Slides:

Draft:

Best regards,
Mach

--------------------------------------------------
From: "Sunil C Gutlapalli" <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, November 17, 2009 6:59 AM
To: <[email-masked]<mailto:[email-masked]>>
Subject: Questions on BFD for MPLS LSP

Hi

Sunil

---

From: Vishwas Manral <[email-masked]>
Date: Wed, 10 Feb 2010 13:59:59 -0800

Hi Shahram,

It also helps with scalability of BFD sessions.

Thanks,
Vishwas
On Wed, Feb 10, 2010 at 12:38 PM, Shahram Davari <[email-masked]>wrote:

>  Hi,
>
> I support extending BFD to monitor only LSP regardless of the FEC. This is
> very useful for MPLS and MPLS-TP protection switching.
>
> Regards,
> Shahram
>
>  ------------------------------
> *From:* [email-masked] [mailto:[email-masked]] *On
> Behalf Of *Vishwas Manral
> *Sent:* Wednesday, February 10, 2010 4:59 AM
> *To:* Mach Chen
> *Cc:* [email-masked]; So Ning
>
> *Subject:* Re: Questions on BFD for MPLS LSP
>
>   Hi Mach,
>
>> RPS Ping defines extensions to LSP Ping [RFC4379] that allows specifying
>> an LSP as the return path of an echo reply.
>>

---

From: Mach Chen <[email-masked]>
Date: Thu, 11 Feb 2010 09:05:38 +0800

Hi Vishwas and Shahram,

Yes, that's one of the purposes of this draft.

Thanks for your comments!

Best regards,
Mach

--------------------------------------------------
From: "Vishwas Manral" <[email-masked]>
Sent: Thursday, February 11, 2010 5:59 AM
To: "Shahram Davari" <[email-masked]>
Cc: "Mach Chen" <[email-masked]>; <[email-masked]>; "So Ning" 
<[email-masked]>
Subject: Re: Questions on BFD for MPLS LSP

>>  With BFD-MPLS a BFD session down means an FEC down and not an LSP down 
>> as
>>> a
>>>> started in the passive mode. This is because packet send starts 
>>>> happening
>>>> if
>>> http://tools.ietf.org/id/draft-chen-mpls-return-path-specified-lsp-ping-01.txtfor 
>>> forward and backward direction FECs mapping. In short, the specific FEC
>>>>>>>>> 3. If we have LSP from Ingress to egress and another LSP from 
>>>>>>>>> egress
>>>>>>>>> to

---

From: Mach Chen <[email-masked]>
Date: Thu, 11 Feb 2010 09:23:09 +0800

Hi Vishwas and Shahram,

Yes, scalability is one of the purposes of this draft!

Thanks for you comments!

Best regards,
Mach

---

From: Mach Chen <[email-masked]>
Date: Thu, 11 Feb 2010 11:10:28 +0800

Hi Vishwas,

Thanks for your prompt response!

> Am not sure, may be you can clarify this in the draft.

Sorry for that, let me try to explain it again.

A sucessful BFD session establishment is at least based on one exchange of 
echo request and echo reply. When the initiator received the echo reply and 
everything is OK, the BFD session is sucessfully established. So it could 
begin to send BFD packets onto the session. For the receiver, it may send 
BFD packets onto the session after sending the echo reply, if the echo reply 
could pass the validation checking of the initiator, there is no problem. 
But there is possibility that the echo reply failed to pass the validation 
checking, that means the reverse direction of BFD is not OK, but the 
receiver will not aware of it. So in order to relsove this issue, the 
receiver MUST wait to send the BFD packets until received the first BFD 
packet from the initiator.

We will clarify this in the next revision.

> extension, however this reason has not been mentioned about why the

I am not sure what's your mean about "why the extension is optional" here.

I think, since this extension is of course not fit for all scenarios, the 
choice of which solution is used belongs to the operators. Based on their 
application scenarios, they should determine whether to use this extension.

> Ok need to have a look at these extensions.

Thanks, hope to receive your comments and suggestions about the RPS Ping 
draft!

Best regards,
Mach