RE: WGLC for draft-ietf-bfd-large-packets

[Les Ginsberg (ginsberg)]

Sooo…this was a real “blast-from-the-past” for me.
Over four years went by with no public updates – and in looking at the diffs 
between the latest version and V2 (which is where the discussion ended for me) 
it seems that not much has changed (albeit YANG section was introduced).

I went back and reread the emails from years ago. It seems my concerns at the 
time were addressed – largely by Section 4.
I am a bit reluctant to look too closely because I fear I will revive issues 
that were resolved years ago, but I no longer have the same context.
So, I am just going to say this looks good to me and I support progressing the 
document.

I would be interested to know – was an implementation ever deployed in the 
environment which first raised the need for this draft – and if so what were 
the results?
If not, does this reflect a lack of interest in the functionality?

   Les


From: Reshad Rahman 
Sent: Thursday, May 9, 2024 1:16 PM
To: BFD WG 
Subject: WGLC for draft-ietf-bfd-large-packets



BFD WG,

This email (re)starts a 2 week Working Group Last Call for "BFD encapsulated in 
large packets":
https://datatracker.ietf.org/doc/draft-ietf-bfd-large-packets/


Please take the time to review the document and provide comments by May 24th. 
Feedback such as "I believe the document is ready to advance" is also welcome.

FYI we did WGLC a few years ago, see previous discussions at 
https://mailarchive.ietf.org/arch/msg/rtg-bfd/rjyxii23qp8-EQSZQ7d8631kMwY/

There is no known IPR for this document:
https://mailarchive.ietf.org/arch/msg/rtg-bfd/jaAjdrkePSocqvvcxt4ffx0NDg8/

https://mailarchive.ietf.org/arch/msg/rtg-bfd/0yfGFB-ywYQMQWledrRRLXhrVYY/


Regards,
Reshad (co-chair).

RE: bfd-unsolicited, possible RFC 5880 ambiguity for passive mode

[Les Ginsberg (ginsberg)]

Jeff -

I don't know for certain what our implementations do, but I will hazard a guess 
that for any platform where BFD is supported in hardware that the hardware is 
unaware of passive mode. It will simply continue to send DOWN packets until the 
control plane destroys the BFD session. Which likely means multiple DOWN 
packets will be sent (depending on the TxInterval in use) even when in passive 
mode - which is actually the behavior that is desired.

You could file an errata and specify that even in Passive mode some minimum # 
of DOWN packets should be sent (or for some minimum duration), but I suspect in 
practice this wouldn't result in an implementation change because (as I 
indicated above) I would be surprised if hardware implementations are aware of 
passive mode.

For me, the intent of the statement:

" A system MUST NOT transmit BFD Control packets if bfd.RemoteDiscr is
   zero and the system is taking the Passive role."

is as a means of implementing passive mode for the session bringup (as you 
mention below). And I would argue that transmitting multiple DOWN packets 
following a DOWN transition doesn't violate the "spirit" of RFC 5880.

I won't argue the pedantic points.

   Les


> -Original Message-
> From: Rtg-bfd  On Behalf Of Jeffrey Haas
> Sent: Wednesday, March 2, 2022 11:05 AM
> To: rtg-bfd@ietf.org
> Cc: draft-ietf-bfd-unsolici...@ietf.org
> Subject: bfd-unsolicited, possible RFC 5880 ambiguity for passive mode
> 
> Working Group,
> 
> Greg Mirsky brought to our attention that we may have an undefined edge
> case
> covering Passive mode in RFC 5880.  This discussion is partially a result of
> prior analysis about Demand mode, but Demand mode is not the relevant
> detail
> here.
> 
> Presuming Greg's observation is correct, this is at least deserving an Errata.
> 
> Copying selectively from the thread with Greg:
> 
> RFC 5880, §6.1:
> :   A system taking the
> :   Passive role MUST NOT begin sending BFD packets for a particular
> :   session until it has received a BFD packet for that session, and thus
> :   has learned the remote system's discriminator value
> 
> Passive governs the initial connection.  A system desiring to be passive
> can't fully go back to being passive until signaling to the remote system
> sufficiently to take the session to the Down state.
> 
> RFC 5880 §6.8.7:
> :   A system MUST NOT transmit BFD Control packets if bfd.RemoteDiscr is
> :   zero and the system is taking the Passive role.
> 
> We have a session that's transitioning, the RemoteDiscr was known, but
> procedure says to clear it:
> 
> RFC 5880 §6.8.1:
> :   bfd.RemoteDiscr
> :
> :  The remote discriminator for this BFD session.  This is the
> :  discriminator chosen by the remote system, and is totally opaque
> :  to the local system.  This MUST be initialized to zero.  If a
> :  period of a Detection Time passes without the receipt of a valid,
> :  authenticated BFD packet from the remote system, this variable
> :  MUST be set to zero.
> 
> So, without a deep comb-through of the RFC to find something that causes
> us
> to send Down "long enough", passive mode could indeed imply with
> pedantic
> reading of the RFC that you'd not do work that lets the remote take the
> state down.  (See the Daves' caveat about excess pedantry.)
> 
> The obvious thing to do here is that we need to send packets in the Down
> state for some period.  The reasonable question is, how long?  And even if
> we provide a length of time, the obvious point is "is that long enough?"
> 
> Since Demand mode isn't a core scenario for the bfd-unsolicited draft, we
> don't have the unfortunate circumstance that reporting the BFD state is
> difficult.  A session that was Up minimally in the presence of such pedantic
> behavior would simply go Down at the Active side once the Detection
> Interval
> expired.
> 
> Since bfd-unsolicited has implementations, what do YOUR implementations
> do?
> 
> One option would be to transmit Down for at least DetectMult number of
> packets.
> 
> -- Jeff

RE: Working Group Last Call for draft-ietf-bfd-unsolicited (ending 16 August, 2020)

[Les Ginsberg (ginsberg)]

Tom -

I defer to chairs/AD in this matter - but here is my understanding of the 
distinction between Normative and Informative References.
From https://www.rfc-editor.org/policy.html#policy.refs 

" Within an RFC, references to other documents fall into two general 
categories: "normative" and "informative". Normative references specify 
documents that must be read to understand or implement the technology in the 
new RFC, or whose technology must be present for the technology in the new RFC 
to work. An informative reference is not normative; rather, it only provides 
additional information. For example, an informative reference might provide 
background or historical information. Informative references are not required 
to implement the technology in the RFC."

To me what this means is that it is the role of the referenced document in the 
document in which the reference appears which determines its category - not 
whether the referenced document itself is Informational or Standard.
So an Informational RFC could be necessary to understand a standards track 
document - in which case it SHOULD be a Normative Reference.
Similarly, a Standards RFC could be merely informational in its role as a 
reference and therefore be an Informative Reference.

Of course what Jeff and I are suggesting is that there be one document which 
includes both YANG and the descriptive text of the functionality and that this 
be Informational.
The more relevant question seems to be whether it is a violation of IETF Policy 
to have YANG defined in an Informational RFC.

??

   Les


> -Original Message-
> From: tom petch 
> Sent: Wednesday, August 19, 2020 1:54 AM
> To: Les Ginsberg (ginsberg) ; Jeff Tantsura
> ; Reshad Rahman (rrahman)
> 
> Cc: rtg-bfd@ietf.org
> Subject: Re: Working Group Last Call for draft-ietf-bfd-unsolicited (ending 16
> August, 2020)
> 
> From: Rtg-bfd  on behalf of Les Ginsberg
> (ginsberg) 
> Sent: 19 August 2020 06:44
> 
> I would prefer this as well – but if that violates some YANG process in the
> IETF please do make sure the draft clearly states that there are no protocol
> changes.
> 
> 
> The YANG will need a Normative Reference to the other document, AFAICT,
> so making the other document Informative just introduces complications to
> the process,
> 
> Tom Petch
> 
> 
> 
> 
> 
>Les
> 
> 
> From: Jeff Tantsura 
> Sent: Tuesday, August 18, 2020 8:09 PM
> To: Reshad Rahman (rrahman) 
> Cc: Robert Raszuk ; Les Ginsberg (ginsberg)
> ; Martin Vigoureux ;
> rtg-bfd@ietf.org
> Subject: Re: Working Group Last Call for draft-ietf-bfd-unsolicited (ending 16
> August, 2020)
> 
> An informational document that also has a  management/YANG part included
> would IMHO be the right outcome.
> Regards,
> Jeff
> 
> 
> On Aug 18, 2020, at 19:38, Reshad Rahman (rrahman)
> mailto:rrah...@cisco.com>> wrote:
> 
> Hi Jeff and Les,
> 
> In general I  prefer to have the 2 together (here’s the protocol details and
> here’s how it’s managed), IMHO there’s benefit in having the 2 together
> since the YANG discussions are happening while we’re in the thick of the
> protocol discussions. I am actually not keen to end up with 2 docs, RFC XXX
> and RFC : YANG for  with 2 different lifecycles, by the time the
> YANG is done people aren’t interested anymore because the protocol spec is
> done.  I brought this up some time ago with RTG AD and OPS AD, but I don’t
> think there was any conclusion.
> 
> In this specific case, I agree that there’s no protocol changes. So with 2
> documents, are you proposing that the BFD spec should be informational and
> the YANG standards track? Or both informational? If it’s the latter, I’d 
> rather
> they be in the same doc.
> 
> Regards,
> Reshad ( no hat).
> From: Jeff Tantsura
> mailto:jefftant.i...@gmail.com>>
> Date: Tuesday, August 18, 2020 at 9:01 PM
> To: Robert Raszuk mailto:rob...@raszuk.net>>, "Les
> Ginsberg (ginsberg)" mailto:ginsb...@cisco.com>>,
> "Reshad Rahman (rrahman)"
> mailto:rrah...@cisco.com>>, Martin Vigoureux
> mailto:martin.vigour...@nokia.com>>
> Cc: "rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>"  b...@ietf.org<mailto:rtg-bfd@ietf.org>>
> Subject: Re: Working Group Last Call for draft-ietf-bfd-unsolicited (ending 16
> August, 2020)
> 
> IMHO - It isn’t right that presence of YANG defines document’  designation
> track. The common practice is that if the draft in question doesn’t require 
> any
> protocol changes it should aim for Informational track (or BCP).
> https://ietf.org/standards/process/informational-vs-experimental/
> 
> I’d rather have 2 separate documents. In general, given t

RE: Working Group Last Call for draft-ietf-bfd-unsolicited (ending 16 August, 2020)

[Les Ginsberg (ginsberg)]

I would prefer this as well – but if that violates some YANG process in the 
IETF please do make sure the draft clearly states that there are no protocol 
changes.

   Les


From: Jeff Tantsura 
Sent: Tuesday, August 18, 2020 8:09 PM
To: Reshad Rahman (rrahman) 
Cc: Robert Raszuk ; Les Ginsberg (ginsberg) 
; Martin Vigoureux ; 
rtg-bfd@ietf.org
Subject: Re: Working Group Last Call for draft-ietf-bfd-unsolicited (ending 16 
August, 2020)

An informational document that also has a  management/YANG part included would 
IMHO be the right outcome.
Regards,
Jeff


On Aug 18, 2020, at 19:38, Reshad Rahman (rrahman) 
mailto:rrah...@cisco.com>> wrote:

Hi Jeff and Les,

In general I  prefer to have the 2 together (here’s the protocol details and 
here’s how it’s managed), IMHO there’s benefit in having the 2 together since 
the YANG discussions are happening while we’re in the thick of the protocol 
discussions. I am actually not keen to end up with 2 docs, RFC XXX and RFC 
: YANG for  with 2 different lifecycles, by the time the YANG is done 
people aren’t interested anymore because the protocol spec is done.  I brought 
this up some time ago with RTG AD and OPS AD, but I don’t think there was any 
conclusion.

In this specific case, I agree that there’s no protocol changes. So with 2 
documents, are you proposing that the BFD spec should be informational and the 
YANG standards track? Or both informational? If it’s the latter, I’d rather 
they be in the same doc.

Regards,
Reshad ( no hat).
From: Jeff Tantsura mailto:jefftant.i...@gmail.com>>
Date: Tuesday, August 18, 2020 at 9:01 PM
To: Robert Raszuk mailto:rob...@raszuk.net>>, "Les Ginsberg 
(ginsberg)" mailto:ginsb...@cisco.com>>, "Reshad Rahman 
(rrahman)" mailto:rrah...@cisco.com>>, Martin Vigoureux 
mailto:martin.vigour...@nokia.com>>
Cc: "rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>" 
mailto:rtg-bfd@ietf.org>>
Subject: Re: Working Group Last Call for draft-ietf-bfd-unsolicited (ending 16 
August, 2020)

IMHO - It isn’t right that presence of YANG defines document’  designation 
track. The common practice is that if the draft in question doesn’t require any 
protocol changes it should aim for Informational track (or BCP).
https://ietf.org/standards/process/informational-vs-experimental/

I’d rather have 2 separate documents. In general, given that YANG documents 
life cycle is quite different from that of protocol ones, it is perhaps a good 
practice to keep them separate.
I have included Martin (Routing AD for BFD)

Cheers,
Jeff
On Aug 18, 2020, 4:24 AM -0700, Reshad Rahman (rrahman) 
mailto:rrahman=40cisco@dmarc.ietf.org>>,
 wrote:


Indeed, draft-chen-bfd-unsolicited was informational and with the addition of 
the YANG module draft-ietf-bfd-unsolicted was changed to standards track.

Regards,
Reshad (no hat).

From: Rtg-bfd mailto:rtg-bfd-boun...@ietf.org>> on 
behalf of Robert Raszuk mailto:rob...@raszuk.net>>
Date: Tuesday, August 18, 2020 at 5:44 AM
To: "Les Ginsberg (ginsberg)" 
mailto:ginsberg=40cisco@dmarc.ietf.org>>
Cc: "rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>" 
mailto:rtg-bfd@ietf.org>>
Subject: Re: Working Group Last Call for draft-ietf-bfd-unsolicited (ending 16 
August, 2020)

Hi Les,

While shifting to Informational would be perhaps ok protocol wise - isn't it 
common practice in IETF that any draft (or at least most of them) which define 
a YANG model is a Standards Track document ?

I hope you are not suggesting to split this one into two :).

Thx,
R.

On Tue, Aug 18, 2020 at 5:36 AM Les Ginsberg (ginsberg) 
mailto:40cisco@dmarc.ietf.org>> wrote:
Sorry to be tardy in responding...

As I stated almost 2 years ago when this draft was introduced:

a)The problem the draft is addressing is real and the solution useful

b)There are implementations which have already addressed this problem with no 
interoperability issues

c)I do not see that any changes have been made to the BFD protocol (e.g.. RFC 
5881)

Therefore, I think this should go forward - but as Informational.

   Les


> -Original Message-
> From: Rtg-bfd mailto:rtg-bfd-boun...@ietf.org>> On 
> Behalf Of Jeffrey Haas
> Sent: Monday, August 17, 2020 1:45 PM
> To: rtg-...@ietf..org<mailto:rtg-bfd@ietf.org>
> Subject: Re: Working Group Last Call for draft-ietf-bfd-unsolicited (ending 16
> August, 2020)
>
> On Tue, Aug 04, 2020 at 09:21:22AM -0400, Jeffrey Haas wrote:
> > Working Group,
> >
> > https://datatracker.ietf.org/doc/draft-ietf-bfd-unsolicited/
> >
> > With apologies to the authors of BFD unsolicited, this document is past due
> > for Working Group Last Call.  The primary holdup on the document had
> been
> > last minute interaction with the RFC Editor with regard to its impact on the
> > BFD Yang model.  That work ha

RE: Working Group Last Call for draft-ietf-bfd-unsolicited (ending 16 August, 2020)

[Les Ginsberg (ginsberg)]

So, I won’t prolong what is now becoming an administrative discussion – except 
to say:

If the standards part of the document is the YANG model, then the draft should 
be renamed to indicate that it is a YANG document – and the description of the 
implementation behavior (Section 2 mostly) is just there as supportive context.
Otherwise, we have a case of the tail wagging the dog…

