Transparent Interconnection of Lots of Links (TRILL): Bidirectional Forwarding Detection (BFD) Support
draft-ietf-trill-rbridge-bfd-07

[Ballot comment]
Thanks for working on the Discuss points and my Comments. The new revision has resolved most of them and I am downgrading the remaing two Discuss points to be Comments. I still hope they will be looked at, but I do not think they merit blocking the document.

---

In looking for a a reference to be added to draft-ietf-trill-rbridge-oam
(and/or to draft-ietf-trill-oam-req or draft-salam-trill-oam-framework)
I am seeking joined-up thinking about OAM within Trill such that the
reader can see that BFD is just part of the overall OAM solution and
can understand when other tools might be more appropriate.
Although the document is self-contained wrt motivation for BFD, it
does not present the necessary hooks for seeing the whole OAM
picture.

In general, one would expect the OAM requirements and framework
to be developed first, and solutions to follow. But I understand that
carts often get ahead of horses. Thus normative references might not
be an absolute requirement. But some form of reference is really
desirable.

---

> Finally, although I understand that the scope of this document is
> limited to encapsulation, I think that this leaves the solution
> deficient. It needs a description of bootstrapping in the Trill
> environment.

The authors proposed adding text to section 2.1 to say:

  For many applications, a means of triggering or bootstrapping the BFD
  session is required. This will be specified with the particular use of
  BFD over TRILL. For example, see draft-hpothetical-trill-rfc6327bis.

This would be good.

[Ballot discuss]
I've updated my Discuss to take into account some email exchanges with the authors. The net effect is to move points 1 and 2 of the Discuss to a Comment with a suggested action.

===

John Scudder raised a number of concerns in his Routing Directorate
review. I support these in my Discuss as follows.

3. "the entire TRILL BFD Echo protocol specific
  data area is considered opaque and left to the discretion of the
  originating RBridge.  Nevertheless, it is RECOMMENDED that this data
  include information by which the originating RBridge can authenticate
  the returned BFD Echo frame and confirm the neighbor that echoed the
  frame back."

  The use of "RECOMMENDED" contradicts "left to the discretion of"
  because "RECOMMENDED" is a very strong encouragement to do something.
  I think you need "suggested" as this is just general advice to an
  implementation.

4. In two places text like the following appears:

  "Is the M-bit in the TRILL Header non-zero?  If so, discard the
  frame. TRILL support of multi-destination BFD Echo is beyond the
  scope of this document."

  If multi-destination doesn't make sense in the context of TRILL, it
  is fine to exclude it by enforcing that the M-bit be zero. However,
  "beyond the scope of this document" normally means something like
  "we may do it in the future but haven't worked it out yet". By
  forcing the discard under these conditions you are doing more than
  putting the function out of scope: you are disabling it.

  You might solve this by mandating the setting of the bit to zero,
  and saying that if the bit is non-zero the behavior is future
  description, and that an implementation MAY discard the packet.
 
5. The Security Considerations section specifies how authentication is
  to be done, but doesn't provide an analysis of it or of any broader
  issues. According to RFC 3552 (Section 5) the Security Considerations
  section should include an analysis of issues that arise from the
  operation of the protocol defined in the rest of the document,
  including but not limited to the security features of that protocol.

  You could place the current text in a subsection of the Security
  Considerations (called "Authentication") and add more text to the
  core section.

Additionally, I think you are missing a normative reference to
https://datatracker.ietf.org/doc/draft-ietf-trill-rbridge-oam/
This is necessary to set the context for why you are using BFD and
for what purpose. It would also clarify which BFD features are needed
and what OAM features (from the whole set) are addressed by BFD.

Finally, although I understand that the scope of this document is
limited to encapsulation, I think that this leaves the solution
deficient. It needs a description of bootstrapping in the Trill
environment.

[Ballot comment]
It is very odd to bring this document forward ahead of the normatively
referenced draft-ietf-trill-rbridge-channel 

Doing this makes the review less certain.

---

  It is not clear why demand mode was explicitly excluded. TRILL
  would actually seem to be a reasonable fit for demand mode.

  Please either include demand mode, or a short note on why it is
  excluded. It is clear from email exchanges that the authors
  consider that demand mode is redundant because asynchronous
  will always need to be supported and because the underlying
  connectivity will often encompass multiple hops in the lower
  layer. It would be helpful if this was stated as a reason.

---

  "there will be only a single TRILL BFD Control session between
  two RBridges over a given interface visible to TRILL."

  This text is a little hard to parse and may be ambiguous. Please
  find a way to re-write it with reference to a pair of RBridges RB1
  and RB2 and their interfaces RB1_Int1 and RB2_Int1. Or something
  like that.

[Ballot discuss]
John Scudder raised a number of concerns in his Routing Directorate
review. I support these in my Discuss as follows.

