Re: WG Adoption request for draft-mirsky-bfd-mpls-demand

[Greg Mirsky]

Dear Jeff, Reshad, et al.,
after more discussions and analyzing our discussion I'm accepting your
arguments regarding that the behavior of a system in the Demand mode
already sufficiently covered in RFC 5880. What I'd like us to discuss is
the note by Jeff:

If you're also saying that the ingress is NOT receiving a Down state change
from the egress as part of this and that the ingress moves to down just
because the Diag changes, that at least is clear, and is worth further
discussion.


Much appreciate your consideration and advise on how to proceed further.

Regards,
Greg

On Mon, Feb 25, 2019 at 6:26 PM Jeffrey Haas  wrote:

> On Mon, Feb 25, 2019 at 09:10:16AM -0800, Greg Mirsky wrote:
> > Hi Jeff,
> > please find my answers in-line tagged GIM4>>.
> >
> > Regards,
> > Greg
> >
> > On Sun, Feb 24, 2019 at 7:24 PM Jeffrey Haas  wrote:
> >
> > > Greg,
> > >
> > > On Sun, Feb 24, 2019 at 09:53:20AM -0800, Greg Mirsky wrote:
> > > > Hi Jeff,
> > > > I'm glad that you feel that our discussion is helpful. I want to
> point
> > > that
> > > > the use of the Poll sequence to communicate to the remote BFD system
> in
> > > the
> > > > Concatenated Paths section is to relay the failure detected in the
> > > > downstream segment of the multi-segment OAM domain. Also, section
> 6.8.17
> > > > does not specify how the upstream BFD system responds to the
> situation:
> > > >Note that if the BFD session subsequently fails, the diagnostic
> code
> > > will
> > > >be overwritten with a code detailing the cause of the failure.
> It is
> > > >up to the interworking agent to perform the above procedure again,
> > > >once the BFD session reaches Up state, if the propagation of the
> > > >concatenated path failure is to resume.
> > >
> > > Correct.  That is up to the upstream to determine its behavior.
> > >
> > > > And so far we were discussing RFC 5880 though the scope of the draft
> is
> > > on
> > > > the use of Demand mode over MPLS LSP.
> > >
> > > MPLS does not magically change the behavior of demand mode specified
> in the
> > > core RFC.
> > >
> > GIM4>> The draft defines how the head-end LER reacts to receiving the BFD
> > control message with Diag set to Control Detection Time Expired and the
> > Poll flag set:
> >Reception of such BFD control packet by the ingress
> >LER indicates that the monitored LSP has a failure and sending BFD
> >control packet with the Final flag set to acknowledge failure
> >indication is likely to fail.  Instead, the ingress LER transmits the
> >BFD Control packet to the egress LER over the IP network with:
> >
> >o  destination IP address MUST be set to the destination IP address
> >   of the LSP Ping Echo request message [RFC8029];
> >
> >o  destination UDP port set to 4784 [RFC5883];
> >
> >o  Final (F) flag in BFD control packet MUST be set;
> >
> >o  Demand (D) flag in BFD control packet MUST be cleared.
> >
> >The ingress LER changes the state of the BFD session to Down and
> >changes rate of BFD Control packets transmission to one packet per
> >second.  The ingress LER in Down mode changes to Asynchronous mode
> >until the BFD session comes to Up state once again.  Then the ingress
> >LER switches to the Demand mode.
> >
> >
> > > > And the draft does describe how the
> > > > BFD system acts after it receives the control message with Diag
> field set
> > > > to Control Detection Time Expired, a.k.a. RDI, and the Poll flag
> set. In
> > > > that, I consider, the draft is complimentary to RFC 5884 whose scope
> is
> > > on
> > > > the Asynchronous mode only.
> > >
> > > I continue to have problems understanding how the text in your draft is
> > > intended to be different than 6.8.4 of RFC 5880.  Simply saying "we're
> > > allowed to use demand mode" can't be it?
> > >
> > GIM4>> Section 6.8.4 does not specify that if the BFD system is in Demand
> > mode and the bfd.LocalDiag is set to 1 (Control Detection Time Expired)
> the
> > Poll sequence MAY, SHOULD or MUST be used to notify the remote BFD
> system.
>
> I shall paste this one last time:
>
> :   If Demand mode is active on either or both systems, a Poll Sequence
> :   MUST be initiated whenever the contents of the next BFD Control
> :   packet to be sent would be different than the contents of the
> :   previous packet, with the exception of the Poll (P) and Final (F)
> :   bits.  This ensures that parameter changes are transmitted to the
> :   remote system and that the remote system acknowledges these changes.
>
> If you've changed diag, you've changed the contents.  If you are running in
> demand mode, you will send a poll.
>
> If you're also saying that the ingress is NOT receiving a Down state change
> from the egress as part of this and that the ingress moves to down just
> because the Diag changes, that at least is clear, and is worth further
> discussion.
>
> > > It will help clear this conversation if you simply state your changes
> in
> > > 

Re: WG Adoption request for draft-mirsky-bfd-mpls-demand

[Greg Mirsky]

Hi Reshad,
thank you for sharing your views. Please find my notes in-line tagged
GIM7>>.

Regards,
Greg

On Mon, Feb 25, 2019 at 7:01 PM Reshad Rahman (rrahman) 
wrote:

> Hi Greg,
>
>
>
> Please see inline.
>
>
>
> *From: *Rtg-bfd  on behalf of Greg Mirsky <
> gregimir...@gmail.com>
> *Date: *Monday, February 25, 2019 at 1:40 PM
> *To: *Jeffrey Haas 
> *Cc: *"Reshad Rahman (rrahman)" , "rtg-bfd@ietf.org" <
> rtg-bfd@ietf.org>
> *Subject: *Re: WG Adoption request for draft-mirsky-bfd-mpls-demand
>
>
>
> Hi Jeff,
>
> now with GIM6>>.
>
>
>
> Regards,
>
> Greg
>
>
>
> On Mon, Feb 25, 2019 at 9:26 AM Jeffrey Haas  wrote:
>
> On Mon, Feb 25, 2019 at 09:10:16AM -0800, Greg Mirsky wrote:
> > Hi Jeff,
> > please find my answers in-line tagged GIM4>>.
> >
> > Regards,
> > Greg
> >
> > On Sun, Feb 24, 2019 at 7:24 PM Jeffrey Haas  wrote:
> >
> > > Greg,
> > >
> > > On Sun, Feb 24, 2019 at 09:53:20AM -0800, Greg Mirsky wrote:
> > > > Hi Jeff,
> > > > I'm glad that you feel that our discussion is helpful. I want to
> point
> > > that
> > > > the use of the Poll sequence to communicate to the remote BFD system
> in
> > > the
> > > > Concatenated Paths section is to relay the failure detected in the
> > > > downstream segment of the multi-segment OAM domain. Also, section
> 6.8.17
> > > > does not specify how the upstream BFD system responds to the
> situation:
> > > >Note that if the BFD session subsequently fails, the diagnostic
> code
> > > will
> > > >be overwritten with a code detailing the cause of the failure.
> It is
> > > >up to the interworking agent to perform the above procedure again,
> > > >once the BFD session reaches Up state, if the propagation of the
> > > >concatenated path failure is to resume.
> > >
> > > Correct.  That is up to the upstream to determine its behavior.
> > >
> > > > And so far we were discussing RFC 5880 though the scope of the draft
> is
> > > on
> > > > the use of Demand mode over MPLS LSP.
> > >
> > > MPLS does not magically change the behavior of demand mode specified
> in the
> > > core RFC.
> > >
> > GIM4>> The draft defines how the head-end LER reacts to receiving the BFD
> > control message with Diag set to Control Detection Time Expired and the
> > Poll flag set:
> >Reception of such BFD control packet by the ingress
> >LER indicates that the monitored LSP has a failure and sending BFD
> >control packet with the Final flag set to acknowledge failure
> >indication is likely to fail.  Instead, the ingress LER transmits the
> >BFD Control packet to the egress LER over the IP network with:
> >
> >o  destination IP address MUST be set to the destination IP address
> >   of the LSP Ping Echo request message [RFC8029];
> >
> >o  destination UDP port set to 4784 [RFC5883];
> >
> >o  Final (F) flag in BFD control packet MUST be set;
> >
> >o  Demand (D) flag in BFD control packet MUST be cleared.
> >
> >The ingress LER changes the state of the BFD session to Down and
> >changes rate of BFD Control packets transmission to one packet per
> >second.  The ingress LER in Down mode changes to Asynchronous mode
> >until the BFD session comes to Up state once again.  Then the ingress
> >LER switches to the Demand mode.
> >
> >
> > > > And the draft does describe how the
> > > > BFD system acts after it receives the control message with Diag
> field set
> > > > to Control Detection Time Expired, a.k.a. RDI, and the Poll flag
> set. In
> > > > that, I consider, the draft is complimentary to RFC 5884 whose scope
> is
> > > on
> > > > the Asynchronous mode only.
> > >
> > > I continue to have problems understanding how the text in your draft is
> > > intended to be different than 6.8.4 of RFC 5880.  Simply saying "we're
> > > allowed to use demand mode" can't be it?
> > >
> > GIM4>> Section 6.8.4 does not specify that if the BFD system is in Demand
> > mode and the bfd.LocalDiag is set to 1 (Control Detection Time Expired)
> the
> > Poll sequence MAY, SHOULD or MUST be used to notify the remote BFD
> system.
>
> I shall paste this one last time:
>
> :   If Demand mode is active on 

Re: WG Adoption request for draft-mirsky-bfd-mpls-demand

[Reshad Rahman (rrahman)]

Hi Greg,

Please see inline.

From: Rtg-bfd  on behalf of Greg Mirsky 

Date: Monday, February 25, 2019 at 1:40 PM
To: Jeffrey Haas 
Cc: "Reshad Rahman (rrahman)" , "rtg-bfd@ietf.org" 

Subject: Re: WG Adoption request for draft-mirsky-bfd-mpls-demand

Hi Jeff,
now with GIM6>>.

Regards,
Greg

On Mon, Feb 25, 2019 at 9:26 AM Jeffrey Haas 
mailto:jh...@pfrc.org>> wrote:
On Mon, Feb 25, 2019 at 09:10:16AM -0800, Greg Mirsky wrote:
> Hi Jeff,
> please find my answers in-line tagged GIM4>>.
>
> Regards,
> Greg
>
> On Sun, Feb 24, 2019 at 7:24 PM Jeffrey Haas 
> mailto:jh...@pfrc.org>> wrote:
>
> > Greg,
> >
> > On Sun, Feb 24, 2019 at 09:53:20AM -0800, Greg Mirsky wrote:
> > > Hi Jeff,
> > > I'm glad that you feel that our discussion is helpful. I want to point
> > that
> > > the use of the Poll sequence to communicate to the remote BFD system in
> > the
> > > Concatenated Paths section is to relay the failure detected in the
> > > downstream segment of the multi-segment OAM domain. Also, section 6.8.17
> > > does not specify how the upstream BFD system responds to the situation:
> > >Note that if the BFD session subsequently fails, the diagnostic code
> > will
> > >be overwritten with a code detailing the cause of the failure.  It is
> > >up to the interworking agent to perform the above procedure again,
> > >once the BFD session reaches Up state, if the propagation of the
> > >concatenated path failure is to resume.
> >
> > Correct.  That is up to the upstream to determine its behavior.
> >
> > > And so far we were discussing RFC 5880 though the scope of the draft is
> > on
> > > the use of Demand mode over MPLS LSP.
> >
> > MPLS does not magically change the behavior of demand mode specified in the
> > core RFC.
> >
> GIM4>> The draft defines how the head-end LER reacts to receiving the BFD
> control message with Diag set to Control Detection Time Expired and the
> Poll flag set:
>Reception of such BFD control packet by the ingress
>LER indicates that the monitored LSP has a failure and sending BFD
>control packet with the Final flag set to acknowledge failure
>indication is likely to fail.  Instead, the ingress LER transmits the
>BFD Control packet to the egress LER over the IP network with:
>
>o  destination IP address MUST be set to the destination IP address
>   of the LSP Ping Echo request message [RFC8029];
>
>o  destination UDP port set to 4784 [RFC5883];
>
>o  Final (F) flag in BFD control packet MUST be set;
>
>o  Demand (D) flag in BFD control packet MUST be cleared.
>
>The ingress LER changes the state of the BFD session to Down and
>changes rate of BFD Control packets transmission to one packet per
>second.  The ingress LER in Down mode changes to Asynchronous mode
>until the BFD session comes to Up state once again.  Then the ingress
>LER switches to the Demand mode.
>
>
> > > And the draft does describe how the
> > > BFD system acts after it receives the control message with Diag field set
> > > to Control Detection Time Expired, a.k.a. RDI, and the Poll flag set. In
> > > that, I consider, the draft is complimentary to RFC 5884 whose scope is
> > on
> > > the Asynchronous mode only.
> >
> > I continue to have problems understanding how the text in your draft is
> > intended to be different than 6.8.4 of RFC 5880.  Simply saying "we're
> > allowed to use demand mode" can't be it?
> >
> GIM4>> Section 6.8.4 does not specify that if the BFD system is in Demand
> mode and the bfd.LocalDiag is set to 1 (Control Detection Time Expired) the
> Poll sequence MAY, SHOULD or MUST be used to notify the remote BFD system.

I shall paste this one last time:

