Skip to main content

Bidirectional Forwarding Detection (BFD) Directed Return Path for MPLS Label Switched Paths (LSPs)
draft-ietf-mpls-bfd-directed-31

Revision differences

Document history

Date Rev. By Action
2024-05-18
31 Tero Kivinen Closed request for Last Call review by SECDIR with state 'Overtaken by Events'
2024-05-18
31 Tero Kivinen Assignment of request for Last Call review by SECDIR to Sean Turner was marked no-response
2024-05-17
31 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2024-05-17
31 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2024-05-17
31 (System) IANA Action state changed to In Progress from Waiting on Authors
2024-05-17
31 (System) IANA Action state changed to Waiting on Authors from In Progress
2024-05-14
31 (System) RFC Editor state changed to EDIT
2024-05-14
31 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2024-05-14
31 (System) Announcement was received by RFC Editor
2024-05-13
31 (System) IANA Action state changed to In Progress
2024-05-13
31 (System) Removed all action holders (IESG state changed)
2024-05-13
31 Jenny Bui IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2024-05-13
31 Jenny Bui IESG has approved the document
2024-05-13
31 Jenny Bui Closed "Approve" ballot
2024-05-13
31 Jenny Bui Ballot approval text was generated
2024-05-13
31 Jim Guichard IESG state changed to Approved-announcement to be sent from Approved-announcement to be sent::AD Followup
2024-05-13
31 (System) Changed action holders to Jim Guichard (IESG state changed)
2024-05-13
31 (System) Sub state has been changed to AD Followup from Revised I-D Needed
2024-05-13
31 Greg Mirsky New version available: draft-ietf-mpls-bfd-directed-31.txt
2024-05-13
31 Greg Mirsky New version accepted (logged-in submitter: Greg Mirsky)
2024-05-13
31 Greg Mirsky Uploaded new revision
2024-05-02
30 Cindy Morgan Changed consensus to Yes from Unknown
2024-05-02
30 (System) Changed action holders to Greg Mirsky, Jeff Tantsura, Ilya Varlashkin, Mach Chen (IESG state changed)
2024-05-02
30 Jenny Bui IESG state changed to Approved-announcement to be sent::Revised I-D Needed from IESG Evaluation
2024-05-02
30 Éric Vyncke
[Ballot comment]

# Éric Vyncke, INT AD, comments for draft-ietf-mpls-bfd-directed-30

Thank you for the work put into this document.

Please find below some non-blocking COMMENT …
[Ballot comment]

# Éric Vyncke, INT AD, comments for draft-ietf-mpls-bfd-directed-30

Thank you for the work put into this document.

Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education).

Special thanks to Nicolai Leymann for the shepherd's detailed write-up including the WG consensus *but it lacks* the justification of the intended status.

Thanks also to Murray and John for spotting BCP19-related issues.

I hope that this review helps to improve the document,

Regards,

-éric


# DISCUSS (blocking)

As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a DISCUSS ballot is a request to have a discussion on the following topics:

##

# COMMENTS (non-blocking)


## Section 1

```
For the case when BFD is used to detect defects of the traffic engineered LSP the path the BFD control packets transmitted by the egress BFD system toward the ingress may be disjoint from the LSP in the forward direction.
```
The above text is very hard to parse.


`More implementations are encouraged to understand better the operational impact of the mechanism described in the document.` this sounds more application for an I-D with an intended status of 'experimental' though.
2024-05-02
30 Éric Vyncke [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke
2024-05-02
30 Deb Cooley [Ballot Position Update] New position, No Objection, has been recorded for Deb Cooley
2024-05-02
30 Zaheduzzaman Sarker [Ballot comment]
Thanks for working on this document. Thanks to Lars for his TSVART review. I see reviewer's comments has been addressed.
2024-05-02
30 Zaheduzzaman Sarker [Ballot Position Update] New position, No Objection, has been recorded for Zaheduzzaman Sarker
2024-05-01
30 Murray Kucherawy
[Ballot comment]
Thanks for a very thorough shepherd writeup.

The SHOULDs in the last paragraph of Section 5 are bare.  Why are they not MUSTs?  …
[Ballot comment]
Thanks for a very thorough shepherd writeup.

The SHOULDs in the last paragraph of Section 5 are bare.  Why are they not MUSTs?  What's the choice we're giving implementers here, and what guidance should they have to decide?

John did a good job of finding other BCP 19 and IANA issues before I got to them, so I second his suggestions.
2024-05-01
30 Murray Kucherawy [Ballot Position Update] New position, No Objection, has been recorded for Murray Kucherawy
2024-05-01
30 John Scudder
[Ballot comment]
Thanks for this document. I have several comments I hope may be helpful to you.

### Section 2, unambiguously interpreted

  *  detection …
[Ballot comment]
Thanks for this document. I have several comments I hope may be helpful to you.

### Section 2, unambiguously interpreted

  *  detection by an ingress node of a failure on the reverse path may
      not be unambiguously interpreted as the failure of the path in the
      forward direction.

I think I get what you're trying to say here, but even if the forward and reverse paths are co-routed, it's not completely guaranteed that the failure of one implies a failure of the other in any case. So I think it might be worth rephrasing.

### Section 3, Section 3.1, zero sub-TLVs

In several places, you make the point that the BFD reverse path TLV can have zero ("none") sub-TLVs included. I don't understand what the use case for zero sub-TLV's is, especially in light of

                                                                    If
  no sub-TLVs are found in the BFD Reverse Path TLV, the egress BFD
  peer MUST revert to using the local policy-based decision as
  described in Section 7 of [RFC5884], i.e., routed over IP network.

Isn't that semantically the same as saying, if there aren't any sub-TLVs, the reverse path TLV must be ignored? Which is... also what you'd say if the TLV were invalid.

This oddity is harmless as far as I can tell, which is why this isn't a DISCUSS point, but I'd still like to understand the reason.

### Section 3.1, syntax tortured past the breaking point

                                                                Only
  non-multicast  Target FEC Stack- sub-TLVs (already defined, or to be
  defined in the future) for  TLV Types 1, 16, and 21 of MPLS LSP Ping
  Parameters registry MUST be used  in this field.
 
RFC 2119 is often nice, but in my opinion, it's actively harmful in this case. The most obvious English-language reading I can see of this sentence is that the listed sub-TLV types have to be used, implying that other sub-TLV types may be used, although they aren't mandatory. I'm sure that's not what you mean.

A potential rewrite might be something like,

NEW:
  Only non-multicast Target FEC Stack sub-TLVs (already defined, or to be
  defined in the future) for TLV Types 1, 16, and 21 of MPLS LSP Ping
  Parameters registry are permitted to be used in this field. Any other
  sub-TLV MUST NOT be used.
 
See how I even got you a replacement RFC 2119 keyword there? ;-)

### Section 3.1, redundant prohibition

Continuing to the next sentence,

                                                Multicast Target
  FEC Stack sub-TLVs, i.e., p2mp and mp2mp, MUST NOT be included in
  Reverse Path field. 
 
