Re: Shephered writeup for draft-ietf-bfd-secure-sequence-numbers

[Reshad Rahman (rrahman)]

Hi,

Authors, thank you for addressing my comments in rev-06.

I believe there’s some room for clarification in Section 3.

Comments:

  1.  [0] states monotonically increasing sequence number but the sequence 
number is actually in [S]

[A] states Authentication but the authentication format contains the sequence 
#. So this is supposed to be the hash of the BFD packet as described in 4.4 of 
RFC5880.



   As currently defined in BFD [RFC5880], a BFD packet with
   authentication will undergo the following steps, where:

   [O]: original RFC 5880 packet with monotonically increasing sequence
   number

   [S]: pseudo random sequence number

   [A]: Authentication

   SenderReceiver

   [O] [S] [A] - [A] [S] [O]


  1.  The text below states that “mechanism of provisioning such a key is 
outside the scope of this document”.  But further down H1 and H2 are both 
calculated with key ‘k’. So is the key to calculate the sequence number hash 
the same as the key to calculate the hash for the packet (as per section 4.4 of 
RFC5880)? And if they are the same and the attacker has it, can’t the attacker 
fudge the sequence number hash also? I think I could be missing something here.

   This document proposes that for enhanced security in sequence number
   encoding, the sender would identify a hash algorithm (symmetric) that
   would create a 32 bit hash.  The hashing key is provisioned securely
   on the sender and receiver of the BFD session.  The mechanism of
   provisioning such a key is outside the scope of this document.
   Instead of using the sequence number, the sender encodes the sequence
   number with the hashing key to produce a hash.


  1.  When the receiver does the reverse hash operation to extract the sequence 
number,  > previously received ‘s’  is not enough as per previous text which 
mentions tolerate dropped frames.



   k: hashing key



   s: sequence number



   O: original RFC 5880 packet with monotonically increasing sequence

   number



  1.  What is meant by “remainder of packet”?



   R: remainder of packet



   H1: hash of s



   H2: hash of entire packet



   A: H2 + insertion in packet



   hash(s, k) = H1



   hash((H1 + R), k) = H2



   hash'((Packet - H2), k) == H2 ? Good packet : bad packet



   hash'(H1, k) > previously received s ? Good sequence number : bad

   sequence number



SenderReceiver



[O] [H1] [A]  [A] [H1] [O]



   The above diagram describes how the sender encodes and receiver

   decodes the sequence number.  The sender starts by taking the

   monotonically increasing sequence number and hashing it.  It replaces

   the sequence number with the hash.  It then calculates the hash for

   the entire packet and appends the hash value to the end of the

   packet, before transmitting it.



  1.  s/retrieve s/retrieve ‘s’/ and s/monotically/monotonically/



   The receiver hashes the entire packet without H2, and compares the

   hash value with the received hash (H2).  If the hash values are

   equal, it is a good packet, else it is a bad packet.  It then

   calculates the hash on the received sequence number to retreive s.

   If it is greater than the previously received monotically increasing

   sequence number, then the receiver knows it's a valid sequence

   number.

Regards,
Reshad.

From: "Reshad Rahman (rrahman)" 
Date: Sunday, June 14, 2020 at 2:50 PM
To: "rtg-bfd@ietf.org" , 
"draft-ietf-bfd-secure-sequence-numb...@ietf.org" 

Subject: Shephered writeup for draft-ietf-bfd-secure-sequence-numbers

Authors, WG,

The writeup is available at 
https://datatracker.ietf.org/doc/draft-ietf-bfd-secure-sequence-numbers/shepherdwriteup/

For convenience I’ve copied the comments on the document below.

Regards,
Reshad.


This document updates RFC5880. This is missing from the title page header.



Abstract

s/a security enhancements/a security enhancement/

Suggestion: “This document describes a security enhancement for the sequence 
number used in BFD control packets”.



Requirements Language

Please put this later in the document, e.g. after introduction. Add RFC8174, 
and add it as normative reference.



Introduction

Don’t use Authentication TLV, instead use “Authentication Section”. E.g.

s/in BFD authentication TLVs/in the BFD authentication section/





s/pseudo-random sequence numbers on the frame/pseudo-random sequence numbers in 
BFD control packets/

I’m not sure I understood the last sentence starting with “Further security may 
be ….”. What is “resetting un-encrypted sequence”? Does it mean that when the 
sequence numbers rolls over, it’s reset to a pseudo-random number?



Section 2

Rename to “Theory of operation”

Suggest splitting the  1st sentence, e.g.

   Instead of inserting a monotonically, sometimes occasionally, increasing

   sequence number in BFD

Re: Shepherd writeup for draft-ietf-bfd-optimizing-authentication

[Reshad Rahman (rrahman)]

Hi,

I have gone through rev-11 and my comments have been addressed. Thank you.

Regards,
Reshad.

From: Rtg-bfd  on behalf of "Reshad Rahman (rrahman)" 

Date: Sunday, June 14, 2020 at 2:51 PM
To: "rtg-bfd@ietf.org" , 
"draft-ietf-bfd-optimizing-authenticat...@ietf.org" 

Subject: Shepherd writeup for draft-ietf-bfd-optimizing-authentication

Authors, WG,

The writeup is available at 
https://datatracker.ietf.org/doc/draft-ietf-bfd-optimizing-authentication/

For convenience I’ve copied the comments on the document below.

Regards,
Reshad.


General:

  *   Updates RFC5880 missing from title page
  *   Replace BFD frames by BFD packets or BFD control packets. Don’t use 
frames since RFC5880 uses packets.
  *   Use of term Null-authentication TLV. RFC5880 uses authentication section, 
doesn’t mention auth TLV.



Abstract:

Mention that this document updates RFC5880.



Requirements Language

Please put this is a separate (sub)section later, e.g. after introduction.



Introduction

First paragraph: s/is computationally intensive process/is a computationally 
intensive process/

Split first sentence into 2, e.g.

   Authenticating every BFD [RFC5880] packet with a Simple Password, or

   with a MD5 Message-Digest Algorithm [RFC1321], or Secure Hash

   Algorithm (SHA-1) algorithms is a computationally intensive process.

   This makes it difficult, if not impossible, to authenticate every packet,

   particularly at faster rates.



2nd paragraph: “… only BFD frames that signal a state change in BFD be 
authenticated.” State change is not 100% correct since P/F/D bit changes aren’t 
state changes (as mentioned in more detail below in section 2 comments). What 
about this instead: “State change, a demand mode change (to D bit) or a poll 
sequence change (P or F bit change) in a BFD packet are categorized as a 
significant BFD change. This document proposes that all BFD control packets 
which signal a significant BFD change MUST be authenticated if the session’s 
bfd.AuthType is non-zero. Other BFD control packets MAY be transmitted and 
received without the A bit set.” If you do use “significant BFD change”, add it 
to terminology section.

s/non-state change frame/BFD control packets without state or D/F/P bit 
change/, e.g.

“To detect a Man In the Middle (MITM) attack, it is also proposed that BFD 
control packets without a significant change be authenticated occasionally.  
The interval of these control packets…”



Section 2

POLL and DEMAND are NOT strictly states. POLL refers to “Poll sequence” as 
specified in section 6.5 of RFC5880. DEMAND refers to “Demand mode” as 
specified in section 6.6 of RFC5880. In the table, the POLL entry refers to 
polling sequence enabled and in any BFD state. Likewise, the DEMAND entry 
refers to Demand mode. This means that a session in UP state, in demand mode 
and polling sequence enabled will match 3 entries in that table. It’s a bit 
confusing. Here’s what I suggest instead:

  1.  Take POLL out of the table. Add a paragraph mentioning that if P or F bit 
changes value, the packet MUST be authenticated
  2.  Take DEMAND out of the table. Add a paragraph mentioning that if D bit 
changes value, the packet MUST be authenticated



Another comment on the table. The text says it should be read as state change 
from column to row. Column INIT to row UP is n/a whereas column UP to row INIT 
is Auth. INIT to UP is a valid transition, UP to INIT is not (has to go through 
DOWN first). So I think those entries should be reversed in the table.



Last paragraph: CC frames is not defined in BFD, use “control packets” instead?



Section 3

Sequence number mentions “as defined in [RFC5880]”. Suggest mentioning 
bfd.XmitAuthSeq



Security Considerations.

I believe this needs to be beefed up:

  1.  Use of sequence number for non-authenticated frames. Secure sequence 
numbers even better.
  2.  Mention (again) that non-authenticated BFD packets which have a 
significant change (state, D/F/P) are dropped. So if someone injects a 
non-authenticated packet with Down state to take down the session, that won’t 
work.



Section 6.2

RFC5880 should be a normative reference.

Re: New Version Notification for draft-ietf-bfd-stability-06.txt

[Reshad Rahman (rrahman)]

Hi Santosh, authors,

The comments below are pretty minor. Please address them in next rev and we’ll 
be good to go to next step for this document.

Regards,
Reshad,

From: Rtg-bfd  on behalf of "Reshad Rahman (rrahman)" 

Date: Thursday, July 23, 2020 at 10:43 PM
To: Santosh P K , "rtg-bfd@ietf.org" 

Subject: Re: New Version Notification for draft-ietf-bfd-stability-06.txt

Hi Santosh,

Thanks for addressing the comments.

General: NULL authentication TLV is still used, should be replaced with NULL 
authentication type or section as appropriate.
Be consistent for Null v/s NULL (NULL Auth is used in 
bfd-optimizing-authentication)

Introduction
s/detect lost packet/detect lost packets/

Section 3 Use Cases:
s/any BFD packet loss if loss/any BFD packet loss if the loss/
s/BFD implementation/BFD implementations/
Where the text says “failure of a link”, might be better to say “failure of a 
datapath”?
Informative references to CFM and TWAMP would be useful

Section 4

“by appending the Null-Authentication type “. Suggest “by appending an 
authentication section with the NULL Authentication type “

Section 5
“BFD uses authentication TLV”, suggest change to “BFD uses an authentication 
section”.

“BFD packets MUST include NULL-Auth TLV”. Change to “BFD control packets MUST 
include an authentication section with the NULL Authentication type”

Section 5.1


“The first BFD NULL-Auth type processed by the receiver…”.  Change to  “The 
first BFD authentication section with the NULL Authentication type, in a valid 
BFD control packet, processed by the receiver” .

Also, does it have to be NULL Auth, I believe it can be any auth with sequence 
number? If that’s the case change to  “The first BFD authentication section 
with a non-zero sequence number, in a valid BFD control packet, processed by 
the receiver is used for….”.



Regards,

Reshad.


From: Rtg-bfd  on behalf of Santosh P K 

Date: Sunday, July 19, 2020 at 4:06 PM
To: "rtg-bfd@ietf.org" 
Subject: Fwd: New Version Notification for draft-ietf-bfd-stability-06.txt

Hello All,
A new version of draft for BFD-stablity is here for review. Changes include 
addressing shepherd comments as provided here. 
https://datatracker.ietf.org/doc/draft-ietf-bfd-stability/shepherdwriteup/. 
Please also see attached diff.

Thanks
Santosh P K
-- Forwarded message -
From: mailto:internet-dra...@ietf.org>>
Date: Mon, Jul 13, 2020 at 4:41 PM
Subject: New Version Notification for draft-ietf-bfd-stability-06.txt
To: Mach Chen mailto:mach.c...@huawei.com>>, Ankur Saxena 
mailto:ankurpsax...@gmail.com>>, Peng Fan 
mailto:fan...@gmail.com>>, Mahesh Jethanandani 
mailto:mjethanand...@gmail.com>>, Ashesh Mishra 
mailto:mishra.ash...@gmail.com>>, Santosh Pallagatti 
mailto:santosh.pallaga...@gmail.com>>



A new version of I-D, draft-ietf-bfd-stability-06.txt
has been successfully submitted by Santosh Pallagatti and posted to the
IETF repository.

Name:   draft-ietf-bfd-stability
Revision:   06
Title:  BFD Stability
Document date:  2020-07-13
Group:  bfd
Pages:  6
URL:
https://www.ietf.org/internet-drafts/draft-ietf-bfd-stability-06.txt
Status: https://datatracker.ietf.org/doc/draft-ietf-bfd-stability/
Htmlized:   https://tools.ietf.org/html/draft-ietf-bfd-stability-06
Htmlized:   https://datatracker.ietf.org/doc/html/draft-ietf-bfd-stability
Diff:   https://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-stability-06

Abstract:
   This document describes extensions to the Bidirectional Forwarding
   Detection (BFD) protocol to measure BFD stability.  Specifically, it
   describes a mechanism for detection of BFD packet loss.




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<http://tools.ietf.org>.

The IETF Secretariat

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

[Reshad Rahman (rrahman)]

Jeff, Martin, Rob, Warren,

Any guidance on this? As mentioned below, I favour having the YANG model in the 
same document. If we go that way, the question then is whether the document is 
informational or not.

Regards,
Reshad (no hat).

On 2020-08-19, 11:04 AM, "tom petch"  wrote:


At the end

From: Les Ginsberg (ginsberg) 
Sent: 19 August 2020 15:42

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.


I agree with your characterisation of Normative and Informative.

With split documents, then it seems clear to me that there would be a 
Normative Reference from the YANG document to the non-YANG one since it is 
impossible to make sense of the YANG one without understanding the use of the 
BFD protocol. If the non-YANG one is Informational, then you have a downref 
from one to the other which is more work for the AD and IESG which I would seek 
to avoid.

I went through YANG and YANG Guidelines and there is no explicit statement 
that a Normative YANG module (which this one clearly is AFAICT) must be in a 
Standards Track I-D but there are plenty of places where that is implicit, the 
alternatives being e.g. the document of another SDO versus IETF Standards track 
with no consideration of IETF not on the Standards track so I think that a 
single Informational document is also more work for the AD to push through the 
IESG.

Which leaves a single Standards Track document as the best alternative IMHO 
with text to allay the concerns expressed here about the absence of changes to 
the protocol.

I would see Ops AD as the authority on this , the one who has to convince 
the IESG of the correctness of the WG decision, to make the presence of a YANG 
module the deciding factor; I cannot recall it arising before. YMMV

Tom Petch
.
??

   Les

> -Original Message-
> From: tom petch 
> Sent: Wednesday, August 19, 2020 1:54 AM
>
> 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 toget

Re: I-D Action: draft-ietf-bfd-yang-17.txt

[Reshad Rahman (rrahman)]

On 2020-08-21, 5:57 AM, "tom petch"  wrote:

From: Reshad Rahman (rrahman) 
Sent: 20 August 2020 18:42

I had noticed the lsps vs lsps-state, mentioned it at last BFD WG meeting 
and have been in touch with the teas-yang authors.

I hadn't noticed that mpls:enabled had been removed. I'll have to go 
through all MPLS-related items in the BFD yang.


Yes please; enabled is still there but in a different place; I have not 
gone back to mpls-base-yang-03 to see if the semantics are the same.

Note my third rather indecisive comment that mpls-base-yang now models mpls 
in a different way, splitting IP routes with some MPLS, from MPLS only routes, 
with no IP, as described in mpls-base-yang-15; I have not got my head around 
this and do not know how it fits with bfd but suspect that it needs some 
thinking about.
 I don't think it has an impact because BFD uses an IP-prefix as MPLS-FEC. 
But I will take a look.

I read the meeting minutes but your significant (for me) contribution 
appears to have passed the minute taker by:-)
  It was mentioned in the chairs slides though.

Regards,
Reshad.

Tom Petch



Regards,
Reshad.

On 2020-08-20, 12:33 PM, "t petch"  wrote:

Yes bfd-yang.  Sometimes I would like to be wrong.

When I look at this I-D, I see that it references
 /rt:routing/mpls:mpls/mpls:interface/mpls:config/mpls:enabled
In 2018, the MPLS WG removed that /config from the mpls-base-yang so
this would seem to be no longer valid. What needs changing to rectify
this I have not explored.

The I-D has
  augment "/te:te/te:lsps-state/te:lsp"
which I no longer see in  draft-ietf-teas-yang-te - the -state has gone.
Again, I have not explored the ramifications of this.

MPLS WG has a new base-yang out this week which differentiates between
an IP route with a MPLS next hop and a MPLS route with no IP, the latter
forming a new, mpls Address Family.  I would think that the latter is
not catered for by BFD but it would be nice to be wrong

Tom Petch

Re: I-D Action: draft-ietf-bfd-yang-17.txt

[Reshad Rahman (rrahman)]

I had noticed the lsps vs lsps-state, mentioned it at last BFD WG meeting and 
have been in touch with the teas-yang authors.

I hadn't noticed that mpls:enabled had been removed. I'll have to go through 
all MPLS-related items in the BFD yang.

Regards,
Reshad.

On 2020-08-20, 12:33 PM, "t petch"  wrote:

Yes bfd-yang.  Sometimes I would like to be wrong.

When I look at this I-D, I see that it references
 /rt:routing/mpls:mpls/mpls:interface/mpls:config/mpls:enabled
In 2018, the MPLS WG removed that /config from the mpls-base-yang so
this would seem to be no longer valid. What needs changing to rectify
this I have not explored.

The I-D has
  augment "/te:te/te:lsps-state/te:lsp"
which I no longer see in  draft-ietf-teas-yang-te - the -state has gone.
Again, I have not explored the ramifications of this.

MPLS WG has a new base-yang out this week which differentiates between
an IP route with a MPLS next hop and a MPLS route with no IP, the latter
forming a new, mpls Address Family.  I would think that the latter is
not catered for by BFD but it would be nice to be wrong

Tom Petch

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

[Reshad Rahman (rrahman)]

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 
Date: Tuesday, August 18, 2020 at 9:01 PM
To: Robert Raszuk , "Les Ginsberg (ginsberg)" 
, "Reshad Rahman (rrahman)" , Martin 
Vigoureux 
Cc: "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) 
, 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  on behalf of Robert Raszuk 

Date: Tuesday, August 18, 2020 at 5:44 AM
To: "Les Ginsberg (ginsberg)" 
Cc: "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)

[Reshad Rahman (rrahman)]

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  on behalf of Robert Raszuk 

Date: Tuesday, August 18, 2020 at 5:44 AM
To: "Les Ginsberg (ginsberg)" 
Cc: "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
> 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

FW: [108all] Final reminder: IETF 108 meeting survey

[Reshad Rahman (rrahman)]

If you attended IETF108, please take a few mins to fill out the survey.

From: WGChairs  on behalf of Alissa Cooper 

Date: Wednesday, August 5, 2020 at 11:53 AM
To: IETF WG Chairs 
Subject: Fwd: [108all] Final reminder: IETF 108 meeting survey

Please share this with your working group/research group lists if you have not 
done so already.

Thanks,
Alissa


Begin forwarded message:

From: IETF Executive Director 
mailto:exec-direc...@ietf.org>>
Subject: [108all] Final reminder: IETF 108 meeting survey
Date: August 5, 2020 at 6:30:16 AM EDT
To: 108...@ietf.org

Thank you very much to the ~230 people who have filled in the IETF 108 meeting 
survey as this data is crucial to helping us plan future meetings.  We could 
still use another 70 or so responses and so this is a final reminder to please 
help us by taking a few minutes to complete the survey:

https://www.surveymonkey.com/r/T3SL7JF

Thanks in advance

--
Jay Daley
IETF Executive Director
exec-direc...@ietf.org

--
108all mailing list
108...@ietf.org
https://www.ietf.org/mailman/listinfo/108all

Changes to draft-ietf-teas-yang-te

[Reshad Rahman (rrahman)]

Hi,

I was just checking BFD YANG and noticed YANG errors:
err : Failed to resolve augment "/ietf-te:te/ietf-te:lsps-state/ietf-te:lsp". 
(/ietf-bfd-mpls-te:{augment}[/ietf-te:te/ietf-te:lsps-state/ietf-te:lsp])
err : Module "ietf-bfd-mpls-te" parsing failed.

TE YANG got updated on Monday and these diffs show that container lsps-state is 
now gone
https://tools.ietf.org/rfcdiff?difftype=--hwdiff=draft-ietf-teas-yang-te-25.txt

I haven’t looked at the changes in detail, will do so after IETF. Is this just 
replacing container lsps-state with container lsps?

Regards,
Reshad.

Re: I-D Action: draft-ietf-bfd-optimizing-authentication-10.txt

[Reshad Rahman (rrahman)]

Hi Mahesh,

On 2020-07-27, 3:14 PM, "Mahesh Jethanandani"  wrote:


> 
> Section 2. Thanks for modifying the table as per our discussions. 
Regarding adding AdminDown to the table, I believe I misled you. Our discussion 
was based on "what happens if we're UP and receive a packet which says 
AdminDown"? As per 6.2 of RFC5880, the receiver would go to DOWN state. However 
the rows/columns in the table are for the local state (new and old), and not 
for state in received packet. Since we can't go to AdminDown state or leave 
AdmnDown state based on a packet received, AdminDown state should be removed 
from this table . I think it'd be good to add a reference to the BFD FSM (6.8.2 
of RFC5880) in the paragraph before the table.

You mean Section 6.2 of RFC 5880.

Yes indeed that's what I meant.

Regards,
Reshad.

IETF108: BFD WG meeting invitation

[Reshad Rahman (rrahman)]

BEGIN:VCALENDAR
VERSION:2.0
CALSCALE:GREGORIAN
PRODID:-//Henrik Levkowetz//ietf-agenda-ical 1.03//EN
X-WR-CALNAME:IETF-108
X-PUBLISHED-TTL:PT60M
METHOD:PUBLISH
BEGIN:VTIMEZONE
TZID:UTC
BEGIN:STANDARD
TZOFFSETFROM:+
TZOFFSETTO:+
TZNAME:UTC
DTSTART:19-00101T00
RDATE:19000101T00
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
DTSTART;TZID=UTC:20200730T13
DTEND;TZID=UTC:20200730T135000
DTSTAMP:20200726T141717Z
UID:ical-ietf-108-bf...@tools.ietf.org
SEQUENCE:599
SUMMARY:bfd - Bidirectional Forwarding Detection WG (RT
 G)
LOCATION:Room 5
URL:http://tools.ietf.org/wg/bfd/agenda
END:VEVENT
END:VCALENDAR

Re: New Version Notification for draft-ietf-bfd-stability-06.txt

[Reshad Rahman (rrahman)]

Hi Santosh,

Thanks for addressing the comments.

General: NULL authentication TLV is still used, should be replaced with NULL 
authentication type or section as appropriate.
Be consistent for Null v/s NULL (NULL Auth is used in 
bfd-optimizing-authentication)

Introduction
s/detect lost packet/detect lost packets/

Section 3 Use Cases:
s/any BFD packet loss if loss/any BFD packet loss if the loss/
s/BFD implementation/BFD implementations/
Where the text says “failure of a link”, might be better to say “failure of a 
datapath”?
Informative references to CFM and TWAMP would be useful

Section 4

“by appending the Null-Authentication type “. Suggest “by appending an 
authentication section with the NULL Authentication type “

Section 5
“BFD uses authentication TLV”, suggest change to “BFD uses an authentication 
section”.

“BFD packets MUST include NULL-Auth TLV”. Change to “BFD control packets MUST 
include an authentication section with the NULL Authentication type”

Section 5.1


“The first BFD NULL-Auth type processed by the receiver…”.  Change to  “The 
first BFD authentication section with the NULL Authentication type, in a valid 
BFD control packet, processed by the receiver” .

Also, does it have to be NULL Auth, I believe it can be any auth with sequence 
number? If that’s the case change to  “The first BFD authentication section 
with a non-zero sequence number, in a valid BFD control packet, processed by 
the receiver is used for….”.



Regards,

Reshad.


From: Rtg-bfd  on behalf of Santosh P K 

Date: Sunday, July 19, 2020 at 4:06 PM
To: "rtg-bfd@ietf.org" 
Subject: Fwd: New Version Notification for draft-ietf-bfd-stability-06.txt

Hello All,
A new version of draft for BFD-stablity is here for review. Changes include 
addressing shepherd comments as provided here. 
https://datatracker.ietf.org/doc/draft-ietf-bfd-stability/shepherdwriteup/. 
Please also see attached diff.

Thanks
Santosh P K
-- Forwarded message -
From: mailto:internet-dra...@ietf.org>>
Date: Mon, Jul 13, 2020 at 4:41 PM
Subject: New Version Notification for draft-ietf-bfd-stability-06.txt
To: Mach Chen mailto:mach.c...@huawei.com>>, Ankur Saxena 
mailto:ankurpsax...@gmail.com>>, Peng Fan 
mailto:fan...@gmail.com>>, Mahesh Jethanandani 
mailto:mjethanand...@gmail.com>>, Ashesh Mishra 
mailto:mishra.ash...@gmail.com>>, Santosh Pallagatti 
mailto:santosh.pallaga...@gmail.com>>



A new version of I-D, draft-ietf-bfd-stability-06.txt
has been successfully submitted by Santosh Pallagatti and posted to the
IETF repository.

Name:   draft-ietf-bfd-stability
Revision:   06
Title:  BFD Stability
Document date:  2020-07-13
Group:  bfd
Pages:  6
URL:
https://www.ietf.org/internet-drafts/draft-ietf-bfd-stability-06.txt
Status: https://datatracker.ietf.org/doc/draft-ietf-bfd-stability/
Htmlized:   https://tools.ietf.org/html/draft-ietf-bfd-stability-06
Htmlized:   https://datatracker.ietf.org/doc/html/draft-ietf-bfd-stability
Diff:   https://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-stability-06

Abstract:
   This document describes extensions to the Bidirectional Forwarding
   Detection (BFD) protocol to measure BFD stability.  Specifically, it
   describes a mechanism for detection of BFD packet loss.




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.

The IETF Secretariat

BFD presentation material for IETF108

[Reshad Rahman (rrahman)]

Please send your presentation material to the chairs by Tuesday July 28th.

Regards,
Reshad.

From: Rtg-bfd  on behalf of "Reshad Rahman (rrahman)" 

Date: Saturday, July 11, 2020 at 12:30 PM
To: "rtg-bfd@ietf.org" 
Subject: [CORRECTION] IETF108: call for BFD presentations

Final agenda<https://datatracker.ietf.org/meeting/108/agenda.html> is out.

BFD WG is meeting on Thursday July 30th at 13:00 UTC (not PDT).

Regards,
Reshad.

From: "Reshad Rahman (rrahman)" 
Date: Monday, June 29, 2020 at 2:43 PM
To: "rtg-bfd@ietf.org" 
Subject: IETF108: call for BFD presentations

BFD WG,

According to the preliminary 
agenda<https://datatracker.ietf.org/meeting/108/agenda.html>, BFD WG will be 
meeting on Thursday July 30th at 13:00 PDT for 50 mins.

If you’d like to present, please send an email to the chairs with the name of 
the draft, presenter name and duration of presentation. We encourage 
presentations which will foster discussions (as opposed to just a  summary of 
doc update).

Regards,
Reshad & Jeff.

Meetecho for online IETF108 meeting

[Reshad Rahman (rrahman)]

Please take a look @ 
https://www.ietf.org/how/meetings/108/session-participant-guide/

Regards,
Reshad.

BFD preliminary agenda for IETF108

[Reshad Rahman (rrahman)]

BFD WG,

Here is the preliminary agenda for BFD @ IETF108.

https://datatracker.ietf.org/doc/agenda-108-bfd/

Regards,
Reshad & Jeff.

Re: I-D Action: draft-ietf-bfd-optimizing-authentication-10.txt

[Reshad Rahman (rrahman)]

Hi Mahesh and Jeff,

On 2020-07-20, 9:29 PM, "Rtg-bfd on behalf of Mahesh Jethanandani" 
 wrote:

Hi Jeff,

> On Jul 20, 2020, at 5:48 PM, Jeffrey Haas  wrote:
> 
> Mahesh,
> 
> While reviewing version -10, I had the following questions:
> 
> For the state machine changes, in the Init->Init state, we have NULL auth.
> While this is a "boring" transition, it's also happening at a very slow 
part
> of the state machine; timers should be once a second.  Is there a strong
> argument to use NULL here?

Not particularly. The reason to choose NULL was because of the (limited) 
impact it would have. But if the WG feels otherwise, I can change it to Auth.
 I don't have a strong opinion on this yet. But if we change INIT->INIT to 
be Auth, we should be consistent and change Down->Down to Auth too?

Regards,
Reshad.

> 
> In section 3:
> :   Sequence Number: The sequence number for this packet.  Implementation
> :   may use sequence numbers (bfd.XmitAuthSeq) as defined in BFD
> :   [RFC5880], or secure sequence numbers as defined in Secure BFD
> :   Sequence Numbers [I-D.ietf-bfd-secure-sequence-numbers].
> 
> In the core BFD spec, it distinguishes between occasional and meticulous
> modes and uses different code points to determine what you do.  I suspect
> your intent is that we always use meticulous mode here?

Yes, the intent was meticulous. I can clarify that.

> 
> -- Jeff
> 
> 
> On Mon, Jul 13, 2020 at 01:56:14PM -0700, Mahesh Jethanandani wrote:
>>> 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   : Optimizing BFD Authentication
>>>   Authors : Mahesh Jethanandani
>>> Ashesh Mishra
>>> Ankur Saxena
>>> Manav Bhatia
>>> Filename: 
draft-ietf-bfd-optimizing-authentication-10.txt
>>> Pages   : 8
>>> Date: 2020-07-13
>>> 
>>> Abstract:
>>>  This document describes an optimization to BFD Authentication as
>>>  described in Section 6.7 of BFD RFC 5880.  This document updates RFC
>>>  5880.
> 
> 

Mahesh Jethanandani
mjethanand...@gmail.com

Re: I-D Action: draft-ietf-bfd-optimizing-authentication-10.txt

[Reshad Rahman (rrahman)]

Mahesh, thanks for addressing my comments. 

I will update the shepherd write-up based on my comments below.

General: both "BFD control packet" and "BFD packet" are used. I think we should 
stick to "BFD control packet".
General: s/BFD Control packet/BFD control packet/

Introduction, next-to last paragraph. Instead of "The interval of this 
non-state change frame can be...", I'd suggest "The interval of these BFD 
packets can be..." or "The interval of the BFD packets without a significant 
change can be...". Anyway remove "frame" as previously discussed and avoid use 
of "non-state change" now that you've defined what a significant change is.

Section 1.2. The new table could be incorrectly interpreted as having 1 entry. 
Suggest changing this to bullet form would make it clearer.

Section 1.2 introduces the term "configured interval" but section 2 uses the 
term "configured period". Also for the description, what about "interval at 
which BFD control packets are authenticated in the UP state". 
Also wondering if instead we should have a new bfd.AuthUpStateInterval state 
variable (see 6.8.1 of RFC5880) since having this value may not always be 
configured (implementation specific)?

Section 2. Replace  "frame" by "packet" or "BFD control packet"  as appropriate.

Section 2. Thanks for modifying the table as per our discussions. Regarding 
adding AdminDown to the table, I believe I misled you. Our discussion was based 
on "what happens if we're UP and receive a packet which says AdminDown"? As per 
6.2 of RFC5880, the receiver would go to DOWN state. However the rows/columns 
in the table are for the local state (new and old), and not for state in 
received packet. Since we can't go to AdminDown state or leave AdmnDown state 
based on a packet received, AdminDown state should be removed from this table . 
I think it'd be good to add a reference to the BFD FSM (6.8.2 of RFC5880) in 
the paragraph before the table.

Section 2. For configured period (or whatever we decide to call it) add a 
reference to section 1.2.

Section 4. s/to to/to/

Regards,
Reshad.

On 2020-07-13, 4:56 PM, "Rtg-bfd on behalf of Mahesh Jethanandani" 
 wrote:

This version of the draft addresses some of the shepherd comments. Welcome 
any feedback.