1. It is not clear why demand mode was explicitly excluded. TRILL
  would actually seem to be a reasonable fit for demand mode.

  Please either include demand mode, or a short note on why it is
  excluded.

2. "there will be only a single TRILL BFD Control session between
  two RBridges over a given interface visible to TRILL."

  This text is a little hard to parse and may be ambiguous. Please
  find a way to re-write it with reference to a pair of RBridges RB1
  and RB2 and their interfaces RB1_Int1 and RB2_Int1. Or something
  like that.

3. "the entire TRILL BFD Echo protocol specific
  data area is considered opaque and left to the discretion of the
  originating RBridge.  Nevertheless, it is RECOMMENDED that this data
  include information by which the originating RBridge can authenticate
  the returned BFD Echo frame and confirm the neighbor that echoed the
  frame back."

  The use of "RECOMMENDED" contradicts "left to the discretion of"
  because "RECOMMENDED" is a very strong encouragement to do something.
  I think you need "suggested" as this is just general advice to an
  implementation.

4. In two places text like the following appears:

  "Is the M-bit in the TRILL Header non-zero?  If so, discard the
  frame. TRILL support of multi-destination BFD Echo is beyond the
  scope of this document."

  If multi-destination doesn't make sense in the context of TRILL, it
  is fine to exclude it by enforcing that the M-bit be zero. However,
  "beyond the scope of this document" normally means something like
  "we may do it in the future but haven't worked it out yet". By
  forcing the discard under these conditions you are doing more than
  putting the function out of scope: you are disabling it.

  You might solve this by mandating the setting of the bit to zero,
  and saying that if the bit is non-zero the behavior is future
  description, and that an implementation MAY discard the packet.
 
5. The Security Considerations section specifies how authentication is
  to be done, but doesn't provide an analysis of it or of any broader
  issues. According to RFC 3552 (Section 5) the Security Considerations
  section should include an analysis of issues that arise from the
  operation of the protocol defined in the rest of the document,
  including but not limited to the security features of that protocol.

  You could place the current text in a subsection of the Security
  Considerations (called "Authentication") and add more text to the
  core section.

Additionally, I think you are missing a normative reference to
https://datatracker.ietf.org/doc/draft-ietf-trill-rbridge-oam/
This is necessary to set the context for why you are using BFD and
for what purpose. It would also clarify which BFD features are needed
and what OAM features (from the whole set) are addressed by BFD.

Finally, although I understand that the scope of this document is
limited to encapsulation, I think that this leaves the solution
deficient. It needs a description of bootstrapping in the Trill
environment.

[Ballot discuss]
John Scudder raised a number of concerns in his Routing Directorate
review. I support these in my Discuss as follows.

1. It is not clear why demand mode was explicitly excluded. TRILL
  would actually seem to be a reasonable fit for demand mode.

  Please either include demand mode, or a short note on why it is
  excluded.

2. "there will be only a single TRILL BFD Control session between
  two RBridges over a given interface visible to TRILL."

  This text is a little hard to parse and may be ambiguous. Please
  find a way to re-write it with reference to a pair of RBridges RB1
  and RB2 and their interfaces RB1_Int1 and RB2_Int1. Or something
  like that.

3. "the entire TRILL BFD Echo protocol specific
  data area is considered opaque and left to the discretion of the
  originating RBridge.  Nevertheless, it is RECOMMENDED that this data
  include information by which the originating RBridge can authenticate
  the returned BFD Echo frame and confirm the neighbor that echoed the
  frame back."

  The use of "RECOMMENDED" contradicts "left to the discretion of"
  because "RECOMMENDED" is a very strong encouragement to do something.
  I think you need "suggested" as this is just general advice to an
  implementation.

4. In two places text like the following appears:

  "Is the M-bit in the TRILL Header non-zero?  If so, discard the
  frame. TRILL support of multi-destination BFD Echo is beyond the
  scope of this document."

  If multi-destination doesn't make sense in the context of TRILL, it
  is fine to exclude it by enforcing that the M-bit be zero. However,
  "beyond the scope of this document" normally means something like
  "we may do it in the future but haven't worked it out yet". By
  forcing the discard under these conditions you are doing more than
  putting the function out of scope: you are disabling it.

  You might solve this by mandating the setting of the bit to zero,
  and saying that if the bit is non-zero the behavior is future
  description, and that an implementation MAY discard the packet.
 
5. The Security Considerations section specifies how authentication is
  to be done, but doesn't provide an analysis of it or of any broader
  issues. According to RFC 3552 (Section 5) the Security Considerations
  section should include an analysis of issues that arise from the
  operation of the protocol defined in the rest of the document,
  including but not limited to the security features of that protocol.

  You could place the current text in a subsection of the Security
  Considerations (called "Authentication") and add more text to the
  core section.