What's the point of including the sentence at all? The previous sentence already told me (or tried to tell me!) this information. My first inclination would be to just remove this sentence, although if you have some special reason for wanting to emphasize this point, I would suggest rewriting it something like,

NEW:
  (This implies that Multicast Target FEC Stack sub-TLVs, i.e., p2mp
  and mp2mp, are not permitted in the Reverse Path field.)

The point of the rewrite is to avoid stating the same requirement twice, which I think leads to confusion. If it's just a consequence of the previous requirement, say it that way.

### Section 3.1, use a SHOULD

You SHOULD mark your calendar, I am about to suggest changing a MUST to a SHOULD. This almost never happens!

  If the egress peer LSR cannot find the path specified in the Reverse
  Path TLV it MUST send Echo Reply with the received BFD Discriminator
  TLV, Reverse Path TLV and set the Return Code to "Failed to establish
  the BFD session.  The specified reverse path was not found"
  (Section 3.2).  An implementation MAY provide configuration options
  to define action at the egress BFD peer.  For example, optionally, if
  the egress peer LSR cannot find the path specified in the Reverse
  Path TLV, it will establish the BFD session over an IP network, as
  defined in [RFC5884].
 
The MUST in the first sentence isn't really a MUST, because the second sentence gives an exception with the MAY. The most straightforward fix would be to change the MUST to a SHOULD. Alternatively, you could add some words to make it clear that the MAY is an exception to the preceding sentence, something like either,

NEW:
  If the egress peer LSR cannot find the path specified in the Reverse
  Path TLV it MUST send Echo Reply with the received BFD Discriminator
  TLV, Reverse Path TLV and set the Return Code to "Failed to establish
  the BFD session.  The specified reverse path was not found"
  (Section 3.2),
  unless this behavior is overridden by configuration. 
  An implementation MAY provide configuration options
  to define action at the egress BFD peer.  For example, optionally, if
  the egress peer LSR cannot find the path specified in the Reverse
  Path TLV, it will establish the BFD session over an IP network, as
  defined in [RFC5884].
 
Or,

NEW:
  If the egress peer LSR cannot find the path specified in the Reverse
  Path TLV it MUST send Echo Reply with the received BFD Discriminator
  TLV, Reverse Path TLV and set the Return Code to "Failed to establish
  the BFD session.  The specified reverse path was not found"
  (Section 3.2).
  As an exception to the preceding requirement,
  an implementation MAY provide configuration options
  to define action at the egress BFD peer.  For example, optionally, if
  the egress peer LSR cannot find the path specified in the Reverse
  Path TLV, it will establish the BFD session over an IP network, as
  defined in [RFC5884].
 
### Section 4, use cases don't need RFC 2119

A use case by definition, isn't where we specify protocol, so I don't think it makes sense to use RFC 2119 keywords there. However, given that you've used them, isn't the MAY wrong in the following text?

  references H-G-D-C-B-A tunnel.  To bootstrap a BFD session to monitor
  the second tunnel, ingress LSR peer A, MUST include a BFD
  Discriminator TLV with a different Discriminator value (e.g., foobar-
  2) [RFC7726] and MAY include a BFD Reverse Path TLV that references
  H-G-F-E-B-A tunnel.

According to the definitions given in RFC 2119, the MAY means that it's perfectly fine for the ingress LSR to omit the BFD reverse path TLV. How would the use case be satisfied if the TLV were omitted?

I think you should rewrite this section without the use of RFC 2119 keywords, and it would improve readability and clarity.

### Section 5, inappropriate MUST

I can't imagine how could be considered appropriate for you to mandate the following:

  Suppose an operator planned network maintenance activity that
  possibly affects FEC used in the BFD Reverse Path TLV.  In that case,
  the operator MUST avoid the unnecessary disruption using the LSP Ping
  with a new FEC in the BFD Reverse Path TLV.

I think maybe what you mean is something like,

NEW:
  Suppose an operator planned network maintenance activity that
  possibly affects FEC used in the BFD Reverse Path TLV.  In that case,
  the operator can avoid the unnecessary disruption by using the LSP Ping
  with a new FEC in the BFD Reverse Path TLV.
 
Carrot, not stick. The stick is doubly futile considering that we have no protocol police, RFC 8962 notwithstanding.
 
### Section 5, some of these things aren't operational considerations

The second part of that paragraph slides right out of operational considerations and into protocol specification:

                                                        In such a case,
  the ingress BFD peer SHOULD immediately transmit the LSP Ping Echo
  request with Return Path TLV to verify whether the FEC is still
  valid.  If the failure was caused by the change in the FEC used for
  the reverse direction of the BFD session, the ingress BFD peer SHOULD
  bootstrap a new BFD session using another FEC in BFD Reverse Path
  TLV.

Although RFC 5706 isn't prescriptive about how an operational consideration section has to be written or what it can contain, nonetheless this kind of protocol specification material seems out of place. I don't immediately see another section it should move to, but I think it would be cleaner to introduce another small section for this material instead of sneaking it into a section that should be about, well, operational considerations and not protocol implementation.

### Section 6.2, not SA

  The IANA is requested to assign new Return Code values from the
  192-247 range of the "Multi-Protocol Label Switching (MPLS) Label
  Switched Paths (LSPs) Ping Parameters" registry, "Return Codes" sub-
  registry, as follows using a Standards Action value.

Delete "using a Standards Action value". (Or delete 192-247 which is the RFC Required range, not the SA range, but that would be wrong because the status is Experimental.)
2024-05-01
30 John Scudder [Ballot Position Update] New position, No Objection, has been recorded for John Scudder
2024-04-30
30 Paul Wouters
[Ballot comment]
The Security Considerations doesn't say _anything_ about something that could apply to this documents feature? Is there really nothing at all to consider? …
[Ballot comment]
The Security Considerations doesn't say _anything_ about something that could apply to this documents feature? Is there really nothing at all to consider?


        Group communication for CoAP has been enabled in
        [I-D.ietf-core-groupcomm-bis]

Maybe say "has been defined in" ?

        Reverse Path field MAY contain none, one, or more sub-TLVs.

Remove the "MAY" here? Or explain what not following the MAY means?

Similar for:

        None, one or more sub-TLVs MAY be included in the BFD Reverse Path TLV.

Related:

        an implementation MAY be able to control that limit
2024-04-30
30 Paul Wouters [Ballot Position Update] New position, No Objection, has been recorded for Paul Wouters
2024-04-29
30 Mahesh Jethanandani
[Ballot comment]
Section 3.1, paragraph 9
>    The BFD Reverse Path TLV MAY be used in the bootstrapping of a BFD
>    session …
[Ballot comment]
Section 3.1, paragraph 9
>    The BFD Reverse Path TLV MAY be used in the bootstrapping of a BFD
>    session process described in Section 6 of [RFC5884].  A system that
>    supports this specification MUST support using the BFD Reverse Path
>    TLV after the BFD session has been established.  If a system that
>    supports this specification receives an LSP Ping with the BFD
>    Discriminator TLV and no BFD Reverse Path TLV even though the reverse
>    path for the specified BFD session has been established according to
>    the previously received BFD Reverse Path TLV, the egress BFD peer
>    MUST transition to transmitting periodic BFD Control messages as
>    defined in Section 7 of [RFC5884].