> On Jul 13, 2020, at 12:07 PM, internet-dra...@ietf.org wrote:
> 
> 
> 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   : Optimizing BFD Authentication
>Authors : Mahesh Jethanandani
>  Ashesh Mishra
>  Ankur Saxena
>  Manav Bhatia
>   Filename: draft-ietf-bfd-optimizing-authentication-10.txt
>   Pages   : 8
>   Date: 2020-07-13
> 
> Abstract:
>   This document describes an optimization to BFD Authentication as
>   described in Section 6.7 of BFD RFC 5880.  This document updates RFC
>   5880.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-bfd-optimizing-authentication/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-bfd-optimizing-authentication-10
> 
https://datatracker.ietf.org/doc/html/draft-ietf-bfd-optimizing-authentication-10
> 
> A diff from the previous version is available at:
> 
https://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-optimizing-authentication-10
> 
> 
> 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/
> 
> 

Mahesh Jethanandani
mjethanand...@gmail.com

[CORRECTION] IETF108: call for BFD presentations

[Reshad Rahman (rrahman)]

Final agenda<https://datatracker.ietf.org/meeting/108/agenda.html> is out.

BFD WG is meeting on Thursday July 30th at 13:00 UTC (not PDT).

Regards,
Reshad.

From: "Reshad Rahman (rrahman)" 
Date: Monday, June 29, 2020 at 2:43 PM
To: "rtg-bfd@ietf.org" 
Subject: IETF108: call for BFD presentations

BFD WG,

According to the preliminary 
agenda<https://datatracker.ietf.org/meeting/108/agenda.html>, BFD WG will be 
meeting on Thursday July 30th at 13:00 PDT for 50 mins.

If you’d like to present, please send an email to the chairs with the name of 
the draft, presenter name and duration of presentation. We encourage 
presentations which will foster discussions (as opposed to just a  summary of 
doc update).

Regards,
Reshad & Jeff.

Re: Shepherd writeup for draft-ietf-bfd-optimizing-authentication

[Reshad Rahman (rrahman)]

Hi Mahesh,

Thanks for the update.  I’ll re-review the updated document when it’s available.

Inline 

From: Mahesh Jethanandani 
Date: Thursday, July 2, 2020 at 12:13 AM
To: "Reshad Rahman (rrahman)" 
Cc: "rtg-bfd@ietf.org" , 
"draft-ietf-bfd-optimizing-authenticat...@ietf.org" 

Subject: Re: Shepherd writeup for draft-ietf-bfd-optimizing-authentication

Hi Reshad,

Happy Canada day!

Thanks first of all for the shepherd writeup. Please see my comments/questions 
inline.

@Ashesh, please comment on the change to the table.


On Jun 14, 2020, at 11:50 AM, Reshad Rahman (rrahman) 
mailto:rrah...@cisco.com>> wrote:

Authors, WG,

The writeup is available at 
https://datatracker.ietf.org/doc/draft-ietf-bfd-optimizing-authentication/

For convenience I’ve copied the comments on the document below.

Regards,
Reshad.

General:

  *   Updates RFC5880 missing from title page

Hmm. How does one add the “Updates” tag?



  *
  *   Replace BFD frames by BFD packets or BFD control packets. Don’t use 
frames since RFC5880 uses packets.

Done.



  *
  *   Use of term Null-authentication TLV. RFC5880 uses authentication section, 
doesn’t mention auth TLV.

Ok. Have changed all references of “NULL Auth TLV” to “NULL Auth Type”.



  *

Abstract:
Mention that this document updates RFC5880.

Done.



Requirements Language
Please put this is a separate (sub)section later, e.g. after introduction.

Done.



Introduction
First paragraph: s/is computationally intensive process/is a computationally 
intensive process/

Done.


Split first sentence into 2, e.g.
   Authenticating every BFD [RFC5880] packet with a Simple Password, or
   with a MD5 Message-Digest Algorithm [RFC1321], or Secure Hash
   Algorithm (SHA-1) algorithms is a computationally intensive process.
   This makes it difficult, if not impossible, to authenticate every packet,
   particularly at faster rates.

Done.



2nd paragraph: “… only BFD frames that signal a state change in BFD be 
authenticated.” State change is not 100% correct since P/F/D bit changes aren’t 
state changes (as mentioned in more detail below in section 2 comments). What 
about this instead: “State change, a demand mode change (to D bit) or a poll 
sequence change (P or F bit change) in a BFD packet are categorized as a 
significant BFD change. This document proposes that all BFD control packets 
which signal a significant BFD change MUST be authenticated if the session’s 
bfd.AuthType is non-zero. Other BFD control packets MAY be transmitted and 
received without the A bit set.” If you do use “significant BFD change”, add it 
to terminology section.

Done.


s/non-state change frame/BFD control packets without state or D/F/P bit 
change/, e.g.
“To detect a Man In the Middle (MITM) attack, it is also proposed that BFD 
control packets without a significant change be authenticated occasionally.  
The interval of these control packets…”

Done.



Section 2
POLL and DEMAND are NOT strictly states. POLL refers to “Poll sequence” as 
specified in section 6.5 of RFC5880. DEMAND refers to “Demand mode” as 
specified in section 6.6 of RFC5880. In the table, the POLL entry refers to 
polling sequence enabled and in any BFD state. Likewise, the DEMAND entry 
refers to Demand mode. This means that a session in UP state, in demand mode 
and polling sequence enabled will match 3 entries in that table. It’s a bit 
confusing. Here’s what I suggest instead:

  1.  Take POLL out of the table. Add a paragraph mentioning that if P or F bit 
changes value, the packet MUST be authenticated
  2.  Take DEMAND out of the table. Add a paragraph mentioning that if D bit 
changes value, the packet MUST be authenticated

Have made the change as follows. I am hoping Ashesh can comment on it.

The significant changes for which authentication is being suggested
   include:

  Read   : On state change from  to 
  Auth   : Authenticate frame
  NULL   : No Authentication. Use NULL AUTH Type.
  n/a: Invalid state transition.
  Select : Most packets NULL AUTH. Selective (periodic)
   packets authenticated.
 ++---+-+-+
 || DOWN   | INIT   | UP |
 +++++
 | DOWN   |  NULL  |  Auth  |  Auth  |
 +++++
 | INIT   |  Auth  |  NULL  |  n/a   |
 +++++
 | UP |  Auth  |  Auth  | Select |
 +++++

   Optimized Authentication Map

   If P or F bit changes value, the packet MUST be authenticated.  If
   the D bit changes value, the packet MUST be authenticated.
 I’m good with this. I’m ok with doing this differently too, as long as the 
crux of my concern is still addressed.



  1.

Another comment on the table. The text says it should be read as state change 
from colum

IETF108: call for BFD presentations

[Reshad Rahman (rrahman)]

BFD WG,

According to the preliminary 
agenda, BFD WG will be 
meeting on Thursday July 30th at 13:00 PDT for 50 mins.

If you’d like to present, please send an email to the chairs with the name of 
the draft, presenter name and duration of presentation. We encourage 
presentations which will foster discussions (as opposed to just a  summary of 
doc update).

Regards,
Reshad & Jeff.

Shephered writeup for draft-ietf-bfd-secure-sequence-numbers

[Reshad Rahman (rrahman)]

Authors, WG,

The writeup is available at 
https://datatracker.ietf.org/doc/draft-ietf-bfd-secure-sequence-numbers/shepherdwriteup/

For convenience I’ve copied the comments on the document below.

Regards,
Reshad.


This document updates RFC5880. This is missing from the title page header.



Abstract

s/a security enhancements/a security enhancement/

Suggestion: “This document describes a security enhancement for the sequence 
number used in BFD control packets”.



Requirements Language

Please put this later in the document, e.g. after introduction. Add RFC8174, 
and add it as normative reference.



Introduction

Don’t use Authentication TLV, instead use “Authentication Section”. E.g.

s/in BFD authentication TLVs/in the BFD authentication section/





s/pseudo-random sequence numbers on the frame/pseudo-random sequence numbers in 
BFD control packets/

I’m not sure I understood the last sentence starting with “Further security may 
be ….”. What is “resetting un-encrypted sequence”? Does it mean that when the 
sequence numbers rolls over, it’s reset to a pseudo-random number?



Section 2

Rename to “Theory of operation”

Suggest splitting the  1st sentence, e.g.

   Instead of inserting a monotonically, sometimes occasionally, increasing

   sequence number in BFD control packets, a hash is inserted instead.

   The hash is computed, using a shared key, on the sequence number. That

   computed hash is then inserted into the sequence number field of the

   packet.



In the following sentence, the part “used in computing an authenticated packet” 
is referring to computing the SHA1/MD5 hash/digest for the packet? That 
sentence should be clarified then.

   In

   case of BFD Authentication [I-D.ietf-bfd-optimizing-authentication],

   the sequence number used in computing an authenticated packet would

   be this new computed hash.



Also, when referring to the optimization draft, better to use e.g. “optimized 
BFD authentication” than “BFD authentication”. The latter implies per-RFC5880 
BFD authentication.



s/psuedo/pseudo/

s/ scope of this draft/ scope of this document/

s/seuquence/sequence/



Not clear to me what the following means.

  Note: The first sequence number can

   be obtained using the same logic as the My Discriminator value.



The diagram reads well for regular authentication. For secure sequence number, 
I think the diagram would gain clarity from an ordered list of steps on the 
sender and receiver. The current list before the diagram is useful,  I believe 
the sender steps would start at “H1:” and the receiver steps at hash’. And yes, 
hash’ needs an explanation. On the receiver side, for validating that ’s’ is a 
good sequence number, the range has to be checked as mentioned in the previous 
paragraph.



Section 5

s/ stabiluty/ stability/

s/admistratively/administratively/

s/Sequential nature/The sequential nature/

Shepherd writeup for draft-ietf-bfd-stability

[Reshad Rahman (rrahman)]

Authors, WG,

The writeup is available at 
https://datatracker.ietf.org/doc/draft-ietf-bfd-stability/shepherdwriteup/

For convenience I’ve copied the comments on the document below.

Regards,
Reshad.


General:

  *   Don’t use NULL-authentication TLV, use RFC5880 language. 
e.g.NULL-authentication type.
  *   s/control frame/control packet/ (reuse same terms as in RFC5880)
  *   CC frames is not defined in BFD, use “control packets” instead?
  *   Terminology section would help. In there: secure sequence numbers, 
meticulous authentication etc could be added.
  *   Missing “the”, “an” in a few sentences.



Introduction



Following sentence is long and not super clear, what’s the essence of the point 
it’s trying to make?

I’m having a hard time digesting “…, the tolerance for lost or delayed frames 
in the Detection Time,”. Is it just saying that Detection Time is usually set 
to smallest value and

because of this there’s little tolerance for delayed/lost packets? Needs 
tweaking.



  .In order to

   prevent significant data loss due to a datapath failure, the

   tolerance for lost or delayed frames in the Detection Time, as

   defined in BFD [RFC5880] is set to the smallest feasible value.



s/does not propose BFD extension/does not propose any BFD extension/





Requirements Language

Please put this is a separate (sub)section later in the doc, e.g. after intro. 
Add RFC8174, and have RFCs 2119 and 8174  as normative references.



2. Use cases



Legacy BFD? Why not say BFD as specified in RFC5880. Or add “Legacy BFD”  in 
terminology section.



Instead of “dead interval”, use “Detection Time” as defined in RFC5880.

s/This draft/This document/

s/enables BFD engine/enables the BFD engine/

Instead of “BFD engine”, use “BFD implementation”? I understand what you mean 
by “BFD engine”, and ok if you keep it, but it’s not a term I’ve seen in BFD 
drafts/RFCs.



s/In a faulty datapath scenario, operator/In a faulty datapath scenario, an 
operator/

Add references for CFM and TWAMP in last paragraph?



3.  BFD Null-Authentication TLV



Rename to BFD Null-Authentication section?

s/BFD control frame that do not/BFD control packets that do not/



Suggestion: consider putting this is a sub-section of section 4 “Theory of 
operation”?



4. Theory of operations



s/4. Theory of operations/4. Theory of operation/



s/This mechanism allows operator/This mechanism allows operators/



4.1



Following needs clarification. What is “appropriately recorded”? For secure 
sequence number, add normative reference to 
draft-ietf-bfd-secure-sequence-numbers.



   When using

   secure sequence numbers, if the expected values are pre-calculated,

   the matched value must be appropriately recorded to detect lost

   frames.

Shepherd writeup for draft-ietf-bfd-optimizing-authentication

[Reshad Rahman (rrahman)]

Authors, WG,

The writeup is available at 
https://datatracker.ietf.org/doc/draft-ietf-bfd-optimizing-authentication/

For convenience I’ve copied the comments on the document below.

Regards,
Reshad.


General:

  *   Updates RFC5880 missing from title page
  *   Replace BFD frames by BFD packets or BFD control packets. Don’t use 
frames since RFC5880 uses packets.
  *   Use of term Null-authentication TLV. RFC5880 uses authentication section, 
doesn’t mention auth TLV.



Abstract:

Mention that this document updates RFC5880.



Requirements Language

Please put this is a separate (sub)section later, e.g. after introduction.



Introduction

First paragraph: s/is computationally intensive process/is a computationally 
intensive process/

Split first sentence into 2, e.g.

   Authenticating every BFD [RFC5880] packet with a Simple Password, or

   with a MD5 Message-Digest Algorithm [RFC1321], or Secure Hash

   Algorithm (SHA-1) algorithms is a computationally intensive process.

   This makes it difficult, if not impossible, to authenticate every packet,

   particularly at faster rates.



2nd paragraph: “… only BFD frames that signal a state change in BFD be 
authenticated.” State change is not 100% correct since P/F/D bit changes aren’t 
state changes (as mentioned in more detail below in section 2 comments). What 
about this instead: “State change, a demand mode change (to D bit) or a poll 
sequence change (P or F bit change) in a BFD packet are categorized as a 
significant BFD change. This document proposes that all BFD control packets 
which signal a significant BFD change MUST be authenticated if the session’s 
bfd.AuthType is non-zero. Other BFD control packets MAY be transmitted and 
received without the A bit set.” If you do use “significant BFD change”, add it 
to terminology section.

s/non-state change frame/BFD control packets without state or D/F/P bit 
change/, e.g.

“To detect a Man In the Middle (MITM) attack, it is also proposed that BFD 
control packets without a significant change be authenticated occasionally.  
The interval of these control packets…”



Section 2

POLL and DEMAND are NOT strictly states. POLL refers to “Poll sequence” as 
specified in section 6.5 of RFC5880. DEMAND refers to “Demand mode” as 
specified in section 6.6 of RFC5880. In the table, the POLL entry refers to 
polling sequence enabled and in any BFD state. Likewise, the DEMAND entry 
refers to Demand mode. This means that a session in UP state, in demand mode 
and polling sequence enabled will match 3 entries in that table. It’s a bit 
confusing. Here’s what I suggest instead:

  1.  Take POLL out of the table. Add a paragraph mentioning that if P or F bit 
changes value, the packet MUST be authenticated
  2.  Take DEMAND out of the table. Add a paragraph mentioning that if D bit 
changes value, the packet MUST be authenticated



Another comment on the table. The text says it should be read as state change 
from column to row. Column INIT to row UP is n/a whereas column UP to row INIT 
is Auth. INIT to UP is a valid transition, UP to INIT is not (has to go through 
DOWN first). So I think those entries should be reversed in the table.



Last paragraph: CC frames is not defined in BFD, use “control packets” instead?



Section 3

Sequence number mentions “as defined in [RFC5880]”. Suggest mentioning 
bfd.XmitAuthSeq



Security Considerations.

I believe this needs to be beefed up:

  1.  Use of sequence number for non-authenticated frames. Secure sequence 
numbers even better.
  2.  Mention (again) that non-authenticated BFD packets which have a 
significant change (state, D/F/P) are dropped. So if someone injects a 
non-authenticated packet with Down state to take down the session, that won’t 
work.



Section 6.2

RFC5880 should be a normative reference.

FW: Nomcom 2020-2021 Second Call For Volunteers

[Reshad Rahman (rrahman)]

NomCom volunteers needed!

From: WGChairs  on behalf of "STARK, BARBARA H" 

Date: Wednesday, June 10, 2020 at 5:51 PM
To: "wgcha...@ietf.org" 
Subject: Fwd: Nomcom 2020-2021 Second Call For Volunteers

Hi fellow chairs,
Would you mind sending this announcement on to your WGs and impress on them how 
important it is? Especially if the WG’s AD is up for selection.
Thx,
Barbara


Begin forwarded message:
From: NomCom Chair 2020 
Date: June 10, 2020 at 1:55:21 PM CDT
To: IETF Announcement List 
Cc: "i...@ietf.org" 
Subject: Nomcom 2020-2021 Second Call For Volunteers
This is the second sending of the call for volunteers for the 2020-2021 NomCom.

I wanted to mention a few updates from the previous email (sent 2 weeks ago):
- I've fixed the URL at the bottom of the email to point to 
https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_nomcom_2020_=DwIDaQ=LFYZ-o9_HUMeMTSQicvjIg=LoGzhC-8sc8SY8Tq4vrfog=ZsNIRqCxjDeOYYDNalOSHcuwQG23wBJtxzmEnsbPBtI=NgIu-7Ij0nEdsFcbJOLcl2M56RxyREhLAtcaHLatD34=
  instead of /2019/. This was a test to see if anyone was paying attention. 
Apparently, some people were. ;)
- The IETF 108 registration form includes a checkbox that will let you 
volunteer. You can use this instead of emailing me, when you register for IETF 
108.
- I currently have 39 volunteers. Last year had 149. I need more volunteers!
-
The IETF NomCom appoints people to fill the open slots on the LLC, IETF Trust, 
the IAB, and the IESG.

Ten voting members for the NomCom are selected in a verifiably random way from 
a pool of volunteers. The more volunteers, the better chance we have of 
choosing a random yet representative cross section of the IETF population.

The details of the operation of the NomCom can be found in BCP 10 (RFC 8713). 
RFC 3797 details the selection algorithm.

Special for this year (and only this year), we also have RFC 8788 (one-off 
update to RFC 8713 / BCP 10) to tell us who is eligible to volunteer:

 Members of the IETF community must have attended at least three of
 the last five in-person IETF meetings in order to volunteer.

 The five meetings are the five most recent in-person meetings that
 ended prior to the date on which the solicitation for NomCom
 volunteers was submitted for distribution to the IETF community.
 Because no IETF 107 in-person meeting was held, for the 2020-2021
 Nominating Committee those five meetings are IETFs
   102 [Montreal, Canada; July 2018],
   103 [Bangkok, Thailand; November 2018],
   104 [Prague, Czech Republic; March 2019],
   105 [Montreal, Canada; July 2019], and
   106 [Singapore; November 2019].

Keep in mind that eligibility is based on in-person attendance at the five 
listed meetings. You can check your eligibility at: 
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_registration_nomcom.py=DwIDaQ=LFYZ-o9_HUMeMTSQicvjIg=LoGzhC-8sc8SY8Tq4vrfog=ZsNIRqCxjDeOYYDNalOSHcuwQG23wBJtxzmEnsbPBtI=7_9x9PPoUIajJs2AnUFYg0KnEg8gkD3Jnwf1v079EQo=
 .

If you qualify, please volunteer. Before you decide to volunteer, please 
remember that anyone appointed to this NomCom will not be considered as a 
candidate for any of the positions that the 2020 - 2021 NomCom is responsible 
for filling.

People commonly volunteer by ticking the box on IETF registration forms. The 
IETF 106 form did not ask whether people were willing to volunteer. IETF 107 
did ask, but all those registrations were canceled. I have asked the 
Secretariat if it is possible to get the list if volunteers from canceled IETF 
107 registrations. If that list is available, I will contact all who are 
verified as eligible. But given the uncertainty of this process, I would 
encourage people to volunteer directly (see the bottom of this email for 
instructions). Thank you for volunteering!

The list of people and posts whose terms end with the March 2021 IETF meeting, 
and thus the positions for which this NomCom is responsible, are

IETF Trust:
   Joel Halpern

LLC:
   Maja Andjelkovic

IAB:
   Jari Arkko
   Jeff Tantsura
   Mark Nottingham
   Stephen Farrell
   Wes Hardaker
   Zhenbin Li

IESG:
   Alissa Cooper, IETF Chair/GEN AD
   Alvaro Retana, RTG AD
   Barry Leiba, ART AD
   Deborah Brungard, RTG AD
   Éric Vyncke, INT AD
   Magnus Westerlund, TSV AD
   Roman Danyliw, SEC AD
   Warren Kumari, OPS AD

All appointments are for 2 years. The Routing area has 3 ADs and the General 
area has 1; all other areas have 2 ADs. Thus, all areas (that have more than 
one AD) have at least one continuing AD.

The primary activity for this NomCom will begin in July 2020 and should be 
completed in January 2021.  The NomCom will have regularly scheduled conference 
calls to ensure progress. There will be activities to collect requirements from 
the community, review candidate questionnaires, review feedback from community 
members about candidates, and 

Re: [Bier] : New Version Notification for draft-hu-bier-bfd-06.txt

[Reshad Rahman (rrahman)]

+ BFD alias.

Regards,
Reshad.

From: BIER  on behalf of Greg Mirsky 

Date: Monday, May 4, 2020 at 12:40 PM
To: "xiong.q...@zte.com.cn" 
Cc: "liuc...@chinaunicom.cn" , "huf...@gmail.com" 
, BIER WG , BIER WG Chairs 

Subject: Re: [Bier] : New Version Notification for draft-hu-bier-bfd-06.txt

Hi Quan,
thank you for the update and the note explaining the scope of changes.

Dear All,
the draft has been extended with a reference to the work in MPLS WG that will 
be presented this at the interim 
meeting
 Thursday at 14:00 - 15:30 UTC. The 
draft-mirsky-mpls-p2mp-bfd
 has been extended to specify how unsolicited notifications of a failure in the 
multicast distribution tree can be used by an egress LSR to notify the ingress 
LSR.. We believe that the same mechanism can be used by BFER to notify BFIR. 
The unsolicited notification mechanism has some advantages comparing to 
multipoint polling and composite polling mechanisms defined in RFC 8563 and 
already mentioned in the draft-hu-bier-bfd. Welcome you joining in the 
discussion at MPLS WG interim and/or on the mailing list (keeping both MPLS and 
BIER WGs in the discussion seems beneficial).

Regards,
Greg

On Mon, May 4, 2020 at 7:16 AM 
mailto:xiong.q...@zte.com.cn>> wrote:

Dear Chairs and all,





The new version of draft-hu-bier-bfd-06 has been uploaded. This draft has been 
discussed many times in IETF meeting and  mailing list.
https://tools.ietf.org/html/draft-hu-bier-bfd-06

For this new version, we updated the process of the active tail in BIER BFD in 
section 6.

With this update,  BFD over BIER is capable to support scenarios when it is 
sufficient for a BFER to detect the failure and act on that, as well as cases 
when the BFIR must be notified of the failre in the multicast distribution tree.



The authors appreciate more feedbacks. Your comments and suggestions are very 
welcome!

Best Regards,

Quan


原始邮件
发件人：internet-dra...@ietf.org 
mailto:internet-dra...@ietf.org>>
收件人：熊泉00091065;Greg Mirsky 
mailto:gregimir...@gmail.com>>;Fangwei Hu 
mailto:huf...@gmail.com>>;Chang Liu 
mailto:liuc...@chinaunicom.cn>>;fangwei hu 
mailto:huf...@gmail.com>>;
日 期 ：2020年04月30日 11:18
主 题 ：New Version Notification for draft-hu-bier-bfd-06.txt

A new version of I-D, draft-hu-bier-bfd-06.txt
has been successfully submitted by Quan Xiong and posted to the
IETF repository.

Name:draft-hu-bier-bfd
Revision:06
Title:BIER BFD
Document date:2020-04-29
Group:Individual Submission
Pages:10
URL:https://www.ietf.org/internet-drafts/draft-hu-bier-bfd-06.txt
Status: https://datatracker.ietf.org/doc/draft-hu-bier-bfd/
Htmlized:   https://tools.ietf.org/html/draft-hu-bier-bfd-06
Htmlized:   https://datatracker.ietf.org/doc/html/draft-hu-bier-bfd
Diff:   https://www.ietf.org/rfcdiff?url2=draft-hu-bier-bfd-06

Abstract:
   Point to multipoint (P2MP) BFD is designed to verify multipoint
   connectivity.  This document specifies the application of P2MP BFD in
   BIER network.




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.

The IETF Secretariat

FW: Reminder: Survey on planning for possible online IETF meetings

[Reshad Rahman (rrahman)]

BFD WG, please fill out the survey if you haven’t already.

Regards,
Reshad.

From: WGChairs  on behalf of Alissa Cooper 

Date: Tuesday, May 5, 2020 at 7:49 AM
To: IETF WG Chairs 
Subject: Fwd: Reminder: Survey on planning for possible online IETF meetings

Please circulate this to your working group lists. The survey data will be very 
important as we plan future IETF meetings.

Thanks,
Alissa


Begin forwarded message:

From: IETF Executive Director 
mailto:exec-direc...@ietf.org>>
Subject: Reminder: Survey on planning for possible online IETF meetings
Date: May 4, 2020 at 3:03:35 AM EDT
To: "IETF Announcement List" 
mailto:ietf-annou...@ietf.org>>
Reply-To: ietf108plann...@ietf.org

This is a reminder that we need the IETF community to help us plan for the 
possibility that one or more upcoming IETF meetings in 2020 and possibly 2021 
may not be able to go ahead in person.  You can help us with this by filling 
out the following survey:

https://www.surveymonkey.com/r/5328FFJ

So far we have 114 responses and we would ideally like 500 or more.

The survey contains the following pages and will take 15-20 minutes to complete:

1. Welcome
2. Online IETF 107 and the subsequent virtual interims
3. Replacing a cancelled in-person meeting
4. Online meeting format and timezone
5. Replicating humming
6. Replicating the hallway environment
7. Fees
8. Thanks and anything else

We run the survey in anonymous mode which means that we only see data that you 
explicitly provide.

Thank you in advance for your help.

--
Alissa Cooper, IETF Chair
Jay Daley, IETF Executive Director
Colin Perkins, IRTF Chair

___
IETF-Announce mailing list
ietf-annou...@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce

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

[Reshad Rahman (rrahman)]

Thanks Jeff and Albert. I will go through the various discussion points and 
will review the latest rev.

Regards,
Reshad.

On 2019-11-01, 11:49 AM, "Rtg-bfd on behalf of Jeffrey Haas" 
 wrote:

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

[Reshad Rahman (rrahman)]

BFD WG, reminder that WGLC is ongoing for this document.

Regards,
Reshad.

From: Rtg-bfd  on behalf of "Reshad Rahman (rrahman)" 

Date: Tuesday, August 27, 2019 at 12:34 PM
To: "rtg-bfd@ietf.org" 
Subject: WGLC for draft-ietf-bfd-large-packets

BFD WG,

As was mentioned at IETF105, this document is stable and there was an interop 
test done between FRR and Junos VMX.

Please provide comments/feedback on the document. The deadline for last call is 
September 13th.

Regards,
Reshad & Jeff.

IPR poll for draft-ietf-bfd-large-packets

[Reshad Rahman (rrahman)]

BFD WG, authors, contributors,

We have started WGLC for draft-ietf-bfd-large-packets and need to do an IPR 
poll. This mail starts the IPR poll.

Are you aware of any IPR that applies to draft-ietf-bfd-large-packets?

If you are aware of a relevant IPR, please state whether this IPR has been 
disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 
for more details).

At this moment, no IPR disclosures have been submitted on this document or the 
individual document it replaced.

If you are listed as a document author or contributor, please reply to this 
email (reply-to-all) stating whether or not you are aware of any relevant IPR.
If you are on the BFD WG email list but are not listed as an author or 
contributor, then please explicitly reply only if you are aware of any IPR that 
has not yet been disclosed in conformance with IETF rules.

Please note that the document will not advance to the next stage unless a 
response has been received from each author and contributor.

This poll closes on the 13th of September 2019.

Regards,
Reshad.

WGLC for draft-ietf-bfd-large-packets

[Reshad Rahman (rrahman)]

BFD WG,

As was mentioned at IETF105, this document is stable and there was an interop 
test done between FRR and Junos VMX.

Please provide comments/feedback on the document. The deadline for last call is 
September 13th.

Regards,
Reshad & Jeff.

Re: Yangdoctors early review of draft-ietf-bfd-unsolicited-01

[Reshad Rahman (rrahman)]

Hi Jeff,