Additionally, I think you are missing a normative reference to
https://datatracker.ietf.org/doc/draft-ietf-trill-rbridge-oam/
This is necessary to set the context for why you are using BFD and
for what purpose. It would also clarify which BFD features are needed
and what OAM features (from the whole set) are addressed by BFD.

[Ballot comment]
I agree with the shepherd's recommendation to change the reference for [ASCII] to ANSI X3.4. I suggest looking at the references in RFC5891 for an example:

[ASCII]      American National Standards Institute (formerly United
                States of America Standards Institute), "USA Code for
                Information Interchange", ANSI X3.4-1968, 1968.  ANSI
                X3.4-1968 has been replaced by newer versions with
                slight modifications, but the 1968 version remains
                definitive for the Internet.

[Ballot discuss]
This is I believe comparing the TRILL case with MPLS-TP

"TRILL BFD uses the TRILL Rbridge Channel [TRILLChannel] similar to
the way that MPLS OAM protocols use the MPLS Generic Associated
Channel [RFC5586].  However, the RBridges that implement TRILL are
IS-IS [IS-IS] based routers, not label switched routers; thus TRILL
BFD is closer to IPv4/IPv6 BFD than to MPLS BFD."

It is unclear what the above statement means. Whilst TRILL uses ISIS and MPLS-TP does not, the fundamentals high speed detection is is common to all. Where TRILL and MPLS-TP are closer than that are to the IP case is that neither have the use of IP addresses available to them.

[Ballot comment]
I am surprised that TRILL did not take the opportunity to profile out the echo mode, since I understand that it is rarely used in IP networks and not used in MPLS_TP networks.

[Ballot discuss]
s6 contains the following:

  If such IS-IS authentication is in effect then, unless configured
  otherwise, TRILL BFD Control frames sent between those RBridges use
  BFD Meticulous Keyed SHA1 authentication [RFC5880] with keying
  material derived as shown below

I think you need to say what the MTI is in this case.  That might be as simple as adding "MUST" before "use" but that's a little more than MTI that's mandatory to use.  Are you trying to say that in this case,  BFD Meticulous Keyed SHA1 authentication [RFC5880] with keying material derived as shown below MUST be supported as a configurable option: ey [material derivation here]?

[Ballot comment]

- I'm not clear if the key derivations described in section
6 are mandatory to implement or not. It says that if IS-IS
auth is in effect, then you "use" (would that be better with
a 2119 MUST?) BDF Meticulous Keyed SHA1 (nice name btw:-),
but its not clear to me if that means this is MTI or not.

- What does "that state of IS-IS shared secret" mean?  Maybe
s/that state//?

- I don't get why this only needs/uses key ID 0, can you
explain further? I guess I'd have expected that if the
IS-IS-shared-key had a key ID, then that would be used for
the derived key(s) defined here.

- I'm wondering if the authentication scheme described here
is really used or not? I think it'd be good to say if its
real or fictional, if that is known.

[Ballot comment]
Minor comments; no need to respond:
I find citing nroff in the Acknowledgments section to be odd, for whatever that's worth.  (I also can't remember when I last saw an actual normative reference to ASCII.)

IANA has reviewed draft-ietf-trill-rbridge-bfd and has the following comments:

The IANA actions in this document are dependent on the approval of
another Internet Draft. This dependency involves the following document:

draft-ietf-trill-rbridge-channel

If both this document and the dependency were approved, IANA
understands that there is a single IANA action required by this document.

In the new Rbridge Channel Protocol number registry, created by
draft-ietf-trill-rbridge-channel, two new numbers would be registered
as follows:

Protocol Number
-------- ------
BFD Control TBD
BFD Echo TBD

IANA notes that the authors have suggested 2 and 3 for the protocol
numbers above.

IANA understands that this is the only action required to be completed
upon approval of this document.

Note: The actions requested in this document will not be completed
until the document has been approved for publication as an RFC.
This message is only to confirm what actions will be performed.

[Ballot discuss]
I wonder if what is said about congestion control  in Section 7 of RFC 5880 is also applicable to this draft.

The current draft text denies this, as it states in Section 5:
>    It is up to the operator of an RBridge campus to configure the rates
>    at which TRILL BFD frames are transmitted on a link to avoid
>    congestion (e.g., link, I/O, CPU) and false failure detection.

This seems to be absolutely contradicting RFC 5880 on the matter of congestion control.

[Ballot discuss]
It is unclear what table the IANA Considerations section is referencing when it asks for two values of out the "Rbridge Channel Protocol" range.  The IANA website does not have any such entry under TRILL that fits that description.  Please reference the exact table name IANA should use to allocate these values.

