Re: A question about RFC5884

2017-07-31 Thread Jeffrey Haas
On Tue, Jul 18, 2017 at 10:25:38AM +, Carlos Pignataro (cpignata) wrote:
> I had not suggested it, but I think that idea has merit. If there are enough 
> updates needed to the spec based on additional running-code learning, or 
> ambiguities that are causing interoperable confusion, the net of a -biz can 
> be positive.
> 
> When that same idea crossed my mind, I thought that the question should be 
> part of a larger consideration from the chairs of maturity, pipeline, and 
> advancement of BFD specs, and not taken in isolation. 5884 seems to require 
> localized fixes only.
> 

Thus far my reading of the thread is that when you pedantically consider
each of the involved specs, we're not to the point where we'd need to update
the procedures in 5884.  The issues seem to occur if you're willing to "read
between the lines".

As a reminder, when the RFCs appear to be broken or unclear, the Errata
feature available in the datatracker can allow issues to be filed.  These
issues are considered when it's time to update the RFC.

-- Jeff



RE: A question about RFC5884

2017-07-18 Thread Mach Chen
Hi Carlos,

OK, thanks for the clarification!

Best regards,
Mach

From: Carlos Pignataro (cpignata) [mailto:cpign...@cisco.com]
Sent: Tuesday, July 18, 2017 6:26 PM
To: Mach Chen
Cc: Reshad Rahman (rrahman); rtg-bfd@ietf.org
Subject: Re: A question about RFC5884

Hi Mach,

I had not suggested it, but I think that idea has merit. If there are enough 
updates needed to the spec based on additional running-code learning, or 
ambiguities that are causing interoperable confusion, the net of a -biz can be 
positive.

When that same idea crossed my mind, I thought that the question should be part 
of a larger consideration from the chairs of maturity, pipeline, and 
advancement of BFD specs, and not taken in isolation. 5884 seems to require 
localized fixes only.

Thanks,

Sent from my iPad

On Jul 18, 2017, at 9:14 AM, Mach Chen 
mailto:mach.c...@huawei.com>> wrote:
Hi Carlos,

Do you suggest to do a 5884-bis?

Best regards,
Mach

From: Carlos Pignataro (cpignata) [mailto:cpign...@cisco.com]
Sent: Monday, July 17, 2017 10:56 PM
To: Mach Chen
Cc: Reshad Rahman (rrahman); Ashesh Mishra; 
rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>
Subject: Re: A question about RFC5884

Hi Mach,

On Jul 17, 2017, at 10:42 AM, Mach Chen 
mailto:mach.c...@huawei.com>> wrote:
Hi Carlos,

Thanks for sharing your thoughts.

IMHO, it may not be necessary to consider this LSP Ping based bootstrapping as 
normal LSP ping.

Would it be considered an abnormal LSP Ping? :-)



If RFC 5884 references RFC 4379, I'd expect it means an LSP Ping as specified 
in 4379, or those processes for LSP Ping be updated.

Sent from my iPad



And since both the ingress and egress LSR process the echo messages in the 
context of BFD session establishment, it should be no problem to process as 
described in RFC5884.

BTW, RFC5884 does not specify which reply mode will be used :)

Best regards,
Mach

From: Carlos Pignataro (cpignata) [mailto:cpign...@cisco.com]
Sent: Monday, July 17, 2017 6:58 AM
To: Reshad Rahman (rrahman)
Cc: Mach Chen; Ashesh Mishra; rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>
Subject: Re: A question about RFC5884

Hi,

I also agree with the conclusion of this thread in regards to what RFC 5884 
says. However, can that be in conflict with RFC 8029's procedures, in which the 
reply might be expected?
https://tools.ietf.org/html/rfc8029#section-4.4

There is certainly no need to carry any information in an MPLS LSP Ping reply, 
since at that point the discriminatory are already carried in BFD. The reply 
might be important only if FEC validation fails.

I wonder though if the text of "The egress LSR MAY respond with an LSP Ping 
Echo" intended to convey that whether to reply or not depends on the value of 
the Reply Mode field in the Echo request.

Sent from my iPad

On Jul 16, 2017, at 6:22 PM, Reshad Rahman (rrahman) 
mailto:rrah...@cisco.com>> wrote:
Hi,

My take too is that the RFC is pretty clear that Echo reply from egress
LSR is not mandatory.

Regards,
Reshad.



On 2017-07-16, 4:29 PM, "Rtg-bfd on behalf of Mach Chen"
mailto:rtg-bfd-boun...@ietf.org> on behalf of 
mach.c...@huawei.com<mailto:mach.c...@huawei.com>> wrote:




Hi Ashesh,

Thanks for your prompt response, we're on the same page!

Best regards,
Mach

-邮件原件-
发件人: Ashesh Mishra [mailto:mishra.ash...@outlook.com]
发送时间: 2017年7月16日 22:26
收件人: Mach Chen
抄送: rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>
主题: Re: A question about RFC5884

That's how I read it ... assuming that proper handling of the LSR echo
includes
gracefully dropping it on rx.

Ashesh

On Jul 16, 2017, at 3:58 PM, Mach Chen 
mailto:mach.c...@huawei.com>> wrote:

Hi BFDers,

We met a multi-vendor interoperate issue recently, it's about whether
an Echo
reply is necessary.

In Section 6 of RFC5884, 2nd paragraph

"... The egress LSR MAY respond with an LSP Ping Echo
 reply message that carries the local discriminator assigned by it for
 the BFD session."