Yes, to me it makes sense to do the change suggested by Martin (add "default 
tx-rx-intervals;" to the choice statement). BFD YANG co-authors, please respond 
asap if you disagree.

Regards,
Reshad.

On 2019-08-21, 4:11 PM, "Jeffrey Haas"  wrote:

Reshad,

If procedures permit it (I'm unclear on the detail), does it make sense to
pull the BFD yang module for a fix from the editor queue?

-- Jeff

On Mon, Aug 19, 2019 at 07:31:27PM +0000, Reshad Rahman (rrahman) wrote:
> I was looking at an old copy of the doc which didn't have default. So 
yes, mandatory doesn't make sense with the default statements.
> 
> Your assumption below wrt the intention is correct. I don't know how 
feasible it is to add this while it's in the editor q.
> 
> Regards,
> Reshad.
> 
> On 2019-08-19, 3:18 PM, "Martin Bjorklund"  wrote:
> 
> "Reshad Rahman (rrahman)"  wrote:
> > Thanks Martin and Mahesh.
> > 
> > I believe we should add a mandatory statement to the choic (speaking
> > as BFD YANG co-author,)
> 
> But then it is not clear why all leafs in the cases have default
> statements.
> 
> Since the 'single-interval' case is optional with a if-feature (which
> BTW is weird since it is trivial to implement), and the only other
> case has default values on both its leafs, I would have assumed that
> the intention was that if nothing is configured, the server should use
> 100 microseconds for the intervals.  If this is the intention,
> perhaps a statement:  "default tx-rx-intervals;" can be added to the
> module, even though the doc is in the RFC ed q.
> 
> 
> /martin
> 
> 
> 
> > 
> > Just created https://github.com/bfd-wg
> > 
> > Regards,
> > Reshad.
> > 
> > 
> > On 2019-08-19, 2:45 PM, "Mahesh Jethanandani" 
 wrote:
> > 
> > [Adding the authors of BFD YANG module]
> > 
> > Martin brings up a good point. But since the document that 
contains ietf-bfd-types is sitting in RFC Ed Queue, this will have to go into a 
bis document.
> > 
> > Chairs, could you create a bfd-wg in GitHub for us to track 
this as an issue to be fixed as part of a bis document?
> > 
> > > On Aug 19, 2019, at 4:29 AM, Martin Björklund via Datatracker 
 wrote:
> > > 
> > > Reviewer: Martin Björklund
> > > Review result: Ready with Nits
> > > 
> > > I have reviewed this document from a YANG model perspective 
only.
> > > 
> > > My only comment is actually for a grouping defined in 
ietf-bfd-type, but used
> > > in this module.  There is a choice "interval-config-type":
> > > 
> > >  +--rw unsolicited {bfd-unsol:unsolicited-params-global}?
> > >   +--rw enable?   boolean
> > >   +--rw local-multiplier? multiplier
> > >   +--rw (interval-config-type)?
> > >  +--:(tx-rx-intervals)
> > >  |  +--rw desired-min-tx-interval?uint32
> > >  |  +--rw required-min-rx-interval?   uint32
> > >  +--:(single-interval) {single-minimum-interval}?
> > > +--rw min-interval?   uint32
> > > 
> > > This choice is not mandatory and doesn't have a default case, 
so the question
> > > is what happens if no nodes from the choice has been 
configured?   I would
> > > expect the choice to have a default case (but this then would 
apply to
> > > ietf-bfd-types, not this document.)
> > > 
> > > 
> > 
> > Mahesh Jethanandani
> > mjethanand...@gmail.com
> > 
> > 
> > 
> > 
> > 
> 
> 

Re: Yangdoctors early review of draft-ietf-bfd-unsolicited-01

[Reshad Rahman (rrahman)]

I was looking at an old copy of the doc which didn't have default. So yes, 
mandatory doesn't make sense with the default statements.

Your assumption below wrt the intention is correct. I don't know how feasible 
it is to add this while it's in the editor q.

Regards,
Reshad.

On 2019-08-19, 3:18 PM, "Martin Bjorklund"  wrote:

    "Reshad Rahman (rrahman)"  wrote:
> Thanks Martin and Mahesh.
> 
> I believe we should add a mandatory statement to the choic (speaking
> as BFD YANG co-author,)

But then it is not clear why all leafs in the cases have default
statements.

Since the 'single-interval' case is optional with a if-feature (which
BTW is weird since it is trivial to implement), and the only other
case has default values on both its leafs, I would have assumed that
the intention was that if nothing is configured, the server should use
100 microseconds for the intervals.  If this is the intention,
perhaps a statement:  "default tx-rx-intervals;" can be added to the
module, even though the doc is in the RFC ed q.


/martin



> 
> Just created https://github.com/bfd-wg
> 
> Regards,
> Reshad.
> 
> 
> On 2019-08-19, 2:45 PM, "Mahesh Jethanandani"  
wrote:
> 
> [Adding the authors of BFD YANG module]
> 
> Martin brings up a good point. But since the document that contains 
ietf-bfd-types is sitting in RFC Ed Queue, this will have to go into a bis 
document.
> 
> Chairs, could you create a bfd-wg in GitHub for us to track this as 
an issue to be fixed as part of a bis document?
> 
> > On Aug 19, 2019, at 4:29 AM, Martin Björklund via Datatracker 
 wrote:
> > 
> > Reviewer: Martin Björklund
> > Review result: Ready with Nits
> > 
> > I have reviewed this document from a YANG model perspective only.
> > 
> > My only comment is actually for a grouping defined in 
ietf-bfd-type, but used
> > in this module.  There is a choice "interval-config-type":
> > 
> >  +--rw unsolicited {bfd-unsol:unsolicited-params-global}?
> >   +--rw enable?   boolean
> >   +--rw local-multiplier? multiplier
> >   +--rw (interval-config-type)?
> >  +--:(tx-rx-intervals)
> >  |  +--rw desired-min-tx-interval?uint32
> >  |  +--rw required-min-rx-interval?   uint32
> >  +--:(single-interval) {single-minimum-interval}?
> > +--rw min-interval?   uint32
> > 
> > This choice is not mandatory and doesn't have a default case, so 
the question
> > is what happens if no nodes from the choice has been configured?   
I would
> > expect the choice to have a default case (but this then would apply 
to
> > ietf-bfd-types, not this document.)
> > 
> > 
> 
> Mahesh Jethanandani
> mjethanand...@gmail.com
> 
> 
> 
> 
> 

Re: Yangdoctors early review of draft-ietf-bfd-unsolicited-01

[Reshad Rahman (rrahman)]

Thanks Martin and Mahesh.

I believe we should add a mandatory statement to the choic (speaking as BFD 
YANG co-author,)

Just created https://github.com/bfd-wg

Regards,
Reshad.


On 2019-08-19, 2:45 PM, "Mahesh Jethanandani"  wrote:

[Adding the authors of BFD YANG module]

Martin brings up a good point. But since the document that contains 
ietf-bfd-types is sitting in RFC Ed Queue, this will have to go into a bis 
document.

Chairs, could you create a bfd-wg in GitHub for us to track this as an 
issue to be fixed as part of a bis document?

> On Aug 19, 2019, at 4:29 AM, Martin Björklund via Datatracker 
 wrote:
> 
> Reviewer: Martin Björklund
> Review result: Ready with Nits
> 
> I have reviewed this document from a YANG model perspective only.
> 
> My only comment is actually for a grouping defined in ietf-bfd-type, but 
used
> in this module.  There is a choice "interval-config-type":
> 
>  +--rw unsolicited {bfd-unsol:unsolicited-params-global}?
>   +--rw enable?   boolean
>   +--rw local-multiplier? multiplier
>   +--rw (interval-config-type)?
>  +--:(tx-rx-intervals)
>  |  +--rw desired-min-tx-interval?uint32
>  |  +--rw required-min-rx-interval?   uint32
>  +--:(single-interval) {single-minimum-interval}?
> +--rw min-interval?   uint32
> 
> This choice is not mandatory and doesn't have a default case, so the 
question
> is what happens if no nodes from the choice has been configured?   I would
> expect the choice to have a default case (but this then would apply to
> ietf-bfd-types, not this document.)
> 
> 

Mahesh Jethanandani
mjethanand...@gmail.com

Re: BFD Echo mode coverage in BFD for VXLAN

[Reshad Rahman (rrahman)]

Hi all,

It is up to the WG to decide whether echo support is desired for BFD over VxLAN 
(any other BFD use-cases also).  Since this hasn’t been brought up in the WG 
before, my take is that the WG isn’t interested in having echo for BFD over 
VxLAN. So if anybody feels that we need echo support, please speak up asap. 
Because it’s holiday season, let’s take 3 weeks instead of the usual 2, so 
please respond by September 5th.

Regards,
Reshad (co-chair hat).

From: Greg Mirsky 
Date: Thursday, August 8, 2019 at 8:04 PM
To: "Carlos Pignataro (cpignata)" 
Cc: "rtg-bfd@ietf.org" , "bfd-cha...@ietf.org" 
, Martin Vigoureux 
Subject: Re: BFD Echo mode coverage in BFD for VXLAN
Resent-From: 
Resent-To: Jeffrey Haas , 
Resent-Date: Thursday, August 8, 2019 at 8:04 PM

Dear All,
I was pointed out that my previous e-mail asking for WG help to progress BFD 
over VXLAN document by sharing opinions regarding coverage of the BFD Echo mode 
may be overstepping the bounds of an Editor. I apologize, that was not my 
intention. I'm asking WG Chairs to help to arrive at the conclusion of this 
question in a reasonable time.

Regards,
Greg

On Thu, Aug 8, 2019 at 4:06 PM Greg Mirsky 
mailto:gregimir...@gmail.com>> wrote:
Dear All,
I have not set the when this poll closes. I hope that two weeks would be 
sufficient time for the WG community to express their thoughts.

Dear Carlos,
thank you for sharing your opinion on the scope of the document in regard to 
BFD Echo mode. You've expressed support for exploring the applicability of the 
BFD Echo mode. Would you support that effort by contributing some text, if WG 
decides that documenting the applicability of the Echo mode in BFD over VXLAN 
is useful?

Regards,
Greg


On Wed, Aug 7, 2019 at 6:18 PM Carlos Pignataro (cpignata) 
mailto:cpign...@cisco.com>> wrote:
Dear Greg,

The option of replacing the existing text for something more ambiguous and 
implicit does not seem like progress in my humble opinion. The spec ends up 
with the same capabilities, but the text is more obscure. I do not support that 
option.

My recommendation for your consideration would be:

  1.  Explore if it is possible to run BFD Echo as a single-hop.
  2.  If yes, add text supporting it.
  3.  If no, add text explaining why not on technical grounds.

A less desirable option would be if the WG does not care about BFD Echo, to 
explicitly keep it out of scope (not on technical grounds).

Best,

Carlos.


On Aug 5, 2019, at 6:16 PM, Greg Mirsky 
mailto:gregimir...@gmail.com>> wrote:

Dear All,
in course of reviews of the draft, several times a question was asked about the 
rationale for excluding BFD Echo from the scope of this document:

7.  Echo BFD

   Support for echo BFD is outside the scope of this document.
Much appreciate your consideration of the following options:

  *   describe the applicability of BFD Echo in VXLAN environment in the 
document;
  *   remove Section 7 and clarify in the Introduction
NEW TEXT:
This specification describes procedures only for BFD Asynchronous mode.

  *   make no changes at all.
Regards,
Greg

IETF105 - BFD minutes

[Reshad Rahman (rrahman)]

Updated minutes have been uploaded.

Regards,
Reshad.

From: Rtg-bfd  on behalf of "Reshad Rahman (rrahman)" 

Date: Tuesday, July 30, 2019 at 12:41 PM
To: "rtg-bfd@ietf.org" 
Subject: IETF105 - BFD draft minutes

BFD WG,

The draft minutes have been uploaded:
https://datatracker.ietf.org/doc/minutes-105-bfd/

Please review them and submit any proposed changes to the minutes by August 
12th.

Regards,
Reshad and Jeff.

Re: I-D Action: draft-ietf-bfd-unsolicited-01.txt

[Reshad Rahman (rrahman)]

- YANG update allow->enable which was discussed at IETF104
- Added 8174 on top of 2119
- Added YANG-related considerations in Security section.

Comments welcome.

Regards,
Reshad.


On 2019-06-28, 4:01 PM, "Rtg-bfd on behalf of internet-dra...@ietf.org" 
 wrote:


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   : Unsolicited BFD for Sessionless Applications
Authors : Enke Chen
  Naiming Shen
  Robert Raszuk
  Reshad Rahman
Filename: draft-ietf-bfd-unsolicited-01.txt
Pages   : 13
Date: 2019-06-28

Abstract:
   For operational simplification of "sessionless" applications using
   BFD, in this document we present procedures for "unsolicited BFD"
   that allow a BFD session to be initiated by only one side, and be
   established without explicit per-session configuration or
   registration by the other side (subject to certain per-interface or
   per-router policies).



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-bfd-unsolicited/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-bfd-unsolicited-01
https://datatracker.ietf.org/doc/html/draft-ietf-bfd-unsolicited-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-unsolicited-01


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/

BFD presentation requests @ IETF105 Montreal

[Reshad Rahman (rrahman)]

BFD WG,

We will be meeting at IETF 105 in Montreal. Please send presentation requests 
to the chairs.

Regards,
Reshad & Jeff.

IETF104 - BFD draft minutes

[Reshad Rahman (rrahman)]

BFD WG,

The draft minutes have been uploaded:
https://datatracker.ietf.org/doc/minutes-104-bfd/

Please review them and submit any proposed changes to the minutes by April 12th.

Regards,
Reshad and Jeff.

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

[Reshad Rahman (rrahman)]

Hi Greg,

Please see inline.

From: Rtg-bfd  on behalf of Greg Mirsky 

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

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

Hi Jeff,
now with GIM6>>.

Regards,
Greg

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

I shall paste this one last time:

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

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

[Reshad Rahman (rrahman)]

Hi Greg,

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


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

   MUST be initiated whenever the contents of the next BFD Control

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

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

   bits.  This ensures that parameter changes are transmitted to the

   remote system and that the remote system acknowledges these changes.

Regards,
Reshad (no hat).

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

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

Regards,
Greg

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

Correct.

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

Would you clarify where in your draft this is discussed?

> Greg

-- Jeff

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

[Reshad Rahman (rrahman)]

Hi authors.,

This document has passed adoption as a BFD WG document.

Please resubmit the doc as draft-ietf-bfd-large-packets. Please also note that 
while there was strong support for adopting the document, the following 
points/questions were raised and should be discussed further within the WG as 
the document progresses:

  1.  Is there necessity to send all packets as large packets or alternatively 
can that be done periodically?
  2.  Authors should consider adding some text wrt use of BFD echo in the 
document

Also, there was a suggestion made to use BFD for PMTUD (as opposed to the BFD 
session failing when expected MTU isn’t met). My take on this is that it falls 
out of our charter but the PMTUD use-case should be considered if/when we 
recharter, I’d like to hear your thoughts on this.

Regards,
Reshad.

From: Rtg-bfd  on behalf of "Reshad Rahman (rrahman)" 

Date: Wednesday, October 17, 2018 at 9: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: Feedback on draft-hu-bier-bfd-02

[Reshad Rahman (rrahman)]

Thanks Greg and Fangwei. As discussed in BIER meeting, please add a reference 
to draft-xiong-bier-resilience.

Regards,
Reshad.

From: Greg Mirsky 
Date: Thursday, November 8, 2018 at 12:18 PM
To: "hu.fang...@zte.com.cn" 
Cc: "Reshad Rahman (rrahman)" , "draft-hu-bier-...@ietf.org" 
, BIER WG , "b...@ietf.org" 

Subject: Re: Feedback on draft-hu-bier-bfd-02

Hi Reshad,
thank you for taking the time to review and sharing your comments, much 
appreciated. I'll add to answers by Fangwei, please find them in-line tagged 
GIM>>.

Regards,
Greg

On Thu, Nov 8, 2018 at 11:27 AM 
mailto:hu.fang...@zte.com.cn>> wrote:

Hi, Rahman

Thanks for your comments.

Plese see inline marked with[hfw].



>Hi,



>I just took a quick look at the draft:

>1.Section 1, 2nd paragraph mentions “…detect unicast failures..”, I believe 
>this  should be unidirectional?

[hfw] Agree, the BFD multipoint document only defines the unidirectional deteck 
from header to one or more tails.
GIM>> Great catch, thank you. Will fix in the next version.

>2.Section 1, 3rd paragraph says that active-tail is for further study. So when 
>a tail detects a failure, how will the head be notified?  If the head does not 
>have to be notified, what action is taken?

[hfw] Ok. Actually, we are considering the active-tails solution. It  will be 
added in the next version.
GIM>> Our plan is to use BFD for Multipoint Network with Active Tail 
specfication as the base for this mode. Since tails in p2mp BFD are in the 
Demand mode the head only can query all tail and/or the particular tail using 
the Poll sequence (referred as multicast and unicast Poll). Depending on the 
type of the failure, the head may recieve or not the BFD control message with 
Final flag set. Absence of the response in combination with the content of the 
Diag field must be used to draw the conclusion on liveleness of the path from 
the head to the particular tail. From here the head may use BIER Ping to 
localize the defect and switch to using the alternative path through the BIER 
domain by using different transient BFRs.



Regards

Fangwei.
发件人：ReshadRahman(rrahman) mailto:rrah...@cisco.com>>
收件人：draft-hu-bier-...@ietf.org<mailto:draft-hu-bier-...@ietf.org> 
mailto:draft-hu-bier-...@ietf.org>>;
抄送人：b...@ietf.org<mailto:b...@ietf.org> 
mailto:b...@ietf.org>>;b...@ietf.org<mailto:b...@ietf.org> 
mailto:b...@ietf.org>>;
日 期 ：2018年11月08日 11:56
主 题 ：Feedback on draft-hu-bier-bfd-02
Hi,

I just took a quick look at the draft:

  1.  Section 1, 2nd paragraph mentions “…detect unicast failures..”, I believe 
this  should be unidirectional?
  2.  Section 1, 3rd paragraph says that active-tail is for further study. So 
when a tail detects a failure, how will the head be notified?  If the head does 
not have to be notified, what action is taken?

Regards,
Reshad.

Re: Feedback on draft-hu-bier-bfd-02

[Reshad Rahman (rrahman)]

And now adding the BFD alias.

From: "Reshad Rahman (rrahman)" 
Date: Thursday, November 8, 2018 at 10:54 AM
To: "draft-hu-bier-...@ietf.org" 
Cc: "b...@ietf.org" , "b...@ietf.org" 
Subject: Feedback on draft-hu-bier-bfd-02

Hi,

I just took a quick look at the draft:

  1.  Section 1, 2nd paragraph mentions “…detect unicast failures..”, I believe 
this should be unidirectional?
  2.  Section 1, 3rd paragraph says that active-tail is for further study. So 
when a tail detects a failure, how will the head be notified? If the head does 
not have to be notified, what action is taken?

Regards,
Reshad.

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

[Reshad Rahman (rrahman)]

Hi,

Inline .


On 2018-10-25, 11:38 AM, "Jeffrey Haas"  wrote:

Les,

I *think* the following text is yours.


On Mon, Oct 22, 2018 at 12:36:52AM +, Les Ginsberg (ginsberg) wrote:
> [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.

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

Regards,
Reshad (no hat).

I suggest taking a look at a different draft that might help direct this
portion of the discussion:

https://tools.ietf.org/html/draft-ietf-bfd-stability-02



-- Jeff

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

[Reshad Rahman (rrahman)]

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)" 
Date: Monday, October 22, 2018 at 4:40 PM
To: "Reshad Rahman (rrahman)" , "Naiming Shen (naiming)" 

Cc: "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) ; 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?


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

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

[Reshad Rahman (rrahman)]

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

Regards,
Reshad.

From: "Les Ginsberg (ginsberg)" 
Date: Sunday, October 21, 2018 at 8:36 PM
To: "Naiming Shen (naiming)" 
Cc: "Reshad Rahman (rrahman)" , "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) 
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 BF

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

[Reshad Rahman (rrahman)]

Yes/support.

Regards,
Reshad.

From: Rtg-bfd  on behalf of "Reshad Rahman (rrahman)" 

Date: Wednesday, October 17, 2018 at 9: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.

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

[Reshad Rahman (rrahman)]

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: Benjamin Kaduk's Discuss on draft-ietf-bfd-yang-16: (with DISCUSS and COMMENT)

[Reshad Rahman (rrahman)]

Revision 17 has been uploaded.

On 2018-08-01, 5:28 PM, "Reshad Rahman (rrahman)"  wrote:

I'm integrating Benjamin's proposal in the next rev.

Regards,
Reshad.

On 2018-07-30, 4:45 PM, "PFFC JHAAS"  wrote:

Benjamin,

Your proposal would be fine. It basically says be mindful of the 
relationship. 

Jeff

> On Jul 30, 2018, at 10:41, Benjamin Kaduk  wrote:
> 
> Hi Reshad,
> 
>> On Thu, Jul 26, 2018 at 12:16:05AM +, Reshad Rahman (rrahman) 
wrote:
>> Hi Benjamin and Jeff,
>> 
>> Following our discussion in Montreal, would the following, or 
something along these lines, be OK with you in the Security Considerations 
section.
>> 
>>   When BFD clients are used to modify BFD configuration (as described
>>   in Section 2.1), any authentication and authorization for the BFD
>>   configuration changes have to take place in the BFD clients.  For
>>   example, if the BFD client is an IGP then the IGP SHOULD be
>>   authenticated. Also, consideration should be given to the access 
control of
>>   the BFD clients.
> 
> I can't speak for Jeff, but I think this is edging closer to the bits 
he
> doesn't like.  (It seems to capture the topics I had in mind just 
fine,
> though.)
> 
>> From our discussion in Montreal, it seemed like we might end up at
> something more like:
> 
> When BFD clients are used to modify BFD configuration (as described
> in Section 2.1), the BFD clients need to be included in an analysis of
> the security properties of the BFD-using system (e.g., when 
considering the
> authentication and authorization of control actions).  In many cases, 
BFD
> is not the most vulnerable portion of such a composite system, since 
BFD is
> limited to generating well-defined traffic at a fixed rate on a given 
path;
> in the case of an IGP as BFD client, attacking the IGP could cause 
more
> broad-scale disruption than (de)configuring a BFD session could cause.
> 
> -Benjamin
> 
> 
>> On 2018-07-15, 9:05 AM, "Benjamin Kaduk"  wrote:
>> 
>>>On Wed, Jul 11, 2018 at 11:32:18AM -0400, Jeffrey Haas wrote:
>>> Benjamin,
>>> 
>>>> On Wed, Jul 11, 2018 at 10:02:41AM -0500, Benjamin Kaduk wrote:
>>>> "may be overkill in some circumstances" sounds exactly like an RFC 
2119
>>>> SHOULD, does it not?
>>> 
>>> Putting it slightly a different way, I am always wary of trying to 
embed too
>>> much operational and security wisdom in documents for the following 
reasons:
>>> - What's wise in one set of circumstances may not be in another.  
By being
>>>  proscriptive, you may lead to implementations that lack necessary
>>>  flexibility.
>> 
>>In my opinion, including guidance with the supporting motivation 
suffices
>>to leave flexibility for unanticipated future cases with 
differing needs.
>> 
>>> - You're imposing a level of fate binding between mechanisms that 
may
>>>  contravene desired behaviors from some operators that have split
>>>  operational roles.
>> 
>>If the stated motivation does not apply to operators with such 
split roles,
>>do we not think they are smart enough to see that the 
prerequisite is not
>>met and ignore the advice?
>> 
>>> [...]
>>>> To frame the same idea in a different fashion, we have this nice 
security
>>>> considerations boilerplate for YANG modules, talking about how the 
usual
>>>> access methods are NETCONF/RESTCONF, with MTI secure transport of 
ssh/TLS.
>>>> The scheme being described here is effectively providing a new 
access
>>>> mechanism (IGP) for a subset of the YANG module,
>>> 
>>> This is perhaps my personal disconnect.
>>> 
>>> Much of the point of providing a common configuration grouping for 
BFD for
>>> client protocols was to encapsulate, "I'm a client of BFD, here's my
>>> parameters".  An implementation is free to use the "please use bfd 
with
>>> these

Re: Benjamin Kaduk's Discuss on draft-ietf-bfd-yang-16: (with DISCUSS and COMMENT)

[Reshad Rahman (rrahman)]

I'm integrating Benjamin's proposal in the next rev.

Regards,
Reshad.

On 2018-07-30, 4:45 PM, "PFFC JHAAS"  wrote:

Benjamin,

Your proposal would be fine. It basically says be mindful of the 
relationship. 

Jeff

> On Jul 30, 2018, at 10:41, Benjamin Kaduk  wrote:
> 
> Hi Reshad,
> 
>> On Thu, Jul 26, 2018 at 12:16:05AM +, Reshad Rahman (rrahman) wrote:
>> Hi Benjamin and Jeff,
>> 
>> Following our discussion in Montreal, would the following, or something 
along these lines, be OK with you in the Security Considerations section.
>> 
>>   When BFD clients are used to modify BFD configuration (as described
>>   in Section 2.1), any authentication and authorization for the BFD
>>   configuration changes have to take place in the BFD clients.  For
>>   example, if the BFD client is an IGP then the IGP SHOULD be
>>   authenticated. Also, consideration should be given to the access 
control of
>>   the BFD clients.
> 
> I can't speak for Jeff, but I think this is edging closer to the bits he
> doesn't like.  (It seems to capture the topics I had in mind just fine,
> though.)
> 
>> From our discussion in Montreal, it seemed like we might end up at
> something more like:
> 
> When BFD clients are used to modify BFD configuration (as described
> in Section 2.1), the BFD clients need to be included in an analysis of
> the security properties of the BFD-using system (e.g., when considering 
the
> authentication and authorization of control actions).  In many cases, BFD
> is not the most vulnerable portion of such a composite system, since BFD 
is
> limited to generating well-defined traffic at a fixed rate on a given 
path;
> in the case of an IGP as BFD client, attacking the IGP could cause more
> broad-scale disruption than (de)configuring a BFD session could cause.
> 
> -Benjamin
> 
> 
>> On 2018-07-15, 9:05 AM, "Benjamin Kaduk"  wrote:
>> 
>>>On Wed, Jul 11, 2018 at 11:32:18AM -0400, Jeffrey Haas wrote:
>>> Benjamin,
>>> 
>>>> On Wed, Jul 11, 2018 at 10:02:41AM -0500, Benjamin Kaduk wrote:
>>>> "may be overkill in some circumstances" sounds exactly like an RFC 2119
>>>> SHOULD, does it not?
>>> 
>>> Putting it slightly a different way, I am always wary of trying to 
embed too
>>> much operational and security wisdom in documents for the following 
reasons:
>>> - What's wise in one set of circumstances may not be in another.  By 
being
>>>  proscriptive, you may lead to implementations that lack necessary
>>>  flexibility.
>> 
>>In my opinion, including guidance with the supporting motivation 
suffices
>>to leave flexibility for unanticipated future cases with differing 
needs.
>> 
>>> - You're imposing a level of fate binding between mechanisms that may
>>>  contravene desired behaviors from some operators that have split
>>>  operational roles.
>> 
>>If the stated motivation does not apply to operators with such split 
roles,
>>do we not think they are smart enough to see that the prerequisite is 
not
>>met and ignore the advice?
>> 
>>> [...]
>>>> To frame the same idea in a different fashion, we have this nice 
security
>>>> considerations boilerplate for YANG modules, talking about how the 
usual
>>>> access methods are NETCONF/RESTCONF, with MTI secure transport of 
ssh/TLS.
>>>> The scheme being described here is effectively providing a new access
>>>> mechanism (IGP) for a subset of the YANG module,
>>> 
>>> This is perhaps my personal disconnect.
>>> 
>>> Much of the point of providing a common configuration grouping for BFD 
for
>>> client protocols was to encapsulate, "I'm a client of BFD, here's my
>>> parameters".  An implementation is free to use the "please use bfd with
>>> these parameters for my protocol" or perhaps ignore them.  But in
>>> circumstances that an operator may wish to limit access to protocol BFD
>>> behavior, it has the existing ability in NACM to enforce its policy on 
those
>>> BFD nodes within the protocol tree.
>>> 
>>> What I feel you're saying is we need to call special attention to these
>>> instantiations that may be importe

IETF 102 - BFD draft minutes

[Reshad Rahman (rrahman)]

BFD WG,

The draft minutes have been uploaded, please review them.

https://datatracker.ietf.org/doc/minutes-102-bfd/

Regards,
Reshad & Jeff.

Re: Benjamin Kaduk's Discuss on draft-ietf-bfd-yang-16: (with DISCUSS and COMMENT)

[Reshad Rahman (rrahman)]

Hi Benjamin and Jeff,

Following our discussion in Montreal, would the following, or something along 
these lines, be OK with you in the Security Considerations section.

   When BFD clients are used to modify BFD configuration (as described
   in Section 2.1), any authentication and authorization for the BFD
   configuration changes have to take place in the BFD clients.  For
   example, if the BFD client is an IGP then the IGP SHOULD be
   authenticated. Also, consideration should be given to the access control of
   the BFD clients.

Regards,
Reshad.

On 2018-07-15, 9:05 AM, "Benjamin Kaduk"  wrote:

On Wed, Jul 11, 2018 at 11:32:18AM -0400, Jeffrey Haas wrote:
> Benjamin,
> 
> On Wed, Jul 11, 2018 at 10:02:41AM -0500, Benjamin Kaduk wrote:
> > "may be overkill in some circumstances" sounds exactly like an RFC 2119
> > SHOULD, does it not?
> 
> Putting it slightly a different way, I am always wary of trying to embed 
too
> much operational and security wisdom in documents for the following 
reasons:
> - What's wise in one set of circumstances may not be in another.  By being
>   proscriptive, you may lead to implementations that lack necessary
>   flexibility.

In my opinion, including guidance with the supporting motivation suffices
to leave flexibility for unanticipated future cases with differing needs.

> - You're imposing a level of fate binding between mechanisms that may
>   contravene desired behaviors from some operators that have split
>   operational roles.

If the stated motivation does not apply to operators with such split roles,
do we not think they are smart enough to see that the prerequisite is not
met and ignore the advice?

> [...]
> > To frame the same idea in a different fashion, we have this nice 
security
> > considerations boilerplate for YANG modules, talking about how the usual
> > access methods are NETCONF/RESTCONF, with MTI secure transport of 
ssh/TLS.
> > The scheme being described here is effectively providing a new access
> > mechanism (IGP) for a subset of the YANG module,
> 
> This is perhaps my personal disconnect.
> 
> Much of the point of providing a common configuration grouping for BFD for
> client protocols was to encapsulate, "I'm a client of BFD, here's my
> parameters".  An implementation is free to use the "please use bfd with
> these parameters for my protocol" or perhaps ignore them.  But in
> circumstances that an operator may wish to limit access to protocol BFD
> behavior, it has the existing ability in NACM to enforce its policy on 
those
> BFD nodes within the protocol tree.
> 
> What I feel you're saying is we need to call special attention to these
> instantiations that may be imported by some module.  
> 
> What I'm confused about is why such an import is any more special than any
> other import from another module.

I've been trying to wrap my head around your explanation for the past few
days, and I'm not sure I'm succeeding at it.  The only reason I'm raising
this point with this document is because there is text in the document like
"[f]or example, when a new IGP peer is discovered, the IGP would create a
BFD session to the newly discovered peer and similarly when an IGP peer
goes away, the IGP would remove the BFD session to that peer."  Imagine if
I was writing a document about a device that controls a physical door, and
the usual way to operate the device is to manually enter a PIN while
physically in front of the door.  If I also said "some people expose this
door-unlocking device to the internet and accept unlock requests over
HTTP", that would be incredibly unresponsible of me unless I added some
extra qualifier.  Perhaps it would be "and these people are crazy", or
perhaps "but HTTP itself is insecure, so in such situations TLS ought to be
used with mutual authentication, authorization checks for the party
requesting unlocking, and the best practices from RFC 7525".

So, in my head, I see this document as using a not-quite-throwaway example
to make a point about the limitations of the main focus of the document,
and should properly qualify the different security properties of that
example.  Your description above still reads to me as if it's focusing on
YANG modules not specified in this document but that also use the same BFD
grouping.  In such a case, when the NACM applies, isn't that still going
through normal management paths for that respective YANG module?  I'm still
trapped in a rut thinking about "received IGP packet from the network that
instantiates a new IGP session; as a side effect instantiate a BFD session
as well", where the incoming IGP packet is just the IGP implementation and
not a "management function" per se.

Re: Alissa Cooper's No Objection on draft-ietf-bfd-yang-16: (with COMMENT)

[Reshad Rahman (rrahman)]

Hi Alissa,

Regarding your comment below on 2.12, I looked at the 4 IANA modules @ 
https://www.iana.org/assignments/yang-parameters/yang-parameters.xhtml: 
iana-if-type, iana-crypt-hash, iana-routing-types and iana-hardware (from the 4 
RFCs you listed below) and they all seem to be using ICANN. I will modify the 
address in draft-ietf-bfd-yang to the address below.

Regards,
Reshad.

Postal: ICANN
12025 Waterfront Drive, Suite 300
Los Angeles, CA 90094-2536
United States of America


On 2018-07-19, 5:07 PM, "Alissa Cooper"  wrote:

Alissa Cooper has entered the following ballot position for
draft-ietf-bfd-yang-16: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-bfd-yang/



--
COMMENT:
--

Looking forward to the discussion of my original DISCUSS in NETMOD. Here it 
was:

I will apologize in advance because this document may be sort of a casualty 
of
this DISCUSS. I should have raised my point below at least two years ago if 
not
four years ago when the first iana-* YANG module was registered, but the
thought did not occur to me until now.

It gives me some pause to see the name "iana" embedded in the file name, 
module
name, namespace, and prefix of the module being defined in Sec. 2.12. I 
realize
there is precedent here, but I question whether tying these kinds of modules
specifically to IANA as the protocol parameter registry operator by name 
puts
them on the most stable deployment footing under all possible 
circumstances. I
am personally pleased as punch with the service we get from IANA, but that
doesn't mean "IANA" will always be the name of the registry operator. The 
more
modules that get created with this embedding, the more of them that may 
need to
change in the unlikely event that the name of the registry operator changes.
Lots of RFCs would need to change too, but embedding the name extends the
potential problem to the modules themselves.

It wasn't clear to me whether there is some ops-area-wide convention around 
the
embedding of "iana" in the names of modules to be maintained by IANA. I 
don't
see this specifically referenced in RFC 7950 or RFC 6020. So I'd like to
discuss whether a different naming convention could be established and used 
in
this document and others going forward.

---

COMMENT:

Some further questions on Sec. 2.12:

Looking back at the other RFCs that have defined YANG modules to be 
maintained
by IANA (7224, 7317, 8294, 8348), they use two different postal addresses 
for
ICANN. Why? Furthermore, is "ICANN" really the right contact name, or 
should it
be PTI?

Re: Benjamin Kaduk's Discuss on draft-ietf-bfd-yang-16: (with DISCUSS and COMMENT)

[Reshad Rahman (rrahman)]

Jeff, which part do you consider overkill? Is it the statement "NACM rules on 
IGP BFD configuration be at least as strict as BFD since the IGPs are 
instantiated BFD sessions"? That should still allow "permit BFD to be 
de-configured for protocols without also giving operators permission to 
similarly de-configure the underlying client protocols"?

Regards,
Reshad.


On 2018-07-11, 10:36 AM, "Jeffrey Haas"  wrote:

Even that may be overkill in some circumstances.