:   If Demand mode is active on either or both systems, a Poll Sequence
:   MUST be initiated whenever the contents of the next BFD Control
:   packet to be sent would be different than the contents of the
:   previous packet, with the exception of the Poll (P) and Final (F)
:   bits.  This ensures that parameter changes are transmitted to the
:   remote system and that the remote system acknowledges these changes.
GIM6>> RFC 5880 uses the term "parameter" in relation to the timers, and most 
are in section 6.8.3. The Diag field is defined not a parameter of a BFD 
session but as:
  A diagnostic code specifying the local system's reason for the
  last change in session state.
 Use of the term “parameter” is indeed not very clear, elsewhere in 5880 
“timing parameters” and “timer

Re: WG Adoption request for draft-mirsky-bfd-mpls-demand

[Greg Mirsky]

Hi Jeff,
now with GIM6>>.

Regards,
Greg

On Mon, Feb 25, 2019 at 9:26 AM Jeffrey Haas  wrote:

> On Mon, Feb 25, 2019 at 09:10:16AM -0800, Greg Mirsky wrote:
> > Hi Jeff,
> > please find my answers in-line tagged GIM4>>.
> >
> > Regards,
> > Greg
> >
> > On Sun, Feb 24, 2019 at 7:24 PM Jeffrey Haas  wrote:
> >
> > > Greg,
> > >
> > > On Sun, Feb 24, 2019 at 09:53:20AM -0800, Greg Mirsky wrote:
> > > > Hi Jeff,
> > > > I'm glad that you feel that our discussion is helpful. I want to
> point
> > > that
> > > > the use of the Poll sequence to communicate to the remote BFD system
> in
> > > the
> > > > Concatenated Paths section is to relay the failure detected in the
> > > > downstream segment of the multi-segment OAM domain. Also, section
> 6.8.17
> > > > does not specify how the upstream BFD system responds to the
> situation:
> > > >Note that if the BFD session subsequently fails, the diagnostic
> code
> > > will
> > > >be overwritten with a code detailing the cause of the failure.
> It is
> > > >up to the interworking agent to perform the above procedure again,
> > > >once the BFD session reaches Up state, if the propagation of the
> > > >concatenated path failure is to resume.
> > >
> > > Correct.  That is up to the upstream to determine its behavior.
> > >
> > > > And so far we were discussing RFC 5880 though the scope of the draft
> is
> > > on
> > > > the use of Demand mode over MPLS LSP.
> > >
> > > MPLS does not magically change the behavior of demand mode specified
> in the
> > > core RFC.
> > >
> > GIM4>> The draft defines how the head-end LER reacts to receiving the BFD
> > control message with Diag set to Control Detection Time Expired and the
> > Poll flag set:
> >Reception of such BFD control packet by the ingress
> >LER indicates that the monitored LSP has a failure and sending BFD
> >control packet with the Final flag set to acknowledge failure
> >indication is likely to fail.  Instead, the ingress LER transmits the
> >BFD Control packet to the egress LER over the IP network with:
> >
> >o  destination IP address MUST be set to the destination IP address
> >   of the LSP Ping Echo request message [RFC8029];
> >
> >o  destination UDP port set to 4784 [RFC5883];
> >
> >o  Final (F) flag in BFD control packet MUST be set;
> >
> >o  Demand (D) flag in BFD control packet MUST be cleared.
> >
> >The ingress LER changes the state of the BFD session to Down and
> >changes rate of BFD Control packets transmission to one packet per
> >second.  The ingress LER in Down mode changes to Asynchronous mode
> >until the BFD session comes to Up state once again.  Then the ingress
> >LER switches to the Demand mode.
> >
> >
> > > > And the draft does describe how the
> > > > BFD system acts after it receives the control message with Diag
> field set
> > > > to Control Detection Time Expired, a.k.a. RDI, and the Poll flag
> set. In
> > > > that, I consider, the draft is complimentary to RFC 5884 whose scope
> is
> > > on
> > > > the Asynchronous mode only.
> > >
> > > I continue to have problems understanding how the text in your draft is
> > > intended to be different than 6.8.4 of RFC 5880.  Simply saying "we're
> > > allowed to use demand mode" can't be it?
> > >
> > GIM4>> Section 6.8.4 does not specify that if the BFD system is in Demand
> > mode and the bfd.LocalDiag is set to 1 (Control Detection Time Expired)
> the
> > Poll sequence MAY, SHOULD or MUST be used to notify the remote BFD
> system.
>
> I shall paste this one last time:
>
> :   If Demand mode is active on either or both systems, a Poll Sequence
> :   MUST be initiated whenever the contents of the next BFD Control
> :   packet to be sent would be different than the contents of the
> :   previous packet, with the exception of the Poll (P) and Final (F)
> :   bits.  This ensures that parameter changes are transmitted to the
> :   remote system and that the remote system acknowledges these changes.
>
> GIM6>> RFC 5880 uses the term "parameter" in relation to the timers, and
most are in section 6.8.3. The Diag field is defined not a parameter of a
BFD session but as:
  A diagnostic code specifying the local system's reason for the
  last change in session state.

If you've changed diag, you've changed the contents.  If you are running in
> demand mode, you will send a poll.
>
GIM6>> If the interpretation of RFC 5880 is as you're suggesting, then
draft-ietf-bfd-multipoint must be updated to the fact that when a
MultipointTail detects that Control Detection Time Expired it MUST initiate
the Poll sequence to the MultipointHead. And
draft-ietf-bfd-multipoint-active-tail seems unnecessary as the same
functionality ensured by the previously mentioned update.

>
> If you're also saying that the ingress is NOT receiving a Down state change
> from the egress as part of this and that the ingress moves to down just
> because the Diag changes, that at least is clear, and

Re: WG Adoption request for draft-mirsky-bfd-mpls-demand

[Jeffrey Haas]

On Mon, Feb 25, 2019 at 09:10:16AM -0800, Greg Mirsky wrote:
> Hi Jeff,
> please find my answers in-line tagged GIM4>>.
> 
> Regards,
> Greg
> 
> On Sun, Feb 24, 2019 at 7:24 PM Jeffrey Haas  wrote:
> 
> > Greg,
> >
> > On Sun, Feb 24, 2019 at 09:53:20AM -0800, Greg Mirsky wrote:
> > > Hi Jeff,
> > > I'm glad that you feel that our discussion is helpful. I want to point
> > that
> > > the use of the Poll sequence to communicate to the remote BFD system in
> > the
> > > Concatenated Paths section is to relay the failure detected in the
> > > downstream segment of the multi-segment OAM domain. Also, section 6.8.17
> > > does not specify how the upstream BFD system responds to the situation:
> > >Note that if the BFD session subsequently fails, the diagnostic code
> > will
> > >be overwritten with a code detailing the cause of the failure.  It is
> > >up to the interworking agent to perform the above procedure again,
> > >once the BFD session reaches Up state, if the propagation of the
> > >concatenated path failure is to resume.
> >
> > Correct.  That is up to the upstream to determine its behavior.
> >
> > > And so far we were discussing RFC 5880 though the scope of the draft is
> > on
> > > the use of Demand mode over MPLS LSP.
> >
> > MPLS does not magically change the behavior of demand mode specified in the
> > core RFC.
> >
> GIM4>> The draft defines how the head-end LER reacts to receiving the BFD
> control message with Diag set to Control Detection Time Expired and the
> Poll flag set:
>Reception of such BFD control packet by the ingress
>LER indicates that the monitored LSP has a failure and sending BFD
>control packet with the Final flag set to acknowledge failure
>indication is likely to fail.  Instead, the ingress LER transmits the
>BFD Control packet to the egress LER over the IP network with:
> 
>o  destination IP address MUST be set to the destination IP address
>   of the LSP Ping Echo request message [RFC8029];
> 
>o  destination UDP port set to 4784 [RFC5883];
> 
>o  Final (F) flag in BFD control packet MUST be set;
> 
>o  Demand (D) flag in BFD control packet MUST be cleared.
> 
>The ingress LER changes the state of the BFD session to Down and
>changes rate of BFD Control packets transmission to one packet per
>second.  The ingress LER in Down mode changes to Asynchronous mode
>until the BFD session comes to Up state once again.  Then the ingress
>LER switches to the Demand mode.
> 
> 
> > > And the draft does describe how the
> > > BFD system acts after it receives the control message with Diag field set
> > > to Control Detection Time Expired, a.k.a. RDI, and the Poll flag set. In
> > > that, I consider, the draft is complimentary to RFC 5884 whose scope is
> > on
> > > the Asynchronous mode only.
> >
> > I continue to have problems understanding how the text in your draft is
> > intended to be different than 6.8.4 of RFC 5880.  Simply saying "we're
> > allowed to use demand mode" can't be it?
> >
> GIM4>> Section 6.8.4 does not specify that if the BFD system is in Demand
> mode and the bfd.LocalDiag is set to 1 (Control Detection Time Expired) the
> Poll sequence MAY, SHOULD or MUST be used to notify the remote BFD system.

I shall paste this one last time:

:   If Demand mode is active on either or both systems, a Poll Sequence
:   MUST be initiated whenever the contents of the next BFD Control
:   packet to be sent would be different than the contents of the
:   previous packet, with the exception of the Poll (P) and Final (F)
:   bits.  This ensures that parameter changes are transmitted to the
:   remote system and that the remote system acknowledges these changes.

If you've changed diag, you've changed the contents.  If you are running in
demand mode, you will send a poll.

If you're also saying that the ingress is NOT receiving a Down state change
from the egress as part of this and that the ingress moves to down just
because the Diag changes, that at least is clear, and is worth further
discussion.

> > It will help clear this conversation if you simply state your changes in
> > behavior vs. 5880 and 5884.
> >
> GIM4>> I've never stated or hinted that the draft is to update RFC 5884.
> The scope of RFC 5884 is the use of BFD in the Asynchronous mode over MPLS
> LSPs. As stated in section 6 RFC 5884:
> 
> BFD demand mode is outside the scope of this specification.

You seem to be confused about how this boilerplate text is used.

If there are no changes to procedure, existing procedure applies - it is
simply not discussed in this document.

If there is changes to procedure (what we are trying to determine), then
further discussion is warranted.

> > A reminder that we don't vote.  C.f. RFC 7282, section 6.
> >
> GIM4>> I'm confused to differentiate when you raise the objection as the
> individual contributor and evaluate them and the consensus as the WG chair.

Chairs are not prohibited from offering 

Re: WG Adoption request for draft-mirsky-bfd-mpls-demand

[Greg Mirsky]

Hi Jeff,
please find my answers in-line tagged GIM4>>.

Regards,
Greg

On Sun, Feb 24, 2019 at 7:24 PM Jeffrey Haas  wrote:

> Greg,
>
> On Sun, Feb 24, 2019 at 09:53:20AM -0800, Greg Mirsky wrote:
> > Hi Jeff,
> > I'm glad that you feel that our discussion is helpful. I want to point
> that
> > the use of the Poll sequence to communicate to the remote BFD system in
> the
> > Concatenated Paths section is to relay the failure detected in the
> > downstream segment of the multi-segment OAM domain. Also, section 6.8.17
> > does not specify how the upstream BFD system responds to the situation:
> >Note that if the BFD session subsequently fails, the diagnostic code
> will
> >be overwritten with a code detailing the cause of the failure.  It is
> >up to the interworking agent to perform the above procedure again,
> >once the BFD session reaches Up state, if the propagation of the
> >concatenated path failure is to resume.
>
> Correct.  That is up to the upstream to determine its behavior.
>
> > And so far we were discussing RFC 5880 though the scope of the draft is
> on
> > the use of Demand mode over MPLS LSP.
>
> MPLS does not magically change the behavior of demand mode specified in the
> core RFC.
>
GIM4>> The draft defines how the head-end LER reacts to receiving the BFD
control message with Diag set to Control Detection Time Expired and the
Poll flag set:
   Reception of such BFD control packet by the ingress
   LER indicates that the monitored LSP has a failure and sending BFD
   control packet with the Final flag set to acknowledge failure
   indication is likely to fail.  Instead, the ingress LER transmits the
   BFD Control packet to the egress LER over the IP network with:

   o  destination IP address MUST be set to the destination IP address
  of the LSP Ping Echo request message [RFC8029];

   o  destination UDP port set to 4784 [RFC5883];

   o  Final (F) flag in BFD control packet MUST be set;

   o  Demand (D) flag in BFD control packet MUST be cleared.

   The ingress LER changes the state of the BFD session to Down and
   changes rate of BFD Control packets transmission to one packet per
   second.  The ingress LER in Down mode changes to Asynchronous mode
   until the BFD session comes to Up state once again.  Then the ingress
   LER switches to the Demand mode.


> > And the draft does describe how the
> > BFD system acts after it receives the control message with Diag field set
> > to Control Detection Time Expired, a.k.a. RDI, and the Poll flag set. In
> > that, I consider, the draft is complimentary to RFC 5884 whose scope is
> on
> > the Asynchronous mode only.
>
> I continue to have problems understanding how the text in your draft is
> intended to be different than 6.8.4 of RFC 5880.  Simply saying "we're
> allowed to use demand mode" can't be it?
>
GIM4>> Section 6.8.4 does not specify that if the BFD system is in Demand
mode and the bfd.LocalDiag is set to 1 (Control Detection Time Expired) the
Poll sequence MAY, SHOULD or MUST be used to notify the remote BFD system.

>
> It will help clear this conversation if you simply state your changes in
> behavior vs. 5880 and 5884.
>
GIM4>> I've never stated or hinted that the draft is to update RFC 5884.
The scope of RFC 5884 is the use of BFD in the Asynchronous mode over MPLS
LSPs. As stated in section 6 RFC 5884:

BFD demand mode is outside the scope of this specification.


> > I believe that the draft addresses practical scenario with the technical
> > and innovative solution. And it was recognized as such by several WG
> > participants during the WG AP. Much appreciate your consideration.
>
> A reminder that we don't vote.  C.f. RFC 7282, section 6.
>
GIM4>> I'm confused to differentiate when you raise the objection as the
individual contributor and evaluate them and the consensus as the WG chair.

>
> -- Jeff
>
>

Re: WG Adoption request for draft-mirsky-bfd-mpls-demand

[Jeffrey Haas]

Greg,

On Sun, Feb 24, 2019 at 09:53:20AM -0800, Greg Mirsky wrote:
> Hi Jeff,
> I'm glad that you feel that our discussion is helpful. I want to point that
> the use of the Poll sequence to communicate to the remote BFD system in the
> Concatenated Paths section is to relay the failure detected in the
> downstream segment of the multi-segment OAM domain. Also, section 6.8.17
> does not specify how the upstream BFD system responds to the situation:
>Note that if the BFD session subsequently fails, the diagnostic code will
>be overwritten with a code detailing the cause of the failure.  It is
>up to the interworking agent to perform the above procedure again,
>once the BFD session reaches Up state, if the propagation of the
>concatenated path failure is to resume.

Correct.  That is up to the upstream to determine its behavior.

> And so far we were discussing RFC 5880 though the scope of the draft is on
> the use of Demand mode over MPLS LSP.

MPLS does not magically change the behavior of demand mode specified in the
core RFC.

> And the draft does describe how the
> BFD system acts after it receives the control message with Diag field set
> to Control Detection Time Expired, a.k.a. RDI, and the Poll flag set. In
> that, I consider, the draft is complimentary to RFC 5884 whose scope is on
> the Asynchronous mode only.

I continue to have problems understanding how the text in your draft is
intended to be different than 6.8.4 of RFC 5880.  Simply saying "we're
allowed to use demand mode" can't be it?

It will help clear this conversation if you simply state your changes in
behavior vs. 5880 and 5884. 

> I believe that the draft addresses practical scenario with the technical
> and innovative solution. And it was recognized as such by several WG
> participants during the WG AP. Much appreciate your consideration.

A reminder that we don't vote.  C.f. RFC 7282, section 6.

-- Jeff

Re: WG Adoption request for draft-mirsky-bfd-mpls-demand

[Greg Mirsky]

Hi Jeff,
I'm glad that you feel that our discussion is helpful. I want to point that
the use of the Poll sequence to communicate to the remote BFD system in the
Concatenated Paths section is to relay the failure detected in the
downstream segment of the multi-segment OAM domain. Also, section 6.8.17
does not specify how the upstream BFD system responds to the situation:
   Note that if the BFD session subsequently fails, the diagnostic code will
   be overwritten with a code detailing the cause of the failure.  It is
   up to the interworking agent to perform the above procedure again,
   once the BFD session reaches Up state, if the propagation of the
   concatenated path failure is to resume.
And so far we were discussing RFC 5880 though the scope of the draft is on
the use of Demand mode over MPLS LSP. And the draft does describe how the
BFD system acts after it receives the control message with Diag field set
to Control Detection Time Expired, a.k.a. RDI, and the Poll flag set. In
that, I consider, the draft is complimentary to RFC 5884 whose scope is on
the Asynchronous mode only.

I believe that the draft addresses practical scenario with the technical
and innovative solution. And it was recognized as such by several WG
participants during the WG AP. Much appreciate your consideration.

Regards,
Greg


On Tue, Feb 19, 2019 at 8:44 PM Jeffrey Haas  wrote:

> Greg,
>
> We seem now to be converging on the substance of your draft.  Thanks for
> sticking with this.
>
> On Tue, Feb 19, 2019 at 03:59:36PM -0800, Greg Mirsky wrote:
> > thank you for pointing to the sloppy terminology I've used referring to
> > what is the proposed update to RFC 5880. In fact, the draft, as I should
> > have done too, refers to the Diag field. Below are quotes from RFC 5880
> to
> > help me explain the intended update:
> >
> >- is section 6.1 Poll sequence in Demand mode MAY be used by any peer
> to
> >verify the bidirectional path continuity (connectivity):
> >
> >If either system wishes to verify
> >bidirectional connectivity, it can initiate a short exchange of BFD
> >Control packets (a "Poll Sequence"; see section 6.5) to do so.
> >
> >- similarly, the first paragraph in section 6.5:
> >
> >A Poll Sequence is an exchange of BFD Control packets that is used in
> >some circumstances to ensure that the remote system is aware of
> >parameter changes.  It is also used in Demand mode (see section 6.6)
> >to validate bidirectional connectivity.
> > Again, no reference that the Poll sequence MAY be used to signal the
> change
> > in the Diag field.
> >
> >- And the very last sentence of section 6.6:
> >
> >Resolving the issue of one system requesting Demand
> >mode while the other requires continuous bidirectional connectivity
> >verification is outside the scope of this specification.
> > Is what is in the scope of the draft we discuss. (Apologies for taking
> too
> > much time to find the right text in RFC 5880.)
>
> I think we're still in the scope of what 5880 permits.
>
> Consider the following:
> :6.8.17.  Concatenated Paths
> :
> :   If the path being monitored by BFD is concatenated with other paths
> :   (connected end-to-end in series), it may be desirable to propagate
> :   the indication of a failure of one of those paths across the BFD
> :   session (providing an interworking function for liveness monitoring
> :   between BFD and other technologies).
> :
> [...]
> :
> :   A system MAY signal one of these failure states by simply setting
> :   bfd.LocalDiag to the appropriate diagnostic code.  Note that the BFD
> :   session is not taken down.  If Demand mode is not active on the
> :   remote system, no other action is necessary, as the diagnostic code
> :   will be carried via the periodic transmission of BFD Control packets.
> :   If Demand mode is active on the remote system (the local system is
> :   not transmitting periodic BFD Control packets), a Poll Sequence MUST
> :   be initiated to ensure that the diagnostic code is transmitted.  Note
> :   that if the BFD session subsequently fails, the diagnostic code will
> :   be overwritten with a code detailing the cause of the failure.  It is
> :   up to the interworking agent to perform the above procedure again,
> :   once the BFD session reaches Up state, if the propagation of the
> :   concatenated path failure is to resume.
>
>
> We thus see here:
> 1. You can propagate state, perhaps your RDI, in a session that is Up.
> 2. If we are in demand mode, by initiating the poll sequence.
>
> Your point about 6.6 and asymmetric configuration of demand mode perhaps
> should be considered in the context of the word "bidirectional".  In a
> profile where we have gone half duplex on the session (one side async
> continuous, other demand), we're likely in a mode where we mostly want
> unidirectional information.  This seems to be perhaps along the lines of
> what you're looking for.  And in such a case, shifting into 

Re: WG Adoption request for draft-mirsky-bfd-mpls-demand

[Jeffrey Haas]

Greg,

We seem now to be converging on the substance of your draft.  Thanks for
sticking with this.

On Tue, Feb 19, 2019 at 03:59:36PM -0800, Greg Mirsky wrote:
> thank you for pointing to the sloppy terminology I've used referring to
> what is the proposed update to RFC 5880. In fact, the draft, as I should
> have done too, refers to the Diag field. Below are quotes from RFC 5880 to
> help me explain the intended update:
> 
>- is section 6.1 Poll sequence in Demand mode MAY be used by any peer to
>verify the bidirectional path continuity (connectivity):
> 
>If either system wishes to verify
>bidirectional connectivity, it can initiate a short exchange of BFD
>Control packets (a "Poll Sequence"; see section 6.5) to do so.
> 
>- similarly, the first paragraph in section 6.5:
> 
>A Poll Sequence is an exchange of BFD Control packets that is used in
>some circumstances to ensure that the remote system is aware of
>parameter changes.  It is also used in Demand mode (see section 6.6)
>to validate bidirectional connectivity.
> Again, no reference that the Poll sequence MAY be used to signal the change
> in the Diag field.
> 
>- And the very last sentence of section 6.6:
> 
>Resolving the issue of one system requesting Demand
>mode while the other requires continuous bidirectional connectivity
>verification is outside the scope of this specification.
> Is what is in the scope of the draft we discuss. (Apologies for taking too
> much time to find the right text in RFC 5880.)

I think we're still in the scope of what 5880 permits.

Consider the following:
:6.8.17.  Concatenated Paths
:
:   If the path being monitored by BFD is concatenated with other paths
:   (connected end-to-end in series), it may be desirable to propagate
:   the indication of a failure of one of those paths across the BFD
:   session (providing an interworking function for liveness monitoring
:   between BFD and other technologies).
:
[...]
:
:   A system MAY signal one of these failure states by simply setting
:   bfd.LocalDiag to the appropriate diagnostic code.  Note that the BFD
:   session is not taken down.  If Demand mode is not active on the
:   remote system, no other action is necessary, as the diagnostic code
:   will be carried via the periodic transmission of BFD Control packets.
:   If Demand mode is active on the remote system (the local system is
:   not transmitting periodic BFD Control packets), a Poll Sequence MUST
:   be initiated to ensure that the diagnostic code is transmitted.  Note
:   that if the BFD session subsequently fails, the diagnostic code will
:   be overwritten with a code detailing the cause of the failure.  It is
:   up to the interworking agent to perform the above procedure again,
:   once the BFD session reaches Up state, if the propagation of the
:   concatenated path failure is to resume.


We thus see here:
1. You can propagate state, perhaps your RDI, in a session that is Up.
2. If we are in demand mode, by initiating the poll sequence.

Your point about 6.6 and asymmetric configuration of demand mode perhaps
should be considered in the context of the word "bidirectional".  In a
profile where we have gone half duplex on the session (one side async
continuous, other demand), we're likely in a mode where we mostly want
unidirectional information.  This seems to be perhaps along the lines of
what you're looking for.  And in such a case, shifting into the poll to pass
along RDI is perfectly reasonable.

If the above reflects a rough understanding of the use case, the core
content of your draft reduces to:
- RFC 5880 permits state, such as RDI, to be communicated on an Up session
  when in demand mode via a poll sequence in the Diag field.

-- Jeff

Re: WG Adoption request for draft-mirsky-bfd-mpls-demand

[Greg Mirsky]

Hi Jeff,
thank you for pointing to the sloppy terminology I've used referring to
what is the proposed update to RFC 5880. In fact, the draft, as I should
have done too, refers to the Diag field. Below are quotes from RFC 5880 to
help me explain the intended update:

   - is section 6.1 Poll sequence in Demand mode MAY be used by any peer to
   verify the bidirectional path continuity (connectivity):

   If either system wishes to verify
   bidirectional connectivity, it can initiate a short exchange of BFD
   Control packets (a "Poll Sequence"; see section 6.5) to do so.

   - similarly, the first paragraph in section 6.5:

   A Poll Sequence is an exchange of BFD Control packets that is used in
   some circumstances to ensure that the remote system is aware of
   parameter changes.  It is also used in Demand mode (see section 6.6)
   to validate bidirectional connectivity.
Again, no reference that the Poll sequence MAY be used to signal the change
in the Diag field.

   - And the very last sentence of section 6.6:

   Resolving the issue of one system requesting Demand
   mode while the other requires continuous bidirectional connectivity
   verification is outside the scope of this specification.
Is what is in the scope of the draft we discuss. (Apologies for taking too
much time to find the right text in RFC 5880.)

Regards,
Greg

On Tue, Feb 19, 2019 at 9:42 AM Jeffrey Haas  wrote:

> A reminder from 5880's state machine (6.8.6)
>
> :   Else
> [...]
> :   Else (bfd.SessionState is Up)
> :   If received State is Down
> :   Set bfd.LocalDiag to 3 (Neighbor signaled
> :   session down)
> :   Set bfd.SessionState to Down
> :
> :   Check to see if Demand mode should become active or not (see
> :   section 6.6).
>
> [...]
> :   If the Poll (P) bit is set, send a BFD Control packet to the
> :   remote system with the Poll (P) bit clear, and the Final (F) bit
> :   set (see section 6.8.7).
>
> A change of state doesn't need a poll sequence.
> A change of state is dealt with prior to considering demand mode
> considerations.
> Poll behavior is considered after both of these.
>
>
> On Mon, Feb 18, 2019 at 08:09:43PM -0800, Greg Mirsky wrote:
> > Hi Reshad,
> > thank you for your question. I've thought that it is the case but then
> have
> > asked why in draft-ietf-bfd-multipoint-active-tail the MultipointHead
> uses
> > a combination of multicast and unicast Poll sequences to verify whether
> the
> > particular MultipointTail considers the p2mp BFD session Up.
>
> Because tails are normally expected to be silent.  A core motivation of
> splitting the active tail procedures from the original draft is there are
> many applications where the head doesn't need or want the state from the
> tails.
>
> In cases where the head does care, the differing procedures attempts to
> determine a given tail's perception of the state.  A multipoint poll would
> determine if the tail is hearing the session via the multipoint BFD
> packets.
> In absence of that, unicast might be used, although it doesn't verify that
> multipoint connectivity is working.  Section 5 of the draft goes through
> the
> different scenarios.
>
> >  Would it be
> > simpler, assuming that the quote describes the same behavior as proposed
> in
> > the draft, to enable MultipointTail to send Poll sequence with RDI? Thus
> > I've concluded that RFC 5880 does not cover the scenario and have started
> > the draft.
>
> You keep on mentioning RDI.  Are you intending to have this in the context
> of RFC 6428?  If so, the discussion is really against the procedures in
> that
> RFC which are deviations from core RFC 5880/5884 behaviors.
>
> This is really the point lacking clarity.
>
> -- Jeff
>
>