But, I leave it to others to decide what to do.

For me, the most important thing is that the content is good.
It might be good to have a statement in the draft that specifies no protocol 
changes are introduced – which I gather will be discussed as part of reviewing 
Greg’s comments.

   Les


From: Reshad Rahman (rrahman) 
Sent: Tuesday, August 18, 2020 4:24 AM
To: Robert Raszuk ; Les Ginsberg (ginsberg) 

Cc: rtg-bfd@ietf.org
Subject: Re: Working Group Last Call for draft-ietf-bfd-unsolicited (ending 16 
August, 2020)

Indeed, draft-chen-bfd-unsolicited was informational and with the addition of 
the YANG module draft-ietf-bfd-unsolicted was changed to standards track.

Regards,
Reshad (no hat).

From: Rtg-bfd mailto:rtg-bfd-boun...@ietf.org>> on 
behalf of Robert Raszuk mailto:rob...@raszuk.net>>
Date: Tuesday, August 18, 2020 at 5:44 AM
To: "Les Ginsberg (ginsberg)" 
mailto:ginsberg=40cisco@dmarc.ietf.org>>
Cc: "rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>" 
mailto:rtg-bfd@ietf.org>>
Subject: Re: Working Group Last Call for draft-ietf-bfd-unsolicited (ending 16 
August, 2020)

Hi Les,

While shifting to Informational would be perhaps ok protocol wise - isn't it 
common practice in IETF that any draft (or at least most of them) which define 
a YANG model is a Standards Track document ?

I hope you are not suggesting to split this one into two :).

Thx,
R.

On Tue, Aug 18, 2020 at 5:36 AM Les Ginsberg (ginsberg) 
mailto:40cisco@dmarc.ietf.org>> wrote:
Sorry to be tardy in responding...

As I stated almost 2 years ago when this draft was introduced:

a)The problem the draft is addressing is real and the solution useful

b)There are implementations which have already addressed this problem with no 
interoperability issues

c)I do not see that any changes have been made to the BFD protocol (e.g. RFC 
5881)

Therefore, I think this should go forward - but as Informational.

   Les


> -Original Message-
> From: Rtg-bfd mailto:rtg-bfd-boun...@ietf.org>> On 
> Behalf Of Jeffrey Haas
> Sent: Monday, August 17, 2020 1:45 PM
> To: rtg-...@ietf..org<mailto:rtg-bfd@ietf.org>
> Subject: Re: Working Group Last Call for draft-ietf-bfd-unsolicited (ending 16
> August, 2020)
>
> On Tue, Aug 04, 2020 at 09:21:22AM -0400, Jeffrey Haas wrote:
> > Working Group,
> >
> > https://datatracker.ietf.org/doc/draft-ietf-bfd-unsolicited/
> >
> > With apologies to the authors of BFD unsolicited, this document is past due
> > for Working Group Last Call.  The primary holdup on the document had
> been
> > last minute interaction with the RFC Editor with regard to its impact on the
> > BFD Yang model.  That work had completed some time ago.  (The Yang
> model,
> > however, is still lingering in MISREF state.)
> >
> > This begins a last call period ending on 16 August.
>
> The last call period has ended with a few comments from Greg and Raj that
> should be addressed before we continue.
>
> It'd also be helpful to hear from additional reviewers before we advance
> this document.
>
> -- Jeff

RE: Working Group Last Call for draft-ietf-bfd-unsolicited (ending 16 August, 2020)

[Les Ginsberg (ginsberg)]

Sorry to be tardy in responding...

As I stated almost 2 years ago when this draft was introduced:

a)The problem the draft is addressing is real and the solution useful

b)There are implementations which have already addressed this problem with no 
interoperability issues

c)I do not see that any changes have been made to the BFD protocol (e.g. RFC 
5881)

Therefore, I think this should go forward - but as Informational.

   Les


> -Original Message-
> From: Rtg-bfd  On Behalf Of Jeffrey Haas
> Sent: Monday, August 17, 2020 1:45 PM
> To: rtg-bfd@ietf.org
> Subject: Re: Working Group Last Call for draft-ietf-bfd-unsolicited (ending 16
> August, 2020)
> 
> On Tue, Aug 04, 2020 at 09:21:22AM -0400, Jeffrey Haas wrote:
> > Working Group,
> >
> > https://datatracker.ietf.org/doc/draft-ietf-bfd-unsolicited/
> >
> > With apologies to the authors of BFD unsolicited, this document is past due
> > for Working Group Last Call.  The primary holdup on the document had
> been
> > last minute interaction with the RFC Editor with regard to its impact on the
> > BFD Yang model.  That work had completed some time ago.  (The Yang
> model,
> > however, is still lingering in MISREF state.)
> >
> > This begins a last call period ending on 16 August.
> 
> The last call period has ended with a few comments from Greg and Raj that
> should be addressed before we continue.
> 
> It'd also be helpful to hear from additional reviewers before we advance
> this document.
> 
> -- Jeff

RE: BFD chair response to presentation on draft-mirmin-bfd-extended

[Les Ginsberg (ginsberg)]

For the record, I agree with Jeff's summary and comments.

I was really surprised that Greg did not wait until IETF 107 - which the BFD 
chairs had already indicated would be the time to resume discussions of this 
work.
However well intentioned, both the timing and the WG were inappropriate for 
this presentation.

   Les


> -Original Message-
> From: Rtg-bfd  On Behalf Of Jeffrey Haas
> Sent: Thursday, November 21, 2019 6:53 PM
> To: rt...@ietf.org
> Cc: rtg-bfd@ietf.org
> Subject: BFD chair response to presentation on draft-mirmin-bfd-extended
> 
> In the interest of permitting the presentations to move smoothly at this
> Friday's rtgwg session, I withheld my comments from microphone.  However,
> please consider these comments for the record for IETF-106.
> 
> Firstly, I'm surprised the chairs had a BFD presentation at rtgwg.  rtgwg is
> indeed intended to be a general purpose dispatch group for work without a
> home, but that's not the case for BFD.
> 
> Secondly, Reshad and I intentionally did not schedule work on BFD extension
> work, including Greg's presentation, for this IETF.  This is because there
> is open charter discussions we're starting with the IESG on this space.
> 
> -
> 
> Specific comments on BFD extension work and the charter discussions:
> 
> During prior IETFs, and culminating at IETF-105, we've seen regular work to
> try to stuff BFD with additional features of various forms.  The litmus test
> generally used for BFD's core use case over the years has been "what do you
> want to hear every 3.3ms?"  To that end, things that enhance BFD's core
> continuity verification uses cases have ended up in the protocol.
> 
> Somewhat similar to other popular protocols such as DNS and BGP, BFD has
> nice properties that make it an appealing place to try to extend.  In
> particular, it's a continuing conversation between two systems.
> 
> During IETF-105, the IPPM group members attending explicitly noted that they
> did not want to see their mechanisms present in BFD and did not consider it
> a good fit.
> 
> As part of that discussion, the chairs noted that one option potentially
> open is that we permit the "BFDv2" option we have discussed at IETF-105 and
> previous to permit an option where we do not use the core BFDv1 session used
> for continuity for these extensions, and use a different protocol version
> and port set to enable the other use cases.
> 
> Thus, the discussion with the IESG is whether BFD hands over the "gift" of a
> general and mature mechanism for a conversation between two systems that
> may
> be generally extended to carry "interesting" information.
> 
> This addresses Tony Li's point about "please don't make BFD difficult to
> implement in hardware".
> 
> -
> 
> Specific comments on draft-mirmin-bfd-extended:
> 
> The somewhat peculiar extension mechanism shown in Greg's draft was
> originally seeded by work I started in BFD for draft-ietf-bfd-large-packets.
> In fairness to history, this was similar to work that was done in OSPF years
> back for how the authentication mechanism was spliced onto the protocol.
> The one sentence description of that use case is "make the packet padded to
> test MTU".  It's a hack, but one that does a reasonable job of its use case.
> 
> However, with regard to leveraging this hack for a general purpose extension
> mechanism, I don't find it a good fit.  BFDv1 does not expect to find
> information regarding the packet or state machine outside of the main PDU..
> It is likely a new version number will need to be used to establish future
> semantics.  (Per prior discussion in the working group.)
> 
> The capabilities mechanism will likely require either integration into some
> form of an updated state machine for the new version header, or a different
> form.  IMO, I find it likely that a "capability advertisement" mechanism
> would be necessary rather than negotiation to avoid a wholesale replacement
> of the BFD state machinery.  And if we replace that much of the machinery,
> let's just stop calling this BFD at all and move on.
> 
> With regard to IPPM style content for the draft, I refer you to the IPPM
> members comments above from IETF-105.
> 
> With regard to authentication, there are two possibilities here:
> - Faster authentication of BFD style packets is covered by work completing
>   BFD WGLC draft-ietf-bfd-optimitizing-authentication.  I'd encourage other
>   working groups in need of a faster per-packet authentication mechanism to
>   consider whether it's an appropriate fit.
> - In the case that such a future BFD, or mechanism built on similar
>   machinery, want a way to autenticate the payload different from the
>   headers, there will likely need to be discussion about not only what
>   envelope is used, but also strength vs. periodicity.  (And if you don't need
>   this stuff periodically, why use something like BFD?)
> 
> -- Jeff

RE: draft-ietf-bfd-large-packets-02

[Les Ginsberg (ginsberg)]

Jeff -

I do not have a specific model in mind for S-BFD and large packets - 
implementations should be free to choose. I think you have covered the options 
well in your comments below. Mainly I wanted this discussed in the draft.

The only thing that might be troublesome is the notion of using a separate 
discriminator for large packet S-BFD (yes - I suggested this - not you ). This 
raises the unsolved problem of how does one indicate which discriminator is for 
which use case. Although the IGP extensions support advertising multiple S-BFD 
discriminators we never figured out how to indicate how a given discriminator 
should be used. I only mention it since this draft introduces a possible use 
case for multiple S-BFD discriminators - but this isn’t a new issue and doesn’t 
have to be solved by this draft.

   Les


> -Original Message-
> From: Jeffrey Haas 
> Sent: Wednesday, November 06, 2019 8:47 AM
> To: Les Ginsberg (ginsberg) 
> Cc: rtg-bfd@ietf.org
> Subject: Re: draft-ietf-bfd-large-packets-02
> 
> Les,
> 
> 
> > On Nov 5, 2019, at 12:55 AM, Les Ginsberg (ginsberg)
>  wrote:
> >
> > Jeff/Albert -
> >
> > Thanx for the updated version. This addresses my concerns.
> >
> > A couple of modest comments.
> >
> > 1)Section 3.4
> >
> > s/that balacing/that balancing
> 
> Queued for next rev.
> 
> > 2)Regarding S-BFD (Section 3.5)
> >
> > It would seem difficult to support (for a given discriminator) some sessions
> using large packets and some not. I  can think of a few options:
> >
> > a)Passive end uses large packets only if the Active end does. This assumes
> MTU is the same in both directions.
> 
> Asymmetric MTUs are not only possible, but likely in S-BFD scenarios.  But 
> it's
> a valid point.
> 
> > b)A separate discriminator is used for large packet sessions
> > c)Use of large packets is always on (or always off) on the passive side
> >
> > Probably there are other choices.
> >
> > What did you have in mind? I think adding some guidance in that regard
> might be useful.
> 
> My personal thought on the matter had been roughly:
> - By default, respond with the same size IP encapsulation as you receive.
> - While S-BFD permits largely non-configured responses to Initiators, there's
> likely to be SOME configuration present.  If necessary, specific configuration
> can be given to cover size of packets to respond to.  (Roughly aligning with
> the ACLs used to manage whom can initiate S-BFD in the first place.)
> 
> One way to interpret your questions is that there should be some implied
> configuration for BFD for Large Packets, not only on the sending side, but on
> the receiver.
> 
> For the receiver, something roughly like "bfd.PaddedPduReceiveMaxSize" as
> a parameter.  Possibly acting also as a way to enable the feature or not.
> 
> For an S-BFD reflector, perhaps parameters to control beyond the receive
> max size whether it responds with the same size as the iP encapsulation, and
> whether there's a cap for such a response.
> 
> Does the above address your concerns?
> 
> -- Jeff

RE: draft-ietf-bfd-large-packets-02

[Les Ginsberg (ginsberg)]

Jeff/Albert -

Thanx for the updated version. This addresses my concerns.

A couple of modest comments.

1)Section 3.4

s/that balacing/that balancing


2)Regarding S-BFD (Section 3.5)

It would seem difficult to support (for a given discriminator) some sessions 
using large packets and some not. I  can think of a few options:

a)Passive end uses large packets only if the Active end does. This assumes MTU 
is the same in both directions.
b)A separate discriminator is used for large packet sessions
c)Use of large packets is always on (or always off) on the passive side

Probably there are other choices.

What did you have in mind? I think adding some guidance in that regard might be 
useful.

   Les


> -Original Message-
> From: Rtg-bfd  On Behalf Of Jeffrey Haas
> Sent: Friday, November 01, 2019 8:53 AM
> To: rtg-bfd@ietf.org
> Subject: draft-ietf-bfd-large-packets-02
> 
> Working Group,
> 
> This version attempts to roll up all discussion points to date.  Your
> further review is appreciated.
> 
> -- Jeff and Albert
> 
> - Forwarded message from internet-dra...@ietf.org -
> 
> Date: Fri, 01 Nov 2019 08:46:00 -0700
> From: internet-dra...@ietf.org
> To: i-d-annou...@ietf.org
> Cc: rtg-bfd@ietf.org
> Subject: I-D Action: draft-ietf-bfd-large-packets-02.txt
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Bidirectional Forwarding Detection WG of the
> IETF.
> 
> Title   : BFD Encapsulated in Large Packets
> Authors : Jeffrey Haas
>   Albert Fu
>   Filename: draft-ietf-bfd-large-packets-02.txt
>   Pages   : 7
>   Date: 2019-11-01
> 
> Abstract:
>The Bidirectional Forwarding Detection (BFD) protocol is commonly
>used to verify connectivity between two systems.  BFD packets are
>typically very small.  It is desirable in some circumstances to know
>that not only is the path between two systems reachable, but also
>that it is capable of carrying a payload of a particular size.  This
>document discusses thoughts on how to implement such a mechanism
>using BFD in Asynchronous mode.
> 
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-bfd-large-packets/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-bfd-large-packets-02
> https://datatracker.ietf.org/doc/html/draft-ietf-bfd-large-packets-02
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-large-packets-02
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> - End forwarded message -

RE: WGLC for draft-ietf-bfd-large-packets

[Les Ginsberg (ginsberg)]

Jeff -

For some reason this is proving to be harder than I think it should be.

I keep thinking I am being transparent - yet you keep reading "ulterior 
motives" into what I say.
There are no ulterior motives.

Let me try again...inline...

> -Original Message-
> From: Jeffrey Haas 
> Sent: Thursday, October 03, 2019 1:13 PM
> To: Les Ginsberg (ginsberg) 
> Cc: Ketan Talaulikar (ketant) ; Reshad Rahman
> (rrahman) ; rtg-bfd@ietf.org
> Subject: Re: WGLC for draft-ietf-bfd-large-packets
> 
> Les,
> 
> On Fri, Sep 27, 2019 at 09:14:08PM +, Les Ginsberg (ginsberg) wrote:
> > > The primary reason this is a "may" in the non-RFC 2119 sense is that our
> > > experience also suggests that when the scaling impacts are primarily pps
> > > rather than bps that this feature will likely have no major impact on
> > > implementations beyond your valid concerns about exercising bugs.
> > >
> > > I suspect had this not been mentioned at all, you would have been
> happier.
> > > But you're not the target audience for this weak caveat.
> > >
> >
> > [Les:] I am not opposed to a discussion of potential issues in the draft -
> > rather I am encouraging it. But the current text isn't really on the mark
> > as far as potential issues - and we seem to agree on that. It also
> > suggests lengthening detection time to compensate - which I think is not
> > at all what you want to suggest as it diminishes the value of the
> > extension. It also isn't likely to address a real problem.
> 
> I think what I'm seeing from you is roughly:
> - Note that larger MTUs may have impact on some implementations for BFD
>   throughput.
> - And simply stop there.
> 
[Les:] What I would like to see discussed are points "a" and "b" below.
This is a section on deployment issues - not a normative part of the spec.