From the above text, my understanding is that an Echo reply is
optional, the
egress LSR can freely to return or not return an Echo reply, and the
Ingress LSR
should not expect there MUST be an Echo reply, but if there is one, it
should
handle it properly.

Is my understanding correct?

Thanks,
Mach




Re: A question about RFC5884

2017-07-18 Thread Carlos Pignataro (cpignata)
Hi Mach,

I had not suggested it, but I think that idea has merit. If there are enough 
updates needed to the spec based on additional running-code learning, or 
ambiguities that are causing interoperable confusion, the net of a -biz can be 
positive.

When that same idea crossed my mind, I thought that the question should be part 
of a larger consideration from the chairs of maturity, pipeline, and 
advancement of BFD specs, and not taken in isolation. 5884 seems to require 
localized fixes only.

Thanks,

Sent from my iPad

On Jul 18, 2017, at 9:14 AM, Mach Chen 
mailto:mach.c...@huawei.com>> wrote:

Hi Carlos,

Do you suggest to do a 5884-bis?

Best regards,
Mach

From: Carlos Pignataro (cpignata) [mailto:cpign...@cisco.com]
Sent: Monday, July 17, 2017 10:56 PM
To: Mach Chen
Cc: Reshad Rahman (rrahman); Ashesh Mishra; 
rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>
Subject: Re: A question about RFC5884

Hi Mach,

On Jul 17, 2017, at 10:42 AM, Mach Chen 
mailto:mach.c...@huawei.com>> wrote:
Hi Carlos,

Thanks for sharing your thoughts.

IMHO, it may not be necessary to consider this LSP Ping based bootstrapping as 
normal LSP ping.

Would it be considered an abnormal LSP Ping? :-)


If RFC 5884 references RFC 4379, I'd expect it means an LSP Ping as specified 
in 4379, or those processes for LSP Ping be updated.

Sent from my iPad


And since both the ingress and egress LSR process the echo messages in the 
context of BFD session establishment, it should be no problem to process as 
described in RFC5884.

BTW, RFC5884 does not specify which reply mode will be used :)

Best regards,
Mach

From: Carlos Pignataro (cpignata) [mailto:cpign...@cisco.com]
Sent: Monday, July 17, 2017 6:58 AM
To: Reshad Rahman (rrahman)
Cc: Mach Chen; Ashesh Mishra; rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>
Subject: Re: A question about RFC5884

Hi,

I also agree with the conclusion of this thread in regards to what RFC 5884 
says. However, can that be in conflict with RFC 8029's procedures, in which the 
reply might be expected?
https://tools.ietf.org/html/rfc8029#section-4.4

There is certainly no need to carry any information in an MPLS LSP Ping reply, 
since at that point the discriminatory are already carried in BFD. The reply 
might be important only if FEC validation fails.

I wonder though if the text of "The egress LSR MAY respond with an LSP Ping 
Echo" intended to convey that whether to reply or not depends on the value of 
the Reply Mode field in the Echo request.

Sent from my iPad

On Jul 16, 2017, at 6:22 PM, Reshad Rahman (rrahman) 
mailto:rrah...@cisco.com>> wrote:
Hi,

My take too is that the RFC is pretty clear that Echo reply from egress
LSR is not mandatory.

Regards,
Reshad.



On 2017-07-16, 4:29 PM, "Rtg-bfd on behalf of Mach Chen"
mailto:rtg-bfd-boun...@ietf.org> on behalf of 
mach.c...@huawei.com<mailto:mach.c...@huawei.com>> wrote:



Hi Ashesh,

Thanks for your prompt response, we're on the same page!

Best regards,
Mach

--
???: Ashesh Mishra [mailto:mishra.ash...@outlook.com]
: 2017?7?16? 22:26
???: Mach Chen
??: rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>
??: Re: A question about RFC5884

That's how I read it ... assuming that proper handling of the LSR echo
includes
gracefully dropping it on rx.

Ashesh

On Jul 16, 2017, at 3:58 PM, Mach Chen 
mailto:mach.c...@huawei.com>> wrote:

Hi BFDers,

We met a multi-vendor interoperate issue recently, it's about whether
an Echo
reply is necessary.

In Section 6 of RFC5884, 2nd paragraph

"... The egress LSR MAY respond with an LSP Ping Echo
 reply message that carries the local discriminator assigned by it for
 the BFD session."

>From the above text, my understanding is that an Echo reply is
optional, the
egress LSR can freely to return or not return an Echo reply, and the
Ingress LSR
should not expect there MUST be an Echo reply, but if there is one, it
should
handle it properly.

Is my understanding correct?

Thanks,
Mach




RE: A question about RFC5884

2017-07-18 Thread Mach Chen
Hi Carlos,

Do you suggest to do a 5884-bis?

Best regards,
Mach

From: Carlos Pignataro (cpignata) [mailto:cpign...@cisco.com]
Sent: Monday, July 17, 2017 10:56 PM
To: Mach Chen
Cc: Reshad Rahman (rrahman); Ashesh Mishra; rtg-bfd@ietf.org
Subject: Re: A question about RFC5884

Hi Mach,

On Jul 17, 2017, at 10:42 AM, Mach Chen 
mailto:mach.c...@huawei.com>> wrote:
Hi Carlos,

Thanks for sharing your thoughts.

IMHO, it may not be necessary to consider this LSP Ping based bootstrapping as 
normal LSP ping.

Would it be considered an abnormal LSP Ping? :-)


If RFC 5884 references RFC 4379, I'd expect it means an LSP Ping as specified 
in 4379, or those processes for LSP Ping be updated.

Sent from my iPad