[Ballot comment]
1. I don't see the benefit to the discussion of MPLS OAM to this use of BFD. If this use of BFD is more closely related to IPv4/IPv6 BFD, why mention MPLS OAM?

2. Section 3 contains an exact copy of the frame format from RFC 5880, but leaves the discussion of the frame fields to 5880.  I would suggest simply referencing 5880 for both the frame format and the descriptions of the fields.

3. The TRILL Header hop count is specified as having a maximum value of 63 in section 2.  After that, all references to the hop count refer to values in hex notation.  I would suggest picking one format and be consistent throughout the document.

4. Section 4 states "... ECHO frames SHOULD only be sent on links...". Why is this a SHOULD as opposed to a MUST?

5. Section 4.1 says received Echo frames "should have the MH bit equal to one".  Is this a normative SHOULD?  If so, why is it not a MUST?

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (TRILL: Bidirectional Forwarding Detection (BFD) Support) to Proposed Standard


The IESG has received a request from the Transparent Interconnection of
Lots of Links WG (trill) to consider the following document:
- 'TRILL: Bidirectional Forwarding Detection (BFD) Support'
  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
ietf@ietf.org mailing lists by 2012-06-06. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document specifies use of the BFD (Bidirectional Forwarding
  Detection) protocol in RBridge campuses based on the Rbridge Channel
  extension to the the TRILL (TRansparent Interconnection of Lots of
  Links) protocol.

  BFD is a widely deployed OAM (Operations, Administration, and
  Maintenance) mechanism in IP and MPLS networks, using UDP and ACH
  encapsulation respectively.  This document specifies the BFD
  encapsulation over TRILL.







The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-trill-rbridge-bfd/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-trill-rbridge-bfd/ballot/


No IPR declarations have been submitted directly on this I-D.

TRILL: Bidirectional Forwarding Detection (BFD) Support


(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)? Why
is this the proper type of RFC? Is this type of RFC indicated in the
title page header?

Proposed Standard as indicated in the title page header. This
document specifies the standard method of encapsulating the BFD
protocol when used in conjunction with TRILL.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

This document specifies use of the Bidirectional Forwarding
Detection (BFD) protocol in RBridge campuses
based on the RBridge Channel extension to the the TRILL
protocol. BFD is a simple, widely deployed OAM mechanism in IP and
MPLS networks, using UDP and ACH encapsulation respectively. This
document specifies the BFD encapsulation over TRILL.

Working Group Summary

There was a clear consensus in favor of the document with the
consensus determination made in late February. There was then some
delay due to fixing various editorial problems and nits, many of
which were discussed on the mailing list during the WG Last Call,
but these have now been fixed.

Document Quality

BFD and TRILL are both widely implemented although there have been
no announced implementations of the BFD encapsulation for TRILL in
this document. During the review period, the addition of some
material to the Security Considerations section was suggested and
adopted. See
http://www.postel.org/pipermail/rbridge/2012-February/004768.html
http://www.postel.org/pipermail/rbridge/2012-February/004819.html

Personnel

Who is the Document Shepherd?

Erik Nordmark

Who is the Responsible Area Director?

Ralph Droms

(3) Briefly describe the review of this document that was performed by
the Document Shepherd. If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

Careful review of the whole document, including looking at its
dependencies on rbridge-channel and rbridge-extension.

There are references to section 10 and section 4, which I think
should both be references to section 7. I've told the authors that
this nit can be deferred until the AD review has been done.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No. See also item 5 below.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

Review related to the BFD aspects was identified. Notice of
this document's working group last call was posted to the BFD WG
mailing list and one of the co-authors of this draft is co-chair of
the BFD WG and particularly knowledgeable in BFD.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of?

None.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Yes.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

No IPR disclosures on this document.
There is existing and disclosed IPR on the BFD base protocol.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it?

The consensus is reasonably broad.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent?

No.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

There is an ID-NITS error flags for a Normative Reference to RFC20
(defining ASCII).
** Downref: Normative reference to an Unknown state RFC: RFC 20

That is the only RFC that defines ASCII. If desirable we can change it
to a reference to:
USA Standard Code for Information Interchange, USAS X3.4-1967, United
States of America Standards Institute, July 7, 1967


(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

No formal review criteria apply.

(13) Have all references within this document been identified as
either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

There is a normative reference to RFC 20 whose status, as a legacy,
RFC is unknown, as noted above.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in the
Last Call procedure.

See item 14 above.

(16) Will publication of this document change the status of any
existing RFCs?

No.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document.

The IANA Considerations section correctly lists the two code points
required to be allocated. These are in a sub-registry of the TRILL
Parameters registry. That sub-registry is created by
draft-ietf-trill-rbridge-channel, a draft being advanced at the same
time as this document.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

No new registries or sub-registries are created by this draft.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

None. No part of this draft is in a formal language.