> > For me, the potential issues are:
> >
> > a)Some BFD implementations might not be able to handle MTU sized BFD
> > packets - not because of performance - but because they did not expect
> BFD
> > packets to be full size and therefore might have issues passing a large
> > packet through the local processing engine.
> 
> In such cases, the BFD session wouldn't be able to come up.  Are you
> picturing a problem more dire than that?
> 

[Les:] No. Again, as this is a discussion of deployment considerations I see 
this as an aid to indicate what problems may be seen.
I am not asking you to "fix" the extension to overcome this.

> > b)Accepted MTU is impacted by encapsulations and what layer is being
> > considered (L2 or L3). And oftentimes link MTUs do not match on both
> ends
> > ("shudder"), so you might end up with unidirectional connectivity.
> 
> Did you mean for BFD or more in the general sense?

[Les:] It is a problem in the general sense, but it is relevant here because 
the extension proposes to send large packets. Absent that, MTU mismatches would 
be very unlikely to affect BFD since the BFD packet size is small.

> 
> For BFD, if you have one side testing for large MTU but not the other, we
> can still have a Up BFD session with possible packet drop for large packets
> on the opposite side.  But there's the chance in some paths that MTU may be
> unidirectionally different - e.g. satellite down vs. land up.[1]
> 
In such cases, configuring BFD large on both sides would be the right
> answer.  But it's also possible that large packets may only need to be
> unidirectionally delivered.
> 

[Les:] I agree - and I think it is valid to use the extension unidirectionally 
in such cases.

>
> > I
> > appreciate that this is exactly the problem that the extensions are
> > designed to detect. I am just asking that these issues be discussed more
> > explicitly as an aid to the implementor. If that also makes Transports ADs
> > happier that is a side benefit - but that's not my motivation.
> 
> We're happy to have that in the document.
> 

[Les:] Great!!

> > > > What might be better?
> > > >
> > > > 1)Some statement that MTU isn't necessarily a consistent value for all
> > > > systems connected to an interface - which can impact the results when
> large
> > > > BFD packets are used. Implementations might then want to consider
> > > > supporting "bfd-mtu" configuration and/or iterating across a range of
> packet
> > > > sizes to determine what works and what doesn't.
> > >
> > > I'm not clear what you intend by this statement.
> > >
> > > Are you asking that we emphasize the use case in a different way?  The
> > > I

RE: WGLC for draft-ietf-bfd-large-packets

[Les Ginsberg (ginsberg)]

Jeff -

Inline.

> -Original Message-
> From: Jeffrey Haas 
> Sent: Thursday, September 26, 2019 12:50 PM
> To: Les Ginsberg (ginsberg) 
> Cc: Ketan Talaulikar (ketant) ; Reshad Rahman
> (rrahman) ; rtg-bfd@ietf.org
> Subject: Re: WGLC for draft-ietf-bfd-large-packets
> 
> Les,
> 
> On Tue, Sep 24, 2019 at 10:48:51PM +, Les Ginsberg (ginsberg) wrote:
> > A few more thoughts - maybe these are more helpful than my previous
> comments - maybe not. I am sure you will let me know.
> >
> > Protocol extensions allowing negotiation and/or advertisement of support
> for larger PDUs may well be useful - but let's agree that it is desirable to
> deploy this without protocol extensions just to keep the interoperability bar
> low.
> >
> > My primary angst is with the following paragraph in Section 3:
> >
> > "It is also worthy of note that even if an implementation can function
> >with larger transport PDUs, that additional packet size may have
> >impact on BFD scaling.  Such systems may support a lower transmission
> >interval (bfd.DesiredMinTxInterval) when operating in large packet
> >mode.  This interval may depend on the size of the transport PDU."
> >
> > Given long experience that CPU use correlates more highly with number of
> packets than with number of bytes, the first sentence would seem to be
> weakly supported.
> > Given the previously mentioned concerns about detection time, the
> second sentence seems to compromise the value of the extension.
> 
> My experience is largely identical to yours.
> 
> The motivation for mentioning anything at all here is TANSTAAFL[1], and
> we've already had people ask about possible impacts.  And, as we discussed
> previously in the thread we shall inevitably get asked about it during TSV
> review in IESG.
> 
> The primary reason this is a "may" in the non-RFC 2119 sense is that our
> experience also suggests that when the scaling impacts are primarily pps
> rather than bps that this feature will likely have no major impact on
> implementations beyond your valid concerns about exercising bugs.
> 
> I suspect had this not been mentioned at all, you would have been happier..
> But you're not the target audience for this weak caveat.
> 

[Les:] I am not opposed to a discussion of potential issues in the draft - 
rather I am encouraging it. But the current text isn't really on the mark as 
far as potential issues - and we seem to agree on that. It also suggests 
lengthening detection time to compensate - which I think is not at all what you 
want to suggest as it diminishes the value of the extension. It also isn't 
likely to address a real problem.


For me, the potential issues are:

a)Some BFD implementations might not be able to handle MTU sized BFD packets - 
not because of performance - but because they did not expect BFD packets to be 
full size and therefore might have issues passing a large packet through the 
local processing engine.

b)Accepted MTU is impacted by encapsulations and what layer is being considered 
(L2 or L3). And oftentimes link MTUs do not match on both ends ("shudder"), so 
you might end up with unidirectional connectivity. I appreciate that this is 
exactly the problem that the extensions are designed to detect. I am just 
asking that these issues be discussed more explicitly as an aid to the 
implementor. If that also makes Transports ADs happier that is a side benefit - 
but that's not my motivation.

> > What might be better?
> >
> > 1)Some statement that MTU isn't necessarily a consistent value for all
> systems connected to an interface - which can impact the results when large
> BFD packets are used. Implementations might then want to consider
> supporting "bfd-mtu" configuration and/or iterating across a range of packet
> sizes to determine what works and what doesn't.
> 
> I'm not clear what you intend by this statement.
> 
> Are you asking that we emphasize the use case in a different way?  The
> Introduction currently states:
>   "However,
>some applications may require that the Path MTU [RFC1191] between
>those two systems meets a certain minimum criteria.  When the Path
>MTU decreases below the minimum threshold, those applications may
>wish to consider the path unusable."
> 
> I'm also unclear what "Implementations" may refer to here.  BFD?  An
> arbitrary user application?  If the latter, the application may not have
> strict control over the generation of a given PDU size; e.g. TCP
> applications.
> 

[Les:] I am talking about BFD implementations.
I suppose one can imagine each BFD client requesting a certain MTU value - but 
that wouldn't be my choice.
I would think the v

RE: WGLC for draft-ietf-bfd-large-packets

[Les Ginsberg (ginsberg)]

Jeff -

A few more thoughts - maybe these are more helpful than my previous comments - 
maybe not. I am sure you will let me know.

Protocol extensions allowing negotiation and/or advertisement of support for 
larger PDUs may well be useful - but let's agree that it is desirable to deploy 
this without protocol extensions just to keep the interoperability bar low.

My primary angst is with the following paragraph in Section 3:

"It is also worthy of note that even if an implementation can function
   with larger transport PDUs, that additional packet size may have
   impact on BFD scaling.  Such systems may support a lower transmission
   interval (bfd.DesiredMinTxInterval) when operating in large packet
   mode.  This interval may depend on the size of the transport PDU."

Given long experience that CPU use correlates more highly with number of 
packets than with number of bytes, the first sentence would seem to be weakly 
supported.
Given the previously mentioned concerns about detection time, the second 
sentence seems to compromise the value of the extension.

What might be better?

1)Some statement that MTU isn't necessarily a consistent value for all systems 
connected to an interface - which can impact the results when large BFD packets 
are used. Implementations might then want to consider supporting "bfd-mtu" 
configuration and/or iterating across a range of packet sizes to determine what 
works and what doesn't.

2)Use of both padded and unpadded packets in combination with 
draft-ietf-bfd-stability to determine whether a BFD failure is due to padding 
or a generic forwarding failure.

Either of these suggestions are really "diagnostic modes" which may help 
diagnose a problem but aren't meant to be used continuously as part of fast 
failure detection.

   Les


> -Original Message-
> From: Jeffrey Haas 
> Sent: Thursday, September 19, 2019 5:17 AM
> To: Les Ginsberg (ginsberg) 
> Cc: Ketan Talaulikar (ketant) ; Reshad Rahman
> (rrahman) ; rtg-bfd@ietf.org
> Subject: Re: WGLC for draft-ietf-bfd-large-packets
> 
> Les,
> 
> 
> > On Sep 18, 2019, at 10:37 PM, Les Ginsberg (ginsberg)
>  wrote:
> >
> > First I would like to reemphasize that I support the draft - so we aren't on
> opposite sides here. It is just that Last Call seems premature.
> 
> The purpose of WGLC is to shake out final comments when things have
> otherwise stalled.  If it's not ready, we're not bothered by that. :-)
> 
> That said, we need to match concerns with something actionable.  That's
> what I'm hunting for.
> 
> > As for the comparison with authentication...
> >
> > Authentication added new functionality which cost CPU time. The tradeoff
> there was clear - performance/scale vs security. But there was no concern
> that the addition of the authentication bytes in and of itself might 
> introduce a
> problem.
> 
> Most of your commentary was focused around the impact on detection time,
> hence the response you got regarding other features that have similar
> impact.
> 
> So, if we've moved on from detection time impact of features to other
> issues, that's fine.
> 
> >
> > Large packets introduces MTU sized packets - which in and of itself is
> unlikely to cause a performance issue. But, having spent a fair number of
> hours debugging MTU related issues of various flavors, I do think it is 
> likely to
> expose bugs in packet processing related to size. It shouldn't - in a perfect
> world - but what chips/software does with sub-MTU sized packets doesn't
> always translate to MTU size packets. And since the definition of what MTU is
> isn't consistent across vendors (let alone even within a single vendor's
> products) there are many ways to screw up configuration here. Throw in all
> the various flavors of encaps...I think we can expect deployment issues - and
> maybe bugs as well.
> 
> I think Albert is happy to see this text. :-)
> 
> The primary purpose of this feature is to shake loose issues related to MTU
> sized packets and try to remove such paths from service when we can't
> forward through them.  The path detection at speed is a general good fit for
> BFD.
> 
> What I'm concerned about is you're trying to point out "when there are
> issues, this doesn't help - and at best exacerbates them".  If so... well, 
> this
> feature isn't intended to be a debugging layer for those sort of issues.
> However, since BFD is riding on top of various transports to do this job, if 
> the
> encapsulation can carry additional information that permits such debugging
> information, we're amenable to discussing what to do with it.
> 
> -- Jeff

RE: WGLC for draft-ietf-bfd-large-packets

[Les Ginsberg (ginsberg)]

Jeff -

First I would like to reemphasize that I support the draft - so we aren't on 
opposite sides here. It is just that Last Call seems premature.

As for the comparison with authentication...

Authentication added new functionality which cost CPU time. The tradeoff there 
was clear - performance/scale vs security. But there was no concern that the 
addition of the authentication bytes in and of itself might introduce a problem.

Large packets introduces MTU sized packets - which in and of itself is unlikely 
to cause a performance issue. But, having spent a fair number of hours 
debugging MTU related issues of various flavors, I do think it is likely to 
expose bugs in packet processing related to size. It shouldn't - in a perfect 
world - but what chips/software does with sub-MTU sized packets doesn't always 
translate to MTU size packets. And since the definition of what MTU is isn't 
consistent across vendors (let alone even within a single vendor's products) 
there are many ways to screw up configuration here. Throw in all the various 
flavors of encaps...I think we can expect deployment issues - and maybe bugs as 
well.

Just my thoughts...

   Les


> -Original Message-
> From: Jeffrey Haas 
> Sent: Wednesday, September 18, 2019 7:01 PM
> To: Les Ginsberg (ginsberg) 
> Cc: Ketan Talaulikar (ketant) ; Reshad Rahman
> (rrahman) ; rtg-bfd@ietf.org
> Subject: Re: WGLC for draft-ietf-bfd-large-packets
> 
> Les,
> 
> On Thu, Sep 19, 2019 at 12:06:13AM +, Les Ginsberg (ginsberg) wrote:
> > > > If these protocol changes are to be made, shouldn't they be specified in
> > > this document?? Otherwise the document would seem just
> informational.
> > >
> > > No.  There's not really any room in BFD v1 for negotiation.  That would
> take
> > > something like BFDv2, as we've started discussing in the working group.
> > >
> >
> > [Les:] I am not fully comfortable with the notion that it is OK to deploy 
> > this
> w/o regard for whether existing implementations can handle it. I think there
> is some risk here and I would like the WG to discuss this point and - if 
> agreed
> to - have the draft explicitly state that the risks of deploying this w/o
> negotiation have been considered and deemed acceptable. The fact that one
> implementation had no issue with it isn't compelling.
> 
> FWIW, I'm not blowing off your considerations.  Mostly, I'm highlighting
> that we get them regularly.  TSV review of BFD in every flavor over the
> entire life of the protocol has been some variety of this conversation.  We
> just get to replay the entire life of BFD RFCs within such considerations
> with every new TSV area director. :-)
> 
> Obviously it's up to Reshad as the shepherding chair how this process plays
> forward, but I suspect it'll resemble:
> - Getting further consensus from the rest of the WG whether this
>   consideration is a sticking point.
> - If it is, do we force this to be deferred to BFD v2?
> - Alternatively, can we cleverly figure out some way to wedge negotiation on
>   top of the existing feature in a backward compatible way?  (My answer:
>   possibly.  Whether it's worth the complexity bump is the arguable
> component
>   since simplicity of the protocol has been a stronger driving factor for
>   implementors than scaling considerations.)
> 
> I'd like to hear from other implementors whether they share your concerns..
> But either way, this exact conversation will play out again with the TSV ADs
> during IESG review.  This is expected.
> 
> > > However, this isn't particularly different from any other BFD
> considerations
> > > we've had over the years across all uses of BFD.  Your scale for sessions
> > > vs. timers will depend on transport, whether it's distributed to the line
> > > card or not, hardware support vs. general purpose CPU, etc.  BFD
> > > implementors and users expect to do some level of tuning.   This is
> normal.
> > >
> >
> > [Les:] The point I am highlighting is that we already have (at least for 
> > some
> deployments) a way to detect this within a scale of several seconds (or at
> least 10s of seconds).
> 
> You're over-simplifying your point slightly.  That's true for one protocol,
> IS-IS, where the padding can be done.  For those that can benefit from that
> scenario, great!  But I suspect you'd agree that not everyone is going to
> enable IS-IS on a link just to test MTU liveness.
> 
> > If the argument is that this is not fast enough, what is fast enough?
> 
> Much as you aren't a fan of RFC 7419, that's exactly why that document
> existed.  Some level of commonality was desired in order to develop more
> uniform scaling comparisons.
> 
> It

RE: WGLC for draft-ietf-bfd-large-packets

[Les Ginsberg (ginsberg)]

A few apologies:

1)Sorry to be late in responding - but just back from vacation.
2)As a number of my comments overlap with Ketan's, I decided to respond to this 
email - apologies if that adds confusion.
3)I will top post my reply in the hopes it will more universally readable - 
apologies if the lack of context makes things harder to understand.

With that out of the way...

I support this draft - but I do not think it is ready for last call.

There are very legitimate concerns about the impact supporting padded BFD PDUs 
may have on existing hardware implementations - both functionally and in terms 
of scalability.
As a standards track document I think more needs to be said about operational 
considerations - and I think there may be legitimate reasons to consider 
negotiation of the capability.
In particular the statement in Section 3:

"Additional changes to the base BFD   protocol may be required to permit 
negotiation of this functionality
 and the padding value."