Re: WG Adoption request for draft-mirsky-bfd-mpls-demand

[Jeffrey Haas]

A reminder from 5880's state machine (6.8.6)

:   Else
[...]
:   Else (bfd.SessionState is Up)
:   If received State is Down
:   Set bfd.LocalDiag to 3 (Neighbor signaled
:   session down)
:   Set bfd.SessionState to Down
: 
:   Check to see if Demand mode should become active or not (see
:   section 6.6).

[...]
:   If the Poll (P) bit is set, send a BFD Control packet to the
:   remote system with the Poll (P) bit clear, and the Final (F) bit
:   set (see section 6.8.7).

A change of state doesn't need a poll sequence.
A change of state is dealt with prior to considering demand mode
considerations.
Poll behavior is considered after both of these.


On Mon, Feb 18, 2019 at 08:09:43PM -0800, Greg Mirsky wrote:
> Hi Reshad,
> thank you for your question. I've thought that it is the case but then have
> asked why in draft-ietf-bfd-multipoint-active-tail the MultipointHead uses
> a combination of multicast and unicast Poll sequences to verify whether the
> particular MultipointTail considers the p2mp BFD session Up.

Because tails are normally expected to be silent.  A core motivation of
splitting the active tail procedures from the original draft is there are
many applications where the head doesn't need or want the state from the
tails.

In cases where the head does care, the differing procedures attempts to
determine a given tail's perception of the state.  A multipoint poll would
determine if the tail is hearing the session via the multipoint BFD packets.
In absence of that, unicast might be used, although it doesn't verify that
multipoint connectivity is working.  Section 5 of the draft goes through the
different scenarios.

>  Would it be
> simpler, assuming that the quote describes the same behavior as proposed in
> the draft, to enable MultipointTail to send Poll sequence with RDI? Thus
> I've concluded that RFC 5880 does not cover the scenario and have started
> the draft.

You keep on mentioning RDI.  Are you intending to have this in the context
of RFC 6428?  If so, the discussion is really against the procedures in that
RFC which are deviations from core RFC 5880/5884 behaviors.

This is really the point lacking clarity.

-- Jeff

Re: WG Adoption request for draft-mirsky-bfd-mpls-demand

[Greg Mirsky]

Hi Reshad,
thank you for your question. I've thought that it is the case but then have
asked why in draft-ietf-bfd-multipoint-active-tail the MultipointHead uses
a combination of multicast and unicast Poll sequences to verify whether the
particular MultipointTail considers the p2mp BFD session Up. Would it be
simpler, assuming that the quote describes the same behavior as proposed in
the draft, to enable MultipointTail to send Poll sequence with RDI? Thus
I've concluded that RFC 5880 does not cover the scenario and have started
the draft.

Regards,
Greg

On Mon, Feb 18, 2019 at 7:53 PM Reshad Rahman (rrahman) 
wrote:

> Hi Greg,
>
>
>
> So the text below is for what you had mentioned in a previous email: “The
> draft proposes to update RFC 5880 in regard to the behavior of BFD system
> in Demand mode so that such system MAY start Poll sequence to inform the
> remote BFD system of the change in BFD session state, i.e. signal RDI.” But
> isn’t that already covered in section 6.6
> <https://tools.ietf.org/html/rfc5880#section-6.6> of 5880?
>
>
>
>If Demand mode is active on either or both systems, a Poll Sequence
>
>MUST be initiated whenever the contents of the next BFD Control
>
>packet to be sent would be different than the contents of the
>
>previous packet, with the exception of the Poll (P) and Final (F)
>
>bits.  This ensures that parameter changes are transmitted to the
>
>remote system and that the remote system acknowledges these changes.
>
>
>
> Regards,
>
> Reshad (no hat).
>
>
>
> *From: *Greg Mirsky 
> *Date: *Monday, February 18, 2019 at 1:03 PM
> *To: *Jeffrey Haas 
> *Cc: *"Reshad Rahman (rrahman)" , Martin Vigoureux <
> martin.vigour...@nokia.com>, "rtg-bfd@ietf.org" 
> *Subject: *Re: WG Adoption request for draft-mirsky-bfd-mpls-demand
>
>
>
> Hi Jeff,
>
> here's the text from the draft that describes the behavior on the BFD
> system:
>
>If the Detection timer at the egress LER expires it MUST send BFD
>
>Control packet to the ingress LER with the Poll (P) bit set, Status
>
>(Sta) field set to Down value, and the Diagnostic (Diag) field set to
>
>Control Detection Time Expired value.  The egress LER sends these
>
>Control packets to the ingress LER at the rate of one per second
>
>until either it receives the valid for this BFD session control
>
>packet with the Final (F) bit set from the ingress LER or the defect
>
>condition clears and the BFD session state reaches Up state at the
>
>egress LER.
>
>
>
> Regards,
>
> Greg
>
>
>
> On Mon, Feb 18, 2019 at 9:34 AM Jeffrey Haas  wrote:
>
> On Mon, Feb 18, 2019 at 08:48:08AM -0800, Greg Mirsky wrote:
> > As for your question of what is the change proposed in the draft I'll
> point
> > to section 6.6 RFC 5880 that describes the Demand mode. It states that
> the
> > periodic transmission of control messages MUST be stopped.
>
> Correct.
>
> > The draft
> > defines, and that is what I consider the update to section 6.6, the
> > procedure by which the system in Demand mode initiates the Poll sequence
> to
> > inform the remote BFD system of RDI.
>
> Would you clarify where in your draft this is discussed?
>
> > Greg
>
> -- Jeff
>
>

Re: WG Adoption request for draft-mirsky-bfd-mpls-demand

[Reshad Rahman (rrahman)]

Hi Greg,

So the text below is for what you had mentioned in a previous email: “The draft 
proposes to update RFC 5880 in regard to the behavior of BFD system in Demand 
mode so that such system MAY start Poll sequence to inform the remote BFD 
system of the change in BFD session state, i.e. signal RDI.” But isn’t that 
already covered in section 6.6<https://tools.ietf.org/html/rfc5880#section-6.6> 
of 5880?


   If Demand mode is active on either or both systems, a Poll Sequence

   MUST be initiated whenever the contents of the next BFD Control

   packet to be sent would be different than the contents of the

   previous packet, with the exception of the Poll (P) and Final (F)

   bits.  This ensures that parameter changes are transmitted to the

   remote system and that the remote system acknowledges these changes.

Regards,
Reshad (no hat).

From: Greg Mirsky 
Date: Monday, February 18, 2019 at 1:03 PM
To: Jeffrey Haas 
Cc: "Reshad Rahman (rrahman)" , Martin Vigoureux 
, "rtg-bfd@ietf.org" 
Subject: Re: WG Adoption request for draft-mirsky-bfd-mpls-demand

Hi Jeff,
here's the text from the draft that describes the behavior on the BFD system:
   If the Detection timer at the egress LER expires it MUST send BFD
   Control packet to the ingress LER with the Poll (P) bit set, Status
   (Sta) field set to Down value, and the Diagnostic (Diag) field set to
   Control Detection Time Expired value.  The egress LER sends these
   Control packets to the ingress LER at the rate of one per second
   until either it receives the valid for this BFD session control
   packet with the Final (F) bit set from the ingress LER or the defect
   condition clears and the BFD session state reaches Up state at the
   egress LER.

Regards,
Greg

On Mon, Feb 18, 2019 at 9:34 AM Jeffrey Haas 
mailto:jh...@pfrc.org>> wrote:
On Mon, Feb 18, 2019 at 08:48:08AM -0800, Greg Mirsky wrote:
> As for your question of what is the change proposed in the draft I'll point
> to section 6.6 RFC 5880 that describes the Demand mode. It states that the
> periodic transmission of control messages MUST be stopped.

Correct.

> The draft
> defines, and that is what I consider the update to section 6.6, the
> procedure by which the system in Demand mode initiates the Poll sequence to
> inform the remote BFD system of RDI.

Would you clarify where in your draft this is discussed?

> Greg

-- Jeff

Re: WG Adoption request for draft-mirsky-bfd-mpls-demand

[Greg Mirsky]

Hi Jeff,
here's the text from the draft that describes the behavior on the BFD
system:
   If the Detection timer at the egress LER expires it MUST send BFD
   Control packet to the ingress LER with the Poll (P) bit set, Status
   (Sta) field set to Down value, and the Diagnostic (Diag) field set to
   Control Detection Time Expired value.  The egress LER sends these
   Control packets to the ingress LER at the rate of one per second
   until either it receives the valid for this BFD session control
   packet with the Final (F) bit set from the ingress LER or the defect
   condition clears and the BFD session state reaches Up state at the
   egress LER.

Regards,
Greg

On Mon, Feb 18, 2019 at 9:34 AM Jeffrey Haas  wrote:

> On Mon, Feb 18, 2019 at 08:48:08AM -0800, Greg Mirsky wrote:
> > As for your question of what is the change proposed in the draft I'll
> point
> > to section 6.6 RFC 5880 that describes the Demand mode. It states that
> the
> > periodic transmission of control messages MUST be stopped.
>
> Correct.
>
> > The draft
> > defines, and that is what I consider the update to section 6.6, the
> > procedure by which the system in Demand mode initiates the Poll sequence
> to
> > inform the remote BFD system of RDI.
>
> Would you clarify where in your draft this is discussed?
>
> > Greg
>
> -- Jeff
>

Re: WG Adoption request for draft-mirsky-bfd-mpls-demand

[Jeffrey Haas]

On Mon, Feb 18, 2019 at 08:48:08AM -0800, Greg Mirsky wrote:
> As for your question of what is the change proposed in the draft I'll point
> to section 6.6 RFC 5880 that describes the Demand mode. It states that the
> periodic transmission of control messages MUST be stopped.

Correct.

> The draft
> defines, and that is what I consider the update to section 6.6, the
> procedure by which the system in Demand mode initiates the Poll sequence to
> inform the remote BFD system of RDI.

Would you clarify where in your draft this is discussed?

> Greg

-- Jeff

Re: WG Adoption request for draft-mirsky-bfd-mpls-demand

[Greg Mirsky]

Hi Jeff,
I haven't heard that IETF encourages the discussion of the relevance of the
IPR Disclosure to the draft it referred to, less the validity of IPR. I
always was told to stay away from these topics.

As for your question of what is the change proposed in the draft I'll point
to section 6.6 RFC 5880 that describes the Demand mode. It states that the
periodic transmission of control messages MUST be stopped. The draft
defines, and that is what I consider the update to section 6.6, the
procedure by which the system in Demand mode initiates the Poll sequence to
inform the remote BFD system of RDI.

And coming back to WGAP, I don't recall any concerns or questions being
brought up on the WG list. The volume of responses was not enthusiastic, I
agree, but all were in favor of adopting the draft.

Regards,
Greg


On Mon, Feb 18, 2019 at 8:24 AM Jeffrey Haas  wrote:

> On Mon, Feb 18, 2019 at 07:32:30AM -0800, Greg Mirsky wrote:
> > Hi Jeff,
> > could you please clarify which of your roles, BFD WG chair or individual
> > contributor, you are in this discussion.
>
> In this case I am speaking as a chair.
>
> For the Working Group to adopt a draft, it needs to solve a problem.  In
> this case, changes to the protocol.  We are asking you what changes there
> are to the protocol.  Please answer that question.
>
> In the prior adoption call, IPR declaration concerns were one of the
> considerations for some respondents as to whether we should adopt this or
> not.  You answered those, and the licensing in the current IPR declaration
> is the in the form that is the most agreeable from a licensing perspective,
> especially for open source implementors.
>
> Again, the only motivation to inquire about the IPR at this point is that
> there appears to be no protocol changes in your draft.  If you are
> asserting
> IPR, it implies that there is something new.  If there's something new, it
> should be reflected as protocol changes in your draft.  Even if you're not
> to the point where you or the IPR holder can disclose, the draft itself
> must
> be clear.
>
> If you have any further concerns beyond the above with specific regard to
> my
> stance as chair on the IPR considerations, I strongly suggest you request
> Martin to ask the IESG to have the IETF legal group intervene.  This would
> be preferable to further aspersions to implicit bias.  Please note that
> IETF
> legal will be asking similar questions to the above.
>
> -- Jeff
>
>
>
>
> >
> > Regards,
> > Greg
> >
> > On Mon, Feb 18, 2019 at 7:26 AM Jeffrey Haas  wrote:
> >
> > > Greg,
> > >
> > > Answering this message with the reply partially reorganized.
> > >
> > >
> > > On Sun, Feb 17, 2019 at 04:40:31PM -0800, Greg Mirsky wrote:
> > > > On Sat, Feb 16, 2019 at 10:46 AM Jeffrey Haas 
> wrote:
> > > > > > GIM>> The behavior of the system in Demand mode is introduced as
> > > > > optional.
> > > > > > And that is precisely the update to RFC 5880.
> > > > >
> > > > > I don't understand.
> > > > >
> > > > > Basically, 5880, 5884 leave demand as an option.  It's built into
> the
> > > > > specs.
> > > > > It's unclear what you're suggesting being changed.
> > > > >
> > > > GIM2>> RFC 5884 leaves the Demand mode outside its scope. RFC 5884
> does
> > > not
> > > > discuss how the Demand mode may be used in BFD over MPLS LSPs.
> > >
> > > Even thought the RFC says demand mode is out of scope, 5880 is clear
> about
> > > how demand mode works.  I'm not seeing anything in your draft that
> alters
> > > that procedure.
> > >
> > > Basically, no draft is needed for a one-liner: you can use demand mode.
> > >
> > > > GIM2>> Is the fact that the patent application is not yet published
> the
> > > > sole foundation for your objection to adopting this draft as Chair
> of BFD
> > > > WG or as an individual contributor? Is there any IETF document that
> > > > requires that the patent must be published before the draft can be
> > > adopted
> > > > or published as RFC?
> > >
> > > The sole reason for mentioning this is demand mode is clear.  BFD over
> mpls
> > > is clear.  You're asserting some sort of IPR on things that are already
> > > clear.  So, either your draft itself is unclear on some new thing
> you're
> > > asserting IPR on, or you're not actually covering something new.
> That's
> > > it.
> > >
> > > -- Jeff
> > >
>