And since both the ingress and egress LSR process the echo messages in the 
context of BFD session establishment, it should be no problem to process as 
described in RFC5884.

BTW, RFC5884 does not specify which reply mode will be used :)

Best regards,
Mach

From: Carlos Pignataro (cpignata) [mailto:cpign...@cisco.com]
Sent: Monday, July 17, 2017 6:58 AM
To: Reshad Rahman (rrahman)
Cc: Mach Chen; Ashesh Mishra; rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>
Subject: Re: A question about RFC5884

Hi,

I also agree with the conclusion of this thread in regards to what RFC 5884 
says. However, can that be in conflict with RFC 8029's procedures, in which the 
reply might be expected?
https://tools.ietf.org/html/rfc8029#section-4.4

There is certainly no need to carry any information in an MPLS LSP Ping reply, 
since at that point the discriminatory are already carried in BFD. The reply 
might be important only if FEC validation fails.

I wonder though if the text of "The egress LSR MAY respond with an LSP Ping 
Echo" intended to convey that whether to reply or not depends on the value of 
the Reply Mode field in the Echo request.

Sent from my iPad

On Jul 16, 2017, at 6:22 PM, Reshad Rahman (rrahman) 
mailto:rrah...@cisco.com>> wrote:
Hi,

My take too is that the RFC is pretty clear that Echo reply from egress
LSR is not mandatory.

Regards,
Reshad.



On 2017-07-16, 4:29 PM, "Rtg-bfd on behalf of Mach Chen"
mailto:rtg-bfd-boun...@ietf.org> on behalf of 
mach.c...@huawei.com<mailto:mach.c...@huawei.com>> wrote:



Hi Ashesh,

Thanks for your prompt response, we're on the same page!

Best regards,
Mach

-邮件原件-
发件人: Ashesh Mishra [mailto:mishra.ash...@outlook.com]
发送时间: 2017年7月16日 22:26
收件人: Mach Chen
抄送: rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>
主题: Re: A question about RFC5884

That's how I read it ... assuming that proper handling of the LSR echo
includes
gracefully dropping it on rx.

Ashesh

On Jul 16, 2017, at 3:58 PM, Mach Chen 
mailto:mach.c...@huawei.com>> wrote:

Hi BFDers,

We met a multi-vendor interoperate issue recently, it's about whether
an Echo
reply is necessary.

In Section 6 of RFC5884, 2nd paragraph

"... The egress LSR MAY respond with an LSP Ping Echo
 reply message that carries the local discriminator assigned by it for
 the BFD session."

From the above text, my understanding is that an Echo reply is
optional, the
egress LSR can freely to return or not return an Echo reply, and the
Ingress LSR
should not expect there MUST be an Echo reply, but if there is one, it
should
handle it properly.

Is my understanding correct?

Thanks,
Mach




Re: A question about RFC5884

2017-07-17 Thread Ashesh Mishra
Greg,

Re: following section


On receipt of the LSP Ping Echo request message, the egress LSR MUST
   send a BFD Control packet to the ingress LSR, if the validation of
   the FEC in the LSP Ping Echo request message succeeds.

GIM>> The LSP Ping Echo is validated. If the validation fails, then the LSP 
Echo Reply MUST be sent with the appropriate Return Code. If the validation 
succeeds, then the BFD control packet MUST be sent.

The MUST in the RFC is for the generation of a BFD control packet and not echo 
reply.

Ashesh

On Jul 17, 2017, at 6:02 PM, Greg Mirsky 
mailto:gregimir...@gmail.com>> wrote:

Hi Carlos,
please find in-lined interpretation of RFC 5884 paragraph tagged GIM>>.

Regards,
Greg

On Mon, Jul 17, 2017 at 8:30 AM, Carlos Pignataro (cpignata) 
mailto:cpign...@cisco.com>> wrote:
Greg,

I am sorry but I don't see how the paragraph supports what you say. Two issues:

1. LSP Ping is based on the Normative reference's spec, RFC 4379. It cannot go 
against it unless it updates its behavior. The following text:

"The egress LSR MAY respond with an LSP Ping Echo
reply message that carries the local discriminator assigned by it for
   the BFD session."

Also has the interpretation that Santosh shared, which is "MAY send a response 
including a TLV, but sending it is not optional"

2. You wrote a MUST in your reply with specific ordering of packet responses. 
MUSTs are for interoperability. The text does not talk about order of packets. 
Where is that coming from?

It is unhelpful to mention references without citing them, and in any case, I 
do not believe the text supports your conclusion.

Sent from my iPad

On Jul 17, 2017, at 5:14 PM, Greg Mirsky 
mailto:gregimir...@gmail.com>> wrote:

Hi Carlos,
it would take me time to dig that old discussion. I strongly believe that the 
wording and the order of listing actions in this paragraph of Section 6 RFC 
5884 supports my interpretation and recollection of the discussion:

   On receipt of the LSP Ping Echo request message, the egress LSR MUST
   send a BFD Control packet to the ingress LSR, if the validation of
   the FEC in the LSP Ping Echo request message succeeds.

GIM>> The LSP Ping Echo is validated. If the validation fails, then the LSP 
Echo Reply MUST be sent with the appropriate Return Code. If the validation 
succeeds, then the BFD control packet MUST be sent.

This BFD
   Control packet MUST set the Your Discriminator field to the
   discriminator received from the ingress LSR in the LSP Ping Echo
   request message.

GIM>> This describes how Your Discriminator field of the BFD control packet to 
be transmitted by the egress LSR MUST be populated as it will be used by the 
ingress LSR to demultiplex BFD sessions..

  The egress LSR MAY respond with an LSP Ping Echo
   reply message that carries the local discriminator assigned by it for
   the BFD session.