If these protocol changes are to be made, shouldn't they be specified in this 
document?? Otherwise the document would seem just informational.

Section 3 also suggests 

  "support[ing] a lower transmission  interval (bfd.DesiredMinTxInterval)"

as a means of minimizing scalability impacts. But in early discussions of this 
draft it had been suggested that rather than use BFD for PathMTU validation we 
could use another protocol (e.g., IS-IS hellos) to do this. But that was 
rejected because it was stated that the deployment requirement required much 
faster detection. If that argument holds, then the suggestion in the draft to 
use longer timers seems inappropriate - or at least without sufficient context.

(BTW, by "lower transmission interval" I assume you mean a longer interval 
(i.e., a larger value for bfd.DesiredMinTxInterval)??)

I think these points need to be addressed in the draft before it is can be 
considered complete.

Les


> -Original Message-
> From: Rtg-bfd  On Behalf Of Jeffrey Haas
> Sent: Friday, September 13, 2019 5:34 AM
> To: Ketan Talaulikar (ketant) 
> Cc: Reshad Rahman (rrahman) ; rtg-bfd@ietf.org
> Subject: Re: WGLC for draft-ietf-bfd-large-packets
> 
> Ketan,
> 
> Thanks for your comments.
> 
> 
> > On Sep 12, 2019, at 11:55 PM, Ketan Talaulikar (ketant)
>  wrote:
> >
> > Hi All,
> >
> > I would like to ask some questions and seek clarifications on this draft.
> >
> > • I am aware that this draft originates from practical pain points at a
> specific operator. During the adoption calls, the scenarios were debated in
> detail. It was basically a L2 WAN circuit service over a provider network and
> the challenge was that the PMTU of the underlying path in the SP network
> changes dynamically. However, from the Enterprise POV, the L2 circuit is
> seen as a single link and the BFD runs in directly connected mode. The draft
> however, discusses BFD multi-hop which is an entirely different use-case.
> 
> This is perhaps some poor wording choices in the Introduction section.  The
> intent is really that this is usable for all cases where BFD may be used.  The
> Introduction text was intended to note that for single-hop scenarios, BFD
> Echo procedures may be sufficient to solve the problem.  (See comment to
> Carlos elsewhere in the thread.)  However, for any form of multi-hop, you
> can't solve this via Echo.
> 
> General note about the "pain points at a specific author": While Albert
> certainly was the first customer I'd had willing to help stamp their name on
> such a draft, I'd been approached in my chair capacity both in IETF and at my
> employer over the years about similar headaches many times.  This is sadly
> not a rare problem.
> 
> > When doing multi-hop, the BFD packet could go over entirely different
> paths in the network with different PMTUs (especially different from the
> application sending large packets) – this makes things flaky? So shouldn’t 
> this
> mechanism be actually focussed on the single hop/directly connected mode
> instead?
> 
> Even for single-hop this may be slightly flakey.  Consider "directly 
> connected"
> links that are composed from LAGs.
> 
> The draft doesn't try to completely address all such forms of multipath
> problems, even for directly connected solutions.  When we were doing BFD
> for LAGs, we realized that trying to get overly specific in terms of the
> implementation not only got ourselves perilously into the specifics of a given
> vendor, but potentially into conflict with IEEE in terms of discussions about
> distributing traffic.  To that end, we've been silent on the matter in this 
> draft.
> 
> It's reasonable in any BFD implementation dealing with multipath issues to
> potentially interact with the load balancer and decide to exercise specific
> links.  I believe it's the case for some scenarios that your own employer may
> do this in pre BFD-on-LAG implementations for single hop BFD based on
> some old mailing list discussion. 

RE: [Lsr] [Idr] draft-merciaz-idr-bgp-bfd-strict-mode

[Les Ginsberg (ginsberg)]

Greg –

I have a very different opinion.

Dampening should always be done at the lowest layer possible.
In most cases this argues for interface layer, but there are cases (switches in 
the path to the directly connected neighbor) where interface dampening doesn’t 
always tell you what you need to know.  So I acknowledge the usefulness of 
dampening at the BFD layer.
But doing it at the BFD client layer is wasteful. It forces the same logic to 
be implemented in multiple places and introduces race conditions where what BFD 
thinks and what the BFD client thinks about the same state differ.
I would argue against such an approach.

I have a related question:

In the case where the BGP neighbor is multiple hops away, what benefit does BFD 
dampening provide?
(Note that I am assuming that there likely would be single hop BFD sessions 
used by the IGPs (for example) along the path to the BGP neighbor and expecting 
that BFD dampening would be use for the single hop sessions when appropriate.)

   Les

From: Lsr  On Behalf Of Greg Mirsky
Sent: Thursday, July 25, 2019 3:41 PM
To: Acee Lindem (acee) 
Cc: i...@ietf.org; Albert Bloomberg ; Ketan Talaulikar 
(ketant) ; l...@ietf.org; rtg-bfd@ietf.org; Albert F 
; Susan Hares 
Subject: Re: [Lsr] [Idr] draft-merciaz-idr-bgp-bfd-strict-mode

Hi Acee,
I imagine that there could be multiple clients of the same BFD session with 
different requirements in regard to dampening behavior. For example, the delay 
each client desires to use may be different for each client of the BFD session. 
If that is a plausible use case, I think that placing dampening to a client may 
be a better choice.

Regards,
Greg

On Thu, Jul 25, 2019 at 6:23 PM Acee Lindem (acee) 
mailto:a...@cisco.com>> wrote:
Hi Albert, Ketan,
The authors will document dampening in the operational considerations. I’m also 
of the mind that the dampening should be done in BFD rather than the BFD 
clients (e.g., BGP).
Thanks,
Acee

From: Lsr mailto:lsr-boun...@ietf.org>> on behalf of 
Albert F mailto:albert.f...@gmail.com>>
Date: Thursday, July 25, 2019 at 5:14 PM
To: "Ketan Talaulikar (ketant)" mailto:ket...@cisco.com>>
Cc: IDR List mailto:i...@ietf.org>>, 
"rtg-bfd@ietf.org" 
mailto:rtg-bfd@ietf.org>>, Albert Bloomberg 
mailto:af...@bloomberg.net>>, Susan Hares 
mailto:sha...@ndzh.com>>, 
"l...@ietf.org" mailto:l...@ietf.org>>
Subject: Re: [Lsr] [Idr] draft-merciaz-idr-bgp-bfd-strict-mode

Hi Ketan,

I think it will be good to mention this in the doc, as I expect most large 
networks concerned with network stability impacted by link flaps to enable the 
BFD hold-up feature.

For example, if one side has BFD hold-up enabled (> BGP hold time) and the 
other side does not, the BGP keepalive message from one side may be delayed 
even if BFD is up. This may have implication on the BGP session transitiining 
to established phase.

Thanks
Albert



On Thu, Jul 25, 2019, 4:27 PM Ketan Talaulikar (ketant) 
mailto:ket...@cisco.com>> wrote:
Hi Albert,

Thanks for your feedback from an operator perspective – it is valuable. This 
“BFD hold up” behaviour that you desire is best handled by BFD since I would 
expect that similar behaviour would be desired across routing protocols (OSPF, 
ISIS, BGP) and perhaps other clients.

IMHO this is not something that we should be tackling within the scope of this 
BGP draft. Would you agree?

That said, this seems like a local implementation aspect to me. We should 
however discuss within the BFD WG if there is value in documenting this.

Thanks,
Ketan

From: Idr mailto:idr-boun...@ietf.org>> On Behalf Of 
Susan Hares
Sent: 25 July 2019 16:21
To: 'Albert Fu' mailto:af...@bloomberg.net>>; 
i...@ietf.org
Subject: Re: [Idr] draft-merciaz-idr-bgp-bfd-strict-mode

Albert:

To clarify, do you support WG adoption with the draft as is.

As a WG chair, I have to trust that all  drafts are improved during the WG 
process.  Can this small change be made after adoption or should it be made 
before the draft is considered for adoption.

Sue Hares

From: Idr [mailto:idr-boun...@ietf.org] On Behalf Of Albert Fu (BLOOMBERG/ 120 
PARK)
Sent: Thursday, July 25, 2019 4:19 PM
To: i...@ietf.org
Subject: [Idr] draft-merciaz-idr-bgp-bfd-strict-mode

I am in support of this draft, and would like to request a small change to make 
this draft more operationally useful.

We have encountered several traffic blackhole problems in our production 
network without this feature. As such, we have deployed BGP with strict BFD 
mode on a proprietary vendor implementation for a while.

Since a lot of MetroE circuit failures occur with interfaces still up, ie. 
break in the middle issues, the traditional knobs like interface 
hold-time/debounce timer can not be used to dampen interface flaps.

We have observed that interface issues tend to occur in bursts and would like 
to request that an option be added in "Section 4 Operation:" to 

RE: WG Adoption for draft-chen-bfd-unsolicted

[Les Ginsberg (ginsberg)]

Naiming -

I did not say that implementations had done exactly what you propose in this 
draft. I said:

" there are implementations which have addressed this issue w/o requiring any 
changes to their BFD implementation"

There is more than one way to solve this problem. :-)

I raise this point because an implementation which has already addressed the 
issue has little motivation to move to a different solution (such as you 
propose).
Which is why I am OK if this is merely informational - but not otherwise.

   Les


> -Original Message-
> From: Naiming Shen (naiming)
> Sent: Monday, October 29, 2018 6:58 PM
> To: Les Ginsberg (ginsberg) 
> Cc: Jeffrey Haas ; rtg-bfd@ietf.org; draft-chen-bfd-
> unsolici...@ietf.org
> Subject: Re: WG Adoption for draft-chen-bfd-unsolicted
> 
> 
> I’m not aware of an implementation taking in the inbound BFD packets,
> then dynamically seting up a session to the received packet sender end-
> point.
> As Jeff mentioned Redback planed on this, but didn’t implement. So there
> most
> likely needs some BFD implementation changes.
> 
> Regards,
> - Naiming
> 
> > On Oct 29, 2018, at 4:52 PM, Les Ginsberg (ginsberg) 
> wrote:
> >
> > The problem the draft addresses is valid and makes sense to address. But I
> know there are implementations which have addressed this issue w/o
> requiring any changes to their BFD implementation - so I am not sure how
> popular this solution will be.
> >
> > So long as this stays Informational I think it is fine to adopt. I would 
> > not be
> as enthused if this is moved to Standards track.
> >
> >   Les
> >
> >
> >> -Original Message-
> >> From: Rtg-bfd  On Behalf Of Jeffrey Haas
> >> Sent: Monday, October 29, 2018 8:53 AM
> >> To: rtg-bfd@ietf.org
> >> Cc: draft-chen-bfd-unsolici...@ietf.org
> >> Subject: WG Adoption for draft-chen-bfd-unsolicted
> >>
> >> Working Group,
> >>
> >> Reviewing my notes, I was remiss in sending out an adoption request for
> >> draft-chen-bfd-unsolicted (Unsolicited BFD for Sessionless Applications).
> >>
> >> https://datatracker.ietf.org/doc/draft-chen-bfd-unsolicited/
> >>
> >> This relatively minor change from the RFC 5880 spec is implemented by at
> >> least one vendor for static route configuration.  Its security
> >> considerations already cover what I believe to be the main concern with
> the
> >> procedural change.
> >>
> >> There's a minor point to resolve regarding the document's status -
> currently
> >> Informational - with our AD.
> >>
> >> Please indicate whether you'd support adopting this draft as a Working
> >> Group
> >> document.
> >>
> >> Authors, please indicate if you're aware of any applicable IPR on it.
> >>
> >> This adoption request will also end on Friday, November 9, IETF 103
> Friday.
> >>
> >> -- Jeff & Reshad
> >

RE: WG Adoption for draft-chen-bfd-unsolicted

[Les Ginsberg (ginsberg)]

The problem the draft addresses is valid and makes sense to address. But I know 
there are implementations which have addressed this issue w/o requiring any 
changes to their BFD implementation - so I am not sure how popular this 
solution will be.

So long as this stays Informational I think it is fine to adopt. I would not be 
as enthused if this is moved to Standards track.

   Les


> -Original Message-
> From: Rtg-bfd  On Behalf Of Jeffrey Haas
> Sent: Monday, October 29, 2018 8:53 AM
> To: rtg-bfd@ietf.org
> Cc: draft-chen-bfd-unsolici...@ietf.org
> Subject: WG Adoption for draft-chen-bfd-unsolicted
> 
> Working Group,
> 
> Reviewing my notes, I was remiss in sending out an adoption request for
> draft-chen-bfd-unsolicted (Unsolicited BFD for Sessionless Applications).
> 
> https://datatracker.ietf.org/doc/draft-chen-bfd-unsolicited/
> 
> This relatively minor change from the RFC 5880 spec is implemented by at
> least one vendor for static route configuration.  Its security
> considerations already cover what I believe to be the main concern with the
> procedural change.
> 
> There's a minor point to resolve regarding the document's status - currently
> Informational - with our AD.
> 
> Please indicate whether you'd support adopting this draft as a Working
> Group
> document.
> 
> Authors, please indicate if you're aware of any applicable IPR on it.
> 
> This adoption request will also end on Friday, November 9, IETF 103 Friday.
> 
> -- Jeff & Reshad

RE: Re: BFD WG adoption for draft-haas-bfd-large-packets

[Les Ginsberg (ginsberg)]

Albert –

Do not confuse the current lack of detection with when the problem gets 
introduced.

The fact that the problem is not detected on protocol adjacency formation does 
not mean the problem gets introduced afterwards. Unless you are saying that 
folks change the link MTU AFTER the link comes up and has been used for a while 
the problem exists as soon as the link comes up. You could therefore detect 
this in a number of ways:

1)Use IS-IS ☺
2)Enhance other routing protocols to do what IS-IS does
3)Send BFD large packets (Echo or async)
4)Potentially some other OAM mechanism

In regards to #3, unless you believe link MTUs will change “on the fly”, 
sending the large packets during initial session bringup would be sufficient. 
If folks are concerned (as I am) that sending large BFD packets all the time 
introduces some risks for scalability/stability of BFD sessions, then one 
strategy would be to send the large packets only on session bringup.

FYI, some implementations have knobs on IS-IS to do exactly this i.e., send 
padded hellos until the adjacency is formed – then revert to small hellos. In 
the case of BFD I think there is a more compelling reason to be conservative in 
how often you send large packets given where it is implemented and how often 
the BFD packets are sent.

   Les



From: Albert Fu (BLOOMBERG/ 120 PARK) 
Sent: Monday, October 29, 2018 10:39 AM
To: Les Ginsberg (ginsberg) ; jh...@juniper.net; 
rtg-bfd@ietf.org
Subject: Re: BFD WG adoption for draft-haas-bfd-large-packets

Hi Les,

> Jeff/Albert -
>
> Given the MTU issue is associated with a link coming up - and the use of Echo 
> would allow the problem to be detected and prevent the BFD session from 
> coming up -
> and you are acknowledging that the protocol allows padded Echo packets today 
> ...
>
> is there really a need to do anything more?
>
> Les
>

Actually, all the issues we have observed were not associated
with link going up. The MTU issues occurred after OSPF/BGP had
established adjacency without any events on the routers.
ospf/BGP hellos/keepalives continued to be transmitted fine (small
packet size), but applications sending max size packets over the
link would time out and fail.

Hence, I mentioned several times that this issue is rather time
consuming to troubleshoot, as the cause is with the Telco network
and outside of our control and we do not see any alarms.

I did also look at BFD echo mode. As Jeff indicated, this is not
widely deployed (among the vendors we use, only one supports it).

Thanks
Albert

RE: BFD WG adoption for draft-haas-bfd-large-packets

[Les Ginsberg (ginsberg)]

Jeff -

I note that no one supports "large-packets" today.
So is the gap between supporting echo mode for this purpose any larger than the 
gap for introducing large packet support?

   Les