Consider the case where an operator may decide that they'll permit BFD to 
be de-configured for protocols without also giving operators permission to 
similarly de-configure the underlying client protocols.  Examples of this may 
be that BFD is experiencing issues that are leading to false negatives and 
tearing down valid sessions.

While the above example would seem unusual, it was more of a concern in the 
more subtle use cases for BFD-on-LAG where links may be managed by one 
provisioning group and protocols by another.

-- Jeff

> On Jul 11, 2018, at 10:31 AM, Reshad Rahman (rrahman)  
wrote:
> 
> Hi Acee,
> 
> That and a statement saying the BFD clients should be authenticated.
> 
> Regards,
> Reshad.
> 
> On 2018-07-11, 10:10 AM, "Acee Lindem (acee)"  wrote:
> 
>Hi Reshad, 
> 
>Ok - so are you saying that all that is being asked for is that the 
NACM rules on IGP BFD configuration be at least as strict as BFD since the IGPs 
are instantiated BFD sessions? I'd be ok with that. 
    > 
>Thanks,
>Acee 
> 
>On 7/11/18, 9:25 AM, "Reshad Rahman (rrahman)"  
wrote:
> 
>Hi,
> 
>My read on the DISCUSS is not just wrt spoofing of BFD clients but 
also making sure that the proper access restriction (NACM) is used for the BFD 
clients. 
> 
>I didn't interpret Benjamin's comments as requiring a security 
boundary between BFD clients (BGP, IPGPs) and BFD running on the same dveice, 
which I agree would be preposterous.
> 
>Regards,
>Reshad.
> 
>On 2018-07-10, 10:17 PM, "Acee Lindem (acee)"  
wrote:
> 
> 
> 
>On 7/10/18, 7:46 PM, "Rtg-bfd on behalf of Jeffrey Haas" 
 wrote:
> 
>On Tue, Jul 03, 2018 at 10:56:49PM -0500, Benjamin Kaduk 
wrote:
>> On Wed, Jul 04, 2018 at 03:20:42AM +, Reshad Rahman (rrahman) wrote:
>>>  I am not 100% sure I understand the point being made. Is it a 
question of underlying the importance of having the IGPs authenticated since 
the IGPs can create/destroy BFD sessions via the local API?
>> 
>> That's the crux of the matter, yes.  Since (in this case) the IGP state
>> changes are being translated directly into BFD configuration changes,
>> the NETCONF/RESTCONF authentication is not really used.  So, any
>> authentication/authorization decisions that are made must be on the basis
>> of authentication at the IGP level.  This does not necessarily mean a 
hard
>> requirement for IGP authentication, though using unauthenticated IGP 
would
>> then be equivalent (for the purposes of this document) to allowing
>> anonymous NETCONF/RESTCONF access.
>> 
>> I'd be happy to just have a note in the security considerations that 
"when
>> BFD clients such as IGPs are used to modify BFD configuration, any
>> authentication and authorization for the configuration changes take place
>> in the BFD client, such as by using authenticated IGPs".  But feel free 
to
>> reword in a better fashion; this is really just about acknowledging the 
new
>> access mechanism (since the boilerplate covers SSH/TLS for
>> NETCONF/RESTCONF).
> 
>I must admit to being somewhat perplexed by the request 
here.
> 
>In the cases where BFD as a top level module is not the 
creator of a BFD
>session, you seem to be concerned that BFD can be used to 
attack a resource
>by spoofing that non-BFD client.
> 
>While this is perhaps logically true, it also means that 
you have a far
>greater problem of being able to spoof the underlying BFD 
clients.  To give
>some real-world examples:
>- BGP typically requires explicit configuration for its 
endpoints.
>- Both OSPF and ISIS will require a matched speaker with 
acceptable
>  configuration parameters for a session to come up.
> 

Re: Benjamin Kaduk's Discuss on draft-ietf-bfd-yang-16: (with DISCUSS and COMMENT)

[Reshad Rahman (rrahman)]

Hi,

My read on the DISCUSS is not just wrt spoofing of BFD clients but also making 
sure that the proper access restriction (NACM) is used for the BFD clients. 

I didn't interpret Benjamin's comments as requiring a security boundary between 
BFD clients (BGP, IPGPs) and BFD running on the same dveice, which I agree 
would be preposterous.

Regards,
Reshad.

On 2018-07-10, 10:17 PM, "Acee Lindem (acee)"  wrote:



On 7/10/18, 7:46 PM, "Rtg-bfd on behalf of Jeffrey Haas" 
 wrote:

On Tue, Jul 03, 2018 at 10:56:49PM -0500, Benjamin Kaduk wrote:
> On Wed, Jul 04, 2018 at 03:20:42AM +, Reshad Rahman (rrahman) 
wrote:
> >  I am not 100% sure I understand the point being made. Is it a 
question of underlying the importance of having the IGPs authenticated since 
the IGPs can create/destroy BFD sessions via the local API?
> 
> That's the crux of the matter, yes.  Since (in this case) the IGP 
state
> changes are being translated directly into BFD configuration changes,
> the NETCONF/RESTCONF authentication is not really used.  So, any
> authentication/authorization decisions that are made must be on the 
basis
> of authentication at the IGP level.  This does not necessarily mean a 
hard
> requirement for IGP authentication, though using unauthenticated IGP 
would
> then be equivalent (for the purposes of this document) to allowing
> anonymous NETCONF/RESTCONF access.
> 
> I'd be happy to just have a note in the security considerations that 
"when
> BFD clients such as IGPs are used to modify BFD configuration, any
> authentication and authorization for the configuration changes take 
place
> in the BFD client, such as by using authenticated IGPs".  But feel 
free to
> reword in a better fashion; this is really just about acknowledging 
the new
> access mechanism (since the boilerplate covers SSH/TLS for
> NETCONF/RESTCONF).

I must admit to being somewhat perplexed by the request here.

In the cases where BFD as a top level module is not the creator of a BFD
session, you seem to be concerned that BFD can be used to attack a 
resource
by spoofing that non-BFD client.

While this is perhaps logically true, it also means that you have a far
greater problem of being able to spoof the underlying BFD clients.  To 
give
some real-world examples:
- BGP typically requires explicit configuration for its endpoints.
- Both OSPF and ISIS will require a matched speaker with acceptable
  configuration parameters for a session to come up.
- Static routes with BFD sessions will require explicit configuration.

In each of these cases, a client protocol that also wants to use BFD, 
the
simple spoofing of the protocol endpoints is already a massive disaster
since it will allow injection of control plane or forwarding state into 
the
device.  This is so much worse than convincing a BFD session to try to 
come
up with its default one packet per mode that ... well, I'm boggled we're
even talking about this. :-)

My request would be that we not complicate the security considerations 
of
this module for such cases.

I agree. This is DISCUSS is just preposterous - imposing some sort of 
security boundary between the IGP modules and the BFD module running on the 
same networking device.

Thanks,
Acee (LSR WG Co-Chair) 



-- Jeff

Re: Eric Rescorla's No Objection on draft-ietf-bfd-yang-16: (with COMMENT)

[Reshad Rahman (rrahman)]

Inline .

From: Eric Rescorla 
Date: Thursday, July 5, 2018 at 8:46 AM
To: "Reshad Rahman (rrahman)" 
Cc: The IESG , Jeffrey Haas , "rtg-bfd@ietf.org" 
, "draft-ietf-bfd-y...@ietf.org" 
, "bfd-cha...@ietf.org" 
Subject: Re: Eric Rescorla's No Objection on draft-ietf-bfd-yang-16: (with 
COMMENT)



On Thu, Jul 5, 2018 at 5:39 AM, Reshad Rahman (rrahman) 
mailto:rrah...@cisco.com>> wrote:
Hi,

Thanks for the review, please see inline .

On 2018-07-04, 6:33 PM, "Eric Rescorla" mailto:e...@rtfm.com>> 
wrote:

Eric Rescorla has entered the following ballot position for
draft-ietf-bfd-yang-16: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-bfd-yang/



--
COMMENT:
--

Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D6374



COMMENTS
S 2.1.4.
>  Minimum TTL of incoming BFD control packets.
>
>   2.1.4.  MPLS Traffic Engineering Tunnels
>
>  For MPLS-TE tunnels, BFD is configured under the MPLS-TE tunnel since
>  the desired failure detection parameters is a property of the MPLS-TE

"parameters are"

 Change made, will be in the next rev.

S 2.8.
>
>   2.8.  BFD over LAG hierarchy
>
>  A "lag" node is added under the "bfd" node in control-plane-protocol.
>  The configuration and operational state data for each BFD LAG session
>  is under this "lag" node.

There seems to be a lot of replication (e.g., number of sessions). Is
it possible to somehow refactor this so that's common?

 There is replication in that the different modules have similar 
information as you pointed out. But this is done via groupings, so the 
information such as number of sessions, number of sessions up etc is defined 
once and used in multiple locations.

Yes, but can't you incorporate the definitions by references so that the 
diagrams are easier to read?

 The pyang tool does this for real references (leafref) but not in the 
grouping case (which is reuse and not reference). Even though there is 
replication in the tree diagrams, I believe there is benefit in seeing the 
complete tree for each module.

Regards,
Reshad.


-Ekr

Regards,
Reshad.

Re: Warren Kumari's Discuss on draft-ietf-bfd-yang-16: (with DISCUSS and COMMENT)

[Reshad Rahman (rrahman)]

Hi Warren,

Thanks for the review. 
In your example below
 +--ro number-of-sessions (10)
 +--ro number-of-sessions-up (2)
 +--ro number-of-sessions-down (5)
 +--ro number-of-sessions-admin-down (3)

There is a description on Page 37 of rev-16 of the draft, I can add to it as 
follows, is this sufficient?
  leaf number-of-sessions {
type yang:gauge32;
description "Number of BFD sessions.";
  }
  leaf number-of-sessions-up {
type yang:gauge32;
description "Number of BFD sessions currently in up state (as defined 
in [RFC5880]).";
  }
  leaf number-of-sessions-down {
type yang:gauge32;
description "Number of BFD sessions currently in down or init state (as 
defined in [RFC5880]).";
  }
  leaf number-of-sessions-admin-down {
type yang:gauge32;
description
  "Number of BFD sessions currently in admin-down state (as defined in 
[RFC5880]).";
  }

I will fix the nits in the next rev.

Regards,
Reshad.   

On 2018-07-04, 1:17 PM, "Warren Kumari"  wrote:

Warren Kumari has entered the following ballot position for
draft-ietf-bfd-yang-16: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-bfd-yang/



--
DISCUSS:
--

Don't panic, this should be an easy DISCUSS to clear, but I think it 
important
for interoperability.

In multiple places, you have:
 +--ro number-of-sessions?
 +--ro number-of-sessions-up?
 +--ro number-of-sessions-down?
 +--ro number-of-sessions-admin-down?

I'm a little confused by the meaning of the counters, and didn't see them
clearly defined anywhere. Apologies if I missed it...

Are "number-of-sessions-admin-down" included in "number-of-sessions-down"?
Is 'number-of-sessions' always equal to 'number-of-sessions-up' +
'number-of-sessions-down', or is it always equal to 'number-of-sessions-up' 
+
'number-of-sessions-down' + 'number-of-sessions-admin-down', or are there 
other
cases?

E.g: I have created 10 sessions (because I have 10 interfaces). 5 of them 
are
down because there is no peer, 3 of them I've configured to be down (admin
down), and so 2 of them are up.

What should be in each of:
number-of-sessions?
number-of-sessions-up?
number-of-sessions-down?
number-of-sessions-admin-down?


--
COMMENT:
--

Thank you.

I also had a few minor nits:
Nits:
Section 1:
"The YANG modules in this document conform to the Network Management 
Datastore
Architecture (NMDA) Network Management Datastore Architecture [RFC8342]. " 
The
Department of Redundancy Department called and wants some of their words 
back
please :-)

Section 2:
"Since BFD is used for liveliness detection of various forwarding
   paths, there is no uniform key to identify a BFD session.  So the BFD
   data model is split in multiple YANG modules where each module
   corresponds to one type of forwarding path."
I think this would be more readable as:
"... to identify a BFD session, and so the BFD..."  (hey, I said it was a 
nit)

Re: IETF102 BFD WG agenda items

[Reshad Rahman (rrahman)]

Deadline for draft agendas is July 4th, so please send requests for agenda 
items by July 2nd.

Regards,
Reshad.

From: "Reshad Rahman (rrahman)" 
Date: Monday, June 25, 2018 at 9:34 AM
To: "rtg-bfd@ietf.org" 
Cc: "bfd-cha...@ietf.org" 
Subject: IETF102 BFD WG agenda items
Resent-From: 
Resent-To: Jeffrey Haas , 
Resent-Date: Monday, June 25, 2018 at 9:34 AM

Hi everyone,

The BFD WG has a time slot during IETF102 in Montreal, we are meeting on 
Wednesday July 18th 2018 from 15:20 to 16:50.

Please send your requests for agenda items (presenter, draft, time requested) 
to bfd-cha...@ietf.org<mailto:bfd-cha...@ietf.org>, no later than Monday July 
9th 2018.

Regards,
Reshad & Jeff.

Re: Last Call: (YANG Data Model for Bidirectional Forwarding Detection (BFD)) to Proposed Standard

[Reshad Rahman (rrahman)]

Hi,

We just uploaded rev14 which (I believe) addresses your comments: we added the 
missing reference statements and also fixed an incorrect reference. The diffs 
also include some small tree diagram changes (I upgraded from pyang 1.7.3 to 
1.7.5).

Regards,
Reshad.

On 2018-05-26, 11:10 AM, "Reshad Rahman (rrahman)"  wrote:

Hi Tom,

Thanks for the review. I will add the missing reference statements, I 
believe this was just an oversight because there are/were no RFC numbers for 
these imported modules (there is now for ietf-routing).  So I will add the 
usual RFC XXX with a note for the RFC Editor.

Regards,
Reshad.


On 2018-05-26, 7:31 AM, "tom p."  wrote:

This I-D has a number of import statements from other YANG modules for
which there is no Reference statement where I believe that there should
be, statements such as .

  import iana-bfd-types
  import ietf-bfd
  import ietf-bfd-mpls
  import ietf-te
  import ietf-routing

In the first three cases, it may be that the editors of this I-D
consider that such a reference is not needed because the relevant
modules are in the same I-D but such thinking is erroneous.  These are
separate modules which will lead independent existences in the wild so
that there will be nothing to tell a user of e.g.  module
ietf-bfd-mpls-te
where to look for
ietf-bfd-types, ietf-bfd,  ietf-bfd-mpls

These need  reference statement such as

  reference "RFC :   YANG Data Model for BFD";

Tom Petch

- Original Message -
From: "The IESG" 
To: "IETF-Announce" 
Cc: ; ;

Sent: Friday, May 25, 2018 2:26 PM

> The IESG has received a request from the Bidirectional Forwarding
Detection
> WG (bfd) to consider the following document: - 'YANG Data Model for
> Bidirectional Forwarding Detection (BFD)'
>as Proposed Standard
>
> The IESG plans to make a decision in the next few weeks, and solicits
final
> comments on this action. Please send substantive comments to the
> i...@ietf.org mailing lists by 2018-06-08. Exceptionally, comments may
be
> sent to i...@ietf.org instead. In either case, please retain the
beginning of
> the Subject line to allow automated sorting.
>
> Abstract
>
>
>This document defines a YANG data model that can be used to
configure
>and manage Bidirectional Forwarding Detection (BFD).
>
>The YANG modules in this document conform to the Network Management
>Datastore Architecture (NMDA).
>
>
>
>
> The file can be obtained via
> https://datatracker.ietf.org/doc/draft-ietf-bfd-yang/
>
> IESG discussion can be tracked via
> https://datatracker.ietf.org/doc/draft-ietf-bfd-yang/ballot/
>
>
> No IPR declarations have been submitted directly on this I-D.
>
>
> The document contains these normative downward references.
> See RFC 3967 for additional information:
> draft-ietf-teas-yang-te: A YANG Data Model for Traffic Engineering
Tunnels and Interfaces (None - IETF stream)
> draft-ietf-mpls-base-yang: A YANG Data Model for MPLS Base (None -
IETF stream)
>
>
>





--- Begin Message ---

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   : YANG Data Model for Bidirectional Forwarding 
Detection (BFD)
Authors : Reshad Rahman
  Lianshu Zheng
  Mahesh Jethanandani
  Santosh Pallagatti
  Greg Mirsky
Filename: draft-ietf-bfd-yang-14.txt
Pages   : 74
Date: 2018-06-01

Abstract:
   This document defines a YANG data model that can be used to configure
   and manage Bidirectional Forwarding Detection (BFD).

   The YANG modules in this document conform to the Network Management
   Datastore Architecture (NMDA).


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-bfd-yang/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-bfd-yang-14
https://datatracker.ietf.org/doc/html/draft-ietf-bfd-yang-14

A diff from the previ

Re: Last Call: (YANG Data Model for Bidirectional Forwarding Detection (BFD)) to Proposed Standard

[Reshad Rahman (rrahman)]

Hi Tom,

Thanks for the review. I will add the missing reference statements, I believe 
this was just an oversight because there are/were no RFC numbers for these 
imported modules (there is now for ietf-routing).  So I will add the usual RFC 
XXX with a note for the RFC Editor.

Regards,
Reshad.


On 2018-05-26, 7:31 AM, "tom p."  wrote:

This I-D has a number of import statements from other YANG modules for
which there is no Reference statement where I believe that there should
be, statements such as .

  import iana-bfd-types
  import ietf-bfd
  import ietf-bfd-mpls
  import ietf-te
  import ietf-routing

In the first three cases, it may be that the editors of this I-D
consider that such a reference is not needed because the relevant
modules are in the same I-D but such thinking is erroneous.  These are
separate modules which will lead independent existences in the wild so
that there will be nothing to tell a user of e.g.  module
ietf-bfd-mpls-te
where to look for
ietf-bfd-types, ietf-bfd,  ietf-bfd-mpls

These need  reference statement such as

  reference "RFC :   YANG Data Model for BFD";

Tom Petch

- Original Message -
From: "The IESG" 
To: "IETF-Announce" 
Cc: ; ;

Sent: Friday, May 25, 2018 2:26 PM

> The IESG has received a request from the Bidirectional Forwarding
Detection
> WG (bfd) to consider the following document: - 'YANG Data Model for
> Bidirectional Forwarding Detection (BFD)'
>as Proposed Standard
>
> The IESG plans to make a decision in the next few weeks, and solicits
final
> comments on this action. Please send substantive comments to the
> i...@ietf.org mailing lists by 2018-06-08. Exceptionally, comments may
be
> sent to i...@ietf.org instead. In either case, please retain the
beginning of
> the Subject line to allow automated sorting.
>
> Abstract
>
>
>This document defines a YANG data model that can be used to
configure
>and manage Bidirectional Forwarding Detection (BFD).
>
>The YANG modules in this document conform to the Network Management
>Datastore Architecture (NMDA).
>
>
>
>
> The file can be obtained via
> https://datatracker.ietf.org/doc/draft-ietf-bfd-yang/
>
> IESG discussion can be tracked via
> https://datatracker.ietf.org/doc/draft-ietf-bfd-yang/ballot/
>
>
> No IPR declarations have been submitted directly on this I-D.
>
>
> The document contains these normative downward references.
> See RFC 3967 for additional information:
> draft-ietf-teas-yang-te: A YANG Data Model for Traffic Engineering
Tunnels and Interfaces (None - IETF stream)
> draft-ietf-mpls-base-yang: A YANG Data Model for MPLS Base (None -
IETF stream)
>
>
>

Re: Comments on Optimizing BFD Authentication

[Reshad Rahman (rrahman)]

Yes looks like we’ll have to do a bis.

Regards,
Reshad.

From: Rtg-bfd  on behalf of Mahesh Jethanandani 

Date: Monday, April 2, 2018 at 8:47 AM
To: "Acee Lindem (acee)" 
Cc: "rtg-bfd@ietf.org" , 
"draft-ietf-bfd-optimizing-authenticat...@ietf.org" 
, Ashesh Mishra 

Subject: Re: Comments on Optimizing BFD Authentication

Acee,

Or by doing a "bis" version of the draft. There is no way to augment a typedef.

Mahesh Jethanandani
mjethanand...@gmail.com

On Apr 2, 2018, at 5:08 AM, Acee Lindem (acee) 
> wrote:
Mahesh – I believe these should be done as augmentations since 
draft-ietf-bfd-yang-13 has already been submitted to the IESG for publication.
Thanks,
Acee

From: Rtg-bfd > on 
behalf of Mahesh Jethanandani 
>
Date: Monday, April 2, 2018 at 12:06 AM
To: Ashesh Mishra >
Cc: "rtg-bfd@ietf.org" 
>, 
"draft-ietf-bfd-optimizing-authenticat...@ietf.org"
 
>
Subject: Re: Comments on Optimizing BFD Authentication





On Apr 1, 2018, at 8:40 AM, Ashesh Mishra 
> wrote:



What are the yang model considerations?  (See prior point.)

[AM] I'll let Mahesh comment on this.

To support the optimized BFD authentication, we will need to change the BFD 
YANG model to add a ‘optimized’ authentication capability.

Following are some of the changes I anticipate

- The current model has a typedef for auth-type, but since a bit has not been 
assigned (it is a TBD), it will require an update to the typedef to include the 
new bit, when it is assigned after IANA approves it.

- The current YANG model only supports the meticulous mode of authentication in 
its grouping for auth-parms. Will need to make it a choice between meticulous 
and the ‘optimized’ mode.


Mahesh Jethanandani
mjethanand...@gmail.com

Re: [mpls] New Version Notification for draft-mirsky-mpls-bfd-bootstrap-clarify-00.txt

[Reshad Rahman (rrahman)]

Hi,

In the BFD meeting yesterday there was discussion about lack of clarity on what 
the spec says wrt to the discriminator TLV being sent by the egress node in the 
echo reply and that this causes interop issues. From RFC 5884:

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

In the errata:

The LSP Ping

Echo reply message generated by the egress LSR MAY carry the local

discriminator assigned by it for the BFD session, as specified in

section 6.1.
So I think it’s clear that this cannot be the discriminator of the ingress 
node. I agree that this information is useless but still don’t see how it can 
cause any harm, and any implementation which interprets the discriminator in 
the echo reply differently is buggy IMHO.

Regards,
Reshad (hat off).

From: Rtg-bfd <rtg-bfd-boun...@ietf.org> on behalf of "Reshad Rahman (rrahman)" 
<rrah...@cisco.com>
Date: Tuesday, March 20, 2018 at 5:49 PM
To: Greg Mirsky <gregimir...@gmail.com>, "Carlos Pignataro (cpignata)" 
<cpign...@cisco.com>
Cc: "m...@ietf.org" <m...@ietf.org>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
Subject: Re: [mpls] New Version Notification for 
draft-mirsky-mpls-bfd-bootstrap-clarify-00.txt

Hi,

While I agree that the echo reply is not needed to bootstrap BFD, and that the 
BFD Disc TLV is not needed in the reply, doing this doesn’t break anything. So 
I don’t see the proposed changes as being necessary.

Does anyone remember why RFC5884  has the echo reply, was it to potentially 
save an echo request from egress for bidirectional case?

Also, if we do go ahead with the proposed changes in this draft, we’ll have to 
fix this errata<https://www.rfc-editor.org/errata/eid5085>.

Regards,
Reshad (speaking as individual contributor).

From: Rtg-bfd <rtg-bfd-boun...@ietf.org> on behalf of Greg Mirsky 
<gregimir...@gmail.com>
Date: Friday, October 20, 2017 at 4:19 PM
To: "Carlos Pignataro (cpignata)" <cpign...@cisco.com>
Cc: "m...@ietf.org" <m...@ietf.org>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
Subject: Re: [mpls] New Version Notification for 
draft-mirsky-mpls-bfd-bootstrap-clarify-00.txt

Hi Carlos,
thank you for taking interest in the proposal, much appreciated. Please find my 
notes in-line and tagged GIM>>.

Regards,
Greg

On Fri, Oct 20, 2017 at 5:54 AM, Carlos Pignataro (cpignata) 
<cpign...@cisco.com<mailto:cpign...@cisco.com>> wrote:
Greg,

This document seems to say “use “Do not Reply” reply mode, and even if you 
reply do not use the BFD Disc TLV, because it is not used.
GIM>> To be precise it says "SHOULD use "Do not Reply" thus preserving 
compliance of implementations that do otherwise.

Wouldn’t it be simpler to say “follow RFC 8029, and the ingress does not care 
about the BFD Disc TLV in the reply”? This would not suddenly make uncompliant 
existing implementations, potentially.
GIM>> I agree that normative language on handling echo reply is bit 
restrictive. My goal is to have good discussion and see what others think.

Also I wonder if this should be bfd-mpls instead of mpls-bfd, given where RFC 
5884 was advanced.
GIM>> Probably it should be the way you've suggested. Hope it is not a big 
problem for individual draft.

Thanks,

—
Carlos Pignataro, car...@cisco.com<mailto:car...@cisco.com>

“Sometimes I use big words that I do not fully understand, to make myself sound 
more photosynthesis."

On Oct 18, 2017, at 8:50 AM, Greg Mirsky 
<gregimir...@gmail.com<mailto:gregimir...@gmail.com>> wrote:

Dear All,
this new document proposes clarification of two questions brought up in course 
of recent discussion of RFC 5884:

  *   use of Return mode values in bootstrapping BFD session echo request;
  *   inclusion of BFD Discriminator TLV in echo response to the bootstrapping 
echo request.
Your comments, questions are always welcome and greatly appreciated.

Regards,
Greg

-- Forwarded message --
From: <internet-dra...@ietf.org<mailto:internet-dra...@ietf.org>>
Date: Wed, Oct 18, 2017 at 5:46 AM
Subject: New Version Notification for 
draft-mirsky-mpls-bfd-bootstrap-clarify-00.txt
To: Gregory Mirsky <gregimir...@gmail.com<mailto:gregimir...@gmail.com>>, 
Yanhua Zhao <zhao.yanh...@zte.com.cn<mailto:zhao.yanh...@zte.com.cn>>



A new version of I-D, draft-mirsky-mpls-bfd-bootstrap-clarify-00.txt
has been successfully submitted by Greg Mirsky and posted to the
IETF repository.

Name:   draft-mirsky-mpls-bfd-bootstrap-clarify
Revision:   00
Title:  Clarifying Use of LSP Ping to Bootstrap BFD over MPLS LSP
Document date:  2017-10-18
Group:  Individual Submission
Pages:  4
URL:
https://www.ietf.org/internet-drafts/draft-mirsky-mpls-bfd-bootst

draft-mirsky-mpls-p2mp-bfd

[Reshad Rahman (rrahman)]

Hi Greg,


Is the goal to be adopted by BFD WG (the draft says BFD Working Group)? If so, 
it should be renamed to draft-mirsky-bfd-mpls-p2mp. OTOH I don’t see any 
proposed BFD changes in this draft, so is this targeted for MPLS WG?



Thanks,

Reshad.

Re: [mpls] New Version Notification for draft-mirsky-mpls-bfd-bootstrap-clarify-00.txt

[Reshad Rahman (rrahman)]

Hi,

While I agree that the echo reply is not needed to bootstrap BFD, and that the 
BFD Disc TLV is not needed in the reply, doing this doesn’t break anything. So 
I don’t see the proposed changes as being necessary.

Does anyone remember why RFC5884  has the echo reply, was it to potentially 
save an echo request from egress for bidirectional case?

Also, if we do go ahead with the proposed changes in this draft, we’ll have to 
fix this errata.

Regards,
Reshad (speaking as individual contributor).

From: Rtg-bfd  on behalf of Greg Mirsky 

Date: Friday, October 20, 2017 at 4:19 PM
To: "Carlos Pignataro (cpignata)" 
Cc: "m...@ietf.org" , "rtg-bfd@ietf.org" 
Subject: Re: [mpls] New Version Notification for 
draft-mirsky-mpls-bfd-bootstrap-clarify-00.txt

Hi Carlos,
thank you for taking interest in the proposal, much appreciated. Please find my 
notes in-line and tagged GIM>>.

Regards,
Greg

On Fri, Oct 20, 2017 at 5:54 AM, Carlos Pignataro (cpignata) 
> wrote:
Greg,

This document seems to say “use “Do not Reply” reply mode, and even if you 
reply do not use the BFD Disc TLV, because it is not used.
GIM>> To be precise it says "SHOULD use "Do not Reply" thus preserving 
compliance of implementations that do otherwise.

Wouldn’t it be simpler to say “follow RFC 8029, and the ingress does not care 
about the BFD Disc TLV in the reply”? This would not suddenly make uncompliant 
existing implementations, potentially.
GIM>> I agree that normative language on handling echo reply is bit 
restrictive. My goal is to have good discussion and see what others think.

Also I wonder if this should be bfd-mpls instead of mpls-bfd, given where RFC 
5884 was advanced.
GIM>> Probably it should be the way you've suggested. Hope it is not a big 
problem for individual draft.

Thanks,

—
Carlos Pignataro, car...@cisco.com

“Sometimes I use big words that I do not fully understand, to make myself sound 
more photosynthesis."

On Oct 18, 2017, at 8:50 AM, Greg Mirsky 
> wrote:

Dear All,
this new document proposes clarification of two questions brought up in course 
of recent discussion of RFC 5884:

  *   use of Return mode values in bootstrapping BFD session echo request;
  *   inclusion of BFD Discriminator TLV in echo response to the bootstrapping 
echo request.
Your comments, questions are always welcome and greatly appreciated.

Regards,
Greg

-- Forwarded message --
From: >
Date: Wed, Oct 18, 2017 at 5:46 AM
Subject: New Version Notification for 
draft-mirsky-mpls-bfd-bootstrap-clarify-00.txt
To: Gregory Mirsky >, 
Yanhua Zhao >



A new version of I-D, draft-mirsky-mpls-bfd-bootstrap-clarify-00.txt
has been successfully submitted by Greg Mirsky and posted to the
IETF repository.

Name:   draft-mirsky-mpls-bfd-bootstrap-clarify
Revision:   00
Title:  Clarifying Use of LSP Ping to Bootstrap BFD over MPLS LSP
Document date:  2017-10-18
Group:  Individual Submission
Pages:  4
URL:
https://www.ietf.org/internet-drafts/draft-mirsky-mpls-bfd-bootstrap-clarify-00.txt
Status: 
https://datatracker.ietf.org/doc/draft-mirsky-mpls-bfd-bootstrap-clarify/
Htmlized:   
https://tools.ietf.org/html/draft-mirsky-mpls-bfd-bootstrap-clarify-00
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-mirsky-mpls-bfd-bootstrap-clarify-00


Abstract:
   This document, if approved, updates RFC 5884 by clarifying procedures
   for using MPLS LSP ping to bootstrap Bidirectional Forwarding
   Detection (BFD) over MPLS Label Switch Path.




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.

The IETF Secretariat

___
mpls mailing list
m...@ietf.org
https://www.ietf.org/mailman/listinfo/mpls

Re: IPR declarations for draft-ietf-bfd-yang

[Reshad Rahman (rrahman)]

I am not aware of any IPR for this document.

On 2018-03-06, 9:40 AM, "Jeffrey Haas"  wrote:

As part of the shepherd writeup, we're required to confirm whether or not
there are any IPR disclosures on the BFD Yang module.

Authors, please respond to this thread, copying the mailing list.

-- Jeff

Re: WGLC on draft-ietf-bfd-yang

[Reshad Rahman (rrahman)]

Hi Qin,

We have made changes in revs 10 and 11 to address YD comments and WGLC comments 
from yourself.

Regards,
Reshad.

From: Rtg-bfd <rtg-bfd-boun...@ietf.org> on behalf of "Reshad Rahman (rrahman)" 
<rrah...@cisco.com>
Date: Friday, February 23, 2018 at 6:43 PM
To: Qin Wu <bill...@huawei.com>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
Subject: Re: WGLC on draft-ietf-bfd-yang

Hi Qin,

Thank you for the review, please see inline.