GIM>> After the egress LSR is done with sending the first BFD control packet it 
MAY send LSP Ping Echo reply with already allocated and included in BFD control 
packet My Discriminator as value of BFD Discriminator TLV.

The local discriminator assigned by the egress LSR
   MUST be used as the My Discriminator field in the BFD session packets
   sent by the egress LSR.



Regards,
Greg

On Mon, Jul 17, 2017 at 8:02 AM, Carlos Pignataro (cpignata) 
mailto:cpign...@cisco.com>> wrote:
Greg,

Pointer?

Thanks,

Sent from my iPad

On Jul 17, 2017, at 9:34 AM, Greg Mirsky 
mailto:gregimir...@gmail.com>> wrote:

Hi Mach, et. al,
I recall that this question was discussed some time ago and the clarification 
came from the original authors of the BFD protocol. The Echo Reply is optional 
if there's no error to report. But if the remote LER, acting as BFD node, does 
decide to send the Echo Reply it MUST send it after is sends the first BFD 
control message.

Regards,
Greg

On Sun, Jul 16, 2017 at 6:58 AM, Mach Chen 
mailto:mach.c...@huawei.com>> wrote:
Hi BFDers,

We met a multi-vendor interoperate issue recently, it's about whether an Echo 
reply is necessary.

In Section 6 of RFC5884, 2nd paragraph

"... The egress LSR MAY respond with an LSP Ping Echo
   reply message that carries the local discriminator assigned by it for
   the BFD session."

>From the above text, my understanding is that an Echo reply is optional, the 
>egress LSR can freely to return or not return an Echo reply, and the Ingress 
>LSR should not expect there MUST be an Echo reply, but if there is one, it 
>should handle it properly.

Is my understanding correct?

Thanks,
Mach






Re: A question about RFC5884

2017-07-17 Thread Greg Mirsky
Hi Carlos,
please find in-lined interpretation of RFC 5884 paragraph tagged GIM>>.

Regards,
Greg

On Mon, Jul 17, 2017 at 8:30 AM, Carlos Pignataro (cpignata) <
cpign...@cisco.com> wrote:

> Greg,
>
> I am sorry but I don't see how the paragraph supports what you say. Two
> issues:
>
> 1. LSP Ping is based on the Normative reference's spec, RFC 4379. It
> cannot go against it unless it updates its behavior. The following text:
>
> "The egress LSR MAY respond with an LSP Ping Echo
> reply message that carries the local discriminator assigned by it for
>the BFD session."
>
> Also has the interpretation that Santosh shared, which is "MAY send a
> response including a TLV, but sending it is not optional"
>
> 2. You wrote a MUST in your reply with specific ordering of packet
> responses. MUSTs are for interoperability. The text does not talk about
> order of packets. Where is that coming from?
>
> It is unhelpful to mention references without citing them, and in any
> case, I do not believe the text supports your conclusion.
>
> Sent from my iPad
>
> On Jul 17, 2017, at 5:14 PM, Greg Mirsky  wrote:
>
> Hi Carlos,
> it would take me time to dig that old discussion. I strongly believe that
> the wording and the order of listing actions in this paragraph of Section 6
> RFC 5884 supports my interpretation and recollection of the discussion:
>
>On receipt of the LSP Ping Echo request message, the egress LSR MUST
>send a BFD Control packet to the ingress LSR, if the validation of
>the FEC in the LSP Ping Echo request message succeeds.
>
> GIM>> The LSP Ping Echo is validated. If the validation fails, then the
LSP Echo Reply MUST be sent with the appropriate Return Code. If the
validation succeeds, then the BFD control packet MUST be sent.

> This BFD
>Control packet MUST set the Your Discriminator field to the
>discriminator received from the ingress LSR in the LSP Ping Echo
>request message.
>
> GIM>> This describes how Your Discriminator field of the BFD control
packet to be transmitted by the egress LSR MUST be populated as it will be
used by the ingress LSR to demultiplex BFD sessions..

>   The egress LSR MAY respond with an LSP Ping Echo
>reply message that carries the local discriminator assigned by it for
>the BFD session.
>
> GIM>> After the egress LSR is done with sending the first BFD control
packet it MAY send LSP Ping Echo reply with already allocated and included
in BFD control packet My Discriminator as value of BFD Discriminator TLV.

> The local discriminator assigned by the egress LSR
>MUST be used as the My Discriminator field in the BFD session packets
>sent by the egress LSR.
>
>
>
> Regards,
> Greg
>
> On Mon, Jul 17, 2017 at 8:02 AM, Carlos Pignataro (cpignata) <
> cpign...@cisco.com> wrote:
>
>> Greg,
>>
>> Pointer?
>>
>> Thanks,
>>
>> Sent from my iPad
>>
>> On Jul 17, 2017, at 9:34 AM, Greg Mirsky  wrote:
>>
>> Hi Mach, et. al,
>> I recall that this question was discussed some time ago and the
>> clarification came from the original authors of the BFD protocol. The Echo
>> Reply is optional if there's no error to report. But if the remote LER,
>> acting as BFD node, does decide to send the Echo Reply it MUST send it
>> after is sends the first BFD control message.
>>
>> Regards,
>> Greg
>>
>> On Sun, Jul 16, 2017 at 6:58 AM, Mach Chen  wrote:
>>
>>> Hi BFDers,
>>>
>>> We met a multi-vendor interoperate issue recently, it's about whether an
>>> Echo reply is necessary.
>>>
>>> In Section 6 of RFC5884, 2nd paragraph
>>>
>>> "... The egress LSR MAY respond with an LSP Ping Echo
>>>reply message that carries the local discriminator assigned by it for
>>>the BFD session."
>>>
>>> >From the above text, my understanding is that an Echo reply is
>>> optional, the egress LSR can freely to return or not return an Echo reply,
>>> and the Ingress LSR should not expect there MUST be an Echo reply, but if
>>> there is one, it should handle it properly.
>>>
>>> Is my understanding correct?
>>>
>>> Thanks,
>>> Mach
>>>
>>>
>>
>