> -Original Message-
> From: Jeffrey Haas 
> Sent: Monday, October 29, 2018 9:42 AM
> To: Les Ginsberg (ginsberg) 
> Cc: Reshad Rahman (rrahman) ; Naiming Shen
> (naiming) ; rtg-bfd@ietf.org
> Subject: Re: BFD WG adoption for draft-haas-bfd-large-packets
> 
> On Mon, Oct 29, 2018 at 04:39:04PM +, Les Ginsberg (ginsberg) wrote:
> > Given the MTU issue is associated with a link coming up - and the use of
> Echo would allow the problem to be detected and prevent the BFD session
> from coming up -
> > and you are acknowledging that the protocol allows padded Echo packets
> today ...
> >
> > is there really a need to do anything more?
> 
> ... the fact that the majority of BFD implementations on the planet do not
> support Echo mode?
> 
> Not to mention my whole comment that BFD Echo is intentionally
> under-specified.  The result being that any attempt to specify anything in
> it will likely cause interop headaches.
> 
> -- Jeff

RE: BFD WG adoption for draft-haas-bfd-large-packets

[Les Ginsberg (ginsberg)]

Jeff/Albert -

Given the MTU issue is associated with a link coming up - and the use of Echo 
would allow the problem to be detected and prevent the BFD session from coming 
up - 
and you are acknowledging that the protocol allows padded Echo packets today ...

is there really a need to do anything more?

   Les

> -Original Message-
> From: Jeffrey Haas 
> Sent: Monday, October 29, 2018 8:36 AM
> To: Reshad Rahman (rrahman) 
> Cc: Les Ginsberg (ginsberg) ; Naiming Shen (naiming)
> ; rtg-bfd@ietf.org
> Subject: Re: BFD WG adoption for draft-haas-bfd-large-packets
> 
> Reshad,
> 
> On Fri, Oct 26, 2018 at 06:32:26PM +, Reshad Rahman (rrahman) wrote:
> >On 2018-10-25, 11:38 AM, "Jeffrey Haas"  wrote:
> > > The draft I had previously worked on with Xiao Min discussing probing
> using
> > > BFD Echo had the concept of probes that would happen wherein the
> session is
> > > not torn down.  The example carries similarly with the "send
> occasional".
> >
> >  We discussed use of echo at IETF102. The large-packets draft
> mentions
> > that echo can only be used for single-hop, hence the need for padding the
> > control packets. But isn't single-hop Albert's main use-case?
> 
> It's Albert's primary use case.  And, I think a common related one is
> protecting tunnels of various flavors; e.g. GRE or IPsec.
> 
> > I believe we
> > should add the echo option in the large-packets draft, it has the benefit
> > that you get the desired functionality even if only 1 side of the WAN link
> > supports echo. I realize not all implementations support echo so they
> > might have to do pad control packets instead.
> 
> While I don't think Albert or I would have any objections to adding Echo
> discussion in the existing document, we perhaps risk running into one of the
> issues Xiao and I had briefly discussed.  Echo is intentionally
> under-specified in RFC 5880 et seq.  While it's possible that we can simply
> put in a discussion section that says "if you use Echo mode with similar
> padding, you can get similar benefit", I think that may be as far as we want
> to go.
> 
> The related observation is that nothing stops an Echo implementation from
> doing this with no changes to the protocol. :-)
> 
> -- Jeff

RE: BFD WG adoption for draft-haas-bfd-large-packets

[Les Ginsberg (ginsberg)]

Albert -

From: Albert Fu (BLOOMBERG/ 120 PARK) 
Sent: Tuesday, October 23, 2018 8:45 AM
To: rtg-bfd@ietf.org; Les Ginsberg (ginsberg) 
Subject: RE: BFD WG adoption for draft-haas-bfd-large-packets

Hi Les,

Given that it takes relative lengthy time to troubleshoot the MTU issue, and 
the associated impact on customer traffic, it is important to have a reliable 
and fast mechanism to detect the issue.

[Les:] This is  one of the points where we are not in full agreement. I agree 
you need an easy and reliable way to detect the problem when it occurs.
However, I disagree that you need to do this “fast” – when fast is defined as 
sub-second.

You have something that we know only occurs during some maintenance event – 
which is planned and only occurs “once/day,week”.
Checking for this even once/second is overly aggressive.
If it came for free, then no reason not to do so.
But as this discussion has shown, there are costs/risks.

For example, if you were using IS-IS and you detected this within the default 
adjacency hold time (30 seconds on p2p circuits) – would that be too slow for 
you? If so, please explain why this is too slow.

I think the primary issue here is ease of use and reliability. Whether 
detection time is one second or one minute seems relatively unimportant.

Do you disagree?

   Les

RE: BFD WG adoption for draft-haas-bfd-large-packets

[Les Ginsberg (ginsberg)]

Reshad –

I think there are two cases:

1)A client who uses encapsulation (MPLS is an easy example) and really needs to 
know if an MTU sized packet plus the encapsulation can be delivered vs a client 
who does NOT use encap and only cares about Layer 3 sized MTU packets

2)A client which has deliberately limited the max-sized packet they will ever 
send and really only cares about (MTU –X)

   Les


From: Reshad Rahman (rrahman)
Sent: Tuesday, October 23, 2018 7:51 AM
To: Les Ginsberg (ginsberg) ; Naiming Shen (naiming) 

Cc: rtg-bfd@ietf.org
Subject: Re: BFD WG adoption for draft-haas-bfd-large-packets

Hi Les,

I still don’t understand what you’re referring to as BFD clients and how they 
could have different MTU limitations. Are you referring to application data?

Regards,
Reshad (no hat).

From: "Les Ginsberg (ginsberg)" mailto:ginsb...@cisco.com>>
Date: Monday, October 22, 2018 at 4:40 PM
To: "Reshad Rahman (rrahman)" mailto:rrah...@cisco.com>>, 
"Naiming Shen (naiming)" mailto:naim...@cisco.com>>
Cc: "rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>" 
mailto:rtg-bfd@ietf.org>>
Subject: RE: BFD WG adoption for draft-haas-bfd-large-packets

Reshad –

Inline.

From: Reshad Rahman (rrahman)
Sent: Monday, October 22, 2018 1:02 PM
To: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>; 
Naiming Shen (naiming) mailto:naim...@cisco.com>>
Cc: rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>
Subject: Re: BFD WG adoption for draft-haas-bfd-large-packets

Hi,

1)  From Albert’s presentation @ IETF102, the motivation for 
doing this is to have BFD fail if the expected MTU can not be met, and 
therefore for traffic to be rerouted as a result. So I think this is the use 
case we should stick with but I’d like to know if others think 
otherwise.
2)  Les, I don’t understand the question regarding client MTU requirement. 
Are you saying if OSPF and BGP are clients of the same BFD session they might 
have different MTU requirements? I don’t think this is the problem the solution 
is trying to solve: the solution is trying to figure out if packets of up to 
size X can make it to the other end, this is independent of BFD client.
[Les:] I don’t think the example of OSPF/BGP is a good one. Think tunneled 
traffic vs non-tunneled.
I raised the question because different BFD clients can have different MTU 
limitations and wanted to know how this would be addressed when they shared the 
same BFD session.
Does BFD use the minimum or the maximum of all the client MTUs?

3)  Les, I agree we need to balance the cost of a new protocol v/s 
overloading BFD at the risk of “polluting” it. I believe BFD is a good fit for 
this but we have to be careful, so it’s good to have these discussions.

[Les:] My current feeling is that this isn’t a good fit for BFD. But I agree 
with you – discussing this at this early stage is a good thing to do.

Les

Regards,
Reshad.

From: "Les Ginsberg (ginsberg)" mailto:ginsb...@cisco.com>>
Date: Sunday, October 21, 2018 at 8:36 PM
To: "Naiming Shen (naiming)" mailto:naim...@cisco.com>>
Cc: "Reshad Rahman (rrahman)" mailto:rrah...@cisco.com>>, 
"rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>" 
mailto:rtg-bfd@ietf.org>>
Subject: RE: BFD WG adoption for draft-haas-bfd-large-packets

Naiming -

Thanx for the good discussion. Responses inline.

From: Naiming Shen (naiming)
Sent: Sunday, October 21, 2018 3:36 PM
To: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>
Cc: Reshad Rahman (rrahman) mailto:rrah...@cisco.com>>; 
rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>
Subject: Re: BFD WG adoption for draft-haas-bfd-large-packets


Les,

On Oct 21, 2018, at 3:26 PM, Les Ginsberg (ginsberg) 
mailto:ginsb...@cisco.com>> wrote:

Naiming –

Inline…

From: Naiming Shen (naiming)
Sent: Sunday, October 21, 2018 3:12 PM
To: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>
Cc: Reshad Rahman (rrahman) mailto:rrah...@cisco.com>>; 
rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>
Subject: Re: BFD WG adoption for draft-haas-bfd-large-packets


It probably should say “the payload size MAY be increased to this value and it 
is
not recommended for a BFD session to always use the large size packet for 
padding.
How frequent the large size packet being used is application specific”.

[Les:] This does not address the question as to why we want to use a mechanism 
specifically designed for sub-second detection for this case.
??? (Note that it does not come for free. ☺ )

Since we already have a session between two end-points, a BFD session, why not 
utilize that
instead of having to explicitly configurae another ‘MTU discovery protocol’ 
session with burden
of configuration and management.

[Les:] Because it comes with costs and risks and problems of its own.

We do not know how many of the existing BFD implementations will be able to 
handl

RE: BFD WG adoption for draft-haas-bfd-large-packets

[Les Ginsberg (ginsberg)]

Albert –

Please understand that I fully agree with the importance of being able to 
detect/report MTU issues. In my own experience this can be a difficult problem 
to diagnose. You do not have to convince me that some improvement in 
detection/reporting is needed. The question really is whether using BFD is the 
best option.

Could you respond to my original questions – particularly why sub-second 
detection of this issue is a requirement?

For your convenience:


It has been stated that there is a need for sub-second detection of this 
condition – but I really question that requirement.
What I would expect is that MTU changes only occur as a result of some 
maintenance operation (configuration change, link addition/bringup, insertion 
of a new box in the physical path etc.). The idea of using a mechanism which is 
specifically tailored for sub-second detection to monitor something that is 
only going to change occasionally seems inappropriate. It makes me think that 
other mechanisms (some form of OAM, enhancements to routing protocols to do 
what IS-IS already does ) could be more appropriate and would still meet the 
operational requirements.

I have listened to the Montreal recording – and I know there was discussion 
related to these issues (not sending padded packets all the time, use of BFD 
echo, etc.) – but I would be interested in more discussion of the need for 
sub-second detection.

Also, given that a path might be used with a variety of encapsulations, how do 
you see such a mechanism being used when multiple BFD clients share the same 
BFD session and their MTU constraints are different?


Thanx.

   Les



From: Rtg-bfd  On Behalf Of Albert Fu (BLOOMBERG/ 120 
PARK)
Sent: Monday, October 22, 2018 2:08 PM
To: rtg-bfd@ietf.org
Subject: RE: BFD WG adoption for draft-haas-bfd-large-packets

Sorry for the late response, and thanks for the comments so far.

We have observed the "MTU" issue on Telco WAN circuits (typically, the p2p WAN 
links are deployed using MPLS L2VPN service). So the cause is outside of our 
control. But when the MTU issue happens, there are no network events/alarms, 
since most protocol keepalive packets are small. It is quite time consuming to 
troubleshoot the issue, especially in networks with many ECMP paths.

I would agree that this issue is less likely to occur within customer 
infrastructure that use back-back links, assuming there are good provisioning 
tools in place.

This draft proposes adding padding at the IP layer, without any change to the 
BFD/UDP packet. Depending on the implementation, the padding bytes will be 
stripped off at the IP layer, and may not be visible to the BFD process, hence 
potentially little impact on performance (the increase in link util is small 
relative to today's BW).

The advantage of having padding implemented in BFD is that it will enable the 
issue to be detected very quickly as it happens, and traffic can be diverted to 
working paths with minimal network downtime. Of all the routing protocols, ISIS 
is the only one I am aware of that supports hello padding, but since this is a 
control plane process, we have to use conservative detection timer, which means 
there will be noticeable network downtime using this method.

The BFD padding will be an option on a per neighbor basis and user 
configurable. In our case, we will look at setting the total padded BFD packet 
size to 1512 bytes, being 1500 IP payload + up to 3 MPLS headers. If scaling is 
an issue, Network Designer can choose to enable the padding feature for WAN 
circuits, but not on circuits within customer infrastructure where this is 
unlikely to be an issue.







From: rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org> At: 10/22/18 16:43:05
To: rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>
Subject: Rtg-bfd Digest, Vol 152, Issue 20

Send Rtg-bfd mailing list submissions to
rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>

To subscribe or unsubscribe via the World Wide Web, visit
https://www.ietf.org/mailman/listinfo/rtg-bfd
or, via email, send a message with subject or body 'help' to
rtg-bfd-requ...@ietf.org<mailto:rtg-bfd-requ...@ietf.org>

You can reach the person managing the list at
rtg-bfd-ow...@ietf.org<mailto:rtg-bfd-ow...@ietf.org>

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Rtg-bfd digest..."


Today's Topics:

1. RE: BFD WG adoption for draft-haas-bfd-large-packets
(Les Ginsberg (ginsberg))


--

Message: 1
Date: Mon, 22 Oct 2018 20:40:49 +
From: "Les Ginsberg (ginsberg)" mailto:ginsb...@cisco.com>>
To: "Reshad Rahman (rrahman)" mailto:rrah...@cisco.com>>, 
"Naiming Shen
(naiming)" mailto:naim...@cisco.com>>
Cc: "rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>" 
mailto:rtg-bfd@ietf.org>>
Subject: RE: BFD WG adoption for draft-haas-bfd-large-pac

RE: BFD WG adoption for draft-haas-bfd-large-packets

[Les Ginsberg (ginsberg)]

Reshad –

Inline.

From: Reshad Rahman (rrahman)
Sent: Monday, October 22, 2018 1:02 PM
To: Les Ginsberg (ginsberg) ; Naiming Shen (naiming) 

Cc: rtg-bfd@ietf.org
Subject: Re: BFD WG adoption for draft-haas-bfd-large-packets

Hi,

1)  From Albert’s presentation @ IETF102, the motivation for 
doing this is to have BFD fail if the expected MTU can not be met, and 
therefore for traffic to be rerouted as a result. So I think this is the use 
case we should stick with but I’d like to know if others think 
otherwise.
2)  Les, I don’t understand the question regarding client MTU requirement. 
Are you saying if OSPF and BGP are clients of the same BFD session they might 
have different MTU requirements? I don’t think this is the problem the solution 
is trying to solve: the solution is trying to figure out if packets of up to 
size X can make it to the other end, this is independent of BFD client.
[Les:] I don’t think the example of OSPF/BGP is a good one. Think tunneled 
traffic vs non-tunneled.
I raised the question because different BFD clients can have different MTU 
limitations and wanted to know how this would be addressed when they shared the 
same BFD session.
Does BFD use the minimum or the maximum of all the client MTUs?

3)  Les, I agree we need to balance the cost of a new protocol v/s 
overloading BFD at the risk of “polluting” it. I believe BFD is a good fit for 
this but we have to be careful, so it’s good to have these discussions.

[Les:] My current feeling is that this isn’t a good fit for BFD. But I agree 
with you – discussing this at this early stage is a good thing to do.

Les

Regards,
Reshad.

From: "Les Ginsberg (ginsberg)" mailto:ginsb...@cisco.com>>
Date: Sunday, October 21, 2018 at 8:36 PM
To: "Naiming Shen (naiming)" mailto:naim...@cisco.com>>
Cc: "Reshad Rahman (rrahman)" mailto:rrah...@cisco.com>>, 
"rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>" 
mailto:rtg-bfd@ietf.org>>
Subject: RE: BFD WG adoption for draft-haas-bfd-large-packets

Naiming -

Thanx for the good discussion. Responses inline.