What happens if the peer does not support this specification, but receives a BFD Reverse Path TLV? Does the request get silently dropped? If so, it should be stated in this document.

Section 5, paragraph 3

The document refers to a configuration option that in addition to other options defines the action an egress BFD peer should do to specify the action the peer can take if the LSR cannot find a path. How can this option be configured? Is there a YANG model extension planned to enable this capability?
2024-04-29
30 Mahesh Jethanandani [Ballot Position Update] New position, No Objection, has been recorded for Mahesh Jethanandani
2024-04-27
30 Erik Kline [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline
2024-04-26
30 Roman Danyliw
[Ballot comment]
Thank you to Linda Dunbar for the GENART review.

To the MPLS WG chairs: it wasn’t clear which milestone in the charter this …
[Ballot comment]
Thank you to Linda Dunbar for the GENART review.

To the MPLS WG chairs: it wasn’t clear which milestone in the charter this work fit under.  I does not appear to have one.

** Section 6.1.  Please update Table 1 to explicitly say that the Sub-TLV Registry column should read “No Sub-TLVs”

** Section 6.  Please add guidance to the RFCEditor somewhere in the text to say the obvious – that “This document” should be replaced by the published RFC number.
2024-04-26
30 Roman Danyliw [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw
2024-04-22
30 Cindy Morgan Placed on agenda for telechat - 2024-05-02
2024-04-22
30 Jim Guichard Ballot has been issued
2024-04-22
30 Jim Guichard [Ballot Position Update] New position, Yes, has been recorded for Jim Guichard
2024-04-22
30 Jim Guichard Created "Approve" ballot
2024-04-22
30 Jim Guichard IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead
2024-04-22
30 Jim Guichard Ballot writeup was changed
2024-04-19
30 (System) IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed
2024-04-16
30 Greg Mirsky New version available: draft-ietf-mpls-bfd-directed-30.txt
2024-04-16
30 Greg Mirsky New version accepted (logged-in submitter: Greg Mirsky)
2024-04-16
30 Greg Mirsky Uploaded new revision
2024-04-16
29 Greg Mirsky New version available: draft-ietf-mpls-bfd-directed-29.txt
2024-04-16
29 Greg Mirsky New version accepted (logged-in submitter: Greg Mirsky)
2024-04-16
29 Greg Mirsky Uploaded new revision
2024-04-16
28 (System) IANA Review state changed to Version Changed - Review Needed from IANA - Not OK
2024-04-16
28 Greg Mirsky New version available: draft-ietf-mpls-bfd-directed-28.txt
2024-04-16
28 Greg Mirsky New version accepted (logged-in submitter: Greg Mirsky)
2024-04-16
28 Greg Mirsky Uploaded new revision
2024-04-15
27 Lars Eggert Request for Last Call review by TSVART Completed: On the Right Track. Reviewer: Lars Eggert. Sent review to list.
2024-04-15
27 (System) IESG state changed to Waiting for AD Go-Ahead from In Last Call
2024-04-12
27 (System) IANA Review state changed to IANA - Not OK from IANA - Review Needed
2024-04-12
27 David Dong
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-mpls-bfd-directed-27. If any part of this review is inaccurate, please let us know.

IANA …
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-mpls-bfd-directed-27. If any part of this review is inaccurate, please let us know.

IANA has a question about the first action requested in the IANA Considerations section of this document.

IANA understands that, upon approval of this document, there are two actions which we must complete.

First, in the TLV registry in the Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters registry group located at:

https://www.iana.org/assignments/mpls-lsp-ping-parameters/

a single new TLV is to be registered from the 16384-31739 range as follows:

Value: [ TBD-at-Registration ]
TLV Name: BFD Reverse Path TLV
Reference: [ RFC-to-be ]
Sub-TLV Registry:

IANA Question --> will there be a sub-TLV registry for this new TLV?

Second, in the Return Codes registry, also in the Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters registry group located at:

https://www.iana.org/assignments/mpls-lsp-ping-parameters/

two new return codes are to be registered from the 192-247 range as follows:

Value: [ TBD-at-Registration ]
Meaning: Inappropriate Target FEC Stack sub-TLV present.
Reference: [ RFC-to-be ]

Value: [ TBD-at-Registration ]
Meaning: Failed to establish the BFD session. The specified reverse path was not found.
Reference: [ RFC-to-be ]

We understand that these are the only actions 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 meant only to confirm the list of actions that will be performed.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist
2024-04-12
27 Joe Clarke Request for Last Call review by OPSDIR Completed: Has Nits. Reviewer: Joe Clarke. Sent review to list.
2024-04-10
27 Linda Dunbar Request for Last Call review by GENART Completed: Ready. Reviewer: Linda Dunbar. Sent review to list.
2024-04-09
27 Magnus Westerlund Request for Last Call review by TSVART is assigned to Lars Eggert
2024-04-05
27 Tero Kivinen Request for Last Call review by SECDIR is assigned to Sean Turner
2024-04-04
27 Greg Mirsky New version available: draft-ietf-mpls-bfd-directed-27.txt
2024-04-04
27 Greg Mirsky New version accepted (logged-in submitter: Greg Mirsky)
2024-04-04
27 Greg Mirsky Uploaded new revision
2024-04-04
26 Jean Mahoney Request for Last Call review by GENART is assigned to Linda Dunbar
2024-04-03
26 Andrew Alston Request for Last Call review by RTGDIR Completed: Has Issues. Reviewer: Andrew Alston. Sent review to list. Submission of review completed at an earlier date.
2024-04-03
26 Andrew Alston Request for Last Call review by RTGDIR Completed: Has Issues. Reviewer: Andrew Alston.
2024-04-02
26 Carlos Pignataro Request for Last Call review by OPSDIR is assigned to Joe Clarke
2024-04-01
26 Daniam Henriques Request for Last Call review by RTGDIR is assigned to Andrew Alston
2024-04-01
26 Liz Flynn IANA Review state changed to IANA - Review Needed
2024-04-01
26 Liz Flynn
The following Last Call announcement was sent out (ends 2024-04-15):

From: The IESG
To: IETF-Announce
CC: Nicolai Leymann , draft-ietf-mpls-bfd-directed@ietf.org, james.n.guichard@futurewei.com, mpls-chairs@ietf.org, …
The following Last Call announcement was sent out (ends 2024-04-15):

From: The IESG
To: IETF-Announce
CC: Nicolai Leymann , draft-ietf-mpls-bfd-directed@ietf.org, james.n.guichard@futurewei.com, mpls-chairs@ietf.org, mpls@ietf.org, n.leymann@telekom.de
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Bidirectional Forwarding Detection (BFD) Directed Return Path for MPLS Label Switched Paths (LSPs)) to Experimental RFC


The IESG has received a request from the Multiprotocol Label Switching WG
(mpls) to consider the following document: - 'Bidirectional Forwarding
Detection (BFD) Directed Return Path for MPLS
  Label Switched Paths (LSPs)'
  as Experimental RFC

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
last-call@ietf.org mailing lists by 2024-04-15. 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


  Bidirectional Forwarding Detection (BFD) is expected to be able to
  monitor a wide variety of encapsulations of paths between systems.
  When a BFD session monitors an explicitly routed unidirectional path
  there may be a need to direct egress BFD peer to use a specific path
  for the reverse direction of the BFD session.  This document
  describes an extension to the MPLS Label Switched Path (LSP) echo
  request that allows a BFD system requests that the remote BFD peer
  transmits BFD control packets over the specified LSP.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-mpls-bfd-directed/


The following IPR Declarations may be related to this I-D:

  https://datatracker.ietf.org/ipr/2625/
  https://datatracker.ietf.org/ipr/2769/
  https://datatracker.ietf.org/ipr/2892/





2024-04-01
26 Liz Flynn IESG state changed to In Last Call from Last Call Requested::AD Followup
2024-04-01
26 Liz Flynn Last call announcement was generated
2024-04-01
26 Jim Guichard Requested Last Call review by RTGDIR
2024-04-01
26 Jim Guichard Requested Last Call review by SECDIR
2024-04-01
26 Jim Guichard Last call was requested
2024-04-01
26 Jim Guichard Last call announcement was generated
2024-04-01
26 Jim Guichard Ballot approval text was generated
2024-04-01
26 Jim Guichard Ballot writeup was generated
2024-04-01
26 Jim Guichard IESG state changed to Last Call Requested::AD Followup from Publication Requested
2024-04-01
26 Jim Guichard Changed action holders to Jim Guichard
2024-03-20
26 Cindy Morgan Shepherding AD changed to Jim Guichard
2024-03-17
26 Nicolai Leymann
## Document History

1 - Does the working group (WG) consensus represent the strong concurrence of a few individuals, with others being silent, or did …
## Document History

1 - Does the working group (WG) consensus represent the strong concurrence of a few individuals, with others being silent, or did it reach broad agreement?
During Last Call the draft received support from five people who are not document authors. There were no voices or concerns raised moving the document forward towards publication. This is of particular importance because there was a controversy about earlier versions of the draft which were solved during several iterations of the document (for details see next sections below).

2 - Was there controversy about particular points, or were there decisions where the consensus was particularly rough?
The draft has a long history and went through several major updates. In total there where four WGLC necessary in order to address all issues raised on the document. The first three working group calls failed due to technical concerns mainly related to  the question if the feature addressed in the draft is fragile and wether this means that the problem described is being solved by the document.

For more details see:
https://mailarchive.ietf.org/arch/msg/mpls/iXsENQuPWmmgsueNiUMlyRCcu4U/
https://mailarchive.ietf.org/arch/msg/mpls/pYhEHsGAg13KBJ6PkPWeL3CnQp4/

In summary the conclusion is that the feature is in several environments fragile and does not guarantee to solve the problem (because in case BFD chooses it's own return path that this session might be less stable than the tunnel being tested). But on the other hand in static environments it solves the problem and there are cases where people might want to implement and run the solution described in the document (as an option to use to solve a specific problem). This is overall a fair assumption. The draft was updated to reflect this and also moved from "Proposed Standard" to "Experimental" marking the approach being part of a research or development effort.

3 - Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)
None (see above).

4 - For protocol documents, are there existing implementations of the contents of the document? Have a significant number of potential implementers indicated plans to implement? Are any existing implementations reported somewhere, either in the document itself (as [RFC 7942][3] recommends) or elsewhere (where)?
Yes. There is one implementation  reported by ZTE.

5 - Do the contents of this document closely interact with technologies in other IETF working groups or external organizations, and would it therefore benefit from their review? Have those reviews occurred? If yes, describe which reviews took place.
None needed.

6 - Describe how the document meets any required formal expert review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.
N/A.

7 - If the document contains a YANG module, has the final version of the module been checked with any of the [recommended validation tools][4] for syntax and formatting validation? If there are any resulting errors or warnings, what is  the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in [RFC 8342][5]?
N/A.

8 - Describe reviews and automated checks performed to validate sections of the final version of the document written in a formal language, such as XML code, BNF rules, MIB definitions, CBOR's CDDL, etc.
N/A.

### Document Shepherd Checks

9 - Based on the shepherd's review of the document, is it their opinion that this  document is needed, clearly written, complete, correctly designed, and ready to be handed off to the responsible Area Director?
Yes.

10 - Several IETF Areas have assembled [lists of common issues that their reviewers encounter][6]. For which areas have such issues been identified and addressed? For which does this still need to happen in subsequent reviews?
None.

11 - What type of RFC publication is being requested on the IETF stream ([Best Current Practice][12], [Proposed Standard, Internet Standard][13], [Informational, Experimental or Historic][14])? Why is this the proper type of RFC? Do all Datatracker state attributes correctly reflect this intent?
Experimental.  This state attribute is also reflected in the Datatracker.

12 - Have reasonable efforts been made to remind all authors of the intellectual property rights (IPR) disclosure obligations described in [BCP 79][8]? To the best of your knowledge, have all required disclosures been filed? If not, explain why. If yes, summarize any relevant discussion, including links to publicly-available messages when applicable.
Yes.
There are three IPRs listed for the document:
https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-mpls-bfd-directed
One of the reasons for the controversial discussion was related to IPR2625 because it did not contain any IPR text:
https://datatracker.ietf.org/ipr/2625/

Authors of the draft are claiming, that the IPR2625 is not applicable anymore. IPR2625 is still listed in the Datatracker and was updated by IPR2769). For more details see:
https://mailarchive.ietf.org/arch/msg/mpls/imnwjd0the9F-F4gdHxh_J3xzq4/
https://datatracker.ietf.org/ipr/2769/