Re: A question about RFC5884

2017-07-17 Thread Carlos Pignataro (cpignata)
Greg,

I am sorry but I don't see how the paragraph supports what you say. Two issues:

1. LSP Ping is based on the Normative reference's spec, RFC 4379. It cannot go 
against it unless it updates its behavior. The following text:

"The egress LSR MAY respond with an LSP Ping Echo
reply message that carries the local discriminator assigned by it for
   the BFD session."

Also has the interpretation that Santosh shared, which is "MAY send a response 
including a TLV, but sending it is not optional"

2. You wrote a MUST in your reply with specific ordering of packet responses. 
MUSTs are for interoperability. The text does not talk about order of packets. 
Where is that coming from?

It is unhelpful to mention references without citing them, and in any case, I 
do not believe the text supports your conclusion.

Sent from my iPad

On Jul 17, 2017, at 5:14 PM, Greg Mirsky 
mailto:gregimir...@gmail.com>> wrote:

Hi Carlos,
it would take me time to dig that old discussion. I strongly believe that the 
wording and the order of listing actions in this paragraph of Section 6 RFC 
5884 supports my interpretation and recollection of the discussion:

   On receipt of the LSP Ping Echo request message, the egress LSR MUST
   send a BFD Control packet to the ingress LSR, if the validation of
   the FEC in the LSP Ping Echo request message succeeds.  This BFD
   Control packet MUST set the Your Discriminator field to the
   discriminator received from the ingress LSR in the LSP Ping Echo
   request message.  The egress LSR MAY respond with an LSP Ping Echo
   reply message that carries the local discriminator assigned by it for
   the BFD session.  The local discriminator assigned by the egress LSR
   MUST be used as the My Discriminator field in the BFD session packets
   sent by the egress LSR.



Regards,
Greg

On Mon, Jul 17, 2017 at 8:02 AM, Carlos Pignataro (cpignata) 
mailto:cpign...@cisco.com>> wrote:
Greg,

Pointer?

Thanks,

Sent from my iPad

On Jul 17, 2017, at 9:34 AM, Greg Mirsky 
mailto:gregimir...@gmail.com>> wrote:

Hi Mach, et. al,
I recall that this question was discussed some time ago and the clarification 
came from the original authors of the BFD protocol. The Echo Reply is optional 
if there's no error to report. But if the remote LER, acting as BFD node, does 
decide to send the Echo Reply it MUST send it after is sends the first BFD 
control message.

Regards,
Greg

On Sun, Jul 16, 2017 at 6:58 AM, Mach Chen 
mailto:mach.c...@huawei.com>> wrote:
Hi BFDers,

We met a multi-vendor interoperate issue recently, it's about whether an Echo 
reply is necessary.

In Section 6 of RFC5884, 2nd paragraph

"... The egress LSR MAY respond with an LSP Ping Echo
   reply message that carries the local discriminator assigned by it for
   the BFD session."

>From the above text, my understanding is that an Echo reply is optional, the 
>egress LSR can freely to return or not return an Echo reply, and the Ingress 
>LSR should not expect there MUST be an Echo reply, but if there is one, it 
>should handle it properly.

Is my understanding correct?

Thanks,
Mach





Re: A question about RFC5884

2017-07-17 Thread Greg Mirsky
Hi Carlos,
it would take me time to dig that old discussion. I strongly believe that
the wording and the order of listing actions in this paragraph of Section 6
RFC 5884 supports my interpretation and recollection of the discussion:

   On receipt of the LSP Ping Echo request message, the egress LSR MUST
   send a BFD Control packet to the ingress LSR, if the validation of
   the FEC in the LSP Ping Echo request message succeeds.  This BFD
   Control packet MUST set the Your Discriminator field to the
   discriminator received from the ingress LSR in the LSP Ping Echo
   request message.  The egress LSR MAY respond with an LSP Ping Echo
   reply message that carries the local discriminator assigned by it for
   the BFD session.  The local discriminator assigned by the egress LSR
   MUST be used as the My Discriminator field in the BFD session packets
   sent by the egress LSR.



Regards,
Greg

On Mon, Jul 17, 2017 at 8:02 AM, Carlos Pignataro (cpignata) <
cpign...@cisco.com> wrote:

> Greg,
>
> Pointer?
>
> Thanks,
>
> Sent from my iPad
>
> On Jul 17, 2017, at 9:34 AM, Greg Mirsky  wrote:
>
> Hi Mach, et. al,
> I recall that this question was discussed some time ago and the
> clarification came from the original authors of the BFD protocol. The Echo
> Reply is optional if there's no error to report. But if the remote LER,
> acting as BFD node, does decide to send the Echo Reply it MUST send it
> after is sends the first BFD control message.
>
> Regards,
> Greg
>
> On Sun, Jul 16, 2017 at 6:58 AM, Mach Chen  wrote:
>
>> Hi BFDers,
>>
>> We met a multi-vendor interoperate issue recently, it's about whether an
>> Echo reply is necessary.
>>
>> In Section 6 of RFC5884, 2nd paragraph
>>
>> "... The egress LSR MAY respond with an LSP Ping Echo
>>reply message that carries the local discriminator assigned by it for
>>the BFD session."
>>
>> >From the above text, my understanding is that an Echo reply is optional,
>> the egress LSR can freely to return or not return an Echo reply, and the
>> Ingress LSR should not expect there MUST be an Echo reply, but if there is
>> one, it should handle it properly.
>>
>> Is my understanding correct?
>>
>> Thanks,
>> Mach
>>
>>
>