From: Naiming Shen (naiming)
Sent: Sunday, October 21, 2018 3:36 PM
To: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>
Cc: Reshad Rahman (rrahman) mailto:rrah...@cisco.com>>; 
rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>
Subject: Re: BFD WG adoption for draft-haas-bfd-large-packets


Les,

On Oct 21, 2018, at 3:26 PM, Les Ginsberg (ginsberg) 
mailto:ginsb...@cisco.com>> wrote:

Naiming –

Inline…

From: Naiming Shen (naiming)
Sent: Sunday, October 21, 2018 3:12 PM
To: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>
Cc: Reshad Rahman (rrahman) mailto:rrah...@cisco.com>>; 
rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>
Subject: Re: BFD WG adoption for draft-haas-bfd-large-packets


It probably should say “the payload size MAY be increased to this value and it 
is
not recommended for a BFD session to always use the large size packet for 
padding.
How frequent the large size packet being used is application specific”.

[Les:] This does not address the question as to why we want to use a mechanism 
specifically designed for sub-second detection for this case.
??? (Note that it does not come for free. ☺ )

Since we already have a session between two end-points, a BFD session, why not 
utilize that
instead of having to explicitly configurae another ‘MTU discovery protocol’ 
session with burden
of configuration and management.

[Les:] Because it comes with costs and risks and problems of its own.

We do not know how many of the existing BFD implementations will be able to 
handle this w/o changes. Some may not be able to handle this at all.
The draft already acknowledges that this may affect BFD scaling. It is not much 
of a leap to think that in order to handle BFD at scale current implementations 
have made certain assumptions – one of which could be what is the maximum 
expected size of a BFD packet.
And the user will – of course – have to configure this as a BFD option (I 
believe this was acknowledged in the Montreal presentation) – so it is not as 
if no additional config is required.

I am sure we can come up with other risks/costs with a bit more thought.

Since most of the application traffic does not fill the full size of the pipe 
to reach the MTU, so
this detection does not need to be sub-seconds, unlike normal BFD down we have 
to switch
the traffic immediately. MTU change can be detected by variing the BFD size say 
once
every minute (just like the BFD authentication proposal, once a while is sort 
of ok). Not knowing
the path MTU has changed for days is bad, but got notified in 2 minutes is 
good:-)


for the variety of encaps, the internal application probably can deduced from a
BFD one into their own as long as we have a number for path MTU.

[Les:] If “your” MTU requirements are smaller than “mine” – would you want the 
BFD session to go down even though yo

RE: BFD WG adoption for draft-haas-bfd-large-packets

[Les Ginsberg (ginsberg)]

Naiming -

Thanx for the good discussion. Responses inline.

From: Naiming Shen (naiming)
Sent: Sunday, October 21, 2018 3:36 PM
To: Les Ginsberg (ginsberg) 
Cc: Reshad Rahman (rrahman) ; rtg-bfd@ietf.org
Subject: Re: BFD WG adoption for draft-haas-bfd-large-packets


Les,

On Oct 21, 2018, at 3:26 PM, Les Ginsberg (ginsberg) 
mailto:ginsb...@cisco.com>> wrote:

Naiming –

Inline…

From: Naiming Shen (naiming)
Sent: Sunday, October 21, 2018 3:12 PM
To: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>
Cc: Reshad Rahman (rrahman) mailto:rrah...@cisco.com>>; 
rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>
Subject: Re: BFD WG adoption for draft-haas-bfd-large-packets


It probably should say “the payload size MAY be increased to this value and it 
is
not recommended for a BFD session to always use the large size packet for 
padding.
How frequent the large size packet being used is application specific”.

[Les:] This does not address the question as to why we want to use a mechanism 
specifically designed for sub-second detection for this case.
??? (Note that it does not come for free. ☺ )

Since we already have a session between two end-points, a BFD session, why not 
utilize that
instead of having to explicitly configurae another ‘MTU discovery protocol’ 
session with burden
of configuration and management.

[Les:] Because it comes with costs and risks and problems of its own.

We do not know how many of the existing BFD implementations will be able to 
handle this w/o changes. Some may not be able to handle this at all.
The draft already acknowledges that this may affect BFD scaling. It is not much 
of a leap to think that in order to handle BFD at scale current implementations 
have made certain assumptions – one of which could be what is the maximum 
expected size of a BFD packet.
And the user will – of course – have to configure this as a BFD option (I 
believe this was acknowledged in the Montreal presentation) – so it is not as 
if no additional config is required.

I am sure we can come up with other risks/costs with a bit more thought.

Since most of the application traffic does not fill the full size of the pipe 
to reach the MTU, so
this detection does not need to be sub-seconds, unlike normal BFD down we have 
to switch
the traffic immediately. MTU change can be detected by variing the BFD size say 
once
every minute (just like the BFD authentication proposal, once a while is sort 
of ok). Not knowing
the path MTU has changed for days is bad, but got notified in 2 minutes is 
good:-)


for the variety of encaps, the internal application probably can deduced from a
BFD one into their own as long as we have a number for path MTU.

[Les:] If “your” MTU requirements are smaller than “mine” – would you want the 
BFD session to go down even though you could continue to use the link 
successfully?

No, I think this document can also specify that, the BFD should not go “DOWN” 
if MTU has reduced, it should
only to be used as a ‘discovery’ mechanism ontop of the BFD itself. Say I’m 
sending large packets every 5 minutes
for 10 packets, this can be on top of the existing BFD schedule. It smaller 
packets still comes back to keep the
session alive. The big packets will give us the “indication” of extra data we 
have learned,

[Les:] So, this has some implications:

We have both a transmit interval and a multiplier for a BFD session because we 
allow that some BFD packets may be dropped for reasons which do not represent a 
true loss of connectivity. Therefore up to N-1 consecutive packets may be 
dropped w/o triggering a session state change. If large BFD packets are 
“occasionally” inserted this means there are intervals during which N-2 packets 
drops (not counting the BFD large packet) would be sufficient to trigger a BFD 
session state change. Further, if the processing of the large BFD packets makes 
it more likely that subsequent BFD packets will be dropped (e.g., because the 
processing of the large BFD packet simply takes longer) then it is possible 
that a BFD session state change might be triggered simply as a side effect of 
the insertion of the large packet into the data stream.

You also are now defining a “child session” which is embedded within the parent 
session. BFD large packets are then not meant to influence the parent BFD 
session state and therefore have to be processed separately. This – in many 
ways – is equivalent to defining “another protocol”. I’ll grant it might be a 
bit simpler as it can inherit some things from the parent session – but it 
certainly is no longer simply a transparent part of existing BFD session 
operation.

And you still have not fully addressed the differing client MTU requirement – 
unless you are proposing that BFD report to its clients what set of MTUs are 
being “tested” and which ones have failed and which have not.

It is conceivable that all of this could be addressed in some way, but it gives 
me pause as to whether this is th

RE: BFD WG adoption for draft-haas-bfd-large-packets

[Les Ginsberg (ginsberg)]

Naiming –

Inline…

From: Naiming Shen (naiming)
Sent: Sunday, October 21, 2018 3:12 PM
To: Les Ginsberg (ginsberg) 
Cc: Reshad Rahman (rrahman) ; rtg-bfd@ietf.org
Subject: Re: BFD WG adoption for draft-haas-bfd-large-packets


It probably should say “the payload size MAY be increased to this value and it 
is
not recommended for a BFD session to always use the large size packet for 
padding.
How frequent the large size packet being used is application specific”.

[Les:] This does not address the question as to why we want to use a mechanism 
specifically designed for sub-second detection for this case.
??? (Note that it does not come for free. ☺ )

for the variety of encaps, the internal application probably can deduced from a
BFD one into their own as long as we have a number for path MTU.

[Les:] If “your” MTU requirements are smaller than “mine” – would you want the 
BFD session to go down even though you could continue to use the link 
successfully?

   Les

thanks.
- Naiming

On Oct 20, 2018, at 5:14 PM, Les Ginsberg (ginsberg) 
mailto:ginsb...@cisco.com>> wrote:

I have some concerns.

It has been stated that there is a need for sub-second detection of this 
condition – but I really question that requirement.
What I would expect is that MTU changes only occur as a result of some 
maintenance operation (configuration change, link addition/bringup, insertion 
of a new box in the physical path etc.). The idea of using a mechanism which is 
specifically tailored for sub-second detection to monitor something that is 
only going to change occasionally seems inappropriate. It makes me think that 
other mechanisms (some form of OAM, enhancements to routing protocols to do 
what IS-IS already does ☺) could be more appropriate and would still meet the 
operational requirements.

I have listened to the Montreal recording – and I know there was discussion 
related to these issues (not sending padded packets all the time, use of BFD 
echo, etc.) – but I would be interested in more discussion of the need for 
sub-second detection.

Also, given that a path might be used with a variety of encapsulations, how do 
you see such a mechanism being used when multiple BFD clients share the same 
BFD session and their MTU constraints are different?

Thanx.

   Les


From: Rtg-bfd mailto:rtg-bfd-boun...@ietf.org>> On 
Behalf Of Reshad Rahman (rrahman)
Sent: Wednesday, October 17, 2018 6:06 PM
To: rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>
Subject: BFD WG adoption for draft-haas-bfd-large-packets

Hello BFD WG,

We have received an adoption request for “BFD encapsulated in large packets”.

https://datatracker.ietf.org/doc/draft-haas-bfd-large-packets/

The adoption call will end on Friday Nov 9th.

Please send email to the list indicating “yes/support”  or “no/do not support”. 
If you do not support adoption, please state your reasons.

Regards,
Reshad & Jeff.

RE: BFD WG adoption for draft-haas-bfd-large-packets

[Les Ginsberg (ginsberg)]

I have some concerns.

It has been stated that there is a need for sub-second detection of this 
condition – but I really question that requirement.
What I would expect is that MTU changes only occur as a result of some 
maintenance operation (configuration change, link addition/bringup, insertion 
of a new box in the physical path etc.). The idea of using a mechanism which is 
specifically tailored for sub-second detection to monitor something that is 
only going to change occasionally seems inappropriate. It makes me think that 
other mechanisms (some form of OAM, enhancements to routing protocols to do 
what IS-IS already does ☺) could be more appropriate and would still meet the 
operational requirements.

I have listened to the Montreal recording – and I know there was discussion 
related to these issues (not sending padded packets all the time, use of BFD 
echo, etc.) – but I would be interested in more discussion of the need for 
sub-second detection.

Also, given that a path might be used with a variety of encapsulations, how do 
you see such a mechanism being used when multiple BFD clients share the same 
BFD session and their MTU constraints are different?

Thanx.

   Les


From: Rtg-bfd  On Behalf Of Reshad Rahman (rrahman)
Sent: Wednesday, October 17, 2018 6:06 PM
To: rtg-bfd@ietf.org
Subject: BFD WG adoption for draft-haas-bfd-large-packets

Hello BFD WG,

We have received an adoption request for “BFD encapsulated in large packets”.

https://datatracker.ietf.org/doc/draft-haas-bfd-large-packets/

The adoption call will end on Friday Nov 9th.

Please send email to the list indicating “yes/support”  or “no/do not support”. 
If you do not support adoption, please state your reasons.

Regards,
Reshad & Jeff.

RE: [Errata Held for Document Update] RFC5880 (5205)

[Les Ginsberg (ginsberg)]

The motivations for this errata puzzle me.

In the Notes you say:



“This turns out to be problematic in the case where system "A" signals 
AdminDown, causing system "B" to respond with Down state.  If the link then 
fails, the existing verbiage implies that "B" will not report the detection 
timeout, even locally.”



[Les:] If A has signaled AdminDown then it is expected that A will (after a 
prudent number of retransmissions of the AdminDown state as specified in 
Section 6.8.16) stop transmission. So why is there a need to report what is 
expected to happen after receiving AdminDown? It also isn’t clear how you could 
determine that the link has failed given that it is expected that A will stop 
transmissions.



“If the link fails in a unidirectional manner (such that "B" is deaf), B will 
give no indication of a timeout in its outgoing Control packets back to A 
(which can in fact hear them).”



[Les:] If B is deaf, how would it have received AdminDown?


The suggested change would also seem to violate Section 4.1 (emphasis added):

Diagnostic (Diag)

  A diagnostic code specifying the local system's reason for the
  last change in session state.  Values are:
…

  This field allows remote systems to determine the reason that the
  previous session failed, for example.

???

   Les







> -Original Message-

> From: Rtg-bfd [mailto:rtg-bfd-boun...@ietf.org] On Behalf Of RFC Errata

> System

> Sent: Wednesday, March 14, 2018 12:28 PM

> To: dk...@juniper.net; dk...@juniper.net; dw...@juniper.net

> Cc: rtg-bfd@ietf.org; rfc-edi...@rfc-editor.org; i...@ietf.org

> Subject: [Errata Held for Document Update] RFC5880 (5205)

>

> The following errata report has been held for document update for RFC5880,

> "Bidirectional Forwarding Detection (BFD)".

>

> --

> You may review the report below and at:

> http://www.rfc-editor.org/errata/eid5205

>

> --

> Status: Held for Document Update

> Type: Technical

>

> Reported by: Dave Katz > Date 
> Reported: 2017-12-14

> Held by: Alvaro Retana (IESG)

>

> Section: 6.8.4

>

> Original Text

> -

> If Demand mode is not active, and a period of time equal to the Detection

> Time passes without receiving a BFD Control packet from the remote system,

> and bfd.SessionState is Init or Up, the session has gone down -- the local

> system MUST set bfd.SessionState to Down and bfd.LocalDiag to 1 (Control

> Detection Time Expired).

>

> Corrected Text

> --

> If Demand mode is not active, and a period of time equal to the Detection

> Time passes without receiving a BFD Control packet from the remote system,

> the session has gone down -- the local system MUST set bfd.SessionState to

> Down and bfd.LocalDiag to 1 (Control Detection Time Expired).

>

> Notes

> -

> This is based on an email I received from Anil Kumar of Nokia

> (anil.kumar_...@nokia.com).

>

> The language as originally written made a session timeout a no-op when in

> Down state.  This was a gratuitous attempt to avoid a null state transition, 
> but

> had the side effect of not setting the diag code (and otherwise is no

> different).

>

> This turns out to be problematic in the case where system "A" signals

> AdminDown, causing system "B" to respond with Down state.  If the link then

> fails, the existing verbiage implies that "B" will not report the detection

> timeout, even locally.

>

> If the link fails in a unidirectional manner (such that "B" is deaf), B will 
> give no

> indication of a timeout in its outgoing Control packets back to A (which can 
> in

> fact hear them).

>

> Making the suggested change should ensure that the diagnostic code is

> always set to Detection Time Expired when Control packets stop arriving,

> even if the far end system was previously reporting AdminDown.

>

> --

> RFC5880 (draft-ietf-bfd-base-11)

> --

> Title   : Bidirectional Forwarding Detection (BFD)

> Publication Date: June 2010

> Author(s)   : D. Katz, D. Ward

> Category: PROPOSED STANDARD

> Source  : Bidirectional Forwarding Detection

> Area: Routing

> Stream  : IETF

> Verifying Party : IESG

RE: [Technical Errata Reported] RFC5884 (5085)

[Les Ginsberg (ginsberg)]

I tend to agree with Mach - and I think what Mach states is also reinforcing 
the point that Carlos has made - which is that echo reply procedures are 
defined by RFC 8029 - not by RFC 5884.

However, the current text suffers from much more than the ambiguity regarding 
Echo Reply.

1)Second paragraph of Section 6 goes back and forth between discussing BFD 
Control packets, then Echo Reply, then BFD Control Packets

2)Third paragraph of Section 6 has an inappropriate use of "," in the sentence:

"The BFD Control packets from the
   ingress to the egress LSR MUST set the local discriminator of the
   egress LSR, in the Your Discriminator field."

3)Section 6.1 defines when the BFD Discriminator TLV MUST be sent and when it 
is optional in LSP ping. There is actually no need for Section 6 to say 
anything in this regard.

