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

From: Greg Mirsky <[email-masked]>
Date: Wed, 6 Feb 2019 08:56:12 -0800

Hi Jeff, Reshad, et al.,
now I can confirm that the IPR licensing terms to this draft were updated
by this IPR Disclosure <https://datatracker.ietf.org/ipr/3359/> 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 <[email-masked]> 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
>

---

From: Jeffrey Haas <[email-masked]>
Date: Sat, 16 Feb 2019 11:31:55 -0500

Greg,

> 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

---

From: Greg Mirsky <[email-masked]>
Date: Sat, 16 Feb 2019 09:38:08 -0800

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

> 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.

>   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.

---

From: Jeffrey Haas <[email-masked]>
Date: Sat, 16 Feb 2019 13:45:10 -0500

Greg,

> last overwrites, including in regard to the licensing terms, previous

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.

> 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

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Sat, 16 Feb 2019 22:19:40 +0000

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" <[email-masked] on behalf of [email-masked]> wrote:

    Greg,

    

    I don't understand.

    -- Jeff

---

From: Greg Mirsky <[email-masked]>
Date: Sun, 17 Feb 2019 16:40:31 -0800

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

Regards,
Greg

> > > 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?

> 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.

> 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.

---

From: Greg Mirsky <[email-masked]>
Date: Sun, 17 Feb 2019 16:48:56 -0800

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) <[email-masked]>
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" <
> [email-masked] on behalf of [email-masked]> wrote:
>
>     Greg,
>

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 18 Feb 2019 10:25:44 -0500

Greg,

Answering this message with the reply partially reorganized.

> 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.

> requires that the patent must be published before the draft can be adopted

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

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 18 Feb 2019 07:32:30 -0800

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

Regards,
Greg

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 18 Feb 2019 11:23:50 -0500

> 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

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 18 Feb 2019 08:48:08 -0800

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 <[email-masked]> wrote:

> > > > > Basically, 5880, 5884 leave demand as an option.  It's built into
> the
> > > > > specs.
> > > > GIM2>> RFC 5884 leaves the Demand mode outside its scope. RFC 5884
> does
> > > not
> > > asserting IPR on, or you're not actually covering something new.
> That's
> > > it.
> > >
> > > -- Jeff
> > >
>

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 18 Feb 2019 12:33:51 -0500

On Mon, Feb 18, 2019 at 08:48:08AM -0800, Greg Mirsky wrote:
> periodic transmission of control messages MUST be stopped.

Correct.

> The draft

Would you clarify where in your draft this is discussed?

-- Jeff

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 18 Feb 2019 10:02:09 -0800

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

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Tue, 19 Feb 2019 03:52:58 +0000

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 <[email-masked]>
Date: Monday, February 18, 2019 at 1:03 PM
To: Jeffrey Haas <[email-masked]>
Cc: "Reshad Rahman (rrahman)" <[email-masked]>, Martin Vigoureux <[email-masked]>, "[email-masked]" <[email-masked]>
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:

Regards,
Greg

On Mon, Feb 18, 2019 at 9:34 AM Jeffrey Haas <[email-masked]<mailto:[email-masked]>> wrote:

Correct.

-- Jeff

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 18 Feb 2019 20:09:43 -0800

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) <[email-masked]>
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?
>
>
>
> *From: *Greg Mirsky <[email-masked]>
> *Date: *Monday, February 18, 2019 at 1:03 PM
> *To: *Jeffrey Haas <[email-masked]>
> *Cc: *"Reshad Rahman (rrahman)" <[email-masked]>, Martin Vigoureux <
> [email-masked]>, "[email-masked]" <[email-masked]>
> *Subject: *Re: WG Adoption request for draft-mirsky-bfd-mpls-demand
>
>
>
> Hi Jeff,
>

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 19 Feb 2019 12:41:10 -0500

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:
> 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

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

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 19 Feb 2019 15:59:36 -0800

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

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 19 Feb 2019 23:43:30 -0500

Greg,

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

> 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

---

From: Greg Mirsky <[email-masked]>
Date: Sun, 24 Feb 2019 09:53:20 -0800

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

---

From: Jeffrey Haas <[email-masked]>
Date: Sun, 24 Feb 2019 22:23:17 -0500

Greg,

>    concatenated path failure is to resume.

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

> 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

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. 

> participants during the WG AP. Much appreciate your consideration.

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

-- Jeff

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 25 Feb 2019 09:10:16 -0800

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

Regards,
Greg

> MPLS does not magically change the behavior of demand mode specified in the
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.

> 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.

> 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.

> 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.

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 25 Feb 2019 12:25:44 -0500

> 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.

> 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.

> individual contributor and evaluate them and the consensus as the WG chair.

Chairs are not prohibited from offering technical feedback.  If you remain
confused on this issue, I suggest you discuss this with Martin at the
upcoming IETF.

-- Jeff

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 25 Feb 2019 10:39:32 -0800

Hi Jeff,
now with GIM6>>.

Regards,
Greg

On Mon, Feb 25, 2019 at 9:26 AM Jeffrey Haas <[email-masked]> wrote:

> > > > 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
> > > >    Note that if the BFD session subsequently fails, the diagnostic
> code
> > > will
> > > > And so far we were discussing RFC 5880 though the scope of the draft
> is
> > > on
> > > > that, I consider, the draft is complimentary to RFC 5884 whose scope
> is
> > > on
> 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.

> 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.

> because the Diag changes, that at least is clear, and is worth further
GIM6>> Thank you for the suggestion. The draft states:
   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.
Can we discuss that?