13 - Has each author, editor, and contributor shown their willingness to be listed as such? If the total number of authors and editors on the front pageis greater than five, please provide a justification.
Yes (number of authors on the front page is four).

14 - Document any remaining I-D nits in this document. Simply running the [idnits tool][8] is not enough; please review the ["Content Guidelines" on authors.ietf.org][15]. (Also note that the current idnits tool generates some incorrect warnings; a rewrite is underway.)
No issues found by I-D nits and review:
Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--).

15 - Should any informative references be normative or vice-versa? See the [IESG Statement on Normative and Informative References][16].
No.

16 - List any normative references that are not freely available to anyone. Did the community have sufficient access to review any such normative references?
None.

17 - Are there any normative downward references (see [RFC3967][9] and [BCP97][10]) that are not already listed in the [DOWNREF registry][17]? If so, list them.
No.

18 - Are there normative references to documents that are not ready to be submitted to the IESG for publication or are otherwise in an unclear state?  If so, what is the plan for their completion?
No. Only RFCs are referenced.

19 - Will publication of this document change the status of any existing RFCs? If so, does the Datatracker metadata correctly reflect this and are those RFCs listed on the title page, in the abstract, and discussed in the introduction? If not, explain why and point to the part of the document where the relationship of this document to these other RFCs is discussed.
No.