I propose revised text below - which is much more extensive in its changes than 
what has been proposed thus far, but I think it is necessary to eliminate all 
ambiguity.
That said, there is no question that the current text is subject to multiple 
interpretations - so any change in text runs the risk of introducing new 
interoperability issues. On balance it is probably necessary to take this risk 
as there is no guarantee that implementations are interoperable today, but the 
WG should still consider this point carefully.

The text below replaces current paragraphs 2 and 3 of Section 6.


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

   The ingress LSR follows the procedures in [BFD] to send BFD Control
   packets to the egress LSR in response to the BFD Control packets
   received from the egress LSR.  The BFD Control packets from the
   ingress to the egress LSR MUST set the local discriminator of the
   egress LSR in the Your Discriminator field.  The egress LSR
   demultiplexes the BFD session based on the received Your
   Discriminator field.  As mentioned above, the egress LSR MUST send
   Control packets to the ingress LSR with the Your Discriminator field
   set to the local discriminator of the ingress LSR.  The ingress LSR
   uses this to demultiplex the BFD session.

  The egress LSR follows the procedures defined in [RFC 8029] to determine when 
to respond with an LSP Ping Echo  reply message.


Les


From: Rtg-bfd [mailto:rtg-bfd-boun...@ietf.org] On Behalf Of Mach Chen
Sent: Tuesday, August 15, 2017 12:56 AM
To: Carlos Pignataro (cpignata); Greg Mirsky
Cc: Tom Nadeau; m...@ietf.org; Kireeti Kompella (kire...@juniper.net); Alia 
Atlas; Reshad Rahman (rrahman); rtg-bfd@ietf. org
Subject: RE: [Technical Errata Reported] RFC5884 (5085)

Hi all,

IMHO, the point is not about whether the Echo Reply is optional for a normal 
LSP Ping, where the echo reply is totally controlled by the reply mode.

For RFC5884, since the reply mode is not specified, based on the current text, 
it can be interpreted as the following two ways:

1)  it implies a new "mode" introduced, it's actually a "special" LSP Ping, 
 the process is just as what is currently described in the RFC: an Echo Reply 
is OPTINAL, whether and when to send Echo Reply is up to the egress LSR, and 
the Ingress LSR should not assume an Echo reply will be returned;

2)  the echo reply is still controlled by the reply mode, and given that 
there is a "Do not reply" mode, the current text seems right, but not that 
clear.

I incline to think way (2) is more nature, if so,  the proposed "Corrected 
Text" may not work if the Sender set the reply mode to "Do not reply".

I'd suggest:

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

NEW:
The egress LSR MAY respond with an LSP Ping Echo
reply message that carries the local discriminator assigned by it for
the BFD session. Whether to send an LSP Ping Echo reply message is
determined by the reply mode carried the received Echo request message.

Best regards,
Mach

From: Rtg-bfd [mailto:rtg-bfd-boun...@ietf.org] On Behalf Of Carlos Pignataro 
(cpignata)
Sent: Tuesday, August 15, 2017 8:17 AM
To: Greg Mirsky >
Cc: Tom Nadeau >; 
m...@ietf.org; Kireeti Kompella 
(kire...@juniper.net) 
>; Alia Atlas 
>; Reshad Rahman (rrahman) 

RE: IETF OSPF YANG and BFD Configuration

[Les Ginsberg (ginsberg)]

Jeff -

Inline.

> -Original Message-
> From: Rtg-bfd [mailto:rtg-bfd-boun...@ietf.org] On Behalf Of Jeffrey Haas
> Sent: Tuesday, June 20, 2017 7:17 AM
> To: Mahesh Jethanandani
> Cc: Jeffrey Haas; Reshad Rahman (rrahman); OSPF WG List; draft-ietf-ospf-
> y...@ietf.org; rtg-bfd@ietf.org; draft-ietf-bfd-y...@ietf.org; Acee Lindem
> (acee)
> Subject: Re: IETF OSPF YANG and BFD Configuration
> 
> Mahesh,
> 
> On Mon, Jun 19, 2017 at 03:11:25PM -0700, Mahesh Jethanandani wrote:
> > > On Jun 19, 2017, at 11:57 AM, Jeffrey Haas  wrote:
> > > Where we run into some issues are the cases highlighted: when the
> > > sessions don't share common properties, how should the protocol pick
> > > what BFD session to use?
> >
> > The issue that I hear most is the timer granularity. Is there something 
> > else?
> 
> Potentially mode (async vs. echo) and authentication.  However, I believe
> timer granularity is the biggest one.
> 
> > > The current BFD yang model only permits a single IP single-hop
> > > session to be configured.  (Key is interface/dst-ip)  This means
> > > that if different parameters *were* desired, the BFD model won't
> > > permit it today.  However, BFD sessions for many protocols tend not
> > > to be configured, but may spring forth from protocol state, such as
> > > IGP adjacencies.  Thus, it's not "configured" - it's solely
> > > operational state.  However, the BFD yang model doesn't really make
> good provision for that as an "on”.
> >
> > The idea is that a BFD session is configured a priori and before a IGP 
> > session
> is configured with the most aggressive timer. IGP sessions then refer to the
> BGP session configured. If a IGP session is added that requires a more
> aggressive timer, we would have to renegotiate the more aggressive timer
> value.
> 
> Consider a broadcast network segment such as Ethernet.
> Consider a few dozen routers on such a segment.
> 
> Is it your expectation that an IGP would require each of those routers to be
> manually configured in the Yang module a priori?  That is, after all, much of
> the point of an IGP: automatic discovery.
> 
> > > Where all endpoint state is known a priori, config state makes better
> sense.
> > >
> > > To pick the example of Juniper's configuration, if OSPF and eBGP
> > > were using BFD, both can choose differing timers.  This represents
> > > two pieces of configuration state for the same endpoints.
> > > Additionally, only one BFD session is formed using the most aggressive
> timers.
> >
> > That is what we are suggesting also.
> 
> The distinguishing point is configuration vs. operational state.  The current
> model doesn't permit more than one set of parameters to be provisioned
> even if the implementation may choose to instantiate exactly one session.
> 
> > > I partially point out the situation of multiple timers since there
> > > have been prior list discussions on the situation where clients have
> > > different timing requirements.  I don't think we handle this
> > > operationally in the BFD protocol in the cleanest fashion right now
> > > - the session will go to Down when the aggressive timers fail and
> > > there's no clean way to renegotiate to the less aggressive timers.
> >
> > A BFD session would fail more likely because there is a real network failure
> than because the timer was more aggressive than what IGP had requested.
> 
> Please note that I raise this point mostly because of prior discussion.  I'm 
> well
> aware of the headaches this currently causes:
> 
> Different protocols have different survivability requirements.  An IGP may
> very well want sub-second timers, potentially for repair behaviors.  BGP may
> want fast failover, but may be fine with second level granularity.  This is
> particularly true since the cost of too aggressively flapping BGP is of
> significantly greater impact to the network and the router.
> 
[Les:] The real issues here are false failures and proper use of dampening. No 
protocol - not even an IGP - wants to flap unnecessarily. If timers are set so 
aggressively that false failures are reported this is BAD.
Even worse is failure to dampen so that we get multiple false failures in a 
short period of time.

Arguing that the right way to solve this problem is to increase the number of 
sessions using different timer granularity seems likely to make any problems 
worse as you have now increased the number of BFD sessions with the associated 
costs.

   Les

> But moving to what *is* rather than what should be, if there are two
> different timing setups for the same endpoint: If you deprovision the more
> aggressive timer, the session should likely renegotiate to the less aggressive
> one rather than drop.
> 
> -- Jeff

RE: [OSPF] More Comments on OSPF S-BFD Discriminator

[Les Ginsberg (ginsberg)]

There is no discussion ongoing nor any action item for the authors that I am 
aware of.
I believe this state exists because we were waiting for discussion on the S-BFD 
base draft to be resolved.

If ADs require any additional updates they need to tell us – otherwise I think 
this draft should move forward as is.

   Les


From: Acee Lindem (acee)
Sent: Friday, February 05, 2016 7:52 AM
To: Les Ginsberg (ginsberg); Carlos Pignataro (cpignata); Manav Bhatia
Cc: draft-ietf-ospf-sbfd-discrimina...@ietf.org; OSPF WG List; isis...@ietf.org 
list; rtg-bfd@ietf.org
Subject: Re: [OSPF] More Comments on OSPF S-BFD Discriminator

I see the DISCUSS on the IS-IS document is still open - are the authors 
discussing resolution?

https://datatracker.ietf.org/doc/draft-ietf-isis-sbfd-discriminator/ballot/

Acee

From: "Les Ginsberg (ginsberg)" <ginsb...@cisco.com<mailto:ginsb...@cisco.com>>
Date: Friday, February 5, 2016 at 9:47 AM
To: Acee Lindem <a...@cisco.com<mailto:a...@cisco.com>>, "Carlos Pignataro 
(cpignata)" <cpign...@cisco.com<mailto:cpign...@cisco.com>>, Manav Bhatia 
<manavbha...@gmail.com<mailto:manavbha...@gmail.com>>
Cc: 
"draft-ietf-ospf-sbfd-discrimina...@ietf.org<mailto:draft-ietf-ospf-sbfd-discrimina...@ietf.org>"
 
<draft-ietf-ospf-sbfd-discrimina...@ietf.org<mailto:draft-ietf-ospf-sbfd-discrimina...@ietf.org>>,
 OSPF WG List <o...@ietf.org<mailto:o...@ietf.org>>, 
"isis...@ietf.org<mailto:isis...@ietf.org> list" 
<isis...@ietf.org<mailto:isis...@ietf.org>>, 
"rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>" 
<rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>>
Subject: RE: [OSPF] More Comments on OSPF S-BFD Discriminator

All of this is fine and as it should be – but the ADs need to tell us if the 
discussion of this point as regards draft-ietf-bfd-seamless-base is concluded 
and the IGP drafts may proceed.
As draft-ietf-bfd-seamless-base has been submitted to IESG for publication I 
assume this should be resolved but the IS-IS Draft still has this state:

“Has a DISCUSS. Has enough positions to pass once DISCUSS positions are 
resolved.”

???

   Les


From: Acee Lindem (acee)
Sent: Friday, February 05, 2016 5:00 AM
To: Carlos Pignataro (cpignata); Manav Bhatia
Cc: Les Ginsberg (ginsberg); 
draft-ietf-ospf-sbfd-discrimina...@ietf.org<mailto:draft-ietf-ospf-sbfd-discrimina...@ietf.org>;
 OSPF WG List
Subject: Re: [OSPF] More Comments on OSPF S-BFD Discriminator

Carlos, Manav,
 I remember now as well - this is the text I was referring to after the 
discussion including Les.
Thanks,
Acee

From: "Carlos Pignataro (cpignata)" 
<cpign...@cisco.com<mailto:cpign...@cisco.com>>
Date: Thursday, February 4, 2016 at 10:33 PM
To: Manav Bhatia <manavbha...@gmail.com<mailto:manavbha...@gmail.com>>
Cc: Acee Lindem <a...@cisco.com<mailto:a...@cisco.com>>, "Les Ginsberg 
(ginsberg)" <ginsb...@cisco.com<mailto:ginsb...@cisco.com>>, 
"draft-ietf-ospf-sbfd-discrimina...@ietf.org<mailto:draft-ietf-ospf-sbfd-discrimina...@ietf.org>"
 
<draft-ietf-ospf-sbfd-discrimina...@ietf.org<mailto:draft-ietf-ospf-sbfd-discrimina...@ietf.org>>,
 OSPF WG List <o...@ietf.org<mailto:o...@ietf.org>>
Subject: Re: [OSPF] More Comments on OSPF S-BFD Discriminator

Thank you Manav! I remember now :-)

Done :-)

https://www.ietf.org/rfcdiff?url2=draft-ietf-ospf-sbfd-discriminator-03

Thanks,

— Carlos.

On Feb 4, 2016, at 9:53 PM, Manav Bhatia 
<manavbha...@gmail.com<mailto:manavbha...@gmail.com>> wrote:

Hi Carlos,

I think we need to add the following in the current version:

“When multiple S-BFD discriminators are advertised how a given discriminator is 
mapped to a specific use case is out of scope for this document.”

I dont have the xml with me that i can update. Can you do it if you have one 
with you?

Cheers, Manav

On Fri, Feb 5, 2016 at 1:17 AM, Carlos Pignataro (cpignata) 
<cpign...@cisco.com<mailto:cpign...@cisco.com>> wrote:
Hi, Acee,

On Feb 4, 2016, at 2:24 PM, Acee Lindem (acee) 
<a...@cisco.com<mailto:a...@cisco.com>> wrote:

Hi Carlos,

From: "Carlos Pignataro (cpignata)" 
<cpign...@cisco.com<mailto:cpign...@cisco.com>>
Date: Thursday, February 4, 2016 at 2:16 PM
To: Acee Lindem <a...@cisco.com<mailto:a...@cisco.com>>
Cc: "Les Ginsberg (ginsberg)" <ginsb...@cisco.com<mailto:ginsb...@cisco.com>>, 
Manav Bhatia <manavbha...@gmail.com<mailto:manavbha...@gmail.com>>, 
"draft-ietf-ospf-sbfd-discrimina...@ietf.org<mailto:draft-ietf-ospf-sbfd-discrimina...@ietf.org>"
 
<draft-ietf-ospf-sbfd-discrimina...@ietf.org<mailto:draft-ietf-ospf-sbfd-discrimina...@ietf.org>>,
 OSPF WG List <o...@ietf.org<mailto:o...@ietf.org>>
Subject: Re: 

RE: [OSPF] More Comments on OSPF S-BFD Discriminator

[Les Ginsberg (ginsberg)]

All of this is fine and as it should be – but the ADs need to tell us if the 
discussion of this point as regards draft-ietf-bfd-seamless-base is concluded 
and the IGP drafts may proceed.
As draft-ietf-bfd-seamless-base has been submitted to IESG for publication I 
assume this should be resolved but the IS-IS Draft still has this state:

“Has a DISCUSS. Has enough positions to pass once DISCUSS positions are 
resolved.”

???

   Les


From: Acee Lindem (acee)
Sent: Friday, February 05, 2016 5:00 AM
To: Carlos Pignataro (cpignata); Manav Bhatia
Cc: Les Ginsberg (ginsberg); draft-ietf-ospf-sbfd-discrimina...@ietf.org; OSPF 
WG List
Subject: Re: [OSPF] More Comments on OSPF S-BFD Discriminator

Carlos, Manav,
 I remember now as well - this is the text I was referring to after the 
discussion including Les.
Thanks,
Acee

From: "Carlos Pignataro (cpignata)" 
<cpign...@cisco.com<mailto:cpign...@cisco.com>>
Date: Thursday, February 4, 2016 at 10:33 PM
To: Manav Bhatia <manavbha...@gmail.com<mailto:manavbha...@gmail.com>>
Cc: Acee Lindem <a...@cisco.com<mailto:a...@cisco.com>>, "Les Ginsberg 
(ginsberg)" <ginsb...@cisco.com<mailto:ginsb...@cisco.com>>, 
"draft-ietf-ospf-sbfd-discrimina...@ietf.org<mailto:draft-ietf-ospf-sbfd-discrimina...@ietf.org>"
 
<draft-ietf-ospf-sbfd-discrimina...@ietf.org<mailto:draft-ietf-ospf-sbfd-discrimina...@ietf.org>>,
 OSPF WG List <o...@ietf.org<mailto:o...@ietf.org>>
Subject: Re: [OSPF] More Comments on OSPF S-BFD Discriminator

Thank you Manav! I remember now :-)

Done :-)

https://www.ietf.org/rfcdiff?url2=draft-ietf-ospf-sbfd-discriminator-03

Thanks,

— Carlos.

On Feb 4, 2016, at 9:53 PM, Manav Bhatia 
<manavbha...@gmail.com<mailto:manavbha...@gmail.com>> wrote:

Hi Carlos,

I think we need to add the following in the current version:

“When multiple S-BFD discriminators are advertised how a given discriminator is 
mapped to a specific use case is out of scope for this document.”