Re: A question about RFC5884

2017-07-17 Thread Carlos Pignataro (cpignata)
Greg,

Pointer?

Thanks,

Sent from my iPad

On Jul 17, 2017, at 9:34 AM, Greg Mirsky 
mailto:gregimir...@gmail.com>> wrote:

Hi Mach, et. al,
I recall that this question was discussed some time ago and the clarification 
came from the original authors of the BFD protocol. The Echo Reply is optional 
if there's no error to report. But if the remote LER, acting as BFD node, does 
decide to send the Echo Reply it MUST send it after is sends the first BFD 
control message.

Regards,
Greg

On Sun, Jul 16, 2017 at 6:58 AM, Mach Chen 
mailto:mach.c...@huawei.com>> wrote:
Hi BFDers,

We met a multi-vendor interoperate issue recently, it's about whether an Echo 
reply is necessary.

In Section 6 of RFC5884, 2nd paragraph

"... The egress LSR MAY respond with an LSP Ping Echo
   reply message that carries the local discriminator assigned by it for
   the BFD session."

>From the above text, my understanding is that an Echo reply is optional, the 
>egress LSR can freely to return or not return an Echo reply, and the Ingress 
>LSR should not expect there MUST be an Echo reply, but if there is one, it 
>should handle it properly.

Is my understanding correct?

Thanks,
Mach




Re: A question about RFC5884

2017-07-17 Thread Carlos Pignataro (cpignata)
Hi Mach,

On Jul 17, 2017, at 10:42 AM, Mach Chen 
mailto:mach.c...@huawei.com>> wrote:

Hi Carlos,

Thanks for sharing your thoughts.

IMHO, it may not be necessary to consider this LSP Ping based bootstrapping as 
normal LSP ping.

Would it be considered an abnormal LSP Ping? :-)

If RFC 5884 references RFC 4379, I'd expect it means an LSP Ping as specified 
in 4379, or those processes for LSP Ping be updated.

Sent from my iPad

And since both the ingress and egress LSR process the echo messages in the 
context of BFD session establishment, it should be no problem to process as 
described in RFC5884.

BTW, RFC5884 does not specify which reply mode will be used :)

Best regards,
Mach

From: Carlos Pignataro (cpignata) [mailto:cpign...@cisco.com]
Sent: Monday, July 17, 2017 6:58 AM
To: Reshad Rahman (rrahman)
Cc: Mach Chen; Ashesh Mishra; rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>
Subject: Re: A question about RFC5884

Hi,

I also agree with the conclusion of this thread in regards to what RFC 5884 
says. However, can that be in conflict with RFC 8029's procedures, in which the 
reply might be expected?
https://tools.ietf.org/html/rfc8029#section-4.4

There is certainly no need to carry any information in an MPLS LSP Ping reply, 
since at that point the discriminatory are already carried in BFD. The reply 
might be important only if FEC validation fails.

I wonder though if the text of "The egress LSR MAY respond with an LSP Ping 
Echo" intended to convey that whether to reply or not depends on the value of 
the Reply Mode field in the Echo request.

Sent from my iPad

On Jul 16, 2017, at 6:22 PM, Reshad Rahman (rrahman) 
mailto:rrah...@cisco.com>> wrote:
Hi,

My take too is that the RFC is pretty clear that Echo reply from egress
LSR is not mandatory.

Regards,
Reshad.



On 2017-07-16, 4:29 PM, "Rtg-bfd on behalf of Mach Chen"
mailto:rtg-bfd-boun...@ietf.org> on behalf of 
mach.c...@huawei.com<mailto:mach.c...@huawei.com>> wrote:


Hi Ashesh,

Thanks for your prompt response, we're on the same page!

Best regards,
Mach

--
???: Ashesh Mishra [mailto:mishra.ash...@outlook.com]
: 2017?7?16? 22:26
???: Mach Chen
??: rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>
??: Re: A question about RFC5884

That's how I read it ... assuming that proper handling of the LSR echo
includes
gracefully dropping it on rx.

Ashesh

On Jul 16, 2017, at 3:58 PM, Mach Chen 
mailto:mach.c...@huawei.com>> wrote:

Hi BFDers,

We met a multi-vendor interoperate issue recently, it's about whether
an Echo
reply is necessary.

In Section 6 of RFC5884, 2nd paragraph

"... The egress LSR MAY respond with an LSP Ping Echo
 reply message that carries the local discriminator assigned by it for
 the BFD session."

>From the above text, my understanding is that an Echo reply is
optional, the
egress LSR can freely to return or not return an Echo reply, and the
Ingress LSR
should not expect there MUST be an Echo reply, but if there is one, it
should
handle it properly.

Is my understanding correct?

Thanks,
Mach




Re: A question about RFC5884

2017-07-17 Thread Santosh P K
I read it as Local discriminator assigned for a BDS session is optional in
echo reply that is being sent in response to LSP ping echo. I don't think
RFC 5884 is not talking about echo reply being optional.

Thanks
Santosh P K