Re: WG Adoption request for draft-mirsky-bfd-mpls-demand

[Jeffrey Haas]

On Mon, Feb 18, 2019 at 07:32:30AM -0800, Greg Mirsky wrote:
> Hi Jeff,
> could you please clarify which of your roles, BFD WG chair or individual
> contributor, you are in this discussion.

In this case I am speaking as a chair.

For the Working Group to adopt a draft, it needs to solve a problem.  In
this case, changes to the protocol.  We are asking you what changes there
are to the protocol.  Please answer that question.

In the prior adoption call, IPR declaration concerns were one of the
considerations for some respondents as to whether we should adopt this or
not.  You answered those, and the licensing in the current IPR declaration
is the in the form that is the most agreeable from a licensing perspective,
especially for open source implementors.

Again, the only motivation to inquire about the IPR at this point is that
there appears to be no protocol changes in your draft.  If you are asserting
IPR, it implies that there is something new.  If there's something new, it
should be reflected as protocol changes in your draft.  Even if you're not
to the point where you or the IPR holder can disclose, the draft itself must
be clear.

If you have any further concerns beyond the above with specific regard to my
stance as chair on the IPR considerations, I strongly suggest you request
Martin to ask the IESG to have the IETF legal group intervene.  This would
be preferable to further aspersions to implicit bias.  Please note that IETF
legal will be asking similar questions to the above.

-- Jeff




> 
> Regards,
> Greg
> 
> On Mon, Feb 18, 2019 at 7:26 AM Jeffrey Haas  wrote:
> 
> > Greg,
> >
> > Answering this message with the reply partially reorganized.
> >
> >
> > On Sun, Feb 17, 2019 at 04:40:31PM -0800, Greg Mirsky wrote:
> > > On Sat, Feb 16, 2019 at 10:46 AM Jeffrey Haas  wrote:
> > > > > GIM>> The behavior of the system in Demand mode is introduced as
> > > > optional.
> > > > > And that is precisely the update to RFC 5880.
> > > >
> > > > I don't understand.
> > > >
> > > > Basically, 5880, 5884 leave demand as an option.  It's built into the
> > > > specs.
> > > > It's unclear what you're suggesting being changed.
> > > >
> > > GIM2>> RFC 5884 leaves the Demand mode outside its scope. RFC 5884 does
> > not
> > > discuss how the Demand mode may be used in BFD over MPLS LSPs.
> >
> > Even thought the RFC says demand mode is out of scope, 5880 is clear about
> > how demand mode works.  I'm not seeing anything in your draft that alters
> > that procedure.
> >
> > Basically, no draft is needed for a one-liner: you can use demand mode.
> >
> > > GIM2>> Is the fact that the patent application is not yet published the
> > > sole foundation for your objection to adopting this draft as Chair of BFD
> > > WG or as an individual contributor? Is there any IETF document that
> > > requires that the patent must be published before the draft can be
> > adopted
> > > or published as RFC?
> >
> > The sole reason for mentioning this is demand mode is clear.  BFD over mpls
> > is clear.  You're asserting some sort of IPR on things that are already
> > clear.  So, either your draft itself is unclear on some new thing you're
> > asserting IPR on, or you're not actually covering something new.  That's
> > it.
> >
> > -- Jeff
> >

Re: WG Adoption request for draft-mirsky-bfd-mpls-demand

[Greg Mirsky]

Hi Jeff,
could you please clarify which of your roles, BFD WG chair or individual
contributor, you are in this discussion.

Regards,
Greg

On Mon, Feb 18, 2019 at 7:26 AM Jeffrey Haas  wrote:

> Greg,
>
> Answering this message with the reply partially reorganized.
>
>
> On Sun, Feb 17, 2019 at 04:40:31PM -0800, Greg Mirsky wrote:
> > On Sat, Feb 16, 2019 at 10:46 AM Jeffrey Haas  wrote:
> > > > GIM>> The behavior of the system in Demand mode is introduced as
> > > optional.
> > > > And that is precisely the update to RFC 5880.
> > >
> > > I don't understand.
> > >
> > > Basically, 5880, 5884 leave demand as an option.  It's built into the
> > > specs.
> > > It's unclear what you're suggesting being changed.
> > >
> > GIM2>> RFC 5884 leaves the Demand mode outside its scope. RFC 5884 does
> not
> > discuss how the Demand mode may be used in BFD over MPLS LSPs.
>
> Even thought the RFC says demand mode is out of scope, 5880 is clear about
> how demand mode works.  I'm not seeing anything in your draft that alters
> that procedure.
>
> Basically, no draft is needed for a one-liner: you can use demand mode.
>
> > GIM2>> Is the fact that the patent application is not yet published the
> > sole foundation for your objection to adopting this draft as Chair of BFD
> > WG or as an individual contributor? Is there any IETF document that
> > requires that the patent must be published before the draft can be
> adopted
> > or published as RFC?
>
> The sole reason for mentioning this is demand mode is clear.  BFD over mpls
> is clear.  You're asserting some sort of IPR on things that are already
> clear.  So, either your draft itself is unclear on some new thing you're
> asserting IPR on, or you're not actually covering something new.  That's
> it.
>
> -- Jeff
>

Re: WG Adoption request for draft-mirsky-bfd-mpls-demand

[Jeffrey Haas]

Greg,

Answering this message with the reply partially reorganized.


On Sun, Feb 17, 2019 at 04:40:31PM -0800, Greg Mirsky wrote:
> On Sat, Feb 16, 2019 at 10:46 AM Jeffrey Haas  wrote:
> > > GIM>> The behavior of the system in Demand mode is introduced as
> > optional.
> > > And that is precisely the update to RFC 5880.
> >
> > I don't understand.
> >
> > Basically, 5880, 5884 leave demand as an option.  It's built into the
> > specs.
> > It's unclear what you're suggesting being changed.
> >
> GIM2>> RFC 5884 leaves the Demand mode outside its scope. RFC 5884 does not
> discuss how the Demand mode may be used in BFD over MPLS LSPs.

Even thought the RFC says demand mode is out of scope, 5880 is clear about
how demand mode works.  I'm not seeing anything in your draft that alters
that procedure.

Basically, no draft is needed for a one-liner: you can use demand mode.

> GIM2>> Is the fact that the patent application is not yet published the
> sole foundation for your objection to adopting this draft as Chair of BFD
> WG or as an individual contributor? Is there any IETF document that
> requires that the patent must be published before the draft can be adopted
> or published as RFC?

The sole reason for mentioning this is demand mode is clear.  BFD over mpls
is clear.  You're asserting some sort of IPR on things that are already
clear.  So, either your draft itself is unclear on some new thing you're
asserting IPR on, or you're not actually covering something new.  That's it.

-- Jeff

Re: WG Adoption request for draft-mirsky-bfd-mpls-demand

[Greg Mirsky]

Hi Reshad,
thank you for your question. As I've noted, this draft has no relation to
RFC 5883 BFD for Multi-hop paths. Also, it is not to update RFC 5884 BFD
for MPLS LSPs as the latter describes only the use of BFD in Asynchronous
mode. The draft describes procedures to use the Demand mode of BFD, which
is beneficial in monitoring unidirectional MPLS paths, e.g. LSP or SR-MPLS
tunnel. The draft proposes to update RFC 5880 in regard to the behavior of
BFD system in Demand mode so that such system MAY start Poll sequence to
inform the remote BFD system of the change in BFD session state, i.e.
signal RDI.

Regards,
Greg

On Sat, Feb 16, 2019 at 2:20 PM Reshad Rahman (rrahman) 
wrote:

> Hi Greg,
>
> I still don't understand what's the intended purpose of the draft. Does it
> change/update any procedures in 5880/5883 and if so could you please
> clarify why and how?
>
> Regards,
> Reshad.
>
>
> On 2019-02-16, 1:46 PM, "Rtg-bfd on behalf of Jeffrey Haas" <
> rtg-bfd-boun...@ietf.org on behalf of jh...@pfrc.org> wrote:
>
> Greg,
>
> On Sat, Feb 16, 2019 at 09:38:08AM -0800, Greg Mirsky wrote:
> > On Sat, Feb 16, 2019 at 8:33 AM Jeffrey Haas  wrote:
> > > Thanks for the update on the IPR declaration.  It's good to see
> that the
> > > terms of the licensing have shifted such that open source
> implementations
> > > would be able to be done.  I'll note that we're still in that
> limbo phase
> > > wherein it's not possible for the Working Group, or holders of IPR
> against
> > > the impacted RFCs 5880, 5883, and 5884, know what is being
> asserted that is
> > > distinct vs. previously published IPR declarations.
> > >
> > GIM>> My understanding of the legal side of IPR Disclosures is that
> the
> > last overwrites, including in regard to the licensing terms, previous
> > disclosures.
>
> The IPR disclosure and the licensing terms are clear.
>
> The patent is still pending.  The draft is against procedures largely
> specified in 5880, 5883, and 5884.  Presumably IPR has been filed
> because
> you're saying that you're doing something new against these documents..
>
> > GIM>> The behavior of the system in Demand mode is introduced as
> optional.
> > And that is precisely the update to RFC 5880.
>
> I don't understand.
>
> Basically, 5880, 5884 leave demand as an option.  It's built into the
> specs.
> It's unclear what you're suggesting being changed.
>
> -- Jeff
>
>
>
>

Re: WG Adoption request for draft-mirsky-bfd-mpls-demand

[Greg Mirsky]

Hi Jeff and Reshad,
thank you for your comments and questions. Please find my answers in-line
and tagged GIM2>>.

Regards,
Greg


On Sat, Feb 16, 2019 at 10:46 AM Jeffrey Haas  wrote:

> Greg,
>
> On Sat, Feb 16, 2019 at 09:38:08AM -0800, Greg Mirsky wrote:
> > On Sat, Feb 16, 2019 at 8:33 AM Jeffrey Haas  wrote:
> > > Thanks for the update on the IPR declaration.  It's good to see that
> the
> > > terms of the licensing have shifted such that open source
> implementations
> > > would be able to be done.  I'll note that we're still in that limbo
> phase
> > > wherein it's not possible for the Working Group, or holders of IPR
> against
> > > the impacted RFCs 5880, 5883, and 5884, know what is being asserted
> that is
> > > distinct vs. previously published IPR declarations.
>
GIM2>> Is the fact that the patent application is not yet published the
sole foundation for your objection to adopting this draft as Chair of BFD
WG or as an individual contributor? Is there any IETF document that
requires that the patent must be published before the draft can be adopted
or published as RFC?

> > >
> > GIM>> My understanding of the legal side of IPR Disclosures is that the
> > last overwrites, including in regard to the licensing terms, previous
> > disclosures.
>
> The IPR disclosure and the licensing terms are clear.
>
> The patent is still pending.  The draft is against procedures largely
> specified in 5880, 5883, and 5884.  Presumably IPR has been filed because
> you're saying that you're doing something new against these documents.
>
GIM2>> I don't recall that I've ever claimed that the draft updates RFC
5883 BFD for Multi-hop paths or RFC 5884 BFD for MPLS LSPs. The draft
describes how the BFD Demand mode may be used over MPLS LSP. I consider it
to be complementary to RFC 5884, which only describes the use of BFD in
Asynchronous mode and leaves the Demand mode out of its scope.

>
> > GIM>> The behavior of the system in Demand mode is introduced as
> optional.
> > And that is precisely the update to RFC 5880.
>
> I don't understand.
>
> Basically, 5880, 5884 leave demand as an option.  It's built into the
> specs.
> It's unclear what you're suggesting being changed.
>
GIM2>> RFC 5884 leaves the Demand mode outside its scope. RFC 5884 does not
discuss how the Demand mode may be used in BFD over MPLS LSPs.

>
> -- Jeff
>

Re: WG Adoption request for draft-mirsky-bfd-mpls-demand

[Reshad Rahman (rrahman)]

Hi Greg,

I still don't understand what's the intended purpose of the draft. Does it 
change/update any procedures in 5880/5883 and if so could you please clarify 
why and how?
   
Regards,
Reshad.


On 2019-02-16, 1:46 PM, "Rtg-bfd on behalf of Jeffrey Haas" 
 wrote:

Greg,

