Subject: RE: More questions on "draft-ietf-bfd-base-09.txt"

From: Linda Dunbar <[email-masked]>
Date: Wed, 07 Oct 2009 09:59:03 -0500

Dave, 

My email was bounced back by rtg-bfd alias due to the size being too large.
So I will send the PDF file marked with my comments directly to you.

Here are my questions and hope you can help. 

Thanks, Linda 

  _____  

From: Linda Dunbar [mailto:[email-masked]] 
Sent: Tuesday, October 06, 2009 6:06 PM
To: 'Dave Katz'; [email-masked]'
Subject: More questions on "draft-ietf-bfd-base-09.txt"

Hi Dave, 

Thank you very much for answering my questions last week. Now I do see
unique values of BFD, comparing to IEEE802.1ag. I was very actively involved
in IEEE802.1ag's development for a few years. BFD is simpler than
IEEE802.1ag and has some useful features, such as its Demand mode, which
IEEE802.1ag doesn't have. I think Demand Mode is very useful in reducing the
processing power imposed on systems. Here are some more questions. Hope you
can help me again. 

-          Section 3 Protocol Overview, 2nd paragraph: "A path is only
declared to be operational when two way communication has been established
."

My comment:  Under the context of MPLS, "a path", i.e. LSP, is always
uni-directional. So it is not correct to declare a path being operational
when two way communication is established. 

My suggestion: Should have an entity which binds two uni-directional paths
in the BFD context, or paired paths. Then you can easily say a path in the
pair (or in the entity) is declared operational when two way communication
is established. Even though the specification doesn't have to specify how
two paths are associated, it is worthwhile to have an entity to bind two
uni-directional paths together in the BFD document. The "My (Your)
Discriminator" in the BFD control packet should have "Entity identifier"
embedded in. 

-          I don't see ECHO reply packet from remote system defined anywhere
in the document. I would think that it is necessary to have an ECHO reply
message which includes the original ECHO packet plus some information from
the remote system. Why?

-          Section 6.8.5: Is the "Detecting Failures with Echo Function"
referring to the system who initiates "Echo"?  

The system which loops back Echo shouldn't have any failure related to Echo,
should it? 

-          The BFD Control Packet has "Required Min RX Interval" and
"Required Min Echo RX Interval". When "Required Min RX Interval" is set to
zero, can remote system still send Echo frame? If yes, then the description
for Required Min RX Interval should be more accurate. 

-          Questions on State Machine of BFD:

o       The second last paragraph of Section 6.2 indicates "Once a session
has been declared down, it cannot come back until remote end first signals
that it is down". What if the local system goes down by provisioning, and
decides to turn up. Why have to wait for the remote end to go down first? 

o       Why "Admin Down" is not on the state machine? 

o       When local system is Down state, why the BFD packet from remote
system with DOWN status transition the state machine from "DOWN" to "INIT"
state? I thought it should be INIT state from remote node to trigger the
local node to go to INIT state. 

-          Section 6.8.16: Why set SessionState to Down when Enabling a
session? Should it be "INIT"? 

-          In the Introduction and overview sections, the word "adjacent
systems/forwarding engines" is used frequently. For example, the first
sentence of the Introduction stated: the rapid detection of communication
failures between adjacent systems.

However, the sections in the latter part of the specification use "two
systems", or "pair of systems". 

My question: are they referring to the same thing? Does the "adjacent" in
the overview sections mean neighboring node as in OSPF's neighbors or two
systems on two ends of the path for BFD session? 

-          Section 2 Design, the first paragraph: 

What does it mean by saying "failure in communication with a forwarding
plane next hop"? Why next hop? The rest of the specification uses "two
systems", "remote system", etc, which I think is more accurate. 

In addition, all forwarding engines are unidirectional.  Who impose the
bi-directional property on forwarding engines? 

Do you mean BFD is to detect failures between two forwarding engines which
face (or peer with) each other for some applications?  

-          Section 4.1, under "Diagnostic (Diag)": 

3 -- Neighbor Signaled Session Down

Should "remote node (or system)" be more accurate description than the
"Neighbor"?

-          End of the first paragraph of Section 2, it stated that BFD
implemented in Control Plane may preclude the detection of some kinds of
failure. What kind of failures will be precluded? 

-          Section 3.1, last sentence of the first paragraph: you stated
that BFD can run between two OSPF neighbors. Why you need to run BFD between
two OSPF neighbors? If the two immediate neighbors need to discover
connectivity to each other faster, HELLO timer can be set shorter. 

I have some editorial comments marked on the enclosed PDF file. Please have
a look. 

Best Regards, Linda Dunbar

Advanced Technology Dept, Wireline Networks,

Huawei Technologies, Inc.

---

From: Vishwas Manral <[email-masked]>
Date: Wed, 7 Oct 2009 10:22:33 -0700

Hi Linda,

Good to see you have spent quite an effort preparing and doing such an
indepth review.

> in IEEE802.1ag’s development for a few years. BFD is simpler than
> IEEE802.1ag doesn’t have. I think Demand Mode is very useful in reducing the

Great to know you were so instrumental in 802.1ag. Yes BFD is a good
CC protocol. The base protocol however does not provide all the other
functionality like Locking etc. There are additional drafts under
consideration for each of the other functionalities extending BFD.

