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

[Greg Mirsky <[e-mail]>]

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) <[e-mail]>
wrote:

> Hi Greg,
>
>
>
> Please see inline.
>
>
>
> *From: *Rtg-bfd <[e-mail]> on behalf of Greg Mirsky <
> [e-mail]>
> *Date: *Monday, February 25, 2019 at 1:40 PM
> *To: *Jeffrey Haas <[e-mail]>
> *Cc: *"Reshad Rahman (rrahman)" <[e-mail]>, "[e-mail]" <
> [e-mail]>
> *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 <[e-mail]> 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 <[e-mail]> 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.
>
> <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.

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

>
>
>
>
>
> 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).
>
>
>
>
> > > 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.
>
> 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.
>
>
> > > 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 technical feedback.  If you remain
> confused on this issue, I suggest you discuss this with Martin at the
> upcoming IETF.
>
> -- Jeff
>
>