On Sat, Feb 16, 2019 at 09:38:08AM -0800, Greg Mirsky wrote:
> On Sat, Feb 16, 2019 at 8:33 AM Jeffrey Haas  wrote:
> > Thanks for the update on the IPR declaration.  It's good to see that the
> > terms of the licensing have shifted such that open source 
implementations
> > would be able to be done.  I'll note that we're still in that limbo 
phase
> > wherein it's not possible for the Working Group, or holders of IPR 
against
> > the impacted RFCs 5880, 5883, and 5884, know what is being asserted 
that is
> > distinct vs. previously published IPR declarations.
> >
> GIM>> My understanding of the legal side of IPR Disclosures is that the
> last overwrites, including in regard to the licensing terms, previous
> disclosures.

The IPR disclosure and the licensing terms are clear.

The patent is still pending.  The draft is against procedures largely
specified in 5880, 5883, and 5884.  Presumably IPR has been filed because
you're saying that you're doing something new against these documents.

> GIM>> The behavior of the system in Demand mode is introduced as optional.
> And that is precisely the update to RFC 5880.

I don't understand.

Basically, 5880, 5884 leave demand as an option.  It's built into the specs.
It's unclear what you're suggesting being changed.

-- Jeff

Re: WG Adoption request for draft-mirsky-bfd-mpls-demand

[Jeffrey Haas]

Greg,

On Sat, Feb 16, 2019 at 09:38:08AM -0800, Greg Mirsky wrote:
> On Sat, Feb 16, 2019 at 8:33 AM Jeffrey Haas  wrote:
> > Thanks for the update on the IPR declaration.  It's good to see that the
> > terms of the licensing have shifted such that open source implementations
> > would be able to be done.  I'll note that we're still in that limbo phase
> > wherein it's not possible for the Working Group, or holders of IPR against
> > the impacted RFCs 5880, 5883, and 5884, know what is being asserted that is
> > distinct vs. previously published IPR declarations.
> >
> GIM>> My understanding of the legal side of IPR Disclosures is that the
> last overwrites, including in regard to the licensing terms, previous
> disclosures.

The IPR disclosure and the licensing terms are clear.

The patent is still pending.  The draft is against procedures largely
specified in 5880, 5883, and 5884.  Presumably IPR has been filed because
you're saying that you're doing something new against these documents.

> GIM>> The behavior of the system in Demand mode is introduced as optional.
> And that is precisely the update to RFC 5880.

I don't understand.

Basically, 5880, 5884 leave demand as an option.  It's built into the specs.
It's unclear what you're suggesting being changed.

-- Jeff

Re: WG Adoption request for draft-mirsky-bfd-mpls-demand

[Greg Mirsky]

Hi Jeff,
thank you for your detailed analysis of the mechanism proposed in the
draft. I've in-lined one question and one note under tag GIM>>.

Regards,
Greg

On Sat, Feb 16, 2019 at 8:33 AM Jeffrey Haas  wrote:

> Greg,
>
> On Wed, Feb 06, 2019 at 08:56:12AM -0800, Greg Mirsky wrote:
> > Hi Jeff, Reshad, et al.,
> > now I can confirm that the IPR licensing terms to this draft were updated
> > by this IPR Disclosure 
> submitted
> > on December 11, 2018. Much appreciate your consideration and welcome
> > technical comments on the draft.
>
> Thanks for the update on the IPR declaration.  It's good to see that the
> terms of the licensing have shifted such that open source implementations
> would be able to be done.  I'll note that we're still in that limbo phase
> wherein it's not possible for the Working Group, or holders of IPR against
> the impacted RFCs 5880, 5883, and 5884, know what is being asserted that is
> distinct vs. previously published IPR declarations.
>
GIM>> My understanding of the legal side of IPR Disclosures is that the
last overwrites, including in regard to the licensing terms, previous
disclosures.

>
> And my apologies for not providing my technical comments more quickly.  The
> last month and a half has been particularly challenging at the day job.
> (Englightening, but challenging.)
>
> draft-mirsky-bfd-mpls-demand seems to be an attempt to provide a profile
> against which BFD, in a MPLS network, can use demand mode.  What I (and
> some
> others) have found puzzling is why there's any perceived need for this
> document.
>
> Working through your document beginning in section 3:
> - It is pointed out that demand mode exists.  Its procedures are documented
>   as part of the core BFD RFC 5880.
> - It points out in the case of MPLS as a transport that LSP Ping is
>   necessary to bootstrap the BFD session.  These procedures are defined in
>   RFC 5884.
> - It points out that we can shift to demand mode.  Again, this procedure is
>   documented in RFC 5880; see section 6.6.
> - It points out that we can test liveness using a poll sequence.  Again,
>   this procedure is documented in third paragaph of section 6.6 in RFC
> 5880.
> - The procedures for declaring a session down when in demand mode and a
> poll
>   sequence is in progress is covered in paragraph 6 of section 6.8.4 of RFC
>   5880.
> - The procedure for a down system reporting its state once per second is
>   covered by paragraph 5 of section 6.8.3 of RFC 5880.  I don't believe I
>   agree with your procedure that a system in demand mode must initiate a
> poll
>   sequence to declare that it is down.
>
GIM>> The behavior of the system in Demand mode is introduced as optional.
And that is precisely the update to RFC 5880.

>
> Am I missing something?
>
> -- Jeff
>
> >
> > Regards,
> > Greg
> >
> > On Mon, Dec 10, 2018 at 2:10 PM Jeffrey Haas  wrote:
> >
> > > Greg,
> > >
> > > Apologies for the long delay in reply.
> > >
> > > On Wed, Nov 21, 2018 at 02:40:50PM -0800, Greg Mirsky wrote:
> > > > I respectfully ask to summarize the comments that were shared with
> you
> > > and
> > > > to publish them to the WG without naming the authors.
> > >
> > > Tersely:
> > > - The document is not addressing fundamental issues.
> > > - It is encumbered by IPR.
> > > - Observed list traffic regarding question on the feature was not
> > >   satisfactorily converging.
> > >
> > > > And I have to admit that I don't understand your suggestion to use
> the
> > > > Errata. The procedures to apply the Demand mode described in the
> draft
> > > are
> > > > not in contradiction with RFC 5880, so the suggestion to use Errata
> > > > surprised me.
> > >
> > > I will respond on my own analysis in detail hopefully this week.  I am
> > > awaiting the resolution of a particular bit of correspondence before
> > > determining the tenor of my response.
> > >
> > > -- Jeff
> > >
>

Re: WG Adoption request for draft-mirsky-bfd-mpls-demand

[Jeffrey Haas]

Greg,

On Wed, Feb 06, 2019 at 08:56:12AM -0800, Greg Mirsky wrote:
> Hi Jeff, Reshad, et al.,
> now I can confirm that the IPR licensing terms to this draft were updated
> by this IPR Disclosure  submitted
> on December 11, 2018. Much appreciate your consideration and welcome
> technical comments on the draft.

Thanks for the update on the IPR declaration.  It's good to see that the
terms of the licensing have shifted such that open source implementations
would be able to be done.  I'll note that we're still in that limbo phase
wherein it's not possible for the Working Group, or holders of IPR against
the impacted RFCs 5880, 5883, and 5884, know what is being asserted that is
distinct vs. previously published IPR declarations.

And my apologies for not providing my technical comments more quickly.  The
last month and a half has been particularly challenging at the day job.
(Englightening, but challenging.)

draft-mirsky-bfd-mpls-demand seems to be an attempt to provide a profile
against which BFD, in a MPLS network, can use demand mode.  What I (and some
others) have found puzzling is why there's any perceived need for this
document.

Working through your document beginning in section 3:
- It is pointed out that demand mode exists.  Its procedures are documented
  as part of the core BFD RFC 5880.
- It points out in the case of MPLS as a transport that LSP Ping is
  necessary to bootstrap the BFD session.  These procedures are defined in
  RFC 5884.
- It points out that we can shift to demand mode.  Again, this procedure is
  documented in RFC 5880; see section 6.6.
- It points out that we can test liveness using a poll sequence.  Again,
  this procedure is documented in third paragaph of section 6.6 in RFC 5880.
- The procedures for declaring a session down when in demand mode and a poll
  sequence is in progress is covered in paragraph 6 of section 6.8.4 of RFC
  5880.
- The procedure for a down system reporting its state once per second is
  covered by paragraph 5 of section 6.8.3 of RFC 5880.  I don't believe I
  agree with your procedure that a system in demand mode must initiate a poll
  sequence to declare that it is down.

Am I missing something?

-- Jeff

> 
> Regards,
> Greg
> 
> On Mon, Dec 10, 2018 at 2:10 PM Jeffrey Haas  wrote:
> 
> > Greg,
> >
> > Apologies for the long delay in reply.
> >
> > On Wed, Nov 21, 2018 at 02:40:50PM -0800, Greg Mirsky wrote:
> > > I respectfully ask to summarize the comments that were shared with you
> > and
> > > to publish them to the WG without naming the authors.
> >
> > Tersely:
> > - The document is not addressing fundamental issues.
> > - It is encumbered by IPR.
> > - Observed list traffic regarding question on the feature was not
> >   satisfactorily converging.
> >
> > > And I have to admit that I don't understand your suggestion to use the
> > > Errata. The procedures to apply the Demand mode described in the draft
> > are
> > > not in contradiction with RFC 5880, so the suggestion to use Errata
> > > surprised me.
> >
> > I will respond on my own analysis in detail hopefully this week.  I am
> > awaiting the resolution of a particular bit of correspondence before
> > determining the tenor of my response.
> >
> > -- Jeff
> >

Re: WG Adoption request for draft-mirsky-bfd-mpls-demand

[Greg Mirsky]

Hi Jeff, Reshad, et al.,
now I can confirm that the IPR licensing terms to this draft were updated
by this IPR Disclosure  submitted
on December 11, 2018. Much appreciate your consideration and welcome
technical comments on the draft.

Regards,
Greg

On Mon, Dec 10, 2018 at 2:10 PM Jeffrey Haas  wrote:

> Greg,
>
> Apologies for the long delay in reply.
>
> On Wed, Nov 21, 2018 at 02:40:50PM -0800, Greg Mirsky wrote:
> > I respectfully ask to summarize the comments that were shared with you
> and
> > to publish them to the WG without naming the authors.
>
> Tersely:
> - The document is not addressing fundamental issues.
> - It is encumbered by IPR.
> - Observed list traffic regarding question on the feature was not
>   satisfactorily converging.
>
> > And I have to admit that I don't understand your suggestion to use the
> > Errata. The procedures to apply the Demand mode described in the draft
> are
> > not in contradiction with RFC 5880, so the suggestion to use Errata
> > surprised me.
>
> I will respond on my own analysis in detail hopefully this week.  I am
> awaiting the resolution of a particular bit of correspondence before
> determining the tenor of my response.
>
> -- Jeff
>

Re: WG Adoption request for draft-mirsky-bfd-mpls-demand

[Greg Mirsky]

Hi Jeff, et al.,
I now would like to comment on the point of "not satisfactory convergence"
of discussion. I assume that this is related to the discussion started by
the message
addressed
to Xiao Min, not to the author of the draft. Oddly enough. But I've
responded nevertheless. Two questions were raised and both were explained:
- BFD Demand mode may be used to monitor the continuity of a path in one
direction and we have two specifications, draft-ietf-bfd-multipoint and
draft-ietf-bfd-multipoint-active-tail, that describe how that can be done
without and with notification to the ingress BFD node;
- indeed, it is the liveliness of the path between the BFD systems that are
 monitored.
These were the questions and, in my opinion, both got answered. And now I
got to wonder what other questions need to be addressed? Plans to
implement? In my experience, evaluating a draft in WG AP I, explicitly or
not, answer to these questions:

   - whether the document is coherent;
   - is it likely to be actually useful in operational networks;
   - is the document technically sound?

And I cannot find any unaddressed question that falls into any of these
categories.
Much appreciate comments from BFD WG Chairs.

Regards,
Greg

On Tue, Dec 11, 2018 at 8:52 AM Greg Mirsky  wrote:

> Hi Jeff, et al.,
> thank you for the update. I wanted to clarify the second item, the
> question related to the IPR Disclosure. The first disclosure used the
> "covenant not to assert" language. The second was to only update the filing
> status, not the licensing terms. I believe I've clarified that at the time
> of asking for WG AP. I was informed that there's the update to IPR
> Disclosure on this work submitted that restores the "covenant not to
> assert" language. I hope that can be taken into consideration by you and
> Reshad.
>
> Regards,
> Greg
>
> On Mon, Dec 10, 2018 at 10:10 PM Jeffrey Haas  wrote:
>
>> Greg,
>>
>> Apologies for the long delay in reply.
>>
>> On Wed, Nov 21, 2018 at 02:40:50PM -0800, Greg Mirsky wrote:
>> > I respectfully ask to summarize the comments that were shared with you
>> and
>> > to publish them to the WG without naming the authors.
>>
>> Tersely:
>> - The document is not addressing fundamental issues.
>> - It is encumbered by IPR.
>> - Observed list traffic regarding question on the feature was not
>>   satisfactorily converging.
>>
>> > And I have to admit that I don't understand your suggestion to use the
>> > Errata. The procedures to apply the Demand mode described in the draft
>> are
>> > not in contradiction with RFC 5880, so the suggestion to use Errata
>> > surprised me.
>>
>> I will respond on my own analysis in detail hopefully this week.  I am
>> awaiting the resolution of a particular bit of correspondence before
>> determining the tenor of my response.
>>
>> -- Jeff
>>
>

Re: WG Adoption request for draft-mirsky-bfd-mpls-demand