> -          Section 3 Protocol Overview, 2nd paragraph: “A path is only
> …”
> My comment:  Under the context of MPLS, “a path”, i.e. LSP, is always
For the BFD case if we only have unidirectional LSP's there has to be
an off path mechanism to transfer packets in the other direction,
otherwise BFD will not be able to operate over such a scenario.

> is established. Even though the specification doesn’t have to specify how
> uni-directional paths together in the BFD document. The “My (Your)
> Discriminator” in the BFD control packet should have “Entity identifier”
> embedded in.
To see how BFD works with MPLS LSP or over Pseudowire you can look at
http://tools.ietf.org/html/draft-ietf-pwe3-vccv-bfd-07
http://tools.ietf.org/html/draft-ietf-bfd-mpls-07

> -          I don’t see ECHO reply packet from remote system defined anywhere
The format of the echo packet is outside the scope of the spec. This
is because the echo packet is only processed and received only by the
sender. It is forwarded from the peers forwarding plane.

> -          Section 6.8.5: Is the “Detecting Failures with Echo Function”
> referring to the system who initiates “Echo”?
That is correct.

> The system which loops back Echo shouldn’t have any failure related to Echo,
> should it?
It would not know.

> -          The BFD Control Packet has “Required Min RX Interval” and
> “Required Min Echo RX Interval”. When “Required Min RX Interval” is set to
Yes. For echo's the "Required Min Echo RX Interval" is used instead.

> o       The second last paragraph of Section 6.2 indicates “Once a session
> that it is down”. What if the local system goes down by provisioning, and
The question is not clear.

> o       Why “Admin Down” is not on the state machine?
It could have been added to the diagram. though there is only one
transition out of it is the ADMIN UP state and to the down state.

> system with DOWN status transition the state machine from “DOWN” to “INIT”
INIT is there for the 3 way handshake. The idea of INIT is, I have
heard from you, but dont know if you have heard from me yet.

> session? Should it be “INIT”?
Refer above.

> -          In the Introduction and overview sections, the word “adjacent
> systems/forwarding engines” is used frequently. For example, the first
> However, the sections in the latter part of the specification use “two
> systems”, or “pair of systems”.
>
>
>
> My question: are they referring to the same thing? Does the “adjacent” in
> the overview sections mean neighboring node as in OSPF’s neighbors or two

It could be made consistent.

> plane next hop"? Why next hop? The rest of the specification uses “two
> systems”, “remote system”, etc, which I think is more accurate.
This could be clarified.

> bi-directional property on forwarding engines?
Can you clarify the question?

> face (or peer with) each other for some applications?
Same as above?

> failure. What kind of failures will be precluded?
This can be clarified for sure.

> connectivity to each other faster, HELLO timer can be set shorter.
This is something that goes back to the introduction. The idea is:

1. Lesser load.
2. Single faster detection mechanism for multiple protocols.

> Best Regards, Linda Dunbar
Thanks a lot for the really thorough review.
Vishwas

---

From: Linda Dunbar <[email-masked]>
Date: Wed, 07 Oct 2009 15:57:17 -0500

Vishwas, 

Thank you very much for the quick feedback. 

		> -          I don't see ECHO reply packet from remote
system defined 
		> anywhere in the document. I would think that it is
necessary to have 
		> an ECHO reply message which includes the original ECHO
packet plus 
		> some information from the remote system. Why?
		The format of the echo packet is outside the scope of the
spec. This is because the echo packet is only processed and received only by
the sender. It is forwarded from the peers forwarding plane.

[Linda] Do you mean the format of the ECHO reply message is out of the
scope? But you have to specify how remote system sends the received Echo
back to the sender, right? Otherwise how does the sender know a received
packet is really a reply message of an Echo message earlier? 

Linda

-----Original Message-----
From: Vishwas Manral [mailto:[email-masked]] 
Sent: Wednesday, October 07, 2009 12:23 PM
To: Linda Dunbar
Cc: Dave Katz; [email-masked]
Subject: Re: More questions on "draft-ietf-bfd-base-09.txt"

Hi Linda,

That is correct.

It would not know.

Refer above.

This could be clarified.

Same as above?

1. Lesser load.

---

From: Vishwas Manral <[email-masked]>
Date: Wed, 7 Oct 2009 14:05:05 -0700

Hi Linda,

>
> The format of the echo packet is outside the scope of the spec. This is
> because the echo packet is only processed and received only by the sender.
> It is forwarded from the peers forwarding plane.
>

The packet format for the echo packet is itself not specified. The
idea is that the echo packet itself is looped back by the forwarder
(there is only forwarding processing the receiver will not know it
received a BFD echo packet).

Thanks,
Vishwas

---

From: "Shahram Davari" <[email-masked]>
Date: Wed, 7 Oct 2009 14:54:57 -0700

Linda,

LSP-ping, ICMP-ping, etc. are examples of Echo packets.

Regards,
Shahram 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Vishwas Manral
Sent: Wednesday, October 07, 2009 2:05 PM
To: Linda Dunbar
Cc: [email-masked]; Dave Katz
Subject: Re: More questions on "draft-ietf-bfd-base-09.txt"

Hi Linda,

Thanks,
Vishwas