Skip to main content

Shepherd writeup
draft-ietf-pals-seamless-vccv

1. Summary

The document shepherd is Andy Malis. The responsible Area Director is Deborah
Brungard.

This document extends the procedures and Connectivity Verification (CV) types
already defined for Bidirectional Forwarding Detection (BFD) for Virtual
Circuit Connectivity Verification (VCCV) to define Seamless BFD (S-BFD) for
VCCV.  It updates RFC 5885, extending the CV Values and the Capability
Selection, and is thus being submitted to be a Proposed Standard.

This draft is part of a group of drafts for Seamless BFD (see the references
for the related drafts). As some of these drafts are normative references, this
draft will need to be published as a part of an RFC Editor cluster.

2. Review and Consensus

As IETF work items go, this draft progressed relatively quickly, as the initial
individual draft came out only about a year ago. One of the reasons that it has
progressed so rapidly is that the draft has received good discussion and
review, first as an individual draft and then as a working group draft. It also
received attention as being a part of the larger Seamless BFD effort. The
acknowledgements section in the draft reflects the people that submitted
substantive reviews and comments. Two WG LC reviews in particular resulted in
some good improvements in the draft.

The draft has been non-controversial and there were no objections to consensus
at any point.

The draft is externally cited by a CableLabs document, Data-Over-Cable Service
Interface Specifications DCA - MHAv2 (
http://www.cablelabs.com/wp-content/uploads/specdocs/CM-SP-R-DEPI-I03-161021.pdf
) as a MUST for portions of its functionality. To my knowledge it has not yet
been implemented, as it has not received IANA early allocations, but it is in
at least one vendor's roadmap once the allocations have been made.

3. Intellectual Property

Each author has confirmed conformance with BCP 78/79. There are no IPR
disclosures on the document.

4. Other Points

This draft does not create any new IANA registries. It requests allocations in
existing registries that require IETF consensus/review, but not expert review.
The allocation requests are clear and straightforward for IANA to execute.
Back