20 - Describe the document shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all aspects of the document requiring IANA assignments are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm  that each newly created IANA registry specifies its initial contents, allocations procedures, and a reasonable name (see [RFC 8126][11]).
The IANA is requested to assign a new value for BFD Reverse Path TLV from the 16384-31739 range in the "TLVs" registry of "Multiprotocol Label Switching Architecture (MPLS) Label Switched Paths (LSPs) Ping Parameters" registry. In addition assignment of a  new Return Code values from the 192-247 range of the "Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" registry, "Return Codes" subregistry is necessary.  The ranges 16384-31739 and 192-247 use the “RFC Required” assignment policy and so are appropriate for an Experimental RFC.

21 - List any new IANA registries that require Designated Expert Review for future allocations. Are the instructions to the Designated Expert clear? Please include suggestions of designated experts, if appropriate.
None.


[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://trac.ietf.org/trac/ops/wiki/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://trac.ietf.org/trac/iesg/wiki/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/
2024-03-17
26 Nicolai Leymann IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up
2024-03-17
26 Nicolai Leymann IESG state changed to Publication Requested from I-D Exists
2024-03-17
26 (System) Changed action holders to Andrew Alston (IESG state changed)
2024-03-17
26 Nicolai Leymann Responsible AD changed to Andrew Alston
2024-03-17
26 Nicolai Leymann Document is now in IESG state Publication Requested
2024-03-07
26 Nicolai Leymann
## Document History

1 - Does the working group (WG) consensus represent the strong concurrence of a few individuals, with others being silent, or did …
## Document History

1 - Does the working group (WG) consensus represent the strong concurrence of a few individuals, with others being silent, or did it reach broad agreement?
During Last Call the draft received support from five people who are not document authors. There were no voices or concerns raised moving the document forward towards publication. This is of particular importance because there was a controversy about earlier versions of the draft which were solved during several iterations of the document (for details see next sections below).

2 - Was there controversy about particular points, or were there decisions where the consensus was particularly rough?
The draft has a long history and went through several major updates. In total there where four WGLC necessary in order to address all issues raised on the document. The first three working group calls failed due to technical concerns mainly related to  the question if the feature addressed in the draft is fragile and wether this means that the problem described is being solved by the document.

For more details see:
https://mailarchive.ietf.org/arch/msg/mpls/iXsENQuPWmmgsueNiUMlyRCcu4U/
https://mailarchive.ietf.org/arch/msg/mpls/pYhEHsGAg13KBJ6PkPWeL3CnQp4/

In summary the conclusion is that the feature is in several environments fragile and does not guarantee to solve the problem (because in case BFD chooses it's own return path that this session might be less stable than the tunnel being tested). But on the other hand in static environments it solves the problem and there are cases where people might want to implement and run the solution described in the document (as an option to use to solve a specific problem). This is overall a fair assumption. The draft was updated to reflect this and also moved from "Proposed Standard" to "Experimental" marking the approach being part of a research or development effort.

3 - Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)
None (see above).

4 - For protocol documents, are there existing implementations of the contents of the document? Have a significant number of potential implementers indicated plans to implement? Are any existing implementations reported somewhere, either in the document itself (as [RFC 7942][3] recommends) or elsewhere (where)?
Yes. There is one implementation  reported by ZTE.

5 - Do the contents of this document closely interact with technologies in other IETF working groups or external organizations, and would it therefore benefit from their review? Have those reviews occurred? If yes, describe which reviews took place.
None needed.

6 - Describe how the document meets any required formal expert review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.
N/A.

7 - If the document contains a YANG module, has the final version of the module been checked with any of the [recommended validation tools][4] for syntax and formatting validation? If there are any resulting errors or warnings, what is  the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in [RFC 8342][5]?
N/A.

8 - Describe reviews and automated checks performed to validate sections of the final version of the document written in a formal language, such as XML code, BNF rules, MIB definitions, CBOR's CDDL, etc.
N/A.

### Document Shepherd Checks

9 - Based on the shepherd's review of the document, is it their opinion that this  document is needed, clearly written, complete, correctly designed, and ready to be handed off to the responsible Area Director?
Yes.

10 - Several IETF Areas have assembled [lists of common issues that their reviewers encounter][6]. For which areas have such issues been identified and addressed? For which does this still need to happen in subsequent reviews?
None.

11 - What type of RFC publication is being requested on the IETF stream ([Best Current Practice][12], [Proposed Standard, Internet Standard][13], [Informational, Experimental or Historic][14])? Why is this the proper type of RFC? Do all Datatracker state attributes correctly reflect this intent?
Experimental.  This state attribute is also reflected in the Datatracker.

12 - Have reasonable efforts been made to remind all authors of the intellectual property rights (IPR) disclosure obligations described in [BCP 79][8]? To the best of your knowledge, have all required disclosures been filed? If not, explain why. If yes, summarize any relevant discussion, including links to publicly-available messages when applicable.
Yes.
There are three IPRs listed for the document:
https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-mpls-bfd-directed
One of the reasons for the controversial discussion was related to IPR2625 because it did not contain any IPR text:
https://datatracker.ietf.org/ipr/2625/

Authors of the draft are claiming, that the IPR2625 is not applicable anymore. IPR2625 is still listed in the Datatracker and was updated by IPR2769). For more details see:
https://mailarchive.ietf.org/arch/msg/mpls/imnwjd0the9F-F4gdHxh_J3xzq4/
https://datatracker.ietf.org/ipr/2769/


13 - Has each author, editor, and contributor shown their willingness to be listed as such? If the total number of authors and editors on the front pageis greater than five, please provide a justification.
Yes (number of authors on the front page is four).

14 - Document any remaining I-D nits in this document. Simply running the [idnits tool][8] is not enough; please review the ["Content Guidelines" on authors.ietf.org][15]. (Also note that the current idnits tool generates some incorrect warnings; a rewrite is underway.)
No issues found by I-D nits and review:
Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--).

15 - Should any informative references be normative or vice-versa? See the [IESG Statement on Normative and Informative References][16].
No.

16 - List any normative references that are not freely available to anyone. Did the community have sufficient access to review any such normative references?
None.

17 - Are there any normative downward references (see [RFC3967][9] and [BCP97][10]) that are not already listed in the [DOWNREF registry][17]? If so, list them.
No.

18 - Are there normative references to documents that are not ready to be submitted to the IESG for publication or are otherwise in an unclear state?  If so, what is the plan for their completion?
No. Only RFCs are referenced.

19 - Will publication of this document change the status of any existing RFCs? If so, does the Datatracker metadata correctly reflect this and are those RFCs listed on the title page, in the abstract, and discussed in the introduction? If not, explain why and point to the part of the document where the relationship of this document to these other RFCs is discussed.
No.