On Sun, Jul 16, 2017 at 7:28 PM, Mach Chen  wrote:

> Hi BFDers,
>
> We met a multi-vendor interoperate issue recently, it's about whether an
> Echo reply is necessary.
>
> In Section 6 of RFC5884, 2nd paragraph
>
> "... The egress LSR MAY respond with an LSP Ping Echo
>reply message that carries the local discriminator assigned by it for
>the BFD session."
>
> >From the above text, my understanding is that an Echo reply is optional,
> the egress LSR can freely to return or not return an Echo reply, and the
> Ingress LSR should not expect there MUST be an Echo reply, but if there is
> one, it should handle it properly.
>
> Is my understanding correct?
>
> Thanks,
> Mach
>
>


RE: A question about RFC5884

2017-07-17 Thread Mach Chen
Hi Carlos,

Thanks for sharing your thoughts.

IMHO, it may not be necessary to consider this LSP Ping based bootstrapping as 
normal LSP ping. And since both the ingress and egress LSR process the echo 
messages in the context of BFD session establishment, it should be no problem 
to process as described in RFC5884.

BTW, RFC5884 does not specify which reply mode will be used :)

Best regards,
Mach

From: Carlos Pignataro (cpignata) [mailto:cpign...@cisco.com]
Sent: Monday, July 17, 2017 6:58 AM
To: Reshad Rahman (rrahman)
Cc: Mach Chen; Ashesh Mishra; rtg-bfd@ietf.org
Subject: Re: A question about RFC5884

Hi,

I also agree with the conclusion of this thread in regards to what RFC 5884 
says. However, can that be in conflict with RFC 8029's procedures, in which the 
reply might be expected?
https://tools.ietf.org/html/rfc8029#section-4.4

There is certainly no need to carry any information in an MPLS LSP Ping reply, 
since at that point the discriminatory are already carried in BFD. The reply 
might be important only if FEC validation fails.

I wonder though if the text of "The egress LSR MAY respond with an LSP Ping 
Echo" intended to convey that whether to reply or not depends on the value of 
the Reply Mode field in the Echo request.

Sent from my iPad

On Jul 16, 2017, at 6:22 PM, Reshad Rahman (rrahman) 
mailto:rrah...@cisco.com>> wrote:
Hi,

My take too is that the RFC is pretty clear that Echo reply from egress
LSR is not mandatory.

Regards,
Reshad.



On 2017-07-16, 4:29 PM, "Rtg-bfd on behalf of Mach Chen"
mailto:rtg-bfd-boun...@ietf.org> on behalf of 
mach.c...@huawei.com<mailto:mach.c...@huawei.com>> wrote:


Hi Ashesh,

Thanks for your prompt response, we're on the same page!

Best regards,
Mach

-邮件原件-
发件人: Ashesh Mishra [mailto:mishra.ash...@outlook.com]
发送时间: 2017年7月16日 22:26
收件人: Mach Chen
抄送: rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>
主题: Re: A question about RFC5884

That's how I read it ... assuming that proper handling of the LSR echo
includes
gracefully dropping it on rx.

Ashesh

On Jul 16, 2017, at 3:58 PM, Mach Chen 
mailto:mach.c...@huawei.com>> wrote:

Hi BFDers,

We met a multi-vendor interoperate issue recently, it's about whether
an Echo
reply is necessary.

In Section 6 of RFC5884, 2nd paragraph

"... The egress LSR MAY respond with an LSP Ping Echo
 reply message that carries the local discriminator assigned by it for
 the BFD session."

From the above text, my understanding is that an Echo reply is
optional, the
egress LSR can freely to return or not return an Echo reply, and the
Ingress LSR
should not expect there MUST be an Echo reply, but if there is one, it
should
handle it properly.

Is my understanding correct?

Thanks,
Mach




Re: A question about RFC5884

2017-07-17 Thread Greg Mirsky
Hi Mach, et. al,
I recall that this question was discussed some time ago and the
clarification came from the original authors of the BFD protocol. The Echo
Reply is optional if there's no error to report. But if the remote LER,
acting as BFD node, does decide to send the Echo Reply it MUST send it
after is sends the first BFD control message.

Regards,
Greg

On Sun, Jul 16, 2017 at 6:58 AM, Mach Chen  wrote:

> Hi BFDers,
>
> We met a multi-vendor interoperate issue recently, it's about whether an
> Echo reply is necessary.
>
> In Section 6 of RFC5884, 2nd paragraph
>
> "... The egress LSR MAY respond with an LSP Ping Echo
>reply message that carries the local discriminator assigned by it for
>the BFD session."
>
> >From the above text, my understanding is that an Echo reply is optional,
> the egress LSR can freely to return or not return an Echo reply, and the
> Ingress LSR should not expect there MUST be an Echo reply, but if there is
> one, it should handle it properly.
>
> Is my understanding correct?
>
> Thanks,
> Mach
>
>


Re: A question about RFC5884

2017-07-16 Thread Carlos Pignataro (cpignata)
Hi,

I also agree with the conclusion of this thread in regards to what RFC 5884 
says. However, can that be in conflict with RFC 8029's procedures, in which the 
reply might be expected?
https://tools.ietf.org/html/rfc8029#section-4.4

There is certainly no need to carry any information in an MPLS LSP Ping reply, 
since at that point the discriminatory are already carried in BFD. The reply 
might be important only if FEC validation fails.

I wonder though if the text of "The egress LSR MAY respond with an LSP Ping 
Echo" intended to convey that whether to reply or not depends on the value of 
the Reply Mode field in the Echo request.

Sent from my iPad