From: Qin Wu <bill...@huawei.com>
Date: Friday, February 23, 2018 at 1:58 AM
To: "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
Cc: Jeffrey Haas <jh...@pfrc.org>, "Reshad Rahman (rrahman)" <rrah...@cisco.com>
Subject: RE: WGLC on draft-ietf-bfd-yang

I have read v-(09) of draft-ietf-bfd-yang and have a few comments and 
suggestions:

1.  I think tree diagram defined in this draft should follow notation defined 
in draft-ietf-netmod-yang-tree-diagrams

Suggest to add a new section 1.1 as follows:

“

1.1 Tree Diagrams



Tree diagrams used in this document follow the notation defined in

[I-D.ietf-netmod-yang-tree-diagrams<https://tools.ietf.org/html/draft-ietf-lime-yang-connection-oriented-oam-model-06#ref-I-D.ietf-netmod-yang-tree-diagrams>].



”

 Will do.

2.  In the abstract and introduction, please add text to clarify this draft is 
NMDA compliant.

You can follow NMDA compliant example defined in 
draft-ietf-lime-yang-connection-oriented-oam-model-06.

Introduction sections mention I-D.dsdt-nmda-guidelines, I believe 
I-D.dsdt-nmda-guidelines

 Has been merged into RFC6087bis, suggest to remove that paragraph.

 Will do.

3.  Section 2.1 said:

“ The mechanism how the BFD sessions are created by the BFD

   clients is outside the scope of this document.  For BFD clients which

   create BFD sessions via their own configuration, authentication

   parameters (if required) are still specified in BFD.

”

Looks like these last two sentence contradict. Suggest to change as follows:

s/ are still specified in BFD/ are still specified in BFD model.

 The BFD authentication parameters are actually in BFD, i.e. not in the BFD 
client.
4.I didn’t see any RPC operation defined in this model, looks like RPC 
operation is incomplete,
Suggest to remove all RPC related text if no RPC operation is defined.
 Correct, no RPCs. Will remove all RPC related text.
5.Section 2 mentions:

“   BFD can operate in the following contexts:



   1.  Network devices as described in Network Device YANG

   Organizational Models [I-D.ietf-rtgwg-device-model]

”

It is not clear that [I-D.ietf-rtgwg-device-model] will be standardized since 
it provides static model structure to assemble

All the other YANG models. But we have schema mount, schema mount can help us 
to assemble YANG model in any mounting point.

I would suggest to remove bullet 1 mentioned above.

 I can remove the reference, but the point is that the model can be used at 
the “top-level”, i.e. without being schema-mounted. I want to keep that piece 
of info here.
6. Section 2: suggest to replace RFC8022 with RFC8022bis since RFC8022bis will 
obsolete RFC8022.
 Will do.
7. Section 2 said:

“ A new control-plane protocol "bfdv1" is defined and a "bfd" container

   is created under control-plane-protocol as specified in A YANG Data

   Model for Routing Management [RFC8022].  This new "bfd" node is

   augmented by all the YANG modules for their respective specific

   information.
”
Where "bfdv1" is defined, I think it is in the ietf-bfd-types module.
 Correct.
Is "bfd" container same as "bfd" node? If yes, please make the term consistent.
 Yes and will do.

In addition, it looks to me you first define ietf-bfd module which is the 
extension of ietf-routing defined in RFC8022bis.

And then all the other technology specific modules are extension of ietf-bfd 
module.

But this is not clear in the text, would it be great to list all the modules 
defined in this document? Clarify their dependency relationship.
 Correct. Will add text to clarify. Note that this is what 2nd paragraph of 
section 2 is trying to convey.



8. The YANG Modules defined in this draft import from

> ietf-te

> ietf-inet-types

> ietf-interfaces

>ietf-routing

But some of them lack reference, some of reference are outdated.

See draft-ietf-netmod-rfc7277bis or draft-ietf-netmod-rfc8022bis for examples 
of how this might be

Handled

 Will update the references (got this from YD review).



Regards,

Reshad.




-Qin
On Thu, Feb 08, 2018 at 03:02:52PM -0500, Jeffrey Haas wrote:




Reminder, WGLC ends tomorrow.

On Wed, Jan 24, 2018 at 01:22:07PM -0500, Jeffrey Haas wrote:




Working Group,

The authors of the BFD Yang module have declared their work on that document
complete.  Thus, working group last call is in progress for this document.
Please provide your hopefully final reviews on the text.

The las

Re: Yangdoctors last call review of draft-ietf-bfd-yang-09

[Reshad Rahman (rrahman)]

Hi Jurgen,

We have made the changes in revs 10 and 11 to address your comments . The 
exception is module ietf-bfd-types which did not get renamed per reason below.

Regards,
Reshad.

On 2018-02-25, 11:28 AM, "Reshad Rahman (rrahman)" <rrah...@cisco.com> wrote:

Hi,

Regarding the following, making the change is easy but ietf-bfd-types is 
used by other modules so this will impact these other modules. E.g. the RIP 
draft (https://datatracker.ietf.org/doc/draft-ietf-rtgwg-yang-rip/) is 
currently in the RFC Editor queue, I presume it's too late then to make this 
name change?

Regards,
Reshad.

* BFD types YANG Module

  -  In fact, ietf-bfd-types is kind of a
misnomer; perhaps this should be ietf-bfd-common (the -common 
was
used in RFC 8194 but I am biased here).
 Will rename to -common


On 2018-02-23, 11:53 AM, "Reshad Rahman (rrahman)" <rrah...@cisco.com> 
wrote:

Hi Jürgen,

Thank you for the review, response inline.

On 2018-02-15, 4:35 AM, "Jürgen Schönwälder" 
<j.schoenwael...@jacobs-university.de> wrote:

Reviewer: Jürgen Schönwälder
Review result: Not Ready

Review of draft-ietf-bfd-yang-09.txt.

* General comments

  - Having requirements language below the abstract looks like a 
novel
idea, I assume the RFC editor will edit this. Also note that
nowadays authors are usually expected to cite RFC 8174 as well
with the extended boilerplate text.
 Will make the changes.

  - Update 2017 to 2018 in copyright statements etc.
 Will make the changes.

  - References to RFC 7223, RFC 7277, RFC 8022 should be updated to
references to the I-Ds replacing them (sitting in the RFC editor
queue). This may also involve changes in the YANG model.
 Will make the changes. I don't think this will involve changes in 
the YANG model, but will pay attention to this.

  - State whether the model is NMDA compliant (which it likely 
should
be), see also previous item.
 This is mentioned in section 2. I will look into moving this to 
the intro and changing the text to clarify.

  - I am not sure why you want to cite I-D.dsdt-nmda-guidelines. 
Would
it not make more sense to cite the NMDA specification?
 Will make the change. By NMDA specification, you're referring to 
draft-ietf-netmod-revised-datastores?

  - There are some YANG validation errors that should be addressed 
(see
the link on the datatracker).
 Those were in 8022bis I believe, gone now.

  - References YANG modules must be in the references and there must
be citations in the text, hence there is the common phrase "This
YANG module imports  [RFCwxyz] and "

  - We generally prefer

  reference "RFC 6991: Common YANG Data Types"

over

  reference "RFC 6991"

since not everybody remembers all the RFC numbers (add the RFC
title after the RFC number, separated by a colon). In some 
places
you actually use the syntactic format but you do not use the RFC
title. Please make this consistent, following the usual
conventions.
 Will make the change. 

  - I have raised a question on yang-doctors concerning the pattern

  import ietf-inet-types {
prefix "inet";
reference "RFC 6991";
  }

and whether this should perhaps be

  import ietf-inet-types {
prefix inet;
reference "RFC 6991: Common YANG Data Types
   (at the time of this writing)";
  }
  Saw the discussion, will make the change once there is closure.

* Design of the Data Model

  - Do I always have to use schema mount to use these YANG models? 
If
so, one might consider I-D.ietf-netmod-schema-mount a normative
reference. Are you not augmenting the routing model?
   I will clarify in the text. There was a follow-up email 
discussion on this, we are augmenting the routing model and schema mount can be 
used (but not mandatory).
  
  - I

Re: Yangdoctors last call review of draft-ietf-bfd-yang-09

[Reshad Rahman (rrahman)]

Hi,

Regarding the following, making the change is easy but ietf-bfd-types is used 
by other modules so this will impact these other modules. E.g. the RIP draft 
(https://datatracker.ietf.org/doc/draft-ietf-rtgwg-yang-rip/) is currently in 
the RFC Editor queue, I presume it's too late then to make this name change?

Regards,
Reshad.

* BFD types YANG Module

  -  In fact, ietf-bfd-types is kind of a
misnomer; perhaps this should be ietf-bfd-common (the -common was
used in RFC 8194 but I am biased here).
 Will rename to -common


On 2018-02-23, 11:53 AM, "Reshad Rahman (rrahman)" <rrah...@cisco.com> wrote:

Hi Jürgen,

Thank you for the review, response inline.

On 2018-02-15, 4:35 AM, "Jürgen Schönwälder" 
<j.schoenwael...@jacobs-university.de> wrote:

Reviewer: Jürgen Schönwälder
Review result: Not Ready

Review of draft-ietf-bfd-yang-09.txt.

* General comments

  - Having requirements language below the abstract looks like a novel
idea, I assume the RFC editor will edit this. Also note that
nowadays authors are usually expected to cite RFC 8174 as well
with the extended boilerplate text.
 Will make the changes.

  - Update 2017 to 2018 in copyright statements etc.
 Will make the changes.

  - References to RFC 7223, RFC 7277, RFC 8022 should be updated to
references to the I-Ds replacing them (sitting in the RFC editor
queue). This may also involve changes in the YANG model.
 Will make the changes. I don't think this will involve changes in the 
YANG model, but will pay attention to this.

  - State whether the model is NMDA compliant (which it likely should
be), see also previous item.
 This is mentioned in section 2. I will look into moving this to the 
intro and changing the text to clarify.

  - I am not sure why you want to cite I-D.dsdt-nmda-guidelines. Would
it not make more sense to cite the NMDA specification?
 Will make the change. By NMDA specification, you're referring to 
draft-ietf-netmod-revised-datastores?

  - There are some YANG validation errors that should be addressed (see
the link on the datatracker).
 Those were in 8022bis I believe, gone now.

  - References YANG modules must be in the references and there must
be citations in the text, hence there is the common phrase "This
YANG module imports  [RFCwxyz] and "

  - We generally prefer

  reference "RFC 6991: Common YANG Data Types"

over

  reference "RFC 6991"

since not everybody remembers all the RFC numbers (add the RFC
title after the RFC number, separated by a colon). In some places
you actually use the syntactic format but you do not use the RFC
title. Please make this consistent, following the usual
conventions.
 Will make the change. 

  - I have raised a question on yang-doctors concerning the pattern

  import ietf-inet-types {
prefix "inet";
reference "RFC 6991";
  }

and whether this should perhaps be

  import ietf-inet-types {
prefix inet;
reference "RFC 6991: Common YANG Data Types
   (at the time of this writing)";
  }
  Saw the discussion, will make the change once there is closure.

* Design of the Data Model

  - Do I always have to use schema mount to use these YANG models? If
so, one might consider I-D.ietf-netmod-schema-mount a normative
reference. Are you not augmenting the routing model?
   I will clarify in the text. There was a follow-up email discussion 
on this, we are augmenting the routing model and schema mount can be used (but 
not mandatory).
  
  - I do not understand the explanations how the groupings solve the
problem that IGPs are moving targets (they come and go). How do
the groupings help the operator to configure BFD parameters for
peers they do not know about yet?
 I will update the text. Basically as IGPs discover peers/neighbors, 
they create BFD sessions "internally" (i.e. via API, not via config).

  - How does a client know which choices of the "min-interval", used
for both transmit and receive intervals, and "desired-min-tx-
interval" and "required-min-rx-interval" are supported by an
  

Re: WGLC on draft-ietf-bfd-yang

[Reshad Rahman (rrahman)]

Hi Qin,

Thank you for the review, please see inline.

From: Qin Wu <bill...@huawei.com>
Date: Friday, February 23, 2018 at 1:58 AM
To: "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
Cc: Jeffrey Haas <jh...@pfrc.org>, "Reshad Rahman (rrahman)" <rrah...@cisco.com>
Subject: RE: WGLC on draft-ietf-bfd-yang

I have read v-(09) of draft-ietf-bfd-yang and have a few comments and 
suggestions:

1.  I think tree diagram defined in this draft should follow notation defined 
in draft-ietf-netmod-yang-tree-diagrams

Suggest to add a new section 1.1 as follows:

“

1.1 Tree Diagrams



Tree diagrams used in this document follow the notation defined in

[I-D.ietf-netmod-yang-tree-diagrams<https://tools.ietf.org/html/draft-ietf-lime-yang-connection-oriented-oam-model-06#ref-I-D.ietf-netmod-yang-tree-diagrams>].



”

 Will do.

2.  In the abstract and introduction, please add text to clarify this draft is 
NMDA compliant.

You can follow NMDA compliant example defined in 
draft-ietf-lime-yang-connection-oriented-oam-model-06.

Introduction sections mention I-D.dsdt-nmda-guidelines, I believe 
I-D.dsdt-nmda-guidelines

 Has been merged into RFC6087bis, suggest to remove that paragraph.

 Will do.

3.  Section 2.1 said:

“ The mechanism how the BFD sessions are created by the BFD

   clients is outside the scope of this document.  For BFD clients which

   create BFD sessions via their own configuration, authentication

   parameters (if required) are still specified in BFD.

”

Looks like these last two sentence contradict. Suggest to change as follows:

s/ are still specified in BFD/ are still specified in BFD model.

 The BFD authentication parameters are actually in BFD, i.e. not in the BFD 
client.
4.I didn’t see any RPC operation defined in this model, looks like RPC 
operation is incomplete,
Suggest to remove all RPC related text if no RPC operation is defined.
 Correct, no RPCs. Will remove all RPC related text.
5.Section 2 mentions:

“   BFD can operate in the following contexts:



   1.  Network devices as described in Network Device YANG

   Organizational Models [I-D.ietf-rtgwg-device-model]

”

It is not clear that [I-D.ietf-rtgwg-device-model] will be standardized since 
it provides static model structure to assemble

All the other YANG models. But we have schema mount, schema mount can help us 
to assemble YANG model in any mounting point.

I would suggest to remove bullet 1 mentioned above.

 I can remove the reference, but the point is that the model can be used at 
the “top-level”, i.e. without being schema-mounted. I want to keep that piece 
of info here.
6. Section 2: suggest to replace RFC8022 with RFC8022bis since RFC8022bis will 
obsolete RFC8022.
 Will do.
7. Section 2 said:

“ A new control-plane protocol "bfdv1" is defined and a "bfd" container

   is created under control-plane-protocol as specified in A YANG Data

   Model for Routing Management [RFC8022].  This new "bfd" node is

   augmented by all the YANG modules for their respective specific

   information.
”
Where "bfdv1" is defined, I think it is in the ietf-bfd-types module.
 Correct.
Is "bfd" container same as "bfd" node? If yes, please make the term consistent.
 Yes and will do.

In addition, it looks to me you first define ietf-bfd module which is the 
extension of ietf-routing defined in RFC8022bis.

And then all the other technology specific modules are extension of ietf-bfd 
module.

But this is not clear in the text, would it be great to list all the modules 
defined in this document? Clarify their dependency relationship.
 Correct. Will add text to clarify. Note that this is what 2nd paragraph of 
section 2 is trying to convey.



8. The YANG Modules defined in this draft import from

> ietf-te

> ietf-inet-types

> ietf-interfaces

>ietf-routing

But some of them lack reference, some of reference are outdated.

See draft-ietf-netmod-rfc7277bis or draft-ietf-netmod-rfc8022bis for examples 
of how this might be

Handled

 Will update the references (got this from YD review).



Regards,

Reshad.




-Qin
On Thu, Feb 08, 2018 at 03:02:52PM -0500, Jeffrey Haas wrote:



Reminder, WGLC ends tomorrow.

On Wed, Jan 24, 2018 at 01:22:07PM -0500, Jeffrey Haas wrote:



Working Group,

The authors of the BFD Yang module have declared their work on that document
complete.  Thus, working group last call is in progress for this document.
Please provide your hopefully final reviews on the text.

The last several revisions of the document have largely been done to resolve
lingering RFC 6087bis comments, and interwork/usability issues by the
importing protocol modules.

A parallel request for directorate review has been done with the routing and
security directorates along with the yang doctors.

The deadline for last call comments is February 9.

-- Jeff (for the chairs)

Re: Yangdoctors last call review of draft-ietf-bfd-yang-09

[Reshad Rahman (rrahman)]

Hi Jürgen,

Thank you for the review, response inline.

On 2018-02-15, 4:35 AM, "Jürgen Schönwälder" 
 wrote:

Reviewer: Jürgen Schönwälder
Review result: Not Ready

Review of draft-ietf-bfd-yang-09.txt.

* General comments

  - Having requirements language below the abstract looks like a novel
idea, I assume the RFC editor will edit this. Also note that
nowadays authors are usually expected to cite RFC 8174 as well
with the extended boilerplate text.
 Will make the changes.

  - Update 2017 to 2018 in copyright statements etc.
 Will make the changes.

  - References to RFC 7223, RFC 7277, RFC 8022 should be updated to
references to the I-Ds replacing them (sitting in the RFC editor
queue). This may also involve changes in the YANG model.
 Will make the changes. I don't think this will involve changes in the YANG 
model, but will pay attention to this.

  - State whether the model is NMDA compliant (which it likely should
be), see also previous item.
 This is mentioned in section 2. I will look into moving this to the intro 
and changing the text to clarify.

  - I am not sure why you want to cite I-D.dsdt-nmda-guidelines. Would
it not make more sense to cite the NMDA specification?
 Will make the change. By NMDA specification, you're referring to 
draft-ietf-netmod-revised-datastores?

  - There are some YANG validation errors that should be addressed (see
the link on the datatracker).
 Those were in 8022bis I believe, gone now.

  - References YANG modules must be in the references and there must
be citations in the text, hence there is the common phrase "This
YANG module imports  [RFCwxyz] and "

  - We generally prefer

  reference "RFC 6991: Common YANG Data Types"

over

  reference "RFC 6991"

since not everybody remembers all the RFC numbers (add the RFC
title after the RFC number, separated by a colon). In some places
you actually use the syntactic format but you do not use the RFC
title. Please make this consistent, following the usual
conventions.
 Will make the change. 

  - I have raised a question on yang-doctors concerning the pattern

  import ietf-inet-types {
prefix "inet";
reference "RFC 6991";
  }

and whether this should perhaps be

  import ietf-inet-types {
prefix inet;
reference "RFC 6991: Common YANG Data Types
   (at the time of this writing)";
  }
  Saw the discussion, will make the change once there is closure.

* Design of the Data Model

  - Do I always have to use schema mount to use these YANG models? If
so, one might consider I-D.ietf-netmod-schema-mount a normative
reference. Are you not augmenting the routing model?
   I will clarify in the text. There was a follow-up email discussion on 
this, we are augmenting the routing model and schema mount can be used (but not 
mandatory).
  
  - I do not understand the explanations how the groupings solve the
problem that IGPs are moving targets (they come and go). How do
the groupings help the operator to configure BFD parameters for
peers they do not know about yet?
 I will update the text. Basically as IGPs discover peers/neighbors, they 
create BFD sessions "internally" (i.e. via API, not via config).

  - How does a client know which choices of the "min-interval", used
for both transmit and receive intervals, and "desired-min-tx-
interval" and "required-min-rx-interval" are supported by an
implementation?
  We'll think about this. We'll either add feature or make both mandatory.
   
  - The phrase 'operational model' probably means 'operational state
model' and 'operational items' probably means 'operational state
data'.
 Will make the change. 

  - You have summary information and detailed BFD session information.
What would an implementation report if say access to some BFD
sessions is restricted by access control? Would information about
them still leak through the summary information? I assume so that
this may be practically the way to do things but perhaps this
needs to be mentioned in the security considerations.
 The summary information contains everything. I don't see what kind of 
security consideration is required if we know e.g. that we have so many 
sessions up and down.

  - In 2.3, you use 'clients of BFD' but I think this is very
different from 'BFD clients'. Please clarify the terminology.
 Will use 'BFD clients' everywhere.

  - s/operational data/operational state data/g
 Yes

  - The *-count leafs seem to be 

Re: [yang-doctors] Yangdoctors last call review of draft-ietf-bfd-yang-09

[Reshad Rahman (rrahman)]

Hi Acee,

What I meant is that BFD always augments the control palne protocols in 
ietf-routing model. And the BFD augmentation can be used as-is or mounted in 
LNE or in NI.

Regards,
Reshad.

On 2018-02-17, 7:46 PM, "Acee Lindem (acee)" <a...@cisco.com> wrote:

Hi Reshad, 
Are you saying that BFD would never augment the list of control place 
protocols in ietf-routing and always be at the root of the tree (whether it be 
the device, LNE, or NI)? I guess it doesn't have to be in the list since it 
will never install routes in the routing table. 

Thanks,
Acee

On 2/17/18, 5:26 PM, "Reshad Rahman (rrahman)" <rrah...@cisco.com> wrote:

Ietf-bfd augments the ietf-routing model, that's not conditional. How 
the ietf-bfd model is used may vary:
1) It may be used "directly" in a device (i.e no schema mount)
2) It may be schema mounted for use in an LNE
3) It may be schema mounted for use in a VRF

I thought this was the case for all routing protocols.

Regards,
Reshad.

On 2018-02-17, 1:31 PM, "Acee Lindem (acee)" <a...@cisco.com> wrote:

I thought about that after I replied. I guess you are saying that 
it is conceivable for a network device to support ietf-bfd but not support 
routing (ietf-routing)? 

Thanks,
    Acee 
        
On 2/17/18, 1:24 PM, "Reshad Rahman (rrahman)" <rrah...@cisco.com> 
wrote:

Right, schema-mount can be used in some cases (logical device 
or in a VRF) but doesn’t have to be used in other cases (e.g. network device 
which doesn't support VRFs). We will clarify the text, at a certain time we 
incorrectly thought that schema mount had to be used in all cases.

Regards,
Reshad.

On 2018-02-17, 3:56 AM, "Juergen Schoenwaelder" 
<j.schoenwael...@jacobs-university.de> wrote:

On Fri, Feb 16, 2018 at 11:11:28PM +, Acee Lindem 
(acee) wrote:

> * Design of the Data Model
> 
>   - Do I always have to use schema mount to use these 
YANG models? If
> so, one might consider 
I-D.ietf-netmod-schema-mount a normative
> reference. Are you not augmenting the routing 
model?
> 
> This Is definitely not the case. This model will augment 
RFC8022BIS. The question on how to do is being discussion on the YANG doctors 
list. 
>

This is what I thought but the text is kind of misleading:

   BFD can operate in the following contexts:

   [...]

   The approach taken is to do a schema-mount (see Schema 
Mount
   [I-D.ietf-netmod-schema-mount]) of the BFD model in the 
appropriate
   locations.

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen 
gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 
Bremen | Germany
Fax:   +49 421 200 3103 
<https://www.jacobs-university.de/>

Re: [yang-doctors] Yangdoctors last call review of draft-ietf-bfd-yang-09

[Reshad Rahman (rrahman)]

Ietf-bfd augments the ietf-routing model, that's not conditional. How the 
ietf-bfd model is used may vary:
1) It may be used "directly" in a device (i.e no schema mount)
2) It may be schema mounted for use in an LNE
3) It may be schema mounted for use in a VRF

I thought this was the case for all routing protocols.

Regards,
Reshad.

On 2018-02-17, 1:31 PM, "Acee Lindem (acee)" <a...@cisco.com> wrote:

I thought about that after I replied. I guess you are saying that it is 
conceivable for a network device to support ietf-bfd but not support routing 
(ietf-routing)? 

Thanks,
Acee 

On 2/17/18, 1:24 PM, "Reshad Rahman (rrahman)" <rrah...@cisco.com> wrote:

Right, schema-mount can be used in some cases (logical device or in a 
VRF) but doesn’t have to be used in other cases (e.g. network device which 
doesn't support VRFs). We will clarify the text, at a certain time we 
incorrectly thought that schema mount had to be used in all cases.

Regards,
Reshad.

On 2018-02-17, 3:56 AM, "Juergen Schoenwaelder" 
<j.schoenwael...@jacobs-university.de> wrote:

On Fri, Feb 16, 2018 at 11:11:28PM +, Acee Lindem (acee) wrote:

> * Design of the Data Model
> 
>   - Do I always have to use schema mount to use these YANG 
models? If
> so, one might consider I-D.ietf-netmod-schema-mount a 
normative
> reference. Are you not augmenting the routing model?
> 
> This Is definitely not the case. This model will augment 
RFC8022BIS. The question on how to do is being discussion on the YANG doctors 
list. 
>

This is what I thought but the text is kind of misleading:

   BFD can operate in the following contexts:

   [...]

   The approach taken is to do a schema-mount (see Schema Mount
   [I-D.ietf-netmod-schema-mount]) of the BFD model in the 
appropriate
   locations.

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | 
Germany
Fax:   +49 421 200 3103 <https://www.jacobs-university.de/>

Re: [yang-doctors] Yangdoctors last call review of draft-ietf-bfd-yang-09

[Reshad Rahman (rrahman)]

Right, schema-mount can be used in some cases (logical device or in a VRF) but 
doesn’t have to be used in other cases (e.g. network device which doesn't 
support VRFs). We will clarify the text, at a certain time we incorrectly 
thought that schema mount had to be used in all cases.

Regards,
Reshad.

On 2018-02-17, 3:56 AM, "Juergen Schoenwaelder" 
 wrote:

On Fri, Feb 16, 2018 at 11:11:28PM +, Acee Lindem (acee) wrote:

> * Design of the Data Model
> 
>   - Do I always have to use schema mount to use these YANG models? If
> so, one might consider I-D.ietf-netmod-schema-mount a normative
> reference. Are you not augmenting the routing model?
> 
> This Is definitely not the case. This model will augment RFC8022BIS. The 
question on how to do is being discussion on the YANG doctors list. 
>

This is what I thought but the text is kind of misleading:

   BFD can operate in the following contexts:

   [...]

   The approach taken is to do a schema-mount (see Schema Mount
   [I-D.ietf-netmod-schema-mount]) of the BFD model in the appropriate
   locations.

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

Re: [RTG-DIR] RtgDir review:

[Reshad Rahman (rrahman)]

Hi Ravi,

There is indeed lots of common information and this was addressed by using 
groupings.

I am not sure I understand the suggestion to use submodules. A submodule can 
belong to only 1 module (https://tools.ietf.org/html/rfc7950#section-5.1) so I 
do not see how using submodules would help (but I could be missing something).

We’ve done what you suggested by defining groupings for the common information, 
so although you see repetitions in the YANG trees, there is no repetition in 
the YANG modules.

Regards,
Reshad.

From: "Acee Lindem (acee)" 
Date: Friday, February 9, 2018 at 9:18 AM
To: Ravi Singh , "rtg-...@ietf.org" 
Cc: "rtg-...@ietf.org" , "rtg-bfd@ietf.org" 
, "draft-ietf-bfd-y...@ietf.org" 
, YANG Doctors 
Subject: Re: [RTG-DIR] RtgDir review:
Resent-From: 
Resent-To: , , 
, , 

Resent-Date: Friday, February 9, 2018 at 9:18 AM

+yang doctors

Hi Ravi,
 submodules have proved to be unwieldy and offer little advantage over 
groupings. I don’t know that we want to crave this model up into submodules. 
I’ve copied the YANG doctors to assure this is the consensus as there have been 
submodule debates on the NETMOD list in the past.

Thanks,
Acee


From: rtg-dir  on behalf of Ravi Singh 

Date: Friday, February 9, 2018 at 8:36 AM
To: "rtg-...@ietf.org" 
Cc: Routing Directorate , "rtg-bfd@ietf.org" 
, "draft-ietf-bfd-y...@ietf.org" 

Subject: [RTG-DIR] RtgDir review:

Hello,

I have been selected as the Routing Directorate reviewer for this draft. The 
Routing Directorate seeks to review all routing or routing-related drafts as 
they pass through IETF last call and IESG review, and sometimes on special 
request. The purpose of the review is to provide assistance to the Routing ADs. 
For more information about the Routing Directorate, please see 
​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Although these comments are primarily for the use of the Routing ADs, it would 
be helpful if you could consider them along with any other IETF Last Call 
comments that you receive, and strive to resolve them through discussion or by 
updating the draft.

Document: draft-ietf-bfd-yang-09
Reviewer: Ravi Singh
Review Date: 02/09/2018
Intended Status: Proposed standard



Summary: there is more commonality of info in the new modules listed in 
sections 2.6-2.10 than there are differences. So, I think it would be 
worthwhile looking at sub-abstracting things to avoid repetitive fields 
individually listed in the modules of section 2.6-2.10.

Details:
I've reviewed the draft. Most sections look good.
My comments below pertain to 2.6 to 2.10.
Section 2 says "Since BFD is used for liveliness detection of various forwarding
   paths, there is no uniform key to identify a BFD session.  So the BFD
   data model is split in multiple YANG modules where each module
   corresponds to one type of forwarding path. "
That is ok. However, this is causing too much repetition of info across the 
multiple modules.
There appears to be scope for modularization to not repeat the individual 
fields in describing them in every module that uses them.
Instead sub-modules should be considered & listed in one section which just 
augment the newly created modules of this draft wherever currently used.

Eg.
Separate sub-modules could be considered for:
A.
+--ro session-statistics
|  +--ro session-count?  uint32
|  +--ro session-up-count?   uint32
|  +--ro session-down-count? uint32
|  +--ro session-admin-down-count?   uint32

B.
   +--rw source-addr inet:ip-address
   +--rw dest-addr   inet:ip-address
   +--rw local-multiplier?   multiplier
   +--rw (interval-config-type)?
   |  +--:(tx-rx-intervals)
   |  |  +--rw desired-min-tx-interval?uint32
   |  |  +--rw required-min-rx-interval?   uint32
   |  +--:(single-interval)
   | +--rw min-interval?   uint32
   +--rw demand-enabled? boolean {demand-mode}?
   +--rw admin-down? boolean
   +--rw authentication! {authentication}?
   |  +--rw key-chain?kc:key-chain-ref
   |  +--rw meticulous?   Boolean

C.
  +--ro path-type?  identityref
  +--ro ip-encapsulation?   boolean
  +--ro local-discriminator?discriminator
  +--ro remote-discriminator?   discriminator
  +--ro remote-multiplier?  multiplier
  +--ro 

Re: WGLC for BFD Multipoint documents (last round)

[Reshad Rahman (rrahman)]

Greg, I agree “MUST use” doesn’t read well. s/use/expect/ is good with me.

Regards,
Reshad.

From: "gregory.mir...@ztetx.com" <gregory.mir...@ztetx.com>
Date: Thursday, February 8, 2018 at 12:14 AM
To: "Reshad Rahman (rrahman)" <rrah...@cisco.com>
Cc: "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
Subject: Re: WGLC for BFD Multipoint documents (last round)


Hi Reshad,

thank you for your consideration. I've came across what looks as simple 
editorial change. Appreciate your comment.

In the second paragraph of section 4.8 Packet consumption on tails the following

  For multipoint LSPs, when IP/UDP encapsulation of BFD control packets

  is used, MultipointTail MUST use destination UDP port "3784" ...

reads akwardly because, I think, of 'MUST use'. I propose simple s/use/look 
for/ or s/use/expect/. What do you think? Is the text god as-is or minor 
editing may help?



Regards,

Greg Mirsky



Sr. Standardization Expert
预研标准部/有线研究院/有线产品经营部 Standard Preresearch Dept./Wireline Product R 
Institute/Wireline Product Operation Division


[cid:9ae3e214c17d49ed935d87c674ba3ee2]

[cid:24242e5637af428891c4db731e7765ad]
E: gregory.mir...@ztetx.com<mailto:gregory.mir...@ztetx.com>
www.zte.com.cn<http://www.zte.com.cn/>

Original Mail
Sender: ReshadRahman(rrahman) <rrah...@cisco.com>
To: gregory mirsky10211915;rtg-bfd@ietf.org <rtg-bfd@ietf.org>
Date: 2018/02/08 11:03
Subject: Re: WGLC for BFD Multipoint documents (last round)

Hi Greg,

I would go with normative SHOULD. What you proposed below is fine.

Regards,
Reshad.


From: "gregory.mir...@ztetx.com" <gregory.mir...@ztetx.com>
Date: Sunday, February 4, 2018 at 8:33 PM
To: "Reshad Rahman (rrahman)" <rrah...@cisco.com>, "rtg-bfd@ietf.org" 
<rtg-bfd@ietf.org>
Subject: Re: WGLC for BFD Multipoint documents (last round)


Hi Reshad,

you've said:

Hi Greg,



While OOB mechanism would improve security, my personal opinion is that we 
should try to improve security without requiring an OOB mechanism. I think we 
can add text to the security considerations to address the concerns below, e.g. 
A tail SHOULD prevent the number of MultipointTail sessions from exceeding the 
number of expected streams.  The concern expressed in b) cannot be fixed by 
what I proposed because of multiple streams.  So just preventing the number of 
MultipointTail sessions from exceeding the number of expected streams should be 
good enough.



Regards,

Reshad.



If we make it normative SHOULD, i.e. s/should/SHOULD/ in the third 
recommendation to the implementers:

 The implementation SHOULD have a reasonable upper bound on the

  number of MultipointTail sessions that can be created, with the

  upper bound potentially being computed based on the number of

  multicast streams that the system is expecting.



Or keep the lower case as it is consistent with the rest of the section, e.g. 
'a MultipointTail session should not be created'?



Kind regards,

Greg Mirsky



Sr. Standardization Expert
预研标准部/有线研究院/有线产品经营部 Standard Preresearch Dept./Wireline Product R 
Institute/Wireline Product Operation Division


[cid:9ae3e214c17d49ed935d87c674ba3ee2]

[cid:24242e5637af428891c4db731e7765ad]
E: gregory.mir...@ztetx.com<mailto:gregory.mir...@ztetx.com>
www.zte.com.cn<http://www.zte.com.cn/>

Re: WGLC for BFD Multipoint documents (last round)

[Reshad Rahman (rrahman)]

Greg, this is good.

Regards,
Reshad.

From: "gregory.mir...@ztetx.com" <gregory.mir...@ztetx.com>
Date: Wednesday, February 7, 2018 at 11:58 PM
To: "Reshad Rahman (rrahman)" <rrah...@cisco.com>
Cc: "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>, "gregimir...@gmail.com" 
<gregimir...@gmail.com>
Subject: Re: WGLC for BFD Multipoint documents (last round)


Hi Reshad,

thank you for the great suggestion. Below is the proposed update to section 
4.3.1 New State Variables:

OLD TEXT

   This variable is only pertinent when bfd.SessionType is

   MultipointTail.

NEW TEXT

This variable is only pertinent when bfd.SessionType is

 MultipointTail and SHOULD NOT be modified after the

 MultipointTail session has been created.





Greg Mirsky



Sr. Standardization Expert
预研标准部/有线研究院/有线产品经营部 Standard Preresearch Dept./Wireline Product R 
Institute/Wireline Product Operation Division


[cid:9ae3e214c17d49ed935d87c674ba3ee2]

[cid:24242e5637af428891c4db731e7765ad]
E: gregory.mir...@ztetx.com<mailto:gregory.mir...@ztetx.com>
www.zte.com.cn<http://www.zte.com.cn/>

Original Mail
Sender: ReshadRahman(rrahman) <rrah...@cisco.com>
To: gregory mirsky10211915;rtg-bfd@ietf.org <rtg-bfd@ietf.org>
CC: gregimir...@gmail.com <gregimir...@gmail.com>
Date: 2018/02/08 11:22
Subject: Re: WGLC for BFD Multipoint documents (last round)
Hi Greg,

Regarding changing bfd.SilentTail on the fly, I think we should consider adding 
some text “… SHOULD not be modified after the MultipointTail session has been 
created.“. This is to prevent  false failure detections as you mentioned.

Regards,
Reshad.

From: "gregory.mir...@ztetx.com" <gregory.mir...@ztetx.com>
Date: Sunday, February 4, 2018 at 8:18 PM
To: "Reshad Rahman (rrahman)" <rrah...@cisco.com>, "rtg-bfd@ietf.org" 
<rtg-bfd@ietf.org>
Cc: "gregimir...@gmail.com" <gregimir...@gmail.com>
Subject: Re: WGLC for BFD Multipoint documents (last round)


Hi Reshad,



You've said:

Hi Greg,



The question about whether we need a new variable wasn’t referring to 
MultipointClient state (I agree this is well explained). Since I mentioned 
“state variable” I realize the confusion…



The question was whether we need a new state variable (not for the 
MultipointClient state) to control the behavior explained in this paragraph, 
e.g the new state variable could be called bfd.TrackTails.



   If the head wishes to know the identity of the tails, it sends

   multipoint Polls as needed.  Previously known tails that don't

   respond to the Polls will be detected.



Regards,

Reshad.

I agree that an operator should have control over whether the head does tail 
discovery, tail monitoring. But I think that that may require whole suite  of 
parameters and some might need coordidation for the MultipointHead with 
MultipointTail, e.g. when the given MultipointTail has bfd.SilentTail changed 
from 0 to 1 or vice versa. Would that trigger false negative on the head? I 
think that there's lots of  open space ofr the innovation in the area of 
monitoring p2mp tails. I hope that someone will be interested to continue and 
produce more detailed specification than draft-ietf-bfd-multipoint-active-tail. 
For example, time interval between multicast Poll and  relationship to unicast 
BFD control packets to tail(s).



Best regards,

Greg Mirsky



Sr. Standardization Expert
预研标准部/有线研究院/有线产品经营部 Standard Preresearch Dept./Wireline Product R 
Institute/Wireline Product Operation Division


[cid:9ae3e214c17d49ed935d87c674ba3ee2]

[cid:24242e5637af428891c4db731e7765ad]
E: gregory.mir...@ztetx.com<mailto:gregory.mir...@ztetx.com>
www.zte.com.cn<http://www.zte.com.cn/>

Re: WGLC for BFD Multipoint documents (last round)

[Reshad Rahman (rrahman)]

Hi Greg,

Regarding changing bfd.SilentTail on the fly, I think we should consider adding 
some text “… SHOULD not be modified after the MultipointTail session has been 
created.“. This is to prevent false failure detections as you mentioned.

Regards,
Reshad.

From: "gregory.mir...@ztetx.com" <gregory.mir...@ztetx.com>
Date: Sunday, February 4, 2018 at 8:18 PM
To: "Reshad Rahman (rrahman)" <rrah...@cisco.com>, "rtg-bfd@ietf.org" 
<rtg-bfd@ietf.org>
Cc: "gregimir...@gmail.com" <gregimir...@gmail.com>
Subject: Re: WGLC for BFD Multipoint documents (last round)


Hi Reshad,



You've said:

Hi Greg,



The question about whether we need a new variable wasn’t referring to 
MultipointClient state (I agree this is well explained). Since I mentioned 
“state variable” I realize the confusion…



The question was whether we need a new state variable (not for the 
MultipointClient state) to control the behavior explained in this paragraph, 
e.g the new state variable could be called bfd.TrackTails.



   If the head wishes to know the identity of the tails, it sends

   multipoint Polls as needed.  Previously known tails that don't

   respond to the Polls will be detected.



Regards,

Reshad.

I agree that an operator should have control over whether the head does tail 
discovery, tail monitoring. But I think that that may require whole suite of 
parameters and some might need coordidation for the MultipointHead with 
MultipointTail, e.g. when the given MultipointTail has bfd.SilentTail changed 
from 0 to 1 or vice versa. Would that trigger false negative on the head? I 
think that there's lots of open space ofr the innovation in the area of 
monitoring p2mp tails. I hope that someone will be interested to continue and 
produce more detailed specification than draft-ietf-bfd-multipoint-active-tail. 
For example, time interval between multicast Poll and relationship to unicast 
BFD control packets to tail(s).



Best regards,

Greg Mirsky



Sr. Standardization Expert
预研标准部/有线研究院/有线产品经营部 Standard Preresearch Dept./Wireline Product R 
Institute/Wireline Product Operation Division


[cid:9ae3e214c17d49ed935d87c674ba3ee2]

[cid:24242e5637af428891c4db731e7765ad]
E: gregory.mir...@ztetx.com<mailto:gregory.mir...@ztetx.com>
www.zte.com.cn<http://www.zte.com.cn/>

Re: WGLC for BFD Multipoint documents (last round)

[Reshad Rahman (rrahman)]

Hi Greg,

I would go with normative SHOULD. What you proposed below is fine.

Regards,
Reshad.


From: "gregory.mir...@ztetx.com" <gregory.mir...@ztetx.com>
Date: Sunday, February 4, 2018 at 8:33 PM
To: "Reshad Rahman (rrahman)" <rrah...@cisco.com>, "rtg-bfd@ietf.org" 
<rtg-bfd@ietf.org>
Subject: Re: WGLC for BFD Multipoint documents (last round)


Hi Reshad,

you've said:

Hi Greg,



While OOB mechanism would improve security, my personal opinion is that we 
should try to improve security without requiring an OOB mechanism. I think we 
can add text to the security considerations to address the concerns below, e.g. 
A tail SHOULD prevent the number of MultipointTail sessions from exceeding the 
number of expected streams.  The concern expressed in b) cannot be fixed by 
what I proposed because of multiple streams.  So just preventing the number of 
MultipointTail sessions from exceeding the number of expected streams should be 
good enough.



Regards,

Reshad.



If we make it normative SHOULD, i.e. s/should/SHOULD/ in the third 
recommendation to the implementers:

 The implementation SHOULD have a reasonable upper bound on the

  number of MultipointTail sessions that can be created, with the

  upper bound potentially being computed based on the number of

  multicast streams that the system is expecting.



Or keep the lower case as it is consistent with the rest of the section, e.g. 
'a MultipointTail session should not be created'?



Kind regards,

Greg Mirsky



Sr. Standardization Expert
预研标准部/有线研究院/有线产品经营部 Standard Preresearch Dept./Wireline Product R 
Institute/Wireline Product Operation Division


[cid:9ae3e214c17d49ed935d87c674ba3ee2]

[cid:24242e5637af428891c4db731e7765ad]
E: gregory.mir...@ztetx.com<mailto:gregory.mir...@ztetx.com>
www.zte.com.cn<http://www.zte.com.cn/>

Re: WGLC for BFD Multipoint documents (last round)

[Reshad Rahman (rrahman)]

Hi Greg,

The question about whether we need a new variable wasn’t referring to 
MultipointClient state (I agree this is well explained). Since I mentioned 
“state variable” I realize the confusion…

The question was whether we need a new state variable (not for the 
MultipointClient state) to control the behavior explained in this paragraph, 
e.g the new state variable could be called bfd.TrackTails.

   If the head wishes to know the identity of the tails, it sends
   multipoint Polls as needed.  Previously known tails that don't
   respond to the Polls will be detected.

Regards,
Reshad.

On 2018-01-31, 8:41 PM, "Greg Mirsky" <gregimir...@gmail.com> wrote:

Hi Reshad,
thank you for your expedient response to the proposed update. I'll
mark the draft as potentially updating RFCs 5880 and 7880. I'm glad
that you consider acceptable almost all proposed changes. I think that
the one open questions is:
- 3.4. 3rd paragraph : add reference to section 5.3? Also do we need a
state variable which controls this behaviour (discovering tails)?
GIM>> In the reverse order.
Then the variable be per tail? What if number of tails is unknown to
the head? I'd rather not define that in the base specification.
 No, the variable would be on the head for all tails.
Let me try to construct already defined variables:
- section New State Variable Value has defined MultipointClient as the
new state of bfd.SessionType:
MultipointClient:  A session on the head that tracks the state of an
individual tail, when desirable.
That is how MultipointClient use explained in section Multipoint
Client Session. I think that the text in the remainder of the
Controlling Multipoint BFD Options does provide reasonable explanation
of use of MultipointClient state. What do you think?

Regards,
Greg

On Wed, Jan 31, 2018 at 4:51 PM, Reshad Rahman (rrahman)
<rrah...@cisco.com> wrote:
> Hi Greg,
>
> Please see inline .
>
> Regards,
> Reshad.
>
>
> On 2018-01-30, 10:47 PM, "Greg Mirsky" <gregimir...@gmail.com> wrote:
>
> Hi Reshad,
> thank you for your detailed review of
> draft-ietf-bfd-multipoint-active-tail and comments. I have copied
> parts of the review an i-lined my answers and notes tagged GIM>>.
> I've attached the diff to highlight the update and the new working
> version of the draft. Greatly appreciate your help.
>
> Regards,
> Greg
>
> :(16) Will publication of this document change the status of any
> : existing RFCs? Are those RFCs listed on the title page header, 
listed
> : in the abstract, and discussed in the introduction? If the RFCs are 
not
> : listed in the Abstract and Introduction, explain why, and point to 
the
> : part of the document where the relationship of this document to the
> : other RFCs is discussed. If this information is not in the document,
> : explain why the WG considers it unnecessary.
> This document will update RFCs 5880 and 7880. They are not in the
> title page header.
> GIM>>  This draft is Informational while RFCs 5880 and 7880 are
> Standard track. Would an Informational track document be updating
> Standard? Please confirm.
>  This draft was experimental at a certain point but got changed to 
Standards Track because AFAIR of a normative reference from the TRILL P2MP BFD.
>
> - General. There are a few instances where singular is used instead of
> plural (e.g. for session, tail) and also where “a” or “the” is
> missing. I have tried to indicate all such occurrences below.
> - General. A few sentences have the period ‘.’ before the closing
> parenthesis instead of after, e.g. in Introduction “path as is
> feasible.)”. I have not called out all of them, search for “.)”
> GIM>> I think I've hunted down them all down.
>
> - 1 Introduction. s/which allows tail/which allows tails/
> - 1 Introduction. Clarifications/explanations are desirable on “it is
> preferable if unicast paths share as little fate with the multipoint
> path as is feasible.)”
> GIM>> Please consider the following text update:
> OLD TEXT
> and in fact it is preferable if unicast paths share as little fate
> with the multipoint path as is feasible
> NEW TEXT
> and in fact it is preferable if unicast paths share as little fate
> with the multipoint path as is feasible, so to increase probability of
> delivering the notif

Re: WGLC for BFD Multipoint documents (last round)

[Reshad Rahman (rrahman)]

Hi Greg,

While OOB mechanism would improve security, my personal opinion is that we 
should try to improve security without requiring an OOB mechanism. I think we 
can add text to the security considerations to address the concerns below, e.g. 
A tail SHOULD prevent the number of MultipointTail sessions from exceeding the 
number of expected streams.  The concern expressed in b) cannot be fixed by 
what I proposed because of multiple streams.  So just preventing the number of 
MultipointTail sessions from exceeding the number of expected streams should be 
good enough.

Regards,
Reshad.

From: Rtg-bfd <rtg-bfd-boun...@ietf.org> on behalf of Greg Mirsky 
<gregimir...@gmail.com>
Date: Thursday, February 1, 2018 at 10:23 PM
To: "Reshad Rahman (rrahman)" <rrah...@cisco.com>
Cc: "Carlos Pignataro (cpignata)" <cpign...@cisco.com>, "rtg-bfd@ietf.org" 
<rtg-bfd@ietf.org>
Subject: Re: WGLC for BFD Multipoint documents (last round)

Hi Reshad,
thank you for your patience and support.
To address your questions a) and b) we may recommend that an implementation 
creates MultipointTail session only if provisioned with My Discriminator value 
for the given pair of MultipointHead and multicast tree via out-of-band control 
or management plane. Discussion of exact mechanisms is outside the scope of 
this document. And then the text will continue to discuss measures for 
implementations that create MultipointTail session dynamically for any known 
combination of head and multicast tree that has Multipoint BFD enabled.

Regards,
Greg


On Wed, Jan 31, 2018 at 6:44 AM, Reshad Rahman (rrahman) 
<rrah...@cisco.com<mailto:rrah...@cisco.com>> wrote:
Hi Greg,

Thanks for addressing the changes so promptly. I’d like to hear from the WG on 
the 2 security concerns below, i.e. whether they need to be addressed and if 
yes, then how. I believe if we address a) below we also address b)?

Regards,
Reshad.

: a) We should have the ability, e.g. via configuration, to prevent the number
: of MultipointTail sessions from exceeding the number of expected streams.
: Otherwise 1 misbehaving head could use up all the MultipointTail session
: resources on a tail.
: b) A misbehaving head which changes My Discriminator for a MultipointHead
: session will cause tails to create many MultipointTail sessions (4.13.2). We
: should consider adding a check to see if we have a MultipointTail session
: based on source address and the identify of the of the multipoint tree with a
: different discriminator?

7.  Security Considerations

   The same security considerations as those described in [RFC5880]
   apply to this document.  Additionally, implementations that create
   MultpointTail sessions dynamically upon receipt of Multipoint BFD
   Control packets MUST implement protective measures to prevent
   infinite number of MultipointTail sessions being created.  Below are
   listed some points to be considered in such implementations.

  If a Multipoint BFD Control packet did not arrive on a multicast
  tree (e.g. on expected interface, with expected MPLS label, etc),
  then a MultipointTail session should not be created.

  If redundant streams are expected for a given multicast stream,
  then the implementations should not create more MultipointTail
  sessions than the number of streams.  Additionally, when the
  number of MultipointTail sessions exceeds the number of expected
  streams, then the implementation should generate an alarm to users
  to indicate the anomaly.



Katz, et al. Expires August 3, 2018[Page 16]


Internet-Draft BFD for Multipoint Networks  January 2018


  The implementation should have a reasonable upper bound on the
  number of MultipointTail sessions that can be created, with the
  upper bound potentially being computed based on the number of
  multicast streams that the system is expecting.

On 2018-01-30, 10:23 PM, "Greg Mirsky" 
<gregimir...@gmail.com<mailto:gregimir...@gmail.com>> wrote:

Hi Reshad, et.al<http://et.al>,
I've uploaded the new version of the draft:

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 for Multipoint Networks
Authors : Dave Katz
  Dave Ward
  Santosh Pallagatti
  Greg Mirsky
Filename: draft-ietf-bfd-multipoint-13.txt
Pages   : 18
Date: 2018-01-30

Abstract:
   This document describes extensions to the Bidirectional Forwarding
   Detection (BFD) protocol for its use in multipoint and multicast
   networks.



The IETF datatracker status page fo

Re: Secdir last call review of draft-ietf-bfd-yang-09

[Reshad Rahman (rrahman)]

Christian, thank you for the review.

Regarding the concern expressed below, the alarm is issued at the other end via 
the Notifications (section 2.3).

Regards,
Reshad.


On 2018-02-01, 5:39 PM, "Christian Huitema"  wrote:

Reviewer: Christian Huitema
Review result: Has Nits

BFD, defined in RFC5880, is a protocol intended to detect faults in the
bidirectional path between two forwarding engines, including interfaces, 
data
link(s), and to the extent possible the forwarding engines themselves, with
potentially very low latency. The Yang module defined in this draft enables
management of this protocol, such as toggling parameters or receiving
notifications.

As stated in the security section, the module is "to be accessed via the
NETCONF protocol [RFC6241]", and as such its security is pretty much tied to
that of NETCONF.

My only nit comes from reading section 6.8.16 of RFC 5880, about
"Administrative Control". This points to an obvious issue when the
administrator of a router disables BFD on a particular link, either by 
mistake
or by malice. This will make future failures harder to notify, and can 
affect
operation of the network. Nothing much can be done about that on the node
itself, but I would expect that disabling BFD would raise some kind of 
alarm at
the other end of the link. I did not understand how that alarm is described 
in
the Yang module, but that may be because I am not all that familiar with 
Yang.

Re: WGLC for BFD Multipoint documents (last round)

[Reshad Rahman (rrahman)]

rs in “new variables” section.
- 3.3.1 New State Variables. The paragraph on bfd.ReportTailDown says
“If 0, the tail..”. Mention that the packets sent from the tail are in
response to the head’s periodic BFD control packets? Also when set to
1, how do the tails know from the head that they need to notify the
head? This paragraph needs some clarification.
3.3.2 State Variable Initialization and Maintenance. s/section 6.8.1
of the [RFC5880] needs/section 6.8.1 of [RFC5880] need/
- 3.4 Controlling Multipoint BFD Options. 2nd paragraph: add reference
to section 5.1?
GIM>> Agree
- 3.4. 3rd paragraph : add reference to section 5.3? Also do we need a
state variable which controls this behaviour (discovering tails)?
GIM>> In the reverse order.
Then the variable be per tail? What if number of tails is unknown to
the head? I'd rather not define that in the base specification.
 No, the variable would be on the head for all tails. 

Reference added.
- 3.4. Paragraph 5 should be after paragraph 3?
GIM>> I agree, makes the narrative more logical.
- 3.4. Paragraph 6, regarding “initial delay”, add a reference to
3.13.3 which describes the delay.
- 3.5 State Machine. s/State machine for/The state machine for/
GIM>> Done and done
- 3.8 Soliciting the Tails. “random delay”, add a reference to 3.13.3
which describes the delay.
- 3.13. “in the base specification” refers to base BFD or base BFD
multipoint? Add a reference.
GIM>> In fact it is both. Added references accordingly.
- 3.13.1. Should reception at head also be covered here? If not, add
“at tail” to the title
GIM>> You're right, the changes update processing at MultipointTail
but the base specification does not differentiate processing of the
received BFD control packet based on the bfd.SessionType. I propose to
have the text without update.
- 3.13.1. s/by head below procedure MUST be/by the head, the procedure
below MUST be/
GIM>> Agree. I think more changes can benefit the text:
OLD TEXT
In addition to that if tail tracking is desired by head below
procedure MUST be applied.
NEW TEXT
In addition to that, if tail tracking is desired by head, below
procedure MUST be applied.
Would you agree?
 Ack.

- 3.13.1 and 3.13.2. Both are adding to the procedures in
draft-ietf-bfd-multipoint, specify where the addition is taking place
(e.g. at the end).
GIM>>
- 7 Security Considerations. Should we add at the beginning “The same
security considerations as those described in [RFC5880] and
[I-D.ietf-bfd-multipoint] apply to this document.”?
GIM>> Agree.

On Wed, Jan 24, 2018 at 2:42 PM, Reshad Rahman (rrahman)
<rrah...@cisco.com> wrote:
> Hi,
>
>
>
> I forgot to mention that last week I did the shepherd write-up for both
> drafts.
>
>
>
> 
https://datatracker.ietf.org/doc/draft-ietf-bfd-multipoint/shepherdwriteup/
>
> 
https://datatracker.ietf.org/doc/draft-ietf-bfd-multipoint-active-tail/shepherdwriteup/
>
>
>
> Regards,
>
> Reshad.
>
>
>
> From: Greg Mirsky <gregimir...@gmail.com>
> Date: Tuesday, January 16, 2018 at 11:01 PM
>
>
> To: "Reshad Rahman (rrahman)" <rrah...@cisco.com>
> Cc: "Carlos Pignataro (cpignata)" <cpign...@cisco.com>, Jeffrey Haas
> <jh...@pfrc.org>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
> Subject: Re: WGLC for BFD Multipoint documents (last round)
>
>
>
> Hi Reshad,
>
> sorry for my sloppiness. Fixed.
>
>
>
> Regards, Greg
>
>
>
> On Jan 16, 2018 7:05 PM, "Reshad Rahman (rrahman)" <rrah...@cisco.com>
> wrote:
>
> Hi Greg,
>
>
>
> In 4.4.1 of MP, “A number values of the state variable are added to the…”,
> looks like there is a missing “of”?
>
>
>
> For the active-tail draft I haven’t completed my review of -06 yet: there
> are parts which aren’t clear to me and I don’t know yet if this is because
> there’s something missing in the document or whether it’s just lack of
> understanding on my part.
>
>
>
> Regards,
>
> Reshad.
>
>
>
> From: Greg Mirsky <gregimir...@gmail.com>
> Date: Tuesday, January 16, 2018 at 9:25 PM
> To: "Reshad Rahman (rrahman)" <rrah...@cisco.com>
> Cc: "Carlos Pignataro (cpignata)" <cpign...@cisco.com>, Jeffrey Haas
> <jh...@pfrc.org>, "rtg-bfd@ietf.o

Re: WGLC for BFD Multipoint documents (last round)

[Reshad Rahman (rrahman)]

Hi Greg,

Thanks for addressing the changes so promptly. I’d like to hear from the WG on 
the 2 security concerns below, i.e. whether they need to be addressed and if 
yes, then how. I believe if we address a) below we also address b)?

Regards,
Reshad.

: a) We should have the ability, e.g. via configuration, to prevent the number
: of MultipointTail sessions from exceeding the number of expected streams.
: Otherwise 1 misbehaving head could use up all the MultipointTail session
: resources on a tail.
: b) A misbehaving head which changes My Discriminator for a MultipointHead
: session will cause tails to create many MultipointTail sessions (4.13.2). We
: should consider adding a check to see if we have a MultipointTail session
: based on source address and the identify of the of the multipoint tree with a
: different discriminator?

7.  Security Considerations

   The same security considerations as those described in [RFC5880]
   apply to this document.  Additionally, implementations that create
   MultpointTail sessions dynamically upon receipt of Multipoint BFD
   Control packets MUST implement protective measures to prevent
   infinite number of MultipointTail sessions being created.  Below are
   listed some points to be considered in such implementations.

  If a Multipoint BFD Control packet did not arrive on a multicast
  tree (e.g. on expected interface, with expected MPLS label, etc),
  then a MultipointTail session should not be created.

  If redundant streams are expected for a given multicast stream,
  then the implementations should not create more MultipointTail
  sessions than the number of streams.  Additionally, when the
  number of MultipointTail sessions exceeds the number of expected
  streams, then the implementation should generate an alarm to users
  to indicate the anomaly.



Katz, et al. Expires August 3, 2018[Page 16]


Internet-Draft BFD for Multipoint Networks  January 2018


  The implementation should have a reasonable upper bound on the
  number of MultipointTail sessions that can be created, with the
  upper bound potentially being computed based on the number of
  multicast streams that the system is expecting.

On 2018-01-30, 10:23 PM, "Greg Mirsky" <gregimir...@gmail.com> wrote:

Hi Reshad, et.al,
I've uploaded the new version of the draft:

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 for Multipoint Networks
Authors : Dave Katz
  Dave Ward
  Santosh Pallagatti
  Greg Mirsky
Filename: draft-ietf-bfd-multipoint-13.txt
Pages   : 18
Date: 2018-01-30

Abstract:
   This document describes extensions to the Bidirectional Forwarding
   Detection (BFD) protocol for its use in multipoint and multicast
   networks.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-bfd-multipoint/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-bfd-multipoint-13
https://datatracker.ietf.org/doc/html/draft-ietf-bfd-multipoint-13

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-multipoint-13

Will respond to your comments on the Active Tails shortly.

Regards,
Greg


On Mon, Jan 29, 2018 at 11:47 AM, Reshad Rahman (rrahman)
<rrah...@cisco.com> wrote:
> Greg, these changes are good with me.
>
>
>
> Regards,
>
> Reshad.
>
>
>
> From: Greg Mirsky <gregimir...@gmail.com>
> Date: Monday, January 29, 2018 at 1:04 PM
> To: "Reshad Rahman (rrahman)" <rrah...@cisco.com>
> Cc: "Carlos Pignataro (cpignata)" <cpign...@cisco.com>, Jeffrey Haas
> <jh...@pfrc.org>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
> Subject: Re: WGLC for BFD Multipoint documents (last round)
>
>
>
> Hi Reshad,
>
> nits fixed and the new text below:
>
> OLD TEXT
>
> A number of values of the state variable are added to the base BFD…
>
> NEW TEXT
>
> A number of new values of the state variable bfd.SessionType are added to
    > the base BFD…
>
> Would you accept this update?
>
>
>
> Regards,
>
> Greg
>
>
>
> On Mon, Jan 29, 2018 at 5:52 AM, Reshad Rahman (rrahman) 
<rrah...@cisco.com>

Re: WGLC for BFD Multipoint documents (last round)

[Reshad Rahman (rrahman)]

Thanks Greg. PSI .

I think we’ve closed on these comments.

Regards,
Reshad.

From: Greg Mirsky <gregimir...@gmail.com>
Date: Friday, January 26, 2018 at 7:42 PM
To: "Reshad Rahman (rrahman)" <rrah...@cisco.com>
Cc: "Carlos Pignataro (cpignata)" <cpign...@cisco.com>, Jeffrey Haas 
<jh...@pfrc.org>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
Subject: Re: WGLC for BFD Multipoint documents (last round)

Hi Reshad, et. al,
thank you for your kind consideration of the update. I'm applied all the 
changes you've agreed to. Remaining are few nits I wanted to confirm with you 
and one update that is not editorial:
In 
4.13.1<https://tools.ietf.org/html/draft-ietf-bfd-multipoint-12#section-4.13.1>.
 Reception of BFD Control Packets
OLD TEXT:
Else (bfd.SessionType is not PointToPoint)
NEW TEXT
Else (bfd.SessionType is MultipointTail)
Please find my notes in-line tagged GIM2>>.

Kind regards,
Greg

On Fri, Jan 26, 2018 at 7:14 AM, Reshad Rahman (rrahman) 
<rrah...@cisco.com<mailto:rrah...@cisco.com>> wrote:
Hi Greg,

Thank you for the prompt response. The changes look good. Some nits I may 
missed during my review and nits on new rev:

  *   3 Overview. s/Details of how head keeps track/Details of how heads keep 
track/ (or if singular “of how a head keeps track”)
GIM2>> I think that singular is consistent with the preceding sentence 'A head 
may wish to be alerted to the tails' connectivity (or lack thereof).' And 
because there's 'a head' should the next reference be 'the head', thus making 
'Details of how the head keeps track ...'?
 Good.

  *
  *   4.2 Session Model. References to Section 4.4.1 were added but consider 
making a change e.g adding () around the reference or “, as defined in Section 
4.4.1, “ .
GIM2>> Done

  *
  *   4.4.1 New State Variable Values. First paragraph starts “A number values 
of the state variable are added to the base BFD…”. Should be “A number of 
values…”? Or reword that paragraph to something along the lines of “A number of 
values are added to some existing state variables defined in the base BFD…”
GIM2>> Used the former 'A number of values ...'
 Ack.

  *
  *   4.10 Timer Manipulation. s/However to indicate a change in the packets 
MultipointHead session MUST send packets with P bit set.  MultipointTail 
session/However to indicate a change in the packets, MultipointHead sessions 
MUST send packets with the P bit set.  MultipointTail sessions/
GIM2>> Or should it be 'However, to indicate a change in the packets, 
MultipointHead MUST send packets with the P bit set.'?
 Good.

  *

Please see inline .

Regards,
Reshad.

From: Greg Mirsky <gregimir...@gmail.com<mailto:gregimir...@gmail.com>>
Date: Thursday, January 25, 2018 at 4:46 PM
To: "Reshad Rahman (rrahman)" <rrah...@cisco.com<mailto:rrah...@cisco.com>>
Cc: "Carlos Pignataro (cpignata)" 
<cpign...@cisco.com<mailto:cpign...@cisco.com>>, Jeffrey Haas 
<jh...@pfrc.org<mailto:jh...@pfrc.org>>, 
"rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>" 
<rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>>
Subject: Re: WGLC for BFD Multipoint documents (last round)

Hi Reshad,
sincere thank you for your help and support. In this note I'll address Shepherd 
Write-up on BFD for Multipoint Networks draft (active tails will be addressed 
in the separate response shortly). Please find my responses to your comments 
in-line tagged GIM>>. Attached are diffs to the updated version and the current 
working text.