20 - Describe the document shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all aspects of the document requiring IANA assignments are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm  that each newly created IANA registry specifies its initial contents, allocations procedures, and a reasonable name (see [RFC 8126][11]).
The IANA is requested to assign a new value for BFD Reverse Path TLV from the 16384-31739 range in the "TLVs" registry of "Multiprotocol Label Switching Architecture (MPLS) Label Switched Paths (LSPs) Ping Parameters" registry. In addition assignment of a  new Return Code values from the 192-247 range of the "Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" registry, "Return Codes" subregistry is necessary.  The ranges 16384-31739 and 192-247 use the “RFC Required” assignment policy and so are appropriate for an Experimental RFC.

21 - List any new IANA registries that require Designated Expert Review for future allocations. Are the instructions to the Designated Expert clear? Please include suggestions of designated experts, if appropriate.
None.


[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://trac.ietf.org/trac/ops/wiki/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://trac.ietf.org/trac/iesg/wiki/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/
2024-03-05
26 Nicolai Leymann IETF WG state changed to WG Consensus: Waiting for Write-Up from Waiting for WG Chair Go-Ahead
2024-03-05
26 Nicolai Leymann
## Document History

1 - Does the working group (WG) consensus represent the strong concurrence of a few individuals, with others being silent, or did …
## Document History

1 - Does the working group (WG) consensus represent the strong concurrence of a few individuals, with others being silent, or did it reach broad agreement?
During Last Call the draft received support from five people who are not document authors. There were no voices or concerns raised moving the document forward towards publication. This is of particular importance because there was a controversy about earlier versions of the draft which were solved during several iterations of the document (for details see next sections below).

2 - Was there controversy about particular points, or were there decisions where the consensus was particularly rough?
The draft has a long history and went through several major updates. In total there where four WGLC necessary in order to address all issues raised on the document. The first three working group calls failed due to technical concerns mainly related to  the question if the feature addressed in the draft is fragile and wether this means that the problem described is being solved by the document.

For more details see:
https://mailarchive.ietf.org/arch/msg/mpls/iXsENQuPWmmgsueNiUMlyRCcu4U/
https://mailarchive.ietf.org/arch/msg/mpls/pYhEHsGAg13KBJ6PkPWeL3CnQp4/

In summary the conclusion is that the feature is in several environments fragile and does not guarantee to solve the problem (because in case BFD chooses it's own return path that this session might be less table thant the tunnel being tested). But on the other hand in static environments it solves the problem and there are cases where people might want to implement and run the solution descrtibed in the document (as an option to use to solve a specific problem). This is overall a fair assumption. The draft was updated to reflect this and also moved from "Proposed Standard" to "Experimental" marking the approach being part of a research or development effort.

3 - Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)
None (see above).

4 - For protocol documents, are there existing implementations of the contents of the document? Have a significant number of potential implementers indicated plans to implement? Are any existing implementations reported somewhere, either in the document itself (as [RFC 7942][3] recommends) or elsewhere (where)?
Yes. There is one implementation  reported by ZTE.

5 - Do the contents of this document closely interact with technologies in other IETF working groups or external organizations, and would it therefore benefit from their review? Have those reviews occurred? If yes, describe which reviews took place.
None needed.

6 - Describe how the document meets any required formal expert review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.
N/A.

7 - If the document contains a YANG module, has the final version of the module been checked with any of the [recommended validation tools][4] for syntax and formatting validation? If there are any resulting errors or warnings, what is  the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in [RFC 8342][5]?
N/A.

8 - Describe reviews and automated checks performed to validate sections of the final version of the document written in a formal language, such as XML code, BNF rules, MIB definitions, CBOR's CDDL, etc.
N/A.

### Document Shepherd Checks

9 - Based on the shepherd's review of the document, is it their opinion that this  document is needed, clearly written, complete, correctly designed, and ready to be handed off to the responsible Area Director?
Yes.

10 - Several IETF Areas have assembled [lists of common issues that their reviewers encounter][6]. For which areas have such issues been identified and addressed? For which does this still need to happen in subsequent reviews?
None.

11 - What type of RFC publication is being requested on the IETF stream ([Best Current Practice][12], [Proposed Standard, Internet Standard][13], [Informational, Experimental or Historic][14])? Why is this the proper type of RFC? Do all Datatracker state attributes correctly reflect this intent?
Experimental.  This state attribute is also reflected in the Datatracker.

12 - Have reasonable efforts been made to remind all authors of the intellectual property rights (IPR) disclosure obligations described in [BCP 79][8]? To the best of your knowledge, have all required disclosures been filed? If not, explain why. If yes, summarize any relevant discussion, including links to publicly-available messages when applicable.
Yes.
There are three IPRs listed for the document:
https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-mpls-bfd-directed
One of the reasons for the controversial discussion was related to IPR2625 because it did not contain any IPR text:
https://datatracker.ietf.org/ipr/2625/

Authors of the draft are claiming, that the IPR2625 is not applicable anymore. IPR2625 is still listed in the Datatracker and was updated by IPR2769). For more details see:
https://mailarchive.ietf.org/arch/msg/mpls/imnwjd0the9F-F4gdHxh_J3xzq4/
https://datatracker.ietf.org/ipr/2769/


13 - Has each author, editor, and contributor shown their willingness to be listed as such? If the total number of authors and editors on the front pageis greater than five, please provide a justification.
Yes (number of authors on the front page is four).

14 - Document any remaining I-D nits in this document. Simply running the [idnits tool][8] is not enough; please review the ["Content Guidelines" on authors.ietf.org][15]. (Also note that the current idnits tool generates some incorrect warnings; a rewrite is underway.)
No issues found by I-D nits and review:
Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--).

15 - Should any informative references be normative or vice-versa? See the [IESG Statement on Normative and Informative References][16].
No.

16 - List any normative references that are not freely available to anyone. Did the community have sufficient access to review any such normative references?
None.

17 - Are there any normative downward references (see [RFC3967][9] and [BCP97][10]) that are not already listed in the [DOWNREF registry][17]? If so, list them.
No.

18 - Are there normative references to documents that are not ready to be submitted to the IESG for publication or are otherwise in an unclear state?  If so, what is the plan for their completion?
No. Only RFCs are referenced.

19 - Will publication of this document change the status of any existing RFCs? If so, does the Datatracker metadata correctly reflect this and are those RFCs listed on the title page, in the abstract, and discussed in the introduction? If not, explain why and point to the part of the document where the relationship of this document to these other RFCs is discussed.
No.

20 - Describe the document shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all aspects of the document requiring IANA assignments are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm  that each newly created IANA registry specifies its initial contents, allocations procedures, and a reasonable name (see [RFC 8126][11]).
The IANA is requested to assign a new value for BFD Reverse Path TLV from the 16384-31739 range in the "TLVs" registry of "Multiprotocol Label Switching Architecture (MPLS) Label Switched Paths (LSPs) Ping Parameters" registry. In addition assignment of a  new Return Code values from the 192-247 range of the "Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" registry, "Return Codes" subregistry is necessary.  The ranges 16384-31739 and 192-247 use the “RFC Required” assignment policy and so are appropriate for an Experimental RFC.