On Jul 16, 2017, at 6:22 PM, Reshad Rahman (rrahman) 
mailto:rrah...@cisco.com>> wrote:

Hi,

My take too is that the RFC is pretty clear that Echo reply from egress
LSR is not mandatory.

Regards,
Reshad.



On 2017-07-16, 4:29 PM, "Rtg-bfd on behalf of Mach Chen"
mailto:rtg-bfd-boun...@ietf.org> on behalf of 
mach.c...@huawei.com<mailto:mach.c...@huawei.com>> wrote:

Hi Ashesh,

Thanks for your prompt response, we're on the same page!

Best regards,
Mach

--
???: Ashesh Mishra [mailto:mishra.ash...@outlook.com]
: 2017?7?16? 22:26
???: Mach Chen
??: rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>
??: Re: A question about RFC5884

That's how I read it ... assuming that proper handling of the LSR echo
includes
gracefully dropping it on rx.

Ashesh

On Jul 16, 2017, at 3:58 PM, Mach Chen 
mailto:mach.c...@huawei.com>> wrote:

Hi BFDers,

We met a multi-vendor interoperate issue recently, it's about whether
an Echo
reply is necessary.

In Section 6 of RFC5884, 2nd paragraph

"... The egress LSR MAY respond with an LSP Ping Echo
 reply message that carries the local discriminator assigned by it for
 the BFD session."

>From the above text, my understanding is that an Echo reply is
optional, the
egress LSR can freely to return or not return an Echo reply, and the
Ingress LSR
should not expect there MUST be an Echo reply, but if there is one, it
should
handle it properly.

Is my understanding correct?

Thanks,
Mach




Re: A question about RFC5884

2017-07-16 Thread Reshad Rahman (rrahman)
Hi,

My take too is that the RFC is pretty clear that Echo reply from egress
LSR is not mandatory.

Regards,
Reshad.



On 2017-07-16, 4:29 PM, "Rtg-bfd on behalf of Mach Chen"
 wrote:

>Hi Ashesh,
>
>Thanks for your prompt response, we're on the same page!
>
>Best regards,
>Mach
>
>> -邮件原件-
>> 发件人: Ashesh Mishra [mailto:mishra.ash...@outlook.com]
>> 发送时间: 2017年7月16日 22:26
>> 收件人: Mach Chen
>> 抄送: rtg-bfd@ietf.org
>> 主题: Re: A question about RFC5884
>> 
>> That's how I read it ... assuming that proper handling of the LSR echo
>>includes
>> gracefully dropping it on rx.
>> 
>> Ashesh
>> 
>> On Jul 16, 2017, at 3:58 PM, Mach Chen  wrote:
>> 
>> Hi BFDers,
>> 
>> We met a multi-vendor interoperate issue recently, it's about whether
>>an Echo
>> reply is necessary.
>> 
>> In Section 6 of RFC5884, 2nd paragraph
>> 
>> "... The egress LSR MAY respond with an LSP Ping Echo
>>   reply message that carries the local discriminator assigned by it for
>>   the BFD session."
>> 
>> > From the above text, my understanding is that an Echo reply is
>>optional, the
>> egress LSR can freely to return or not return an Echo reply, and the
>>Ingress LSR
>> should not expect there MUST be an Echo reply, but if there is one, it
>>should
>> handle it properly.
>> 
>> Is my understanding correct?
>> 
>> Thanks,
>> Mach
>



Re: A question about RFC5884

2017-07-16 Thread Mach Chen
Hi Ashesh,

Thanks for your prompt response, we're on the same page!

Best regards,
Mach

> -邮件原件-
> 发件人: Ashesh Mishra [mailto:mishra.ash...@outlook.com]
> 发送时间: 2017年7月16日 22:26
> 收件人: Mach Chen
> 抄送: rtg-bfd@ietf.org
> 主题: Re: A question about RFC5884
> 
> That's how I read it ... assuming that proper handling of the LSR echo 
> includes
> gracefully dropping it on rx.
> 
> Ashesh
> 
> On Jul 16, 2017, at 3:58 PM, Mach Chen  wrote:
> 
> Hi BFDers,
> 
> We met a multi-vendor interoperate issue recently, it's about whether an Echo
> reply is necessary.
> 
> In Section 6 of RFC5884, 2nd paragraph
> 
> "... The egress LSR MAY respond with an LSP Ping Echo
>   reply message that carries the local discriminator assigned by it for
>   the BFD session."
> 
> > From the above text, my understanding is that an Echo reply is optional, the
> egress LSR can freely to return or not return an Echo reply, and the Ingress 
> LSR
> should not expect there MUST be an Echo reply, but if there is one, it should
> handle it properly.
> 
> Is my understanding correct?
> 
> Thanks,
> Mach



Re: A question about RFC5884

2017-07-16 Thread Ashesh Mishra
That's how I read it ... assuming that proper handling of the LSR echo includes 
gracefully dropping it on rx. 

Ashesh

On Jul 16, 2017, at 3:58 PM, Mach Chen  wrote:

Hi BFDers,

We met a multi-vendor interoperate issue recently, it's about whether an Echo 
reply is necessary.

In Section 6 of RFC5884, 2nd paragraph

"... The egress LSR MAY respond with an LSP Ping Echo
  reply message that carries the local discriminator assigned by it for
  the BFD session."

> From the above text, my understanding is that an Echo reply is optional, the 
> egress LSR can freely to return or not return an Echo reply, and the Ingress 
> LSR should not expect there MUST be an Echo reply, but if there is one, it 
> should handle it properly.

Is my understanding correct? 

Thanks,
Mach