: (16) Will publication of this document change the status of any
: existing RFCs? Are those RFCs listed on the title page header, listed
: in the abstract, and discussed in the introduction? If the RFCs are not
: listed in the Abstract and Introduction, explain why, and point to the
: part of the document where the relationship of this document to the
: other RFCs is discussed. If this information is not in the document,
: explain why the WG considers it unnecessary.
This document will update RFCs 5880 and 7880. They are not in the title page 
header.
GIM>> Fixed.

- General. There are a few instances where singular is used instead of plural 
(e.g. for session, packet) and also where “a” or “the” is missing. I have tried 
to indicate all such occurrences below.
- General. A few sentences have the period ‘.’ before the closing parenthesis 
instead of after, e.g.  in 4.9 “(… than it did previously.)”. I have not called 
out all of them, search for “.)”
GIM>> Got 10+ of those

- General. s/this protocol/Multipoint BFD/?
GIM>>
- General. Use of term tree e.g. multipoint tree. Should we use path instead?
- Abstract. Remove “Comments on this draft…”
GIM>> Done
- 1 Introduction. “Details of tail notification…”. Add reference to 
draft-ietf-bfd-multipoint-active-tail?
GIM>> Current text puts them outside the scope. I agree that 

Re: WGLC for BFD Multipoint documents (last round)

[Reshad Rahman (rrahman)]

Hi Greg,

The proposal below addresses some of the concerns. But I would also like to see 
some wording/procedure to protect the tail in the 2 cases mentioned.

Regards,
Reshad.

From: Greg Mirsky <gregimir...@gmail.com>
Date: Thursday, January 25, 2018 at 6:06 PM
To: Jeffrey Haas <jh...@pfrc.org>
Cc: "Reshad Rahman (rrahman)" <rrah...@cisco.com>, "Carlos Pignataro 
(cpignata)" <cpign...@cisco.com>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
Subject: Re: WGLC for BFD Multipoint documents (last round)

Hi Jeff, Reshad, et. al,
I agree that the Security Considerations section will benefit from clearer 
description of the need to limit resources that may be allocated for p2mp BFD 
sessions on MultipointTail nodes. Perhaps we can use wording close to Security 
Consideration section in RFC 7726:
   BFD sessions, naturally, use system
   and network resources.  More BFD sessions means more resources will
   be used.  It is highly important to ensure that only a minimum number
   of BFD sessions are provisioned per MultipointHead and that bootstrapped BFD
   sessions are properly deleted when they are no longer required.

Regards,
Greg

On Thu, Jan 25, 2018 at 7:28 AM, Jeffrey Haas 
<jh...@pfrc.org<mailto:jh...@pfrc.org>> wrote:
Thanks, Reshad.

Since the majority of the content is nits, Greg can simply address them as
Editor.

The Security Considerations issues raised in the base spec may deserve a bit
more explicit Working Group discussion:

: The shepherd has concerns wrt security:
: a) We should have the ability, e.g. via configuration, to prevent the number
: of MultipointTail sessions from exceeding the number of expected streams.
: Otherwise 1 misbehaving head could use up all the MultipointTail session
: resources on a tail.
: b) A misbehaving head which changes My Discriminator for a MultipointHead
: session will cause tails to create many MultipointTail sessions (4.13.2). We
: should consider adding a check to see if we have a MultipointTail session
: based on source address and the identify of the multipoint tree with a
: different discriminator?

-- Jef

On Wed, Jan 24, 2018 at 10:42:02PM +, Reshad Rahman (rrahman) wrote:
> Hi,
>
> I forgot to mention that last week I did the shepherd write-up for both 
> drafts.
>
> https://datatracker.ietf.org/doc/draft-ietf-bfd-multipoint/shepherdwriteup/
> https://datatracker.ietf.org/doc/draft-ietf-bfd-multipoint-active-tail/shepherdwriteup/
>
> Regards,
> Reshad.
>
> From: Greg Mirsky <gregimir...@gmail.com<mailto:gregimir...@gmail.com>>
> Date: Tuesday, January 16, 2018 at 11:01 PM
> To: "Reshad Rahman (rrahman)" <rrah...@cisco.com<mailto:rrah...@cisco.com>>
> Cc: "Carlos Pignataro (cpignata)" 
> <cpign...@cisco.com<mailto:cpign...@cisco.com>>, Jeffrey Haas 
> <jh...@pfrc.org<mailto:jh...@pfrc.org>>, 
> "rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>" 
> <rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>>
> Subject: Re: WGLC for BFD Multipoint documents (last round)
>
> Hi Reshad,
> sorry for my sloppiness. Fixed.
>
> Regards, Greg
>
> On Jan 16, 2018 7:05 PM, "Reshad Rahman (rrahman)" 
> <rrah...@cisco.com<mailto:rrah...@cisco.com><mailto:rrah...@cisco.com<mailto:rrah...@cisco.com>>>
>  wrote:
> Hi Greg,
>
> In 4.4.1 of MP, “A number values of the state variable are added to the…”, 
> looks like there is a missing “of”?
>
> For the active-tail draft I haven’t completed my review of -06 yet: there are 
> parts which aren’t clear to me and I don’t know yet if this is because 
> there’s something missing in the document or whether it’s just lack of 
> understanding on my part.
>
> Regards,
> Reshad.
>
> From: Greg Mirsky 
> <gregimir...@gmail.com<mailto:gregimir...@gmail.com><mailto:gregimir...@gmail.com<mailto:gregimir...@gmail.com>>>
> Date: Tuesday, January 16, 2018 at 9:25 PM
> To: "Reshad Rahman (rrahman)" 
> <rrah...@cisco.com<mailto:rrah...@cisco.com><mailto:rrah...@cisco.com<mailto:rrah...@cisco.com>>>
> Cc: "Carlos Pignataro (cpignata)" 
> <cpign...@cisco.com<mailto:cpign...@cisco.com><mailto:cpign...@cisco.com<mailto:cpign...@cisco.com>>>,
>  Jeffrey Haas 
> <jh...@pfrc.org<mailto:jh...@pfrc.org><mailto:jh...@pfrc.org<mailto:jh...@pfrc.org>>>,
>  
> "rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org><mailto:rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>>"
>  
> <rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org><mailto:rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>>>
> Subject: Re: WGLC for BFD Multipoint documents (last round)
>
> Hi Reshad, et. al,
> th

Re: WGLC for BFD Multipoint documents (last round)

[Reshad Rahman (rrahman)]

Hi Greg,

Thank you for the prompt response. The changes look good. Some nits I may 
missed during my review and nits on new rev:

  *   3 Overview. s/Details of how head keeps track/Details of how heads keep 
track/ (or if singular “of how a head keeps track”)
  *   4.2 Session Model. References to Section 4.4.1 were added but consider 
making a change e.g adding () around the reference or “, as defined in Section 
4.4.1, “ .
  *   4.4.1 New State Variable Values. First paragraph starts “A number values 
of the state variable are added to the base BFD…”. Should be “A number of 
values…”? Or reword that paragraph to something along the lines of “A number of 
values are added to some existing state variables defined in the base BFD…”
  *   4.10 Timer Manipulation. s/However to indicate a change in the packets 
MultipointHead session MUST send packets with P bit set.  MultipointTail 
session/However to indicate a change in the packets, MultipointHead sessions 
MUST send packets with the P bit set.  MultipointTail sessions/

Please see inline .

Regards,
Reshad.

From: Greg Mirsky <gregimir...@gmail.com>
Date: Thursday, January 25, 2018 at 4:46 PM
To: "Reshad Rahman (rrahman)" <rrah...@cisco.com>
Cc: "Carlos Pignataro (cpignata)" <cpign...@cisco.com>, Jeffrey Haas 
<jh...@pfrc.org>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
Subject: Re: WGLC for BFD Multipoint documents (last round)

Hi Reshad,
sincere thank you for your help and support. In this note I'll address Shepherd 
Write-up on BFD for Multipoint Networks draft (active tails will be addressed 
in the separate response shortly). Please find my responses to your comments 
in-line tagged GIM>>. Attached are diffs to the updated version and the current 
working text.

: (16) Will publication of this document change the status of any
: existing RFCs? Are those RFCs listed on the title page header, listed
: in the abstract, and discussed in the introduction? If the RFCs are not
: listed in the Abstract and Introduction, explain why, and point to the
: part of the document where the relationship of this document to the
: other RFCs is discussed. If this information is not in the document,
: explain why the WG considers it unnecessary.
This document will update RFCs 5880 and 7880. They are not in the title page 
header.
GIM>> Fixed.

- General. There are a few instances where singular is used instead of plural 
(e.g. for session, packet) and also where “a” or “the” is missing. I have tried 
to indicate all such occurrences below.
- General. A few sentences have the period ‘.’ before the closing parenthesis 
instead of after, e.g.  in 4.9 “(… than it did previously.)”. I have not called 
out all of them, search for “.)”
GIM>> Got 10+ of those

- General. s/this protocol/Multipoint BFD/?
GIM>>
- General. Use of term tree e.g. multipoint tree. Should we use path instead?
- Abstract. Remove “Comments on this draft…”
GIM>> Done
- 1 Introduction. “Details of tail notification…”. Add reference to 
draft-ietf-bfd-multipoint-active-tail?
GIM>> Current text puts them outside the scope. I agree that alternative may be 
to point to draft-ietf-bfd-multipoint-active-tail directly, though then we have 
new informational reference. Perhaps
OLD TEXT
Details of tail notification to head are outside the scope of this document.
NEW TEXT
Details of tail notification to head are outside the scope of this document and 
are discussed in [I_D.ietf-bfd-multipoint-active-tail].

Acceptable?
 Yes.

- 1 Introduction. s/is not being used in context/is not being used in the 
context/
GIM>> Done
- 1 Introduction. Add reference to [RFC5880] after “… and adds to the base BFD 
specification.”
GIM>> Done
- 1 Introduction. Remove “It is the intention of the authors to fold…”
GIM>> Done
- 2 Goals. Not sure about “multicast or multipoint medium”, maybe “multipoint 
or multicast path”?
GIM>> Would "Another goal is for the mechanism to work on any multipoint 
network segments or multicast technologies" work?
 I am fine with something along the lines of "Another goal is for the 
mechanism to work on any multicast technology."

- 2 Goals. “… multipoint paths with multiple heads” should that be 
“multipoint-to-multipoint”?
GIM>> Yes, indeed. Would referring to multipoint explicitly as 
point-to-multipoint make it more clear?
OLD TEXT
A further goal is to support multiple, overlapping multipoint paths, as well as 
multipoint paths with multiple heads...
NEW TEXT
A further goal is to support multiple, overlapping point-to-multipoint paths, 
as well as multipoint-to-multipoint paths  ...
 Yes.

- 2 Goals. Remove “A final goal is to integrate multipoint operation…”. If this 
is still relevant we need clarification on how this is being done. May need to 
also explain what is meant by “relatively easy”
GIM>> Agree and done.
- 2 Goals. s/any tails/any tail/
- 2

Re: WGLC for BFD Multipoint documents (last round)

[Reshad Rahman (rrahman)]

Hi,

I forgot to mention that last week I did the shepherd write-up for both drafts.

https://datatracker.ietf.org/doc/draft-ietf-bfd-multipoint/shepherdwriteup/
https://datatracker.ietf.org/doc/draft-ietf-bfd-multipoint-active-tail/shepherdwriteup/

Regards,
Reshad.

From: Greg Mirsky <gregimir...@gmail.com>
Date: Tuesday, January 16, 2018 at 11:01 PM
To: "Reshad Rahman (rrahman)" <rrah...@cisco.com>
Cc: "Carlos Pignataro (cpignata)" <cpign...@cisco.com>, Jeffrey Haas 
<jh...@pfrc.org>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
Subject: Re: WGLC for BFD Multipoint documents (last round)

Hi Reshad,
sorry for my sloppiness. Fixed.

Regards, Greg

On Jan 16, 2018 7:05 PM, "Reshad Rahman (rrahman)" 
<rrah...@cisco.com<mailto:rrah...@cisco.com>> wrote:
Hi Greg,

In 4.4.1 of MP, “A number values of the state variable are added to the…”, 
looks like there is a missing “of”?

For the active-tail draft I haven’t completed my review of -06 yet: there are 
parts which aren’t clear to me and I don’t know yet if this is because there’s 
something missing in the document or whether it’s just lack of understanding on 
my part.

Regards,
Reshad.

From: Greg Mirsky <gregimir...@gmail.com<mailto:gregimir...@gmail.com>>
Date: Tuesday, January 16, 2018 at 9:25 PM
To: "Reshad Rahman (rrahman)" <rrah...@cisco.com<mailto:rrah...@cisco.com>>
Cc: "Carlos Pignataro (cpignata)" 
<cpign...@cisco.com<mailto:cpign...@cisco.com>>, Jeffrey Haas 
<jh...@pfrc.org<mailto:jh...@pfrc.org>>, 
"rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>" 
<rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>>
Subject: Re: WGLC for BFD Multipoint documents (last round)

Hi Reshad, et. al,
the attached are diff to highlight updates to BFD in Multipoint Network and the 
working copy of Active Tails. After checking through the Active Tails draft, 
I've found no additional changes to make resulting from removing all references 
to bfd.SilentTail from BFD in Multipoint Networks draft. Your review and 
comments are most welcome.

Regards,
Greg

On Tue, Jan 16, 2018 at 2:51 PM, Greg Mirsky 
<gregimir...@gmail.com<mailto:gregimir...@gmail.com>> wrote:
Hi Reshad,
thank you. I'll add it into the working version to others updates. I believe 
changes to active tails be more extensive as now it must introduce the 
bfd.SilentTail variable, not just its new state. Will work on that now.

Regards,
Greg

On Tue, Jan 16, 2018 at 1:58 PM, Reshad Rahman (rrahman) 
<rrah...@cisco.com<mailto:rrah...@cisco.com>> wrote:
Hi Greg,

I am fine with the change below.

Regards,
Reshad.

From: Greg Mirsky <gregimir...@gmail.com<mailto:gregimir...@gmail.com>>
Date: Tuesday, January 16, 2018 at 2:20 PM
To: "Reshad Rahman (rrahman)" <rrah...@cisco.com<mailto:rrah...@cisco.com>>
Cc: "Carlos Pignataro (cpignata)" 
<cpign...@cisco.com<mailto:cpign...@cisco.com>>, Jeffrey Haas 
<jh...@pfrc.org<mailto:jh...@pfrc.org>>, 
"rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>" 
<rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>>

Subject: Re: WGLC for BFD Multipoint documents (last round)

Hi Reshad,
I think this is very good idea. Then in section 4.13.3 Transmitting BFD Packets 
of BFD for Multipoint Networks should be edited. Perhaps the following be 
acceptable:
OLD TEXT

   A system MUST NOT transmit any BFD Control packets if bfd.SilentTail

   is 1.
NEW TEXT

   A system MUST NOT transmit any BFD Control packets if bfd.SessionType is

   MultipointTail.

Will look into related changes in active tails if others agree with the 
proposal in general.



Regards,

Greg


On Tue, Jan 16, 2018 at 10:53 AM, Reshad Rahman (rrahman) 
<rrah...@cisco.com<mailto:rrah...@cisco.com>> wrote:
Regarding bfd.SilentTail, I am wondering if instead it should be removed from 
MP draft  (always 1 in there) and kept as new state variable in active-tail?

Regards,
Reshad.

From: "Reshad Rahman (rrahman)" <rrah...@cisco.com<mailto:rrah...@cisco.com>>
Date: Tuesday, January 16, 2018 at 9:32 AM
To: "Carlos Pignataro (cpignata)" 
<cpign...@cisco.com<mailto:cpign...@cisco.com>>, Greg Mirsky 
<gregimir...@gmail.com<mailto:gregimir...@gmail.com>>
Cc: Jeffrey Haas <jh...@pfrc.org<mailto:jh...@pfrc.org>>, 
"rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>" 
<rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>>

Subject: Re: WGLC for BFD Multipoint documents (last round)

Hi Greg,

The changes for bfd.SessionType (in both drafts) look good.

bfd.SilentTail is fine in multipoint but in active-tail it is in the New State 
Variables section.  It should be in 3.3.2 instead and there should be a 
reference to the multipoint draft.

Also, I am in the process of doing the shepherd write

Re: WGLC for BFD Multipoint documents (last round)

[Reshad Rahman (rrahman)]

Hi Greg,

In 4.4.1 of MP, “A number values of the state variable are added to the…”, 
looks like there is a missing “of”?

For the active-tail draft I haven’t completed my review of -06 yet: there are 
parts which aren’t clear to me and I don’t know yet if this is because there’s 
something missing in the document or whether it’s just lack of understanding on 
my part.

Regards,
Reshad.

From: Greg Mirsky <gregimir...@gmail.com>
Date: Tuesday, January 16, 2018 at 9:25 PM
To: "Reshad Rahman (rrahman)" <rrah...@cisco.com>
Cc: "Carlos Pignataro (cpignata)" <cpign...@cisco.com>, Jeffrey Haas 
<jh...@pfrc.org>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
Subject: Re: WGLC for BFD Multipoint documents (last round)

Hi Reshad, et. al,
the attached are diff to highlight updates to BFD in Multipoint Network and the 
working copy of Active Tails. After checking through the Active Tails draft, 
I've found no additional changes to make resulting from removing all references 
to bfd.SilentTail from BFD in Multipoint Networks draft. Your review and 
comments are most welcome.

Regards,
Greg

On Tue, Jan 16, 2018 at 2:51 PM, Greg Mirsky 
<gregimir...@gmail.com<mailto:gregimir...@gmail.com>> wrote:
Hi Reshad,
thank you. I'll add it into the working version to others updates. I believe 
changes to active tails be more extensive as now it must introduce the 
bfd.SilentTail variable, not just its new state. Will work on that now.

Regards,
Greg

On Tue, Jan 16, 2018 at 1:58 PM, Reshad Rahman (rrahman) 
<rrah...@cisco.com<mailto:rrah...@cisco.com>> wrote:
Hi Greg,

I am fine with the change below.

Regards,
Reshad.

From: Greg Mirsky <gregimir...@gmail.com<mailto:gregimir...@gmail.com>>
Date: Tuesday, January 16, 2018 at 2:20 PM
To: "Reshad Rahman (rrahman)" <rrah...@cisco.com<mailto:rrah...@cisco.com>>
Cc: "Carlos Pignataro (cpignata)" 
<cpign...@cisco.com<mailto:cpign...@cisco.com>>, Jeffrey Haas 
<jh...@pfrc.org<mailto:jh...@pfrc.org>>, 
"rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>" 
<rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>>

Subject: Re: WGLC for BFD Multipoint documents (last round)

Hi Reshad,
I think this is very good idea. Then in section 4.13.3 Transmitting BFD Packets 
of BFD for Multipoint Networks should be edited. Perhaps the following be 
acceptable:
OLD TEXT

   A system MUST NOT transmit any BFD Control packets if bfd.SilentTail

   is 1.
NEW TEXT

   A system MUST NOT transmit any BFD Control packets if bfd.SessionType is

   MultipointTail.

Will look into related changes in active tails if others agree with the 
proposal in general.



Regards,

Greg


On Tue, Jan 16, 2018 at 10:53 AM, Reshad Rahman (rrahman) 
<rrah...@cisco.com<mailto:rrah...@cisco.com>> wrote:
Regarding bfd.SilentTail, I am wondering if instead it should be removed from 
MP draft  (always 1 in there) and kept as new state variable in active-tail?

Regards,
Reshad.

From: "Reshad Rahman (rrahman)" <rrah...@cisco.com<mailto:rrah...@cisco.com>>
Date: Tuesday, January 16, 2018 at 9:32 AM
To: "Carlos Pignataro (cpignata)" 
<cpign...@cisco.com<mailto:cpign...@cisco.com>>, Greg Mirsky 
<gregimir...@gmail.com<mailto:gregimir...@gmail.com>>
Cc: Jeffrey Haas <jh...@pfrc.org<mailto:jh...@pfrc.org>>, 
"rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>" 
<rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>>

Subject: Re: WGLC for BFD Multipoint documents (last round)

Hi Greg,

The changes for bfd.SessionType (in both drafts) look good.

bfd.SilentTail is fine in multipoint but in active-tail it is in the New State 
Variables section.  It should be in 3.3.2 instead and there should be a 
reference to the multipoint draft.

Also, I am in the process of doing the shepherd write-up. So you don’t have to 
push these changes immediately, you can wait for the review, up to you.

Regards,
Reshad.

From: "Carlos Pignataro (cpignata)" 
<cpign...@cisco.com<mailto:cpign...@cisco.com>>
Date: Tuesday, January 16, 2018 at 1:47 AM
To: Greg Mirsky <gregimir...@gmail.com<mailto:gregimir...@gmail.com>>
Cc: "Reshad Rahman (rrahman)" <rrah...@cisco.com<mailto:rrah...@cisco.com>>, 
Jeffrey Haas <jh...@pfrc.org<mailto:jh...@pfrc.org>>, 
"rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>" 
<rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>>
Subject: Re: WGLC for BFD Multipoint documents (last round)

Looks good to me, Greg. Thanks.
Thumb typed by Carlos Pignataro.
Excuze typofraphicak errows

On Jan 16, 2018, at 15:32, Greg Mirsky 
<gregimir...@gmail.com<mailto:gregimir...@gmail.com>> wrote:
Hi Reshad and Carlos,
thank you for your suggestions. Please check the diffs with proposed changes to 
BFD Multipoint and BFD Mult

IPR poll for multipoint drafts

[Reshad Rahman (rrahman)]

All,

Are you aware of any IPR that applies to draft-ietf-bfd-multipoint and 
draft-ietf-bfd-multipoint-active-tail?

Specifically, if you are listed as a document author or contributor, please 
respond to this email (reply-to-all) stating whether or not you are aware of 
any relevant IPR.

If you are aware of a relevant IPR, please state whether this IPR been 
disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 
for more details).

This poll closes on the 30th of January 2018.

Regards,
Reshad.

Re: WGLC for BFD Multipoint documents (last round)

[Reshad Rahman (rrahman)]

Hi Greg,

I am fine with the change below.

Regards,
Reshad.

From: Greg Mirsky <gregimir...@gmail.com>
Date: Tuesday, January 16, 2018 at 2:20 PM
To: "Reshad Rahman (rrahman)" <rrah...@cisco.com>
Cc: "Carlos Pignataro (cpignata)" <cpign...@cisco.com>, Jeffrey Haas 
<jh...@pfrc.org>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
Subject: Re: WGLC for BFD Multipoint documents (last round)

Hi Reshad,
I think this is very good idea. Then in section 4.13.3 Transmitting BFD Packets 
of BFD for Multipoint Networks should be edited. Perhaps the following be 
acceptable:
OLD TEXT

   A system MUST NOT transmit any BFD Control packets if bfd.SilentTail

   is 1.
NEW TEXT

   A system MUST NOT transmit any BFD Control packets if bfd.SessionType is

   MultipointTail.

Will look into related changes in active tails if others agree with the 
proposal in general.



Regards,

Greg


On Tue, Jan 16, 2018 at 10:53 AM, Reshad Rahman (rrahman) 
<rrah...@cisco.com<mailto:rrah...@cisco.com>> wrote:
Regarding bfd.SilentTail, I am wondering if instead it should be removed from 
MP draft  (always 1 in there) and kept as new state variable in active-tail?

Regards,
Reshad.

From: "Reshad Rahman (rrahman)" <rrah...@cisco.com<mailto:rrah...@cisco.com>>
Date: Tuesday, January 16, 2018 at 9:32 AM
To: "Carlos Pignataro (cpignata)" 
<cpign...@cisco.com<mailto:cpign...@cisco.com>>, Greg Mirsky 
<gregimir...@gmail.com<mailto:gregimir...@gmail.com>>
Cc: Jeffrey Haas <jh...@pfrc.org<mailto:jh...@pfrc.org>>, 
"rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>" 
<rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>>

Subject: Re: WGLC for BFD Multipoint documents (last round)

Hi Greg,

The changes for bfd.SessionType (in both drafts) look good.

bfd.SilentTail is fine in multipoint but in active-tail it is in the New State 
Variables section.  It should be in 3.3.2 instead and there should be a 
reference to the multipoint draft.

Also, I am in the process of doing the shepherd write-up. So you don’t have to 
push these changes immediately, you can wait for the review, up to you.

Regards,
Reshad.

From: "Carlos Pignataro (cpignata)" 
<cpign...@cisco.com<mailto:cpign...@cisco.com>>
Date: Tuesday, January 16, 2018 at 1:47 AM
To: Greg Mirsky <gregimir...@gmail.com<mailto:gregimir...@gmail.com>>
Cc: "Reshad Rahman (rrahman)" <rrah...@cisco.com<mailto:rrah...@cisco.com>>, 
Jeffrey Haas <jh...@pfrc.org<mailto:jh...@pfrc.org>>, 
"rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>" 
<rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>>
Subject: Re: WGLC for BFD Multipoint documents (last round)

Looks good to me, Greg. Thanks.
Thumb typed by Carlos Pignataro.
Excuze typofraphicak errows

On Jan 16, 2018, at 15:32, Greg Mirsky 
<gregimir...@gmail.com<mailto:gregimir...@gmail.com>> wrote:
Hi Reshad and Carlos,
thank you for your suggestions. Please check the diffs with proposed changes to 
BFD Multipoint and BFD Multipoint with active tails drafts (attached).

Regards,
Greg

On Mon, Jan 15, 2018 at 8:25 PM, Carlos Pignataro (cpignata) 
<cpign...@cisco.com<mailto:cpign...@cisco.com>> wrote:
Reshad, Greg,

Indeed, it seems the content of the section is updated, but the title is 
misleading. The same applies to the active-tail doc:

https://tools.ietf.org/html/draft-ietf-bfd-multipoint-active-tail-06#section-3.3.1
https://tools.ietf.org/html/draft-ietf-bfd-multipoint-12#section-4.4.1

Thanks,

—
Carlos Pignataro, car...@cisco.com<mailto:car...@cisco.com>

“Sometimes I use big words that I do not fully understand, to make myself sound 
more photosynthesis."


On Jan 16, 2018, at 10:52 AM, Reshad Rahman (rrahman) 
<rrah...@cisco.com<mailto:rrah...@cisco.com>> wrote:

Hi Greg,

Section 4.4.1 still says “New state variables” for bfd.SessionType and the text 
still starts with “A number of state variables and their values are added…”, so 
I misinterpreted that as bfd.SessionType is being added as new state variable.

Please consider splitting this section in 2 parts for clarification e.g. 4.4.1 
for New State Variables (bfd.SilentTail) and 4.4.2 for New State Variable 
Values (bfd.SessionType).

https://tools.ietf.org/html/draft-ietf-bfd-multipoint-12#section-4.4.1

Regards,
Reshad.

From: Greg Mirsky <gregimir...@gmail.com<mailto:gregimir...@gmail.com>>
Date: Monday, January 15, 2018 at 6:17 PM
To: "Reshad Rahman (rrahman)" <rrah...@cisco.com<mailto:rrah...@cisco.com>>
Cc: Jeffrey Haas <jh...@pfrc.org<mailto:jh...@pfrc.org>>, "Carlos Pignataro 
(cpignata)" <cpign...@cisco.com<mailto:cpign...@cisco.com>>, 
"rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>" 
<rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>>
S

Re: WGLC for BFD Multipoint documents (last round)

[Reshad Rahman (rrahman)]

Regarding bfd.SilentTail, I am wondering if instead it should be removed from 
MP draft  (always 1 in there) and kept as new state variable in active-tail?

Regards,
Reshad.

From: "Reshad Rahman (rrahman)" <rrah...@cisco.com>
Date: Tuesday, January 16, 2018 at 9:32 AM
To: "Carlos Pignataro (cpignata)" <cpign...@cisco.com>, Greg Mirsky 
<gregimir...@gmail.com>
Cc: Jeffrey Haas <jh...@pfrc.org>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
Subject: Re: WGLC for BFD Multipoint documents (last round)

Hi Greg,

The changes for bfd.SessionType (in both drafts) look good.

bfd.SilentTail is fine in multipoint but in active-tail it is in the New State 
Variables section.  It should be in 3.3.2 instead and there should be a 
reference to the multipoint draft.

Also, I am in the process of doing the shepherd write-up. So you don’t have to 
push these changes immediately, you can wait for the review, up to you.

Regards,
Reshad.

From: "Carlos Pignataro (cpignata)" <cpign...@cisco.com>
Date: Tuesday, January 16, 2018 at 1:47 AM
To: Greg Mirsky <gregimir...@gmail.com>
Cc: "Reshad Rahman (rrahman)" <rrah...@cisco.com>, Jeffrey Haas 
<jh...@pfrc.org>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
Subject: Re: WGLC for BFD Multipoint documents (last round)

Looks good to me, Greg. Thanks.
Thumb typed by Carlos Pignataro.
Excuze typofraphicak errows

On Jan 16, 2018, at 15:32, Greg Mirsky 
<gregimir...@gmail.com<mailto:gregimir...@gmail.com>> wrote:
Hi Reshad and Carlos,
thank you for your suggestions. Please check the diffs with proposed changes to 
BFD Multipoint and BFD Multipoint with active tails drafts (attached).

Regards,
Greg

On Mon, Jan 15, 2018 at 8:25 PM, Carlos Pignataro (cpignata) 
<cpign...@cisco.com<mailto:cpign...@cisco.com>> wrote:
Reshad, Greg,

Indeed, it seems the content of the section is updated, but the title is 
misleading. The same applies to the active-tail doc:

https://tools.ietf.org/html/draft-ietf-bfd-multipoint-active-tail-06#section-3.3.1
https://tools.ietf.org/html/draft-ietf-bfd-multipoint-12#section-4.4.1

Thanks,

—
Carlos Pignataro, car...@cisco.com<mailto:car...@cisco.com>

“Sometimes I use big words that I do not fully understand, to make myself sound 
more photosynthesis."



On Jan 16, 2018, at 10:52 AM, Reshad Rahman (rrahman) 
<rrah...@cisco.com<mailto:rrah...@cisco.com>> wrote:

Hi Greg,

Section 4.4.1 still says “New state variables” for bfd.SessionType and the text 
still starts with “A number of state variables and their values are added…”, so 
I misinterpreted that as bfd.SessionType is being added as new state variable.

Please consider splitting this section in 2 parts for clarification e.g. 4.4.1 
for New State Variables (bfd.SilentTail) and 4.4.2 for New State Variable 
Values (bfd.SessionType).

https://tools.ietf.org/html/draft-ietf-bfd-multipoint-12#section-4.4.1

Regards,
Reshad.

From: Greg Mirsky <gregimir...@gmail.com<mailto:gregimir...@gmail.com>>
Date: Monday, January 15, 2018 at 6:17 PM
To: "Reshad Rahman (rrahman)" <rrah...@cisco.com<mailto:rrah...@cisco.com>>
Cc: Jeffrey Haas <jh...@pfrc.org<mailto:jh...@pfrc.org>>, "Carlos Pignataro 
(cpignata)" <cpign...@cisco.com<mailto:cpign...@cisco.com>>, 
"rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>" 
<rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>>
Subject: Re: WGLC for BFD Multipoint documents (last round)

Hi Reshad,
I thought I've addressed them as per Carlos suggestion. Have I missed anything?

Regards, Greg

On Jan 15, 2018 3:00 PM, "Reshad Rahman (rrahman)" 
<rrah...@cisco.com<mailto:rrah...@cisco.com>> wrote:
The changes for bfd.SessionType (it’s not a new state variable but uses what’s 
defined in RFC7880) weren’t made in the latest revision.

Greg, do you plan on addressing this soon? Or there’s no consensus on this 
topic yet?

Regards,
Reshad.

On 2017-12-20, 12:09 PM, "Rtg-bfd on behalf of Jeffrey Haas" 
<rtg-bfd-boun...@ietf.org<mailto:rtg-bfd-boun...@ietf.org> on behalf of 
jh...@pfrc.org<mailto:jh...@pfrc.org>> wrote:

Greg,