I dont have the xml with me that i can update. Can you do it if you have one 
with you?

Cheers, Manav

On Fri, Feb 5, 2016 at 1:17 AM, Carlos Pignataro (cpignata) 
<cpign...@cisco.com<mailto:cpign...@cisco.com>> wrote:
Hi, Acee,

On Feb 4, 2016, at 2:24 PM, Acee Lindem (acee) 
<a...@cisco.com<mailto:a...@cisco.com>> wrote:

Hi Carlos,

From: "Carlos Pignataro (cpignata)" 
<cpign...@cisco.com<mailto:cpign...@cisco.com>>
Date: Thursday, February 4, 2016 at 2:16 PM
To: Acee Lindem <a...@cisco.com<mailto:a...@cisco.com>>
Cc: "Les Ginsberg (ginsberg)" <ginsb...@cisco.com<mailto:ginsb...@cisco.com>>, 
Manav Bhatia <manavbha...@gmail.com<mailto:manavbha...@gmail.com>>, 
"draft-ietf-ospf-sbfd-discrimina...@ietf.org<mailto:draft-ietf-ospf-sbfd-discrimina...@ietf.org>"
 
<draft-ietf-ospf-sbfd-discrimina...@ietf.org<mailto:draft-ietf-ospf-sbfd-discrimina...@ietf.org>>,
 OSPF WG List <o...@ietf.org<mailto:o...@ietf.org>>
Subject: Re: [OSPF] More Comments on OSPF S-BFD Discriminator

Hi, Acee,

Following up on your note below regarding draft-ietf-ospf-sbfd-discriminator, 
could you request publication and send this document to the IESG?

Has the document been updated with the proposed text? It hasn’t been modified 
since Sept 24, 2015.


Yes. The only text modification proposed and to be implemented was done here:
https://tools.ietf.org/rfcdiff?url2=draft-ietf-ospf-sbfd-discriminator-02.txt

I do not believe there was anything else pending. Do you mean something else?

Thanks!

Carlos.


Thanks,
Acee


[BTW, its sibling document on ISIS is already in IESG ballot.]

Thanks!

— Carlos.

On Nov 11, 2015, at 4:16 PM, Acee Lindem (acee) 
<a...@cisco.com<mailto:a...@cisco.com>> wrote:

I was more concerned about the consumer of the information than the IGPs. I did 
look at base S-BFD draft and I agree this unspecified. Let’s go forward than 
with the proposed text and I will request publication.

Thanks,
Acee

RE: AD Review of draft-ietf-bfd-seamless-base

[Les Ginsberg (ginsberg)]

Manav –

We are mainly in agreement I think.
Inline.

From: Manav Bhatia [mailto:manavbha...@gmail.com]
Sent: Tuesday, December 22, 2015 7:06 AM
To: Les Ginsberg (ginsberg)
Cc: Marc Binderberger; Alvaro Retana (aretana); Santosh P K; rtg-bfd@ietf.org; 
draft-ietf-bfd-seamless-b...@ietf.org; bfd-cha...@ietf.org
Subject: Re: AD Review of draft-ietf-bfd-seamless-base

Les,

>
> So OSPF, IS-IS, L2TP could transport a single discriminator instead of a list?

[Les:] Perhaps - or we could leave these drafts as is - allowing the 
possibility of sending multiple discriminators in the future. The key would be 
for the base S-BFD draft to say something like "currently only support for a 
single discriminator per node is defined".

The problem as i see is this:

1. The use case for supporting multiple discriminators per node imo is pretty 
contrived. I havent yet heard a compelling argument of why we need to support 
that.

2. The bigger problem is to see how the multiple discriminators can be mapped 
to the respective end-points. If IGPs advertise multiple discriminators, then 
we would map all those to the same node, and you cannot support the use case 
defined in the use-case document, which currently is the only case that 
requires multiple discriminators to be advertised.

[Les:] If base S-BFD draft says “only one discriminator is supported” then IGPs 
will never be asked to send multiple discriminators (even though they can).

If in the future support for multiple discriminators is required and defined 
then the IGP/L2TP drafts could either:

   o Be left alone - a simple list is all that is required
   o Be revised to carry whatever additional info S-BFD requires

In future when we are revising  the IGP drafts to carry the additional 
information then why dont we change the drafts then to advertise multiple 
discriminators?

[Les:] LES: I am just trying to avoid modifying the IGP/L2TP drafts at this 
time unnecessarily. And since S-BFD will never ask to advertise multiple 
discriminators this seems safe.

My point is that since we have no idea what additional info might be required 
in the future leaving the IGP/L2TP drafts in their current state does no harm - 
and restricting them to one discriminator only provides no benefit.

I would not argue against this.


That said, if folks feel strongly that we should restrict the IGP/L2TP 
advertisement format to one discriminator I would find that acceptable.

Likewise, if folks feel that we should keep the IGP drafts as is, i would find 
that acceptable.

[Les:] Either way I think we are both OK. ☺

   Les

Cheers, Manav

   Les

>
>
> Regards, Marc
>
>
>
>
> On Mon, 21 Dec 2015 09:36:12 +0530, Manav Bhatia wrote:
> > Hi Les,
> >
> > I had asked the exact same question in an offline email that i did not
> > get a reply for.
> >
> > I can say, as the primary co-author of the base S-BFD draft that the
> > case for multiple SBFD discriminators stands on very tenuous grounds.
> > The idea was very weird and i had argued that it really was an
> > architectural/implementation limitation that was being addressed by
> > way of supporting multiple discriminators per node. Given that there
> > are others that share this concern I would recommend striking that off
> > from the base S-BFD draft. You can look at Sec 3.8 of
> > https://tools.ietf.org/html/draft-ietf-bfd-seamless-use-case-03#page-7
> > to understand why we may want to support multiple discriminators per
> node.
> >
> > I had conceded to that being added since i did not want to preclude
> > the possibility of adding that mechanism in the future. And it was
> > felt that this would get debated in the WG and we would go based on the
> consensus.
> >
> > My considered opinion is to strike that off from the base draft and
> > move on, since S-BFD solves a real problem and should not be stalled
> > for something that may never end up getting implemented.
> >
> > Cheers, Manav
> >
> >
> > On Mon, Dec 21, 2015 at 5:55 AM, Les Ginsberg (ginsberg)
> > <ginsb...@cisco.com<mailto:ginsb...@cisco.com>> wrote:
> >> I certainly agree with everyone that the IGPs are merely a transport
> >> and do not "allocate" reflector discriminators nor - for the purposes
> >> of advertising S-BFD discriminators - do they have any understanding
> >> of how S-BFD discriminators are to be used.
> >>
> >> However, before we rush off in a direction which will invalidate any
> >> early implementations of the IGP drafts, I would like to see a
> >> justification of the need for a given node to require multiple
> >> reflector S-BFD discriminators and an explanation of what criteria
> >> would be used to determine whether 

RE: AD Review of draft-ietf-bfd-seamless-base

[Les Ginsberg (ginsberg)]

Marc -

> -Original Message-
> From: Marc Binderberger [mailto:m...@sniff.de]
> Sent: Monday, December 21, 2015 11:09 PM
> To: Manav Bhatia; Les Ginsberg (ginsberg)
> Cc: Alvaro Retana (aretana); Santosh P K; rtg-bfd@ietf.org; draft-ietf-bfd-
> seamless-b...@ietf.org; bfd-cha...@ietf.org
> Subject: Re: AD Review of draft-ietf-bfd-seamless-base
> 
> Hello Manav!
> 
> > S-BFD draft. You can look at Sec 3.8 of
> > https://tools.ietf.org/html/draft-ietf-bfd-seamless-use-case-03#page-7
> > to understand why we may want to support multiple discriminators per
> node.
> 
> ah, that problem :-)
> 
> > My considered opinion is to strike that off from the base draft and
> > move on, since S-BFD solves a real problem and should not be stalled
> > for something that may never end up getting implemented.
> 
> So OSPF, IS-IS, L2TP could transport a single discriminator instead of a list?

[Les:] Perhaps - or we could leave these drafts as is - allowing the 
possibility of sending multiple discriminators in the future. The key would be 
for the base S-BFD draft to say something like "currently only support for a 
single discriminator per node is defined".

If in the future support for multiple discriminators is required and defined 
then the IGP/L2TP drafts could either:

   o Be left alone - a simple list is all that is required
   o Be revised to carry whatever additional info S-BFD requires

My point is that since we have no idea what additional info might be required 
in the future leaving the IGP/L2TP drafts in their current state does no harm - 
and restricting them to one discriminator only provides no benefit.

That said, if folks feel strongly that we should restrict the IGP/L2TP 
advertisement format to one discriminator I would find that acceptable.

   Les

> 
> 
> Regards, Marc
> 
> 
> 
> 
> On Mon, 21 Dec 2015 09:36:12 +0530, Manav Bhatia wrote:
> > Hi Les,
> >
> > I had asked the exact same question in an offline email that i did not
> > get a reply for.
> >
> > I can say, as the primary co-author of the base S-BFD draft that the
> > case for multiple SBFD discriminators stands on very tenuous grounds.
> > The idea was very weird and i had argued that it really was an
> > architectural/implementation limitation that was being addressed by
> > way of supporting multiple discriminators per node. Given that there
> > are others that share this concern I would recommend striking that off
> > from the base S-BFD draft. You can look at Sec 3.8 of
> > https://tools.ietf.org/html/draft-ietf-bfd-seamless-use-case-03#page-7
> > to understand why we may want to support multiple discriminators per
> node.
> >
> > I had conceded to that being added since i did not want to preclude
> > the possibility of adding that mechanism in the future. And it was
> > felt that this would get debated in the WG and we would go based on the
> consensus.
> >
> > My considered opinion is to strike that off from the base draft and
> > move on, since S-BFD solves a real problem and should not be stalled
> > for something that may never end up getting implemented.
> >
> > Cheers, Manav
> >
> >
> > On Mon, Dec 21, 2015 at 5:55 AM, Les Ginsberg (ginsberg)
> > <ginsb...@cisco.com> wrote:
> >> I certainly agree with everyone that the IGPs are merely a transport
> >> and do not "allocate" reflector discriminators nor - for the purposes
> >> of advertising S-BFD discriminators - do they have any understanding
> >> of how S-BFD discriminators are to be used.
> >>
> >> However, before we rush off in a direction which will invalidate any
> >> early implementations of the IGP drafts, I would like to see a
> >> justification of the need for a given node to require multiple
> >> reflector S-BFD discriminators and an explanation of what criteria
> >> would be used to determine whether the reflector should/should not
> >> respond to an Initiator S-BFD packet to a particular S-BFD reflector
> >> discriminator. Perhaps I have missed it, but to date I am not aware
> >> of any cogent explanation of this capability. The desire for multiple
> >> S-BFD discriminators seems to be made out of either:
> >>
> >>o An abundance of caution ("We don't know why we would need them -
> >> but if we come up with something in the future it would be nice if we
> >> didn't preclude it.")
> >>
> >>o Use cases which no one knows how to support (e.g. mapping a
> >> particular discriminator to a particular incoming interface or line
> >> card)
> &g

RE: AD Review of draft-ietf-bfd-seamless-base

[Les Ginsberg (ginsberg)]

I certainly agree with everyone that the IGPs are merely a transport and do not 
"allocate" reflector discriminators nor - for the purposes of advertising S-BFD 
discriminators - do they have any understanding of how S-BFD discriminators are 
to be used.

However, before we rush off in a direction which will invalidate any early 
implementations of the IGP drafts, I would like to see a justification of the 
need for a given node to require multiple reflector S-BFD discriminators and an 
explanation of what criteria would be used to determine whether the reflector 
should/should not respond to an Initiator S-BFD packet to a particular S-BFD 
reflector discriminator. Perhaps I have missed it, but to date I am not aware 
of any cogent explanation of this capability. The desire for multiple S-BFD 
discriminators seems to be made out of either:

   o An abundance of caution ("We don't know why we would need them - but if we 
come up with something in the future it would be nice if we didn't preclude 
it.")

   o Use cases which no one knows how to support (e.g. mapping a particular 
discriminator to a particular incoming interface or line card)

What are the requirements and what about them necessitates multiple S-BFD 
discriminators?

   Les


> -Original Message-
> From: Rtg-bfd [mailto:rtg-bfd-boun...@ietf.org] On Behalf Of Marc
> Binderberger
> Sent: Saturday, December 19, 2015 1:33 AM
> To: Alvaro Retana (aretana); Santosh P K
> Cc: rtg-bfd@ietf.org; draft-ietf-bfd-seamless-b...@ietf.org; bfd-
> cha...@ietf.org
> Subject: Re: AD Review of draft-ietf-bfd-seamless-base
> 
> Hello Santosh, Alvaro et al.,
> 
> >> [SPK] This is implementation specific right? Do we need this to be
> >> captured in document?
> 
> we could make it "just a TLV" which the IGP/L2TP transports to other S-BFD
> modules. The transport mechanism then would not need to know the inner
> structure, e.g. [type, discriminator], to function correctly.
> 
> But for S-BFD modules to interoperate we would need to define the inner
> structure of the "V" in the TLV.
> 
> Implementation specific could be if you want to have awareness of the inner
> structure in the IGP/L2TP code already, e.g. when the IGP wants to make use
> of S-BFD information it transports, for it's own purpose (shortcutting some
> API calls).
> 
> 
> We have to ask the L2TP, OSPF, IS-IS authors if they would be fine with this
> change :-)
> 
> 
> Regards, Marc
> 
> 
> 
> 
> 
> 
> On Fri, 18 Dec 2015 14:00:16 +, Alvaro Retana (aretana) wrote:
> > On 12/18/15, 4:30 AM, "Santosh P K"  wrote:
> >
> > Santosh:
> >
> > Hi!
> >
> >>> There is another aspect: the protocols (OSPF, IS-IS, L2TP) plan to
> >>> transport
> >>> a list of discriminators. Okay ... but how is the receiver S-BFD module
> >>> making sense out of this list?  Would have expected something like
> (type,
> >>> discriminator). The protocols don't need to understand the details, only
> >>> that
> >>> the API transports one or more of these tuples in/out of the protocol
> >>> module.
> >>> S-BFD would know/define what a particular type means.
> >>> Just asking before we send OSPF, IS-IS, L2TP into the wrong direction :-)
> >>
> >> [SPK] This is implementation specific right? Do we need this to be
> >> captured in document?
> >
> > What is implementation specific?
> >
> > Right now the IGPs (generalizing: ISIS, OSPF, L2TP, etc.) are developing
> > drafts to only carry the discriminators.  If, as Mark suggests, the IGPs
> > also transport something like "type", then S-BFD would know what each
> > discriminator is for.
> >
> > Several questions:  Is this (transporting [type, discriminator]) what is
> > expected from the IGPs?  If so, I assume the S-BFD module on the nodes
> > assigns those values for transportation, right?  How does a receiver know
> > what a particular type means?
> >
> > Maybe the expectation from S-BFD is different...??  That is something that
> > needs to be clarified so the IGP work can proceed.
> >
> > Thanks!
> >
> > Alvaro.
> >

RE: Multiple BFD sessions between the same pair of end-points

[Les Ginsberg (ginsberg)]

Greg -

I agree with your characterization.

I would also suggest that RFC 5883 Section 4.1 makes the same statement for 
multi-hop BFD  - at least from the standpoint of L3 clients.

   Les


From: Rtg-bfd [mailto:rtg-bfd-boun...@ietf.org] On Behalf Of Gregory Mirsky
Sent: Monday, November 02, 2015 6:27 PM
To: rtg-bfd@ietf.org
Subject: Multiple BFD sessions between the same pair of end-points

Dear All,
I think that this paragraph from Section 2 of RFC 5881 prohibits multiple 
single-hop BFD sessions between the same pair of end points:
   Each BFD session between a pair of systems MUST traverse a separate
   network-layer path in both directions.  This is necessary for
   demultiplexing to work properly, and also because (by definition)
   multiple sessions would otherwise be protecting the same path.

Regards,
Greg