21 - List any new IANA registries that require Designated Expert Review for future allocations. Are the instructions to the Designated Expert clear? Please include suggestions of designated experts, if appropriate.
None.


[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://trac.ietf.org/trac/ops/wiki/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://trac.ietf.org/trac/iesg/wiki/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/
2024-02-29
26 Greg Mirsky New version available: draft-ietf-mpls-bfd-directed-26.txt
2024-02-29
26 Greg Mirsky New version accepted (logged-in submitter: Greg Mirsky)
2024-02-29
26 Greg Mirsky Uploaded new revision
2023-12-31
25 Greg Mirsky New version available: draft-ietf-mpls-bfd-directed-25.txt
2023-12-31
25 Greg Mirsky New version accepted (logged-in submitter: Greg Mirsky)
2023-12-31
25 Greg Mirsky Uploaded new revision
2023-11-03
24 Adrian Farrel Datatracker history was messed up.
Looks like this is past WGLC, been updated, and needs shepherd processing
2023-11-03
24 Adrian Farrel IETF WG state changed to Waiting for WG Chair Go-Ahead from In WG Last Call
2023-11-03
24 Adrian Farrel Notification list changed to "Nicolai Leymann" <n.leymann@telekom.de> from "Martin Vigoureux" <martin.vigoureux@nokia.com>, "Nicolai Leymann" <n.leymann@telekom.de>
2023-11-03
24 Adrian Farrel
Notification list changed to "Martin Vigoureux" <martin.vigoureux@nokia.com>, "Nicolai Leymann" <n.leymann@telekom.de> from "Martin Vigoureux" <martin.vigoureux@nokia.com>, loa@pi.nu, "Nicolai Leymann" < …
Notification list changed to "Martin Vigoureux" <martin.vigoureux@nokia.com>, "Nicolai Leymann" <n.leymann@telekom.de> from "Martin Vigoureux" <martin.vigoureux@nokia.com>, loa@pi.nu, "Nicolai Leymann" <n.leymann@telekom.de>
2023-07-02
24 Greg Mirsky New version available: draft-ietf-mpls-bfd-directed-24.txt
2023-07-02
24 Greg Mirsky New version accepted (logged-in submitter: Greg Mirsky)
2023-07-02
24 Greg Mirsky Uploaded new revision
2023-06-22
23 Nicolai Leymann
WG Last call was already done:

https://mailarchive.ietf.org/arch/msg/mpls/v4ZxTPCGmvhsNA8VtMVvG8lGIik/

The document was stuck in the datatacker, need to move to WG Last Call in order to be …
WG Last call was already done:

https://mailarchive.ietf.org/arch/msg/mpls/v4ZxTPCGmvhsNA8VtMVvG8lGIik/

The document was stuck in the datatacker, need to move to WG Last Call in order to be able to request publication.
2023-06-22
23 Nicolai Leymann IETF WG state changed to In WG Last Call from WG Document
2023-05-21
23 Greg Mirsky New version available: draft-ietf-mpls-bfd-directed-23.txt
2023-05-21
23 Greg Mirsky New version accepted (logged-in submitter: Greg Mirsky)
2023-05-21
23 Greg Mirsky Uploaded new revision
2023-03-27
22 Greg Mirsky New version available: draft-ietf-mpls-bfd-directed-22.txt
2023-03-27
22 Greg Mirsky New version accepted (logged-in submitter: Greg Mirsky)
2023-03-27
22 Greg Mirsky Uploaded new revision
2023-01-13
21 Nicolai Leymann Based on discussion with authors and MPLS chairs, status change to experimental.
2023-01-13
21 Nicolai Leymann Intended Status changed to Experimental from Proposed Standard
2022-11-07
21 Greg Mirsky New version available: draft-ietf-mpls-bfd-directed-21.txt
2022-11-07
21 Greg Mirsky New version accepted (logged-in submitter: Greg Mirsky)
2022-11-07
21 Greg Mirsky Uploaded new revision
2022-10-01
20 Greg Mirsky New version available: draft-ietf-mpls-bfd-directed-20.txt
2022-10-01
20 Greg Mirsky New version accepted (logged-in submitter: Greg Mirsky)
2022-10-01
20 Greg Mirsky Uploaded new revision
2022-08-18
19 (System) Document has expired
2022-02-14
19 Greg Mirsky New version available: draft-ietf-mpls-bfd-directed-19.txt
2022-02-14
19 (System) New version accepted (logged-in submitter: Greg Mirsky)
2022-02-14
19 Greg Mirsky Uploaded new revision
2021-08-20
18 Greg Mirsky New version available: draft-ietf-mpls-bfd-directed-18.txt
2021-08-20
18 (System) New version approved
2021-08-20
18 (System) Request for posting confirmation emailed to previous authors: Greg Mirsky , Ilya Varlashkin , Jeff Tantsura , Mach Chen , mpls-chairs@ietf.org
2021-08-20
18 Greg Mirsky Uploaded new revision
2021-08-20
17 (System) Document has expired
2021-02-16
17 Greg Mirsky New version available: draft-ietf-mpls-bfd-directed-17.txt
2021-02-16
17 (System) New version approved
2021-02-16
17 (System) Request for posting confirmation emailed to previous authors: Greg Mirsky , Ilya Varlashkin , Jeff Tantsura , Mach Chen , mpls-chairs@ietf.org
2021-02-16
17 Greg Mirsky Uploaded new revision
2021-02-02
16 Greg Mirsky New version available: draft-ietf-mpls-bfd-directed-16.txt
2021-02-02
16 (System) New version approved
2021-02-02
16 (System) Request for posting confirmation emailed to previous authors: Greg Mirsky , Ilya Varlashkin , Jeff Tantsura , Mach Chen , mpls-chairs@ietf.org
2021-02-02
16 Greg Mirsky Uploaded new revision
2020-08-04
15 Greg Mirsky New version available: draft-ietf-mpls-bfd-directed-15.txt
2020-08-04
15 (System) New version approved
2020-08-04
15 (System) Request for posting confirmation emailed to previous authors: Mach Chen , Greg Mirsky , Jeff Tantsura , Ilya Varlashkin , mpls-chairs@ietf.org
2020-08-04
15 Greg Mirsky Uploaded new revision
2020-06-22
14 Greg Mirsky New version available: draft-ietf-mpls-bfd-directed-14.txt
2020-06-22
14 (System) New version approved
2020-06-22
14 (System) Request for posting confirmation emailed to previous authors: mpls-chairs@ietf.org, Mach Chen , Jeff Tantsura , Greg Mirsky , Ilya Varlashkin
2020-06-22
14 Greg Mirsky Uploaded new revision
2020-06-21
13 (System) Document has expired
2019-12-19
13 Greg Mirsky New version available: draft-ietf-mpls-bfd-directed-13.txt
2019-12-19
13 (System) New version approved
2019-12-19
13 (System) Request for posting confirmation emailed to previous authors: Gregory Mirsky , Mach Chen , mpls-chairs@ietf.org, Ilya Varlashkin , Jeff Tantsura
2019-12-19
13 Greg Mirsky Uploaded new revision
2019-08-21
12 Greg Mirsky New version available: draft-ietf-mpls-bfd-directed-12.txt
2019-08-21
12 (System) New version approved
2019-08-21
12 (System) Request for posting confirmation emailed to previous authors: Gregory Mirsky , Mach Chen , mpls-chairs@ietf.org, Ilya Varlashkin , Jeff Tantsura
2019-08-21
12 Greg Mirsky Uploaded new revision
2019-04-03
11 Greg Mirsky New version available: draft-ietf-mpls-bfd-directed-11.txt
2019-04-03
11 (System) New version approved
2019-04-03
11 (System) Request for posting confirmation emailed to previous authors: Gregory Mirsky , Mach Chen , mpls-chairs@ietf.org, Ilya Varlashkin , Jeff Tantsura
2019-04-03
11 Greg Mirsky Uploaded new revision
2019-04-01
10 (System) Document has expired
2018-09-28
10 Greg Mirsky New version available: draft-ietf-mpls-bfd-directed-10.txt
2018-09-28
10 (System) New version approved
2018-09-28
10 (System) Request for posting confirmation emailed to previous authors: Gregory Mirsky , Mach Chen , mpls-chairs@ietf.org, Ilya Varlashkin , Jeff Tantsura
2018-09-28
10 Greg Mirsky Uploaded new revision
2018-08-21
09 Greg Mirsky New version available: draft-ietf-mpls-bfd-directed-09.txt
2018-08-21
09 (System) New version approved
2018-08-21
09 (System) Request for posting confirmation emailed to previous authors: Gregory Mirsky , Mach Chen , mpls-chairs@ietf.org, Ilya Varlashkin , Jeff Tantsura
2018-08-21
09 Greg Mirsky Uploaded new revision
2018-06-08
08 (System) Document has expired
2017-12-05
08 Greg Mirsky New version available: draft-ietf-mpls-bfd-directed-08.txt
2017-12-05
08 (System) New version approved
2017-12-05
08 (System) Request for posting confirmation emailed to previous authors: Gregory Mirsky , Mach Chen , mpls-chairs@ietf.org, Ilya Varlashkin , Jeff Tantsura
2017-12-05
08 Greg Mirsky Uploaded new revision
2017-07-11
07 Carlos Pignataro Request for Early review by RTGDIR Completed: Has Issues. Reviewer: Carlos Pignataro. Sent review to list.
2017-06-19
07 Min Ye Request for Early review by RTGDIR is assigned to Carlos Pignataro
2017-06-19
07 Min Ye Request for Early review by RTGDIR is assigned to Carlos Pignataro
2017-06-13
07 Greg Mirsky New version available: draft-ietf-mpls-bfd-directed-07.txt
2017-06-13
07 (System) New version approved
2017-06-13
07 (System) Request for posting confirmation emailed to previous authors: Gregory Mirsky , Mach Chen , mpls-chairs@ietf.org, Ilya Varlashkin , Jeff Tantsura
2017-06-13
07 Greg Mirsky Uploaded new revision
2017-06-02
06 Nicolai Leymann Requested Early review by RTGDIR
2017-04-24
06 Greg Mirsky New version available: draft-ietf-mpls-bfd-directed-06.txt
2017-04-24
06 (System) New version approved
2017-04-24
06 (System) Request for posting confirmation emailed to previous authors: Gregory Mirsky , Mach Chen , mpls-chairs@ietf.org, Ilya Varlashkin , Jeff Tantsura
2017-04-24
06 Greg Mirsky Uploaded new revision
2017-02-06
05 Greg Mirsky New version available: draft-ietf-mpls-bfd-directed-05.txt
2017-02-06
05 (System) New version approved
2017-02-06
05 (System) Request for posting confirmation emailed to previous authors: "Mach Chen" , "Gregory Mirsky" , "Jeff Tantsura" , "Ilya Varlashkin" , mpls-chairs@ietf.org
2017-02-06
05 Greg Mirsky Uploaded new revision
2016-11-13
04 Loa Andersson Notification list changed to "Martin Vigoureux" <martin.vigoureux@nokia.com>, loa@pi.nu, "Nicolai Leymann" <n.leymann@telekom.de> from "Martin Vigoureux" <martin.vigoureux@nokia.com>, loa@pi.nu
2016-11-13
04 Loa Andersson Document shepherd changed to Nicolai Leymann
2016-10-15
04 Loa Andersson Notification list changed to "Martin Vigoureux" <martin.vigoureux@nokia.com>, loa@pi.nu from "Ross Callon" <rcallon@juniper.net>, "Martin Vigoureux" <martin.vigoureux@nokia.com>
2016-10-14
Jasmine Magallanes Posted related IPR disclosure: Telefonaktiebolaget LM Ericsson (publ)'s Statement about IPR related to draft-ietf-mpls-bfd-directed
2016-09-13
04 Jeff Tantsura New version available: draft-ietf-mpls-bfd-directed-04.txt
2016-09-13
04 Jeff Tantsura New version approved
2016-09-13
04 Jeff Tantsura Request for posting confirmation emailed to previous authors: "Mach Chen" , "Gregory Mirsky" , "Jeff Tantsura" , "Ilya Varlashkin" , mpls-chairs@ietf.org
2016-09-13
04 (System) Uploaded new revision
2016-08-17
03 Greg Mirsky New version available: draft-ietf-mpls-bfd-directed-03.txt
2016-05-30
02 Ross Callon Notification list changed to "Ross Callon" <rcallon@juniper.net>, "Martin Vigoureux" <martin.vigoureux@nokia.com> from "Ross Callon" <rcallon@juniper.net>
2016-05-30
02 Ross Callon Document shepherd changed to Martin Vigoureux
2016-03-15
Naveen Khan Posted related IPR disclosure: Telefonaktiebolaget LM Ericsson (publ)'s Statement about IPR related to draft-ietf-mpls-bfd-directed
2016-03-02
02 Greg Mirsky New version available: draft-ietf-mpls-bfd-directed-02.txt
2016-01-28
01 Loa Andersson Notification list changed to "Ross Callon" <rcallon@juniper.net>
2016-01-28
01 Loa Andersson Document shepherd changed to Ross Callon
2015-09-08
01 Greg Mirsky New version available: draft-ietf-mpls-bfd-directed-01.txt
2015-09-01
00 George Swallow Intended Status changed to Proposed Standard from None
2015-09-01
00 George Swallow This document now replaces draft-mirsky-mpls-bfd-directed instead of None
2015-09-01
00 Greg Mirsky New version available: draft-ietf-mpls-bfd-directed-00.txt