On Tue, Dec 19, 2017 at 02:17:02PM -0800, Greg Mirsky wrote:
> Hi Carlos and Jeff,
> thank you for responding so expediently. I think we've reached the rough
> consensus. Attached are the diffs for both BFD documents and the updated
> copies. Please let me know if the changes being made have addressed all 
the
> comments received during the WGLC. I'll then upload new versions.

I believe this covers all points I've seen on the mailing list to date.

Please push the updates.

We'll have further discussion about the need for a registry in conjunction
with the Yang module implications discussion.

-- Jeff

> On Tue, Dec 19,

Re: WGLC for BFD Multipoint documents (last round)

[Reshad Rahman (rrahman)]

Hi Greg,

The changes for bfd.SessionType (in both drafts) look good.

bfd.SilentTail is fine in multipoint but in active-tail it is in the New State 
Variables section.  It should be in 3.3.2 instead and there should be a 
reference to the multipoint draft.

Also, I am in the process of doing the shepherd write-up. So you don’t have to 
push these changes immediately, you can wait for the review, up to you.

Regards,
Reshad.

From: "Carlos Pignataro (cpignata)" <cpign...@cisco.com>
Date: Tuesday, January 16, 2018 at 1:47 AM
To: Greg Mirsky <gregimir...@gmail.com>
Cc: "Reshad Rahman (rrahman)" <rrah...@cisco.com>, Jeffrey Haas 
<jh...@pfrc.org>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
Subject: Re: WGLC for BFD Multipoint documents (last round)

Looks good to me, Greg. Thanks.
Thumb typed by Carlos Pignataro.
Excuze typofraphicak errows

On Jan 16, 2018, at 15:32, Greg Mirsky 
<gregimir...@gmail.com<mailto:gregimir...@gmail.com>> wrote:
Hi Reshad and Carlos,
thank you for your suggestions. Please check the diffs with proposed changes to 
BFD Multipoint and BFD Multipoint with active tails drafts (attached).

Regards,
Greg

On Mon, Jan 15, 2018 at 8:25 PM, Carlos Pignataro (cpignata) 
<cpign...@cisco.com<mailto:cpign...@cisco.com>> wrote:
Reshad, Greg,

Indeed, it seems the content of the section is updated, but the title is 
misleading. The same applies to the active-tail doc:

https://tools.ietf.org/html/draft-ietf-bfd-multipoint-active-tail-06#section-3.3.1
https://tools.ietf.org/html/draft-ietf-bfd-multipoint-12#section-4.4.1

Thanks,

—
Carlos Pignataro, car...@cisco.com<mailto:car...@cisco.com>

“Sometimes I use big words that I do not fully understand, to make myself sound 
more photosynthesis."


On Jan 16, 2018, at 10:52 AM, Reshad Rahman (rrahman) 
<rrah...@cisco.com<mailto:rrah...@cisco.com>> wrote:

Hi Greg,

Section 4.4.1 still says “New state variables” for bfd.SessionType and the text 
still starts with “A number of state variables and their values are added…”, so 
I misinterpreted that as bfd.SessionType is being added as new state variable.

Please consider splitting this section in 2 parts for clarification e.g. 4.4.1 
for New State Variables (bfd.SilentTail) and 4.4.2 for New State Variable 
Values (bfd.SessionType).

https://tools.ietf.org/html/draft-ietf-bfd-multipoint-12#section-4.4.1

Regards,
Reshad.

From: Greg Mirsky <gregimir...@gmail.com<mailto:gregimir...@gmail.com>>
Date: Monday, January 15, 2018 at 6:17 PM
To: "Reshad Rahman (rrahman)" <rrah...@cisco.com<mailto:rrah...@cisco.com>>
Cc: Jeffrey Haas <jh...@pfrc.org<mailto:jh...@pfrc.org>>, "Carlos Pignataro 
(cpignata)" <cpign...@cisco.com<mailto:cpign...@cisco.com>>, 
"rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>" 
<rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>>
Subject: Re: WGLC for BFD Multipoint documents (last round)

Hi Reshad,
I thought I've addressed them as per Carlos suggestion. Have I missed anything?

Regards, Greg

On Jan 15, 2018 3:00 PM, "Reshad Rahman (rrahman)" 
<rrah...@cisco.com<mailto:rrah...@cisco.com>> wrote:
The changes for bfd.SessionType (it’s not a new state variable but uses what’s 
defined in RFC7880) weren’t made in the latest revision.

Greg, do you plan on addressing this soon? Or there’s no consensus on this 
topic yet?

Regards,
Reshad.

On 2017-12-20, 12:09 PM, "Rtg-bfd on behalf of Jeffrey Haas" 
<rtg-bfd-boun...@ietf.org<mailto:rtg-bfd-boun...@ietf.org> on behalf of 
jh...@pfrc.org<mailto:jh...@pfrc.org>> wrote:

Greg,

On Tue, Dec 19, 2017 at 02:17:02PM -0800, Greg Mirsky wrote:
> Hi Carlos and Jeff,
> thank you for responding so expediently. I think we've reached the rough
> consensus. Attached are the diffs for both BFD documents and the updated
> copies. Please let me know if the changes being made have addressed all 
the
> comments received during the WGLC. I'll then upload new versions.

I believe this covers all points I've seen on the mailing list to date.

Please push the updates.

We'll have further discussion about the need for a registry in conjunction
with the Yang module implications discussion.

-- Jeff

> On Tue, Dec 19, 2017 at 8:05 AM, Jeffrey Haas 
<jh...@pfrc.org<mailto:jh...@pfrc.org>> wrote:
[...]
> > At this point it is also worth noting that the session type has no
> > centralized location covering their enumerations.  This leads to two
> > interesting observations:
> > - We could have an IANA registry for such things.  However, I'm not sure
> >   this is really need.  But this also means:
> > - Here's another case why some pieces of the BFD yang module likely 
shoudl
> >   be IANA maintained.  In this case, the bfd-path-type identity as the
> >   relevant example.

Re: WGLC for BFD Multipoint documents (last round)

[Reshad Rahman (rrahman)]

Hi Greg,

Section 4.4.1 still says “New state variables” for bfd.SessionType and the text 
still starts with “A number of state variables and their values are added…”, so 
I misinterpreted that as bfd.SessionType is being added as new state variable.

Please consider splitting this section in 2 parts for clarification e.g. 4.4.1 
for New State Variables (bfd.SilentTail) and 4.4.2 for New State Variable 
Values (bfd.SessionType).

https://tools.ietf.org/html/draft-ietf-bfd-multipoint-12#section-4.4.1

Regards,
Reshad.

From: Greg Mirsky <gregimir...@gmail.com>
Date: Monday, January 15, 2018 at 6:17 PM
To: "Reshad Rahman (rrahman)" <rrah...@cisco.com>
Cc: Jeffrey Haas <jh...@pfrc.org>, "Carlos Pignataro (cpignata)" 
<cpign...@cisco.com>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
Subject: Re: WGLC for BFD Multipoint documents (last round)

Hi Reshad,
I thought I've addressed them as per Carlos suggestion. Have I missed anything?

Regards, Greg

On Jan 15, 2018 3:00 PM, "Reshad Rahman (rrahman)" 
<rrah...@cisco.com<mailto:rrah...@cisco.com>> wrote:
The changes for bfd.SessionType (it’s not a new state variable but uses what’s 
defined in RFC7880) weren’t made in the latest revision.

Greg, do you plan on addressing this soon? Or there’s no consensus on this 
topic yet?

Regards,
Reshad.

On 2017-12-20, 12:09 PM, "Rtg-bfd on behalf of Jeffrey Haas" 
<rtg-bfd-boun...@ietf.org<mailto:rtg-bfd-boun...@ietf.org> on behalf of 
jh...@pfrc.org<mailto:jh...@pfrc.org>> wrote:

Greg,

On Tue, Dec 19, 2017 at 02:17:02PM -0800, Greg Mirsky wrote:
> Hi Carlos and Jeff,
> thank you for responding so expediently. I think we've reached the rough
> consensus. Attached are the diffs for both BFD documents and the updated
> copies. Please let me know if the changes being made have addressed all 
the
> comments received during the WGLC. I'll then upload new versions.

I believe this covers all points I've seen on the mailing list to date.

Please push the updates.

We'll have further discussion about the need for a registry in conjunction
with the Yang module implications discussion.

-- Jeff

> On Tue, Dec 19, 2017 at 8:05 AM, Jeffrey Haas 
<jh...@pfrc.org<mailto:jh...@pfrc.org>> wrote:
[...]
> > At this point it is also worth noting that the session type has no
> > centralized location covering their enumerations.  This leads to two
> > interesting observations:
> > - We could have an IANA registry for such things.  However, I'm not sure
> >   this is really need.  But this also means:
> > - Here's another case why some pieces of the BFD yang module likely 
shoudl
> >   be IANA maintained.  In this case, the bfd-path-type identity as the
> >   relevant example.

Re: WGLC for BFD Multipoint documents (last round)

[Reshad Rahman (rrahman)]

The changes for bfd.SessionType (it’s not a new state variable but uses what’s 
defined in RFC7880) weren’t made in the latest revision. 

Greg, do you plan on addressing this soon? Or there’s no consensus on this 
topic yet?

Regards,
Reshad.

On 2017-12-20, 12:09 PM, "Rtg-bfd on behalf of Jeffrey Haas" 
 wrote:

Greg,

On Tue, Dec 19, 2017 at 02:17:02PM -0800, Greg Mirsky wrote:
> Hi Carlos and Jeff,
> thank you for responding so expediently. I think we've reached the rough
> consensus. Attached are the diffs for both BFD documents and the updated
> copies. Please let me know if the changes being made have addressed all 
the
> comments received during the WGLC. I'll then upload new versions.

I believe this covers all points I've seen on the mailing list to date.

Please push the updates.

We'll have further discussion about the need for a registry in conjunction
with the Yang module implications discussion.

-- Jeff

> On Tue, Dec 19, 2017 at 8:05 AM, Jeffrey Haas  wrote:
[...]
> > At this point it is also worth noting that the session type has no
> > centralized location covering their enumerations.  This leads to two
> > interesting observations:
> > - We could have an IANA registry for such things.  However, I'm not sure
> >   this is really need.  But this also means:
> > - Here's another case why some pieces of the BFD yang module likely 
shoudl
> >   be IANA maintained.  In this case, the bfd-path-type identity as the
> >   relevant example.

Re: Last Call: (A YANG Data Model for Routing Information Protocol (RIP)) to Proposed Standard

[Reshad Rahman (rrahman)]

Hi Xufeng,

Changes below look good. 

As for changing 'enable' to 'enabled', I had checked what OSPF and ISIS were 
using and in both cases it is 'enable'. But yes I agree it should be consistent.

Regards,
Reshad.  

From: Xufeng Liu <xufeng_...@jabil.com>
Sent: Tuesday, December 5, 2017 11:31 AM
To: Reshad Rahman (rrahman); i...@ietf.org
Cc: draft-ietf-rtgwg-yang-...@ietf.org; rt...@ietf.org; rtgwg-cha...@ietf.org; 
rtg-bfd@ietf.org
Subject: RE: Last Call:  (A YANG Data Model 
for Routing Information Protocol (RIP)) to Proposed Standard

Hi Reshad,

Thanks for the review comment. Can you please check the following?
Regards,
- Xufeng

> -Original Message-
> From: Reshad Rahman (rrahman) [mailto:rrah...@cisco.com]
> Sent: Friday, December 1, 2017 5:05 PM
> To: Xufeng Liu <xufeng_...@jabil.com>; i...@ietf.org
> Cc: draft-ietf-rtgwg-yang-...@ietf.org; rt...@ietf.org; rtgwg-cha...@ietf.org;
> rtg-bfd@ietf.org
> Subject: Re: Last Call:  (A YANG Data Model
> for Routing Information Protocol (RIP)) to Proposed Standard
>
> Hi Xufeng,
>
> You are correct, I looked at the wrong version.
>
> If explicit-neighbors feature is not supported, would you want to have the BFD
> client parameters (client-cfg-parms) configured in RIP? Otherwise operator
> needs to look at neighbors discovered and configure parameters under BFD for
> that neighbor. And when a new neighbor shows up, the same thing has to be
> done again.

[Xufeng] Yes. It would be better to have such a capability. Now that a newer 
version of the BFD model (draft-ietf-bfd-yang-07) have been posted, it would be 
better to use the  new grouping "client-cfg-parms" and be consistent with other 
IGPs. Please review if the followings are the proper changes:

  module ietf-rip {
+ import ietf-bfd-types {
+  prefix "bfd-types";
+}

  container bfd {
if-feature bfd;
description "BFD configuration.";
-   leaf enabled {
- type boolean;
- default false;
- description
-   "'true' if BFD is enabled for the interface.";
-   }
+   uses bfd-types:client-cfg-parms;
  }

  }

   +--rw interfaces
   |  +--rw interface* [interface]
   | +--rw interface  if:interface-ref
   | +--rw bfd {bfd}?
-   | |  +--rw enabled?   boolean
+  | |  +--rw enable? boolean   
  <== From grouping client-cfg-parms
+  | |  +--rw local-multiplier?   multiplier
+  | |  +--rw (interval-config-type)?
+  | | +--:(tx-rx-intervals)
+  | | |  +--rw desired-min-tx-interval uint32
+  | | |  +--rw required-min-rx-intervaluint32
+  | | +--:(single-interval)
+  | |+--rw min-intervaluint32

[Xufeng] BTW. A comment about the leaf "enable" above: in most published 
models, "enabled" is used instead of "enable". Do you want to make it 
consistent?

>
> Please see email discussion with OSPF/ISIS YANG authors.
> https://mailarchive.ietf.org/arch/msg/rtg-bfd/KNipAESw8fGKuUKrCxFlhdkRA0Y
>
> Regards,
> Reshad.
>
> 
> From: Xufeng Liu <xufeng_...@jabil.com>
> Sent: Friday, December 1, 2017 4:50 PM
> To: Reshad Rahman (rrahman); i...@ietf.org
> Cc: draft-ietf-rtgwg-yang-...@ietf.org; rt...@ietf.org; rtgwg-cha...@ietf.org;
> rtg-bfd@ietf.org
> Subject: RE: Last Call:  (A YANG Data Model
> for Routing Information Protocol (RIP)) to Proposed Standard
>
> Hi Reshad,
>
> Can you please double-check the revision 06 of the document? draft-ietf-rtgwg-
> yang-rip-04 used bfd-grouping-base-cfg-parms, and was taken out by draft-ietf-
> rtgwg-yang-rip-05. Please let us know if this is not the case, or we need to 
> do
> something differently.
>
> Thanks,
> - Xufeng
>
> > -Original Message-
> > From: Reshad Rahman (rrahman) [mailto:rrah...@cisco.com]
> > Sent: Wednesday, November 29, 2017 11:49 AM
> > To: i...@ietf.org
> > Cc: draft-ietf-rtgwg-yang-...@ietf.org; rt...@ietf.org;
> > rtgwg-cha...@ietf.org; rtg-bfd@ietf.org
> > Subject: Re: Last Call:  (A YANG
> > Data Model for Routing Information Protocol (RIP)) to Proposed
> > Standard
> >
> > Hi,
> >
> > The RIP YANG model uses bfd-grouping-base-cfg-parms from BFD YANG.
> > That grouping does not exist in latest revision (it has been renamed).
> > Also, as per discussions we had with OSPF/ISIS YANG authors, the
> > grouping which should be used from BFD is client-cfg-parms.
> >
> > Regards,
> > Reshad.
> > ___

Re: Last Call: (A YANG Data Model for Routing Information Protocol (RIP)) to Proposed Standard

[Reshad Rahman (rrahman)]

Hi Xufeng,

You are correct, I looked at the wrong version.

If explicit-neighbors feature is not supported, would you want to have the BFD 
client parameters (client-cfg-parms) configured in RIP? Otherwise operator 
needs to look at neighbors discovered and configure parameters under BFD for 
that neighbor. And when a new neighbor shows up, the same thing has to be done 
again.

Please see email discussion with OSPF/ISIS YANG authors.
https://mailarchive.ietf.org/arch/msg/rtg-bfd/KNipAESw8fGKuUKrCxFlhdkRA0Y

Regards,
Reshad.


From: Xufeng Liu <xufeng_...@jabil.com>
Sent: Friday, December 1, 2017 4:50 PM
To: Reshad Rahman (rrahman); i...@ietf.org
Cc: draft-ietf-rtgwg-yang-...@ietf.org; rt...@ietf.org; rtgwg-cha...@ietf.org; 
rtg-bfd@ietf.org
Subject: RE: Last Call:  (A YANG Data Model 
for Routing Information Protocol (RIP)) to Proposed Standard

Hi Reshad,

Can you please double-check the revision 06 of the document? 
draft-ietf-rtgwg-yang-rip-04 used bfd-grouping-base-cfg-parms, and was taken 
out by draft-ietf-rtgwg-yang-rip-05. Please let us know if this is not the 
case, or we need to do something differently.

Thanks,
- Xufeng

> -Original Message-
> From: Reshad Rahman (rrahman) [mailto:rrah...@cisco.com]
> Sent: Wednesday, November 29, 2017 11:49 AM
> To: i...@ietf.org
> Cc: draft-ietf-rtgwg-yang-...@ietf.org; rt...@ietf.org; rtgwg-cha...@ietf.org;
> rtg-bfd@ietf.org
> Subject: Re: Last Call:  (A YANG Data Model
> for Routing Information Protocol (RIP)) to Proposed Standard
>
> Hi,
>
> The RIP YANG model uses bfd-grouping-base-cfg-parms from BFD YANG. That
> grouping does not exist in latest revision (it has been renamed). Also, as per
> discussions we had with OSPF/ISIS YANG authors, the grouping which should be
> used from BFD is client-cfg-parms.
>
> Regards,
> Reshad.
> 
> From: rtgwg <rtgwg-boun...@ietf.org> on behalf of The IESG  secret...@ietf.org>
> Sent: Tuesday, November 28, 2017 11:29 AM
> To: IETF-Announce
> Cc: draft-ietf-rtgwg-yang-...@ietf.org; rt...@ietf.org; rtgwg-cha...@ietf.org
> Subject: Last Call:  (A YANG Data Model for
> Routing Information Protocol (RIP)) to Proposed Standard
>
> The IESG has received a request from the Routing Area Working Group WG
> (rtgwg) to consider the following document: - 'A YANG Data Model for Routing
> Information Protocol (RIP)'
>as Proposed Standard
>
> The IESG plans to make a decision in the next few weeks, and solicits final
> comments on this action. Please send substantive comments to the
> i...@ietf.org mailing lists by 2017-12-12. Exceptionally, comments may be sent
> to i...@ietf.org instead. In either case, please retain the beginning of the
> Subject line to allow automated sorting.
>
> Abstract
>
>
>This document describes a data model for the Routing Information
>Protocol (RIP).  Both RIP version 2 and RIPng are covered.
>
>
>
>
> The file can be obtained via
> https://datatracker.ietf.org/doc/draft-ietf-rtgwg-yang-rip/
>
> IESG discussion can be tracked via
> https://datatracker.ietf.org/doc/draft-ietf-rtgwg-yang-rip/ballot/
>
>
> No IPR declarations have been submitted directly on this I-D.
>
>
> The document contains these normative downward references.
> See RFC 3967 for additional information:
> draft-bjorklund-netmod-rfc7223bis: A YANG Data Model for Interface
> Management (None - IETF stream)
> draft-ietf-netmod-revised-datastores: Network Management Datastore
> Architecture (None - IETF stream)
> draft-acee-netmod-rfc8022bis: A YANG Data Model for Routing Management
> (NDMA Version) (None - )
> draft-bjorklund-netmod-rfc7277bis: A YANG Data Model for IP Management
> (None - IETF stream)
> draft-ietf-ospf-yang: Yang Data Model for OSPF Protocol (None - IETF 
> stream)
>
>
>
> ___
> rtgwg mailing list
> rt...@ietf.org
> https://www.ietf.org/mailman/listinfo/rtgwg

Re: [Technical Errata Reported] RFC5884 (5085)

[Reshad Rahman (rrahman)]

Regarding Kireeti’s point below, I also think errata would be best. Jeff?
"As to how to implement these changes, I don’t personally care.  It seems 
heavyweight to issue a bis for this, rather than just errata, but I’m happy to 
leave that to the WG chairs to decide."


From: Greg Mirsky <gregimir...@gmail.com<mailto:gregimir...@gmail.com>>
Date: Wednesday, October 4, 2017 at 7:26 PM
To: "Les Ginsberg (ginsberg)" <ginsb...@cisco.com<mailto:ginsb...@cisco.com>>
Cc: Kireeti Kompella <kire...@juniper.net<mailto:kire...@juniper.net>>, Mach 
Chen <mach.c...@huawei.com<mailto:mach.c...@huawei.com>>, "Carlos Pignataro 
(cpignata)" <cpign...@cisco.com<mailto:cpign...@cisco.com>>, Tom Nadeau 
<tnad...@lucidvision.com<mailto:tnad...@lucidvision.com>>, 
"m...@ietf.org<mailto:m...@ietf.org>" <m...@ietf.org<mailto:m...@ietf.org>>, 
Alia Atlas <akat...@gmail.com<mailto:akat...@gmail.com>>, Reshad 
<rrah...@cisco.com<mailto:rrah...@cisco.com>>, 
"rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>" 
<rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>>
Subject: Re: [Technical Errata Reported] RFC5884 (5085)

Hi Kireeti, Les, et. al,
I agree and support the proposed changes, including the most recent proposed by 
Kireeti.
If errata report can be used to record the changes - absolutely great.
I hope that the errata report that triggered this discussion will be processed 
and marked accordingly.

Regards,
Greg

On Wed, Oct 4, 2017 at 12:47 PM, Les Ginsberg (ginsberg) 
<ginsb...@cisco.com<mailto:ginsb...@cisco.com>> wrote:
Kireeti –

The text I proposed below (3 paragraph’s worth) is intended to “replace current 
paragraphs 2 and 3 of Section 6”.

I am fine with changing

 “The egress LSR follows the procedures defined in [RFC 8029]…”

To

 “The egress LSR MUST follow the procedures defined in [RFC 8029]…”

Mach and Greg should speak for themselves – but I had the impression that Mach 
was agreeable – but Greg I am not so sure about.

   Les


From: Kireeti Kompella [mailto:kire...@juniper.net<mailto:kire...@juniper.net>]
Sent: Wednesday, October 04, 2017 12:06 PM
To: Les Ginsberg (ginsberg) <ginsb...@cisco.com<mailto:ginsb...@cisco.com>>; 
Mach Chen <mach.c...@huawei.com<mailto:mach.c...@huawei.com>>; Carlos Pignataro 
(cpignata) <cpign...@cisco.com<mailto:cpign...@cisco.com>>; Greg Mirsky 
<gregimir...@gmail.com<mailto:gregimir...@gmail.com>>
Cc: Tom Nadeau <tnad...@lucidvision.com<mailto:tnad...@lucidvision.com>>; 
m...@ietf.org<mailto:m...@ietf.org>; Alia Atlas 
<akat...@gmail.com<mailto:akat...@gmail.com>>; Reshad Rahman (rrahman) 
<rrah...@cisco.com<mailto:rrah...@cisco.com>>; rtg-bfd@ietf. org 
<rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>>; Kireeti Kompella 
<kire...@juniper.net<mailto:kire...@juniper.net>>
Subject: Re: [Technical Errata Reported] RFC5884 (5085)

Hi Les,

Just to be sure, you’re suggesting
a)   Change the sentence “The egress LSR MAY respond … BFD session.” to 
“The egress LSR follows the procedures … reply message.”  (or better yet, “The 
egress LSR MUST follow the procedures ….”)
b)  Move this sentence to after the BFD stuff.
c)   Remove the redundant comma (sigh!  Thought I knew commas.)

I am fine with all three suggestions.  I think that the main point (the source 
of interop issues) is (a); the other changes definitely improve readability, 
but are not showstoppers (imo).

I gather from Greg’s latest email (2017/09/08) and Mach’s email below that 
they’re both fine with these changes.  Greg, Mach: speak up if not.

As for “new interop issues”, the current situation is pretty bad, so let’s fix 
it.

As to how to implement these changes, I don’t personally care.  It seems 
heavyweight to issue a bis for this, rather than just errata, but I’m happy to 
leave that to the WG chairs to decide.

Kireeti.

From: "Les Ginsberg (ginsberg)" <ginsb...@cisco.com<mailto:ginsb...@cisco.com>>
Date: Tuesday, August 15, 2017 at 05:16
To: Mach Chen <mach.c...@huawei.com<mailto:mach.c...@huawei.com>>, "Carlos 
Pignataro (cpignata)" <cpign...@cisco.com<mailto:cpign...@cisco.com>>, Greg 
Mirsky <gregimir...@gmail.com<mailto:gregimir...@gmail.com>>
Cc: Tom Nadeau <tnad...@lucidvision.com<mailto:tnad...@lucidvision.com>>, 
"m...@ietf.org<mailto:m...@ietf.org>" <m...@ietf.org<mailto:m...@ietf.org>>, 
Kireeti Kompella <kire...@juniper.net<mailto:kire...@juniper.net>>, Alia Atlas 
<akat...@gmail.com<mailto:akat...@gmail.com>>, "Reshad Rahman (rrahman)" 
<rrah...@cisco.com<mailto:rrah...@cisco.com>>, "rtg-bfd@ietf. 
org<mailto:rtg-bfd@ietf.%20org>

Re: I-D Action: draft-ietf-bfd-yang-06.txt

[Reshad Rahman (rrahman)]

I am gradually catching up to emails so I may not have absorbed all the
emails I have gone through yetŠ.

Regarding echo config, we agreed in Chicago to remove the echo config
based on the fact that implementations of echo are vendor specific. e.g.
An implementation which has echo as continuous would likely have echo
configuration whereas an implementation which has echo as on-demand may
use RPC. There is an example of a vendor augmentation for echo config in
Appendix A.1.

Regards,
Reshad.



On 2017-08-01, 12:33 PM, "Jeffrey Haas"  wrote:

>On Tue, Aug 01, 2017 at 08:33:38AM -0700, Mahesh Jethanandani wrote:
>> > I'm ambivalent.  This depends really on real world behavior.
>> > 
>> > As we saw from some brief googling yesterday on Cisco IOS/IOS-XR
>>docs, that
>> > implementation doesn't appear to expose echo intervals as a separably
>> > configurable item.  It did, however, expose a boolean to disable echo.
>> 
>> True. But the standard seems to imply the ability to configure echo
>>values separately. Worst case implementations would have to set both the
>>values to be the same.
>
>The protocol does. But that doesn't mean the config model should.
>
>> > This minimally suggests that there should be a "use echo mode" flag.
>> 
>> Will add a boolean to enable/disable echo mode.
>
>I think that's a good start.
>
>> > The remaining homework is to figure out whether we should expose
>> > configuration state for echo directly in this version of the yang.
>> 
>> Per NMDA guidelines, unless the configuration state values are
>>different from config, we do not need to model them as separate
>>attributes.
>
>Right.  So, again need to check real world implementations.
>
>If it's the case that implementations supporting echo only use a single
>set
>of the intervals for echo or not, then we only need that in the model.
>
>If it becomes the case that an implementation supports echo intervals
>differently, a vendor *could* augment the model to support such values.
>However, since this is imported via grouping, it means that the
>augmentation
>has to be done in each module that uses the grouping.
>
>I hate yang grouping augmentation rules. :-P
>
>-- Jeff

Re: I-D Action: draft-ietf-bfd-yang-06.txt

[Reshad Rahman (rrahman)]

I am fine with this proposal. It will impact other groupings also.



On 2017-07-28, 5:25 PM, "Mahesh Jethanandani" <mjethanand...@gmail.com>
wrote:

>Would it not be better to call bfd-grouping-base-cfg-parms something like
>bfd-grouping-client-cfg-params or more simply client-cfg-params. We know
>it is a grouping and we know it is a bfd grouping. Why repeat?
>
>> On Jul 27, 2017, at 7:34 PM, Acee Lindem (acee) <a...@cisco.com> wrote:
>> 
>> Hi Reshad, 
>> 
>> Ok - I see now. I was looking at the wrong -base-cfg-parms
>>groupings.
>> Fewer similar grouping and modules will be better ;^)
>> 
>> Thanks,
>> Acee
>> 
>> On 7/27/17, 9:03 PM, "Reshad Rahman (rrahman)" <rrah...@cisco.com>
>>wrote:
>> 
>>> Hi Acee,
>>> 
>>> What I see @ 
>>> 
>>>https://github.com/jhaas-pfrc/ietf-bfd-yang/blob/master/src/yang/ietf-bf
>>>d-
>>> t
>>> ypes.yang:
>>> 1) bfd-client-base-cfg-parms has leaf enabled only. BTW this grouping
>>>is
>>> defined twice, this will be fixed when I get rid of
>>>ietf-bfd-clients.yang
>>> 2) bfd-grouping-base-cfg-parms has multiplier/timers.
>>> 
>>> Let me get rid of the client module and have everything in the types
>>> module.
>>> 
>>> I am not sure why you’re not seeing something different.
>>> 
>>> Regards,
>>> Reshad.
>>> 
>>> 
>>> 
>>> On 2017-07-27, 3:40 PM, "Acee Lindem (acee)" <a...@cisco.com> wrote:
>>> 
>>>> Hi Reshad, 
>>>> 
>>>> On 7/27/17, 3:35 PM, "Reshad Rahman (rrahman)" <rrah...@cisco.com>
>>>>wrote:
>>>> 
>>>>> Hi Acee,
>>>>> 
>>>>> 1) I’ll see if others chime in on this but I am fine with having the
>>>>> client grouping in ietf-bfd-types.yang.
>>>>> 2) bfd-grouping-common-cfg-parms has much more than just the
>>>>> multiplier/timers that the IGPs need. It also has BFD specific stuff
>>>>> (demand-mode, BFD auth) which IMO has no business outside of BFD.
>>>> 
>>>> Agreed. 
>>>> 
>>>> 
>>>>> bfd-grouping-base-cfg-parms has only the multiplier/timers.
>>>> 
>>>> Perhaps, the addition of multiplier/timers to
>>>>bfd-grouping-base-cfg-parms
>>>> isn’t pushed to GitHub yet. This version
>>>> 
>>>>https://github.com/jhaas-pfrc/ietf-bfd-yang/blob/master/src/yang/ietf-b
>>>>fd
>>>> -
>>>> t
>>>> ypes.yang only has the enabled leaf.
>>>> 
>>>> 
>>>> Thanks,
>>>> Acee 
>>>> 
>>>> 
>>>>> 
>>>>> Regards,
>>>>> Reshad.
>>>>> 
>>>>> 
>>>>> 
>>>>> On 2017-07-27, 3:30 PM, "Acee Lindem (acee)" <a...@cisco.com> wrote:
>>>>> 
>>>>>> Hi Reshad, 
>>>>>> 
>>>>>> On 7/27/17, 3:19 PM, "Reshad Rahman (rrahman)" <rrah...@cisco.com>
>>>>>> wrote:
>>>>>> 
>>>>>>> Hi Acee,
>>>>>>> 
>>>>>>> When we met we agreed to have a new model for clients. Afterwards I
>>>>>>> decided to create a new types module, and still went ahead with the
>>>>>>> clients module. I am fine with having everything in the types
>>>>>>>module
>>>>>>> (no
>>>>>>> client module).
>>>>>> 
>>>>>> Although I don’t feel that strongly - I just don’t see that putting
>>>>>>the
>>>>>> client config params in wrappers provides any benefit. As for
>>>>>> detriments,
>>>>>> it requires more one more local modules for validation and one more
>>>>>> level
>>>>>> of indirection to see what we are really allowing to be configured.
>>>>>> 
>>>>>>> 
>>>>>>> I am not sure I fully understand your comment/question on
>>>>>>> bfd-client-ext-cfg-parms/bfd-grouping-common-cfg-parms. The reason
>>>>>>>we
>>>>>>> have
>>>>>>> 2 groupings is that some protocols may decide to have just the
>>>>>>>enable
>>>>>>> leaf
>>&