> further discussion is warranted.
GIM6>> I don't consider the switch to the Demand mode as "change to
procedure" defined in RFC 5884 because the Demand mode is explicitly
outside the scope of the document. True, the initialization of a BFD
session follows the same steps as defined in RFC 5884. But that all changes:
  Once the BFD session is in Up state the ingress LER
   that supports this specification MUST switch to the Demand mode by
   setting Demand (D) bit in its Control packet and initiating a Poll
   Sequence.  If the egress LER supports this specification it MUST
   respond with the Final (F) bit set in its BFD Control packet sent to
   the ingress LER and ceases further transmission of periodic BFD
   control packets to the ingress LER.
I haven't viewed these steps as "change to procedure" of RFC 5884 as they
lead to the state that is outside the scope for RFC 5884.

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Tue, 26 Feb 2019 03:01:51 +0000

Hi Greg,

Please see inline.

From: Rtg-bfd <[email-masked]> on behalf of Greg Mirsky <[email-masked]>
Date: Monday, February 25, 2019 at 1:40 PM
To: Jeffrey Haas <[email-masked]>
Cc: "Reshad Rahman (rrahman)" <[email-masked]>, "[email-masked]" <[email-masked]>
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 <[email-masked]<mailto:[email-masked]>> wrote:
On Mon, Feb 25, 2019 at 09:10:16AM -0800, Greg Mirsky wrote:
> On Sun, Feb 24, 2019 at 7:24 PM Jeffrey Haas <[email-masked]<mailto:[email-masked]>> wrote:
>
> > Greg,
> >

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:
<RR> Use of the term “parameter” is indeed not very clear, elsewhere in 5880 “timing parameters” and “timer parameters” are used. But what is clear is “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”, the next packet would be different in this case because of state/diag change. So as per my previous reply, my interpretation is that this is indeed covered by 5880.

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.
<RR> I don’t have all the history on these 2 drafts but this text from draft-ietf-bfd-multipoint mentions no return path, so this would explain why tail does not do poll sequence.
   As multipoint transmissions are inherently unidirectional, this
   mechanism purports only to verify this unidirectional connectivity.
   Although this seems in conflict with the "Bidirectional" in BFD, the
   protocol is capable of supporting this use case.  Use of BFD in
   Demand mode enables a tail monitor availability of a multipoint path
   even without the existence of some kind of a return path to the head.
   As an option, if a return path from a tail to the head exists, the
   tail may notify the head of the lack of multipoint connectivity.
   Details of tail notification to the head are outside the scope of
   this document and are discussed in
   [I-D.ietf-bfd-multipoint-active-tail<https://tools.ietf.org/html/draft-ietf-bfd-multipoint-18#ref-I-D.ietf-bfd-multipoint-active-tail>].

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.
GIM6>> Thank you for the suggestion. The draft states:
   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.
Can we discuss that?
<RR> Isn’t the paragraph covered in 6.6 of 5880?
   Note that
   the Demand bit MUST NOT be set unless both systems perceive the
   session to be Up (the local system thinks the session is Up, and the
   remote system last reported Up state in the State (Sta) field of the
   BFD Control packet).

Regards,
Reshad (no hat).

GIM6>> I don't consider the switch to the Demand mode as "change to procedure" defined in RFC 5884 because the Demand mode is explicitly outside the scope of the document. True, the initialization of a BFD session follows the same steps as defined in RFC 5884. But that all changes:
I haven't viewed these steps as "change to procedure" of RFC 5884 as they lead to the state that is outside the scope for RFC 5884.

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

-- Jeff

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 25 Feb 2019 20:26:21 -0800

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) <[email-masked]>
wrote:

> Hi Greg,
>
>
>
> Please see inline.
>
>
>
> *From: *Rtg-bfd <[email-masked]> on behalf of Greg Mirsky <
> [email-masked]>
> *Date: *Monday, February 25, 2019 at 1:40 PM
> *Cc: *"Reshad Rahman (rrahman)" <[email-masked]>, "[email-masked]" <
> [email-masked]>
> <RR> Use of the term “parameter” is indeed not very clear, elsewhere in
> 5880 “timing parameters” and “timer parameters” are used. But what is clear
> is “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”, the next packet would be different in
> this case because of state/diag change. So as per my previous reply, my
> interpretation is that this is indeed covered by 5880.
>
GIM7>> I think that the next sentence clarifies the intent of initiating
the Poll sequence:
   This ensures that parameter changes are transmitted to the
   remote system and that the remote system acknowledges these changes.
So, the goal is not to update the peer on the change in state of the
session but only to keep parameters in sync. And these are configurable
parameters, in my understanding of the text.

> <RR> I don’t have all the history on these 2 drafts but this text from
> draft-ietf-bfd-multipoint mentions no return path, so this would explain
> why tail does not do poll sequence.
>
>    [I-D.ietf-bfd-multipoint-active-tail
> <https://tools.ietf.org/html/draft-ietf-bfd-multipoint-18#ref-I-D.ietf-bfd-multipoint-active-tail>
> ].
>
GIM7>> I think that the reference to lack of any return path to the head is
to merely illustrate that even in such network this specification provides
some value. But this specification, we may refer to it as p2mp BFD base
specification, is equally applicable in the network where the return path
from a tail to the head exists. And yet, no mention of using the Poll
sequence from a tail to the head as the mechanism to notify the head of
failure in the multipoint tree. And the same in
draft-ietf-bfd-multipoint-active-tail. Very elaborate mechanism combining
multicast and unicast Poll sequence initiated by the head and no mention of
possibly using the Poll sequence initiated by a tail. I can only explain
that as an indication that initiating the Poll sequence by the system in
Demand mode was not intended by the authors of BFD specifications.