[Greg Mirsky]

Hi Jeff, et al.,
thank you for the update. I wanted to clarify the second item, the question
related to the IPR Disclosure. The first disclosure used the "covenant not
to assert" language. The second was to only update the filing status, not
the licensing terms. I believe I've clarified that at the time of asking
for WG AP. I was informed that there's the update to IPR Disclosure on this
work submitted that restores the "covenant not to assert" language. I hope
that can be taken into consideration by you and Reshad.

Regards,
Greg

On Mon, Dec 10, 2018 at 10:10 PM Jeffrey Haas  wrote:

> Greg,
>
> Apologies for the long delay in reply.
>
> On Wed, Nov 21, 2018 at 02:40:50PM -0800, Greg Mirsky wrote:
> > I respectfully ask to summarize the comments that were shared with you
> and
> > to publish them to the WG without naming the authors.
>
> Tersely:
> - The document is not addressing fundamental issues.
> - It is encumbered by IPR.
> - Observed list traffic regarding question on the feature was not
>   satisfactorily converging.
>
> > And I have to admit that I don't understand your suggestion to use the
> > Errata. The procedures to apply the Demand mode described in the draft
> are
> > not in contradiction with RFC 5880, so the suggestion to use Errata
> > surprised me.
>
> I will respond on my own analysis in detail hopefully this week.  I am
> awaiting the resolution of a particular bit of correspondence before
> determining the tenor of my response.
>
> -- Jeff
>

Re: WG Adoption request for draft-mirsky-bfd-mpls-demand

[Jeffrey Haas]

Greg,

Apologies for the long delay in reply.  

On Wed, Nov 21, 2018 at 02:40:50PM -0800, Greg Mirsky wrote:
> I respectfully ask to summarize the comments that were shared with you and
> to publish them to the WG without naming the authors.

Tersely:
- The document is not addressing fundamental issues.
- It is encumbered by IPR.
- Observed list traffic regarding question on the feature was not
  satisfactorily converging.

> And I have to admit that I don't understand your suggestion to use the
> Errata. The procedures to apply the Demand mode described in the draft are
> not in contradiction with RFC 5880, so the suggestion to use Errata
> surprised me.

I will respond on my own analysis in detail hopefully this week.  I am
awaiting the resolution of a particular bit of correspondence before
determining the tenor of my response.

-- Jeff

Re: WG Adoption request for draft-mirsky-bfd-mpls-demand

[Greg Mirsky]

Dear WG Chairs,
I respectfully ask to summarize the comments that were shared with you and
to publish them to the WG without naming the authors.

And I have to admit that I don't understand your suggestion to use the
Errata. The procedures to apply the Demand mode described in the draft are
not in contradiction with RFC 5880, so the suggestion to use Errata
surprised me.

Regards,
Greg

On Wed, Nov 21, 2018 at 2:28 PM Jeffrey Haas  wrote:

> Working Group,
>
> After discussion among the chairs, we have decided to not adopt
> draft-mirsky-bfd-mpls-demand at this time.  Since the list response to the
> adoption were positive, it is necessary to explain some of the reasoning
> for
> this choice.
>
> The chairs had private exchanges with individuals that did not wish to
> publicly comment on their reasons for not supporting adoption.  We have
> chosen to consider their comments and accept their reasoning for declining
> to publicly comment.
>
> Additionally, on more thorough review of the proposal by the chairs, it's
> our opinion that the core procedures for BFD demand mode are not
> necessarily in need of amending in this instance to warrant a new working
> group task.  Errata would be considered for minor issues, if necessary.
>
> -- Jeff
>
>
> On Wed, Oct 17, 2018 at 06:24:31PM -0400, Jeffrey Haas wrote:
> > Working Group,
> >
> > The BFD chairs have received an adoption request for
> > "BFD in Demand Mode over Point-to-Point MPLS LSP"
> > (draft-mirsky-bfd-mpls-demand).
> >
> > https://datatracker.ietf.org/doc/draft-mirsky-bfd-mpls-demand/
> >
> > The adoption call will end on the Friday after IETF 103, November 9.
> >
> > Note that there is are existing IPR statements on this draft:
> > https://datatracker.ietf.org/ipr/3301/
> > https://datatracker.ietf.org/ipr/3104/
> >
> > Please indicate to the mailing list whether you support adoption of this
> > draft.
> >
> > -- Jeff & Reshad
>
>

Re: WG Adoption request for draft-mirsky-bfd-mpls-demand

[Jeffrey Haas]

Working Group,

After discussion among the chairs, we have decided to not adopt
draft-mirsky-bfd-mpls-demand at this time.  Since the list response to the
adoption were positive, it is necessary to explain some of the reasoning for
this choice.

The chairs had private exchanges with individuals that did not wish to
publicly comment on their reasons for not supporting adoption.  We have
chosen to consider their comments and accept their reasoning for declining
to publicly comment.

Additionally, on more thorough review of the proposal by the chairs, it's
our opinion that the core procedures for BFD demand mode are not
necessarily in need of amending in this instance to warrant a new working
group task.  Errata would be considered for minor issues, if necessary.

-- Jeff


On Wed, Oct 17, 2018 at 06:24:31PM -0400, Jeffrey Haas wrote:
> Working Group,
> 
> The BFD chairs have received an adoption request for 
> "BFD in Demand Mode over Point-to-Point MPLS LSP"
> (draft-mirsky-bfd-mpls-demand).
> 
> https://datatracker.ietf.org/doc/draft-mirsky-bfd-mpls-demand/
> 
> The adoption call will end on the Friday after IETF 103, November 9.
> 
> Note that there is are existing IPR statements on this draft:
> https://datatracker.ietf.org/ipr/3301/
> https://datatracker.ietf.org/ipr/3104/
> 
> Please indicate to the mailing list whether you support adoption of this
> draft.
> 
> -- Jeff & Reshad

Re: WG Adoption request for draft-mirsky-bfd-mpls-demand

[Greg Mirsky]

Hi Carlos,
thank you for the continued discussion. Please find my answers in-line
tagged GIM>>.

Regards,
Greg

On Sat, Oct 27, 2018 at 8:45 AM Carlos Pignataro (cpignata) <
cpign...@cisco.com> wrote:

> Hi Xiao,
>
> Thanks much for the quick response!
>
> Please find my follow ups:
>
> 1. Sorry if I was not clear. Yes, RFC 5880 lists exemplary possible
> mechanisms to glean continued connectivity but requires the use of one. My
> question is: which mechanisms does this draft propose? Could it please be
> spelled out?
>
GIM>> I have to point that:

   - BFD for Multipoint Networks uses the Demand mode of BFD with no such
   mechanism;
   - BFD for Multipoint Networks with Active Tail uses Poll sequence
   (possibly combination of multicast Poll and unicast Poll) to verify
   availability of the multicast path. But according to your interpretation of
   RFC 5880, this is not one of mechanisms to be used.

Now I have a question to you Do you believe that these two BFD
specifications for multicast and multipoint networks are insufifcient or
impaired because of the way the Demand mode being used?

>
> 2. Again, apologies if I was not clean enough. I understand what the
> abstract says, but the quoted text says that live was needs to be checked
> for a node (egress LER) instead of the forwarding path. Does that mean ~
> “of the forwarding path towards/upto the node”?
>
GIM>> Thank you for pointing to this issue. In the next version will
clarify that the Poll sequence allows the ingress LER to verify
availability of the LSP and the liveness of the egress LER.

>
> Thanks for your consideration.
>
> Thumb typed by Carlos Pignataro.
> Excuze typofraphicak errows
>
> On Oct 27, 2018, at 01:07, "xiao.m...@zte.com.cn" 
> wrote:
>
> Hi Carlos,
>
>
> My answers to your two questions are as follow:
>
>1.
>
>In section 6.6 of RFC5880, just after the text you quoted, it says
>"One possible mechanism is the receipt of traffic from the remote system;
>another is the use of the Echo function." So I'm not sure what's your real
>concern.
>2.
>
>In the abstract of this draft it says "This document describes
>procedures for using Bidirectional Forwarding Detection (BFD) in Demand
>mode to detect data plane failures in Multiprotocol Label Switching (MPLS)
>point-to-point Label Switched Paths." If you don't like the expression form
>of the text quoted by you, pls feel free to propose some text.
>
>
> Best Regards,
>
> Xiao Min
> 原始邮件
> *发件人：*CarlosPignataro(cpignata) 
> *收件人：*肖敏10093570;
> *抄送人：*Jeff Haas ;rtg-bfd@ietf.org ;
> *日 期 ：*2018年10月26日 12:04
> *主 题 ：**Re: WG Adoption request for draft-mirsky-bfd-mpls-demand*
> Xiao,
> Scanning through the draft, two questions:
>
> 1. What is the underlying mechanism to check liveness such that Demand can
> be used?
>
> https://tools.ietf.org/html/rfc5880#section-6.6
>
>Demand mode requires that some other mechanism is used to imply
>continuing connectivity between the two systems.  The mechanism used
>
>
> 2. Is this draft testing liveness of a path or a node?
>
> https://tools.ietf.org/html/draft-mirsky-bfd-mpls-demand-03#section-3
>
>In this state BFD peers MAY remain as long as the egress LER is in Up
>state.  The ingress LER MAY check liveness of the egress LER by
>setting the Poll flag.  The egress LER will respond by transmitting
>
>
> Thanks,
>
> — Carlos Pignataro
>
> On Oct 19, 2018, at 9:59 PM, xiao.m...@zte.com.cn wrote:
>
> I support WG adoption of this draft. Use of the demand mode for p2p LSP
> monitoring is feasible and required.
>
>
> Best Regards,
>
> Xiao Min
>
>
>
> *发件人：*JeffreyHaas 
> *收件人：*rtg-bfd@ietf.org ;
> *日 期 ：*2018年10月18日 06:24
> *主 题 ：**WG Adoption request for draft-mirsky-bfd-mpls-demand*
> Working Group,
>
> The BFD chairs have received an adoption request for
> "BFD in Demand Mode over Point-to-Point MPLS LSP"
> (draft-mirsky-bfd-mpls-demand).
>
> https://datatracker.ietf.org/doc/draft-mirsky-bfd-mpls-demand/
>
> The adoption call will end on the Friday after IETF 103, November 9.
>
> Note that there is are existing IPR statements on this draft:
> https://datatracker.ietf.org/ipr/3301/
> https://datatracker.ietf.org/ipr/3104/
>
> Please indicate to the mailing list whether you support adoption of this
> draft.
>
> -- Jeff & Reshad
>
>
>

Re: WG Adoption request for draft-mirsky-bfd-mpls-demand

[Carlos Pignataro (cpignata)]

Hi Xiao,

Thanks much for the quick response!

Please find my follow ups:

1. Sorry if I was not clear. Yes, RFC 5880 lists exemplary possible mechanisms 
to glean continued connectivity but requires the use of one. My question is: 
which mechanisms does this draft propose? Could it please be spelled out?

2. Again, apologies if I was not clean enough. I understand what the abstract 
says, but the quoted text says that live was needs to be checked for a node 
(egress LER) instead of the forwarding path. Does that mean ~ “of the 
forwarding path towards/upto the node”?

Thanks for your consideration.

Thumb typed by Carlos Pignataro.
Excuze typofraphicak errows

On Oct 27, 2018, at 01:07, "xiao.m...@zte.com.cn<mailto:xiao.m...@zte.com.cn>" 
mailto:xiao.m...@zte.com.cn>> wrote:


Hi Carlos,


My answers to your two questions are as follow:

  1.  In section 6.6 of RFC5880, just after the text you quoted, it says "One 
possible mechanism is the receipt of traffic from the remote system; another is 
the use of the Echo function." So I'm not sure what's your real concern.

  2.  In the abstract of this draft it says "This document describes procedures 
for using Bidirectional Forwarding Detection (BFD) in Demand mode to detect 
data plane failures in Multiprotocol Label Switching (MPLS) point-to-point 
Label Switched Paths." If you don't like the expression form of the text quoted 
by you, pls feel free to propose some text.


Best Regards,

Xiao Min

原始邮件
发件人：CarlosPignataro(cpignata) mailto:cpign...@cisco.com>>
收件人：肖敏10093570;
抄送人：Jeff Haas 
mailto:jh...@pfrc.org>>;rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>
 mailto:rtg-bfd@ietf.org>>;
日 期 ：2018年10月26日 12:04
主 题 ：Re: WG Adoption request for draft-mirsky-bfd-mpls-demand
Xiao,
Scanning through the draft, two questions:

1. What is the underlying mechanism to check liveness such that Demand can be 
used?

https://tools.ietf.org/html/rfc5880#section-6.6

   Demand mode requires that some other mechanism is used to imply
   continuing connectivity between the two systems.  The mechanism used


2. Is this draft testing liveness of a path or a node?

https://tools.ietf.org/html/draft-mirsky-bfd-mpls-demand-03#section-3

   In this state BFD peers MAY remain as long as the egress LER is in Up
   state.  The ingress LER MAY check liveness of the egress LER by
   setting the Poll flag.  The egress LER will respond by transmitting


Thanks,

— Carlos Pignataro

On Oct 19, 2018, at 9:59 PM, xiao.m...@zte.com.cn<mailto:xiao.m...@zte.com.cn> 
wrote:


I support WG adoption of this draft. Use of the demand mode for p2p LSP 
monitoring is feasible and required.


Best Regards,

Xiao Min


发件人：JeffreyHaas mailto:jh...@pfrc.org>>
收件人：rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org> 
mailto:rtg-bfd@ietf.org>>;
日 期 ：2018年10月18日 06:24
主 题 ：WG Adoption request for draft-mirsky-bfd-mpls-demand
Working Group,

The BFD chairs have received an adoption request for
"BFD in Demand Mode over Point-to-Point MPLS LSP"
(draft-mirsky-bfd-mpls-demand).

https://datatracker.ietf.org/doc/draft-mirsky-bfd-mpls-demand/

The adoption call will end on the Friday after IETF 103, November 9.

Note that there is are existing IPR statements on this draft:
https://datatracker.ietf.org/ipr/3301/
https://datatracker.ietf.org/ipr/3104/

Please indicate to the mailing list whether you support adoption of this
draft.

-- Jeff & Reshad

Re: Re: WG Adoption request for draft-mirsky-bfd-mpls-demand

[xiao.min2]

Hi Carlos,






My answers to your two questions are as follow:


In section 6.6 of RFC5880, just after the text you quoted, it says "One 
possible mechanism is the receipt of traffic from the remote system; another is 
the use of the Echo function." So I'm not sure what's your real concern.


In the abstract of this draft it says "This document describes procedures for 
using Bidirectional Forwarding Detection (BFD) in Demand mode to detect data 
plane failures in Multiprotocol Label Switching (MPLS) point-to-point Label 
Switched Paths." If you don't like the expression form of the text quoted by 
you, pls feel free to propose some text.






Best Regards,


Xiao Min



原始邮件



发件人：CarlosPignataro(cpignata) 
收件人：肖敏10093570;
抄送人：Jeff Haas ;rtg-bfd@ietf.org ;
日 期 ：2018年10月26日 12:04
主 题 ：Re: WG Adoption request for draft-mirsky-bfd-mpls-demand


Xiao, 
Scanning through the draft, two questions:
 
1. What is the underlying mechanism to check liveness such that Demand can be 
used?
 
https://tools.ietf.org/html/rfc5880#section-6.6
 

   Demand mode requires that some other mechanism is used to imply

   continuing connectivity between the two systems.  The mechanism used
 

2. Is this draft testing liveness of a path or a node?
 
https://tools.ietf.org/html/draft-mirsky-bfd-mpls-demand-03#section-3
 

   In this state BFD peers MAY remain as long as the egress LER is in Up

   state.  The ingress LER MAY check liveness of the egress LER by

   setting the Poll flag.  The egress LER will respond by transmitting
 

 


Thanks,
 
— Carlos Pignataro


 
On Oct 19, 2018, at 9:59 PM, xiao.m...@zte.com.cn wrote:
 


I support WG adoption of this draft. Use of the demand mode for p2p LSP 
monitoring is feasible and required.


 


Best Regards,


Xiao Min


 




 






发件人：JeffreyHaas 

收件人：rtg-bfd@ietf.org ;

日 期 ：2018年10月18日 06:24

主 题 ：WG Adoption request for draft-mirsky-bfd-mpls-demand



Working Group, The BFD chairs have received an adoption request for  "BFD in 
Demand Mode over Point-to-Point MPLS LSP" (draft-mirsky-bfd-mpls-demand). 
https://datatracker.ietf.org/doc/draft-mirsky-bfd-mpls-demand/ The adoption 
call will end on the Friday after IETF 103, November 9. Note that there is are 
existing IPR statements on this draft: https://datatracker.ietf.org/ipr/3301/ 
https://datatracker.ietf.org/ipr/3104/ Please indicate to the mailing list 
whether you support adoption of this draft. -- Jeff & Reshad

Re: WG Adoption request for draft-mirsky-bfd-mpls-demand

[Carlos Pignataro (cpignata)]

Hi, Greg,

Thanks for the quick response — please see inline, since I do not believe you 
were answering my actual points.

On Oct 26, 2018, at 11:23 AM, Greg Mirsky 
mailto:gregimir...@gmail.com>> wrote:

Hi Carlos,
thank you for your interest in the draft and the questions. Please find my 
answers in-line tagged GIM>>.

Regards,
Greg

On Thu, Oct 25, 2018 at 9:04 PM Carlos Pignataro (cpignata) 
mailto:cpign...@cisco.com>> wrote:
Xiao,

Scanning through the draft, two questions:

1. What is the underlying mechanism to check liveness such that Demand can be 
used?

https://tools.ietf.org/html/rfc5880#section-6.6

   Demand mode requires that some other mechanism is used to imply
   continuing connectivity between the two systems.  The mechanism used
GIM>> The Poll sequence may also be used as such, and 
draft-ietf-bfd-multipoint-active-tail is the example of how the Poll sequence 
is used in BFD Demand mode.


This is not what the spec says. Quoting the same text again, but adding 
emphasis:

   Demand mode **requires** that **some other mechanism** is used to imply
   continuing connectivity between the two systems.  The mechanism used

What is the **some other mechanism** outside BFD, in this case? It is something 
that Demand mode **requires**


2. Is this draft testing liveness of a path or a node?

https://tools.ietf.org/html/draft-mirsky-bfd-mpls-demand-03#section-3

   In this state BFD peers MAY remain as long as the egress LER is in Up
   state.  The ingress LER MAY check liveness of the egress LER by
   setting the Poll flag.  The egress LER will respond by transmitting
GIM>> BFD does not differentiate between the path and, to certain extent, the 
node. From RFC 5880 Abstract:
   This document describes a protocol intended to detect faults in the
   bidirectional path between two forwarding engines, including
   interfaces, data link(s), and to the extent possible the forwarding
   engines themselves, with potentially very low latency.

The text you quote says nothing about the node. Only about the *path* and 
*forwarding* elements...

What is, for BFD, to "check liveness of the egress LER”?

Best,

Carlos.


Thanks,

— Carlos Pignataro

On Oct 19, 2018, at 9:59 PM, xiao.m...@zte.com.cn 
wrote:


I support WG adoption of this draft. Use of the demand mode for p2p LSP 
monitoring is feasible and required.


Best Regards,

Xiao Min

原始邮件
发件人：JeffreyHaas mailto:jh...@pfrc.org>>
收件人：rtg-bfd@ietf.org 
mailto:rtg-bfd@ietf.org>>;
日 期 ：2018年10月18日 06:24
主 题 ：WG Adoption request for draft-mirsky-bfd-mpls-demand
Working Group,

The BFD chairs have received an adoption request for
"BFD in Demand Mode over Point-to-Point MPLS LSP"
(draft-mirsky-bfd-mpls-demand).

https://datatracker.ietf.org/doc/draft-mirsky-bfd-mpls-demand/

The adoption call will end on the Friday after IETF 103, November 9.

Note that there is are existing IPR statements on this draft:
https://datatracker.ietf.org/ipr/3301/
https://datatracker.ietf.org/ipr/3104/

Please indicate to the mailing list whether you support adoption of this
draft.

-- Jeff & Reshad

Re: WG Adoption request for draft-mirsky-bfd-mpls-demand

[Greg Mirsky]

Hi Carlos,
thank you for your interest in the draft and the questions. Please find my
answers in-line tagged GIM>>.

Regards,
Greg

On Thu, Oct 25, 2018 at 9:04 PM Carlos Pignataro (cpignata) <
cpign...@cisco.com> wrote:

> Xiao,
>
> Scanning through the draft, two questions:
>
> 1. What is the underlying mechanism to check liveness such that Demand can
> be used?
>
> https://tools.ietf.org/html/rfc5880#section-6.6
>
>Demand mode requires that some other mechanism is used to imply
>continuing connectivity between the two systems.  The mechanism used
> GIM>> The Poll sequence may also be used as such, and
> draft-ietf-bfd-multipoint-active-tail is the example of how the Poll
> sequence is used in BFD Demand mode.
>
> 2. Is this draft testing liveness of a path or a node?
>
> https://tools.ietf.org/html/draft-mirsky-bfd-mpls-demand-03#section-3
>
>In this state BFD peers MAY remain as long as the egress LER is in Up
>state.  The ingress LER MAY check liveness of the egress LER by
>setting the Poll flag.  The egress LER will respond by transmitting
> GIM>> BFD does not differentiate between the path and, to certain extent,
> the node. From RFC 5880 Abstract:
>
   This document describes a protocol intended to detect faults in the
   bidirectional path between two forwarding engines, including
   interfaces, data link(s), and to the extent possible the forwarding
   engines themselves, with potentially very low latency.

>
> Thanks,
>
> — Carlos Pignataro
>
> On Oct 19, 2018, at 9:59 PM, xiao.m...@zte.com.cn wrote:
>
> I support WG adoption of this draft. Use of the demand mode for p2p LSP
> monitoring is feasible and required.
>
>
> Best Regards,
>
> Xiao Min
> 原始邮件
> *发件人：*JeffreyHaas 
> *收件人：*rtg-bfd@ietf.org ;
> *日 期 ：*2018年10月18日 06:24
> *主 题 ：**WG Adoption request for draft-mirsky-bfd-mpls-demand*
> Working Group,
>
> The BFD chairs have received an adoption request for
> "BFD in Demand Mode over Point-to-Point MPLS LSP"
> (draft-mirsky-bfd-mpls-demand).
>
> https://datatracker.ietf.org/doc/draft-mirsky-bfd-mpls-demand/
>
> The adoption call will end on the Friday after IETF 103, November 9.
>
> Note that there is are existing IPR statements on this draft:
> https://datatracker.ietf.org/ipr/3301/
> https://datatracker.ietf.org/ipr/3104/
>
> Please indicate to the mailing list whether you support adoption of this
> draft.
>
> -- Jeff & Reshad
>
>
>
>

Re: WG Adoption request for draft-mirsky-bfd-mpls-demand

[Carlos Pignataro (cpignata)]

Xiao,

Scanning through the draft, two questions:

1. What is the underlying mechanism to check liveness such that Demand can be 
used?

https://tools.ietf.org/html/rfc5880#section-6.6

   Demand mode requires that some other mechanism is used to imply
   continuing connectivity between the two systems.  The mechanism used


2. Is this draft testing liveness of a path or a node?

https://tools.ietf.org/html/draft-mirsky-bfd-mpls-demand-03#section-3

   In this state BFD peers MAY remain as long as the egress LER is in Up
   state.  The ingress LER MAY check liveness of the egress LER by
   setting the Poll flag.  The egress LER will respond by transmitting


Thanks,

— Carlos Pignataro

On Oct 19, 2018, at 9:59 PM, xiao.m...@zte.com.cn 
wrote:


I support WG adoption of this draft. Use of the demand mode for p2p LSP 
monitoring is feasible and required.


Best Regards,

Xiao Min

原始邮件
发件人：JeffreyHaas mailto:jh...@pfrc.org>>
收件人：rtg-bfd@ietf.org 
mailto:rtg-bfd@ietf.org>>;
日 期 ：2018年10月18日 06:24
主 题 ：WG Adoption request for draft-mirsky-bfd-mpls-demand
Working Group,

The BFD chairs have received an adoption request for
"BFD in Demand Mode over Point-to-Point MPLS LSP"
(draft-mirsky-bfd-mpls-demand).

https://datatracker.ietf.org/doc/draft-mirsky-bfd-mpls-demand/

The adoption call will end on the Friday after IETF 103, November 9.

Note that there is are existing IPR statements on this draft:
https://datatracker.ietf.org/ipr/3301/
https://datatracker.ietf.org/ipr/3104/

Please indicate to the mailing list whether you support adoption of this
draft.

-- Jeff & Reshad

答复: Re: WG Adoption request for draft-mirsky-bfd-mpls-demand

[hu.fangwei]

Hi, all


I support the adoption. 




Regards


Fangwei.














发件人：JeffreyHaas 
收件人：rtg-bfd@ietf.org ;
日 期 ：2018年10月18日 06:24
主 题 ：WG Adoption request for draft-mirsky-bfd-mpls-demand


Working Group,

The BFD chairs have received an adoption request for 
"BFD in Demand Mode over Point-to-Point MPLS LSP"
(draft-mirsky-bfd-mpls-demand).

https://datatracker.ietf.org/doc/draft-mirsky-bfd-mpls-demand/

The adoption call will end on the Friday after IETF 103, November 9.

Note that there is are existing IPR statements on this draft:
https://datatracker.ietf.org/ipr/3301/
https://datatracker.ietf.org/ipr/3104/

Please indicate to the mailing list whether you support adoption of this
draft.

-- Jeff & Reshad

Re: WG Adoption request for draft-mirsky-bfd-mpls-demand

[xiao.min2]

I support WG adoption of this draft. Use of the demand mode for p2p LSP 
monitoring is feasible and required.






Best Regards,


Xiao Min










原始邮件



发件人：JeffreyHaas 
收件人：rtg-bfd@ietf.org ;
日 期 ：2018年10月18日 06:24
主 题 ：WG Adoption request for draft-mirsky-bfd-mpls-demand


Working Group,

The BFD chairs have received an adoption request for 
"BFD in Demand Mode over Point-to-Point MPLS LSP"
(draft-mirsky-bfd-mpls-demand).

https://datatracker.ietf.org/doc/draft-mirsky-bfd-mpls-demand/

The adoption call will end on the Friday after IETF 103, November 9.

Note that there is are existing IPR statements on this draft:
https://datatracker.ietf.org/ipr/3301/
https://datatracker.ietf.org/ipr/3104/

Please indicate to the mailing list whether you support adoption of this
draft.

-- Jeff & Reshad