Label Switched Path (LSP) Ping Mechanisms for EVPN and Provider Backbone Bridging EVPN (PBB-EVPN)
draft-ietf-bess-evpn-lsp-ping-11

[Ballot comment]
# GEN AD review of draft-ietf-bess-evpn-lsp-ping-09

CC @larseggert

Thanks to Joel Halpern for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/o65AsTa-IlE5tq5kZy_2kZ80bfE).

## Comments

### Section 4.1, paragraph 4
```
                        Figure 1: EVPN MAC Sub-TLV format
```
Why are there two "Must Be Zero" bytes? RFC7432 doesn't seem to have these.

### Section 4.3, paragraph 5
```
                Figure 3: EVPN Ethernet Auto-Discovery Sub-TLV format
```
Why is there a "Must Be Zero" field?

### Section 4.4, paragraph 3
```
                      Figure 4: EVPN IP Prefix Sub-TLV format
```
Why is there a "Must Be Zero" field?

### Missing references

No reference entries found for these items, which were mentioned in the text:
`[RFC8174]` and `[RFC2119]`.

## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### Typos

#### "Abstract", paragraph 1
```
-    mechanisms for detecting data plane failures using LSP Ping in MPLS
+    mechanisms for detecting data plane failures using LSP Ping in MPLS-
+                                                                      +
```

#### Section 1, paragraph 1
```
-    [RFC7432] describes MPLS based Ethernet VPN (EVPN) technology.  An
-                            ^
+    [RFC7432] describes MPLS-based Ethernet VPN (EVPN) technology.  An
+                            ^
```

#### Section 1, paragraph 3
```
-    belonging to the same Forwarding Equivalent Classs (FEC).  The Echo
-                                                    -
```

#### Section 1, paragraph 3
```
-    packet contains sufficient infiormation to verify correctness of data
-                                  -
```

#### Section 3, paragraph 10
```
-    FEC: Forwarding Equivalent Classs
-                                    -
```

#### Section 4, paragraph 1
```
-    an indentifier for a given EVPN is programmed at the target node.
-        -
```

#### Section 4.3, paragraph 5
```
-    EVPN Ethernet AD Sub-TLV can be sent in the context of per-Ethernet
-    Segememnt (ES) or per-EVI.  When an operator performs a connectivity
-      -  -
+    EVPN Ethernet AD Sub-TLV can be sent in the context of per-Ethernet-
+                                                                      +
```

### Grammar/style

#### "Table of Contents", paragraph 1
```
E(s) in the control plane using multi-protocol BGP. EVPN enables multihoming
                                ^^^^^^^^^^^^^^
```
This word is normally spelled as one.

#### Section 1, paragraph 1
```
ing LSP Ping in MPLS network are well defined in [RFC8029] and [RFC6425]. The
                                ^^^^^^^^^^^^
```
This word is normally spelled with a hyphen.

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
[IRT]: https://github.com/larseggert/ietf-reviewtool

[Ballot comment]
Thanks for this update, I've cleared my DISCUSS.

I do think there is a little further improvement possible. The new text is adequate, so please use your own judgment, but my suggestion would be something like the following, using RFC 9136 Section 3.1 as a model. This adds a MUST, some parentheses, and a comma, and drops an "as". Other than the MUST the changes are just stylistic.

OLD:
  The EVPN IP Prefix Sub-TLV has the format as shown in Figure 4.  The
  total length of this sub-TLV can be either 32 bytes if IPv4 addresses
  are carried or 56 bytes if IPv6 addresses are carried. The IP prefix
  and gateway IP address MUST be from the same IP address family as
  described in Section 3.1 of [RFC9136].
 
NEW:
  The EVPN IP Prefix Sub-TLV has the format shown in Figure 4.  The
  total length (not shown) of this sub-TLV MUST be either 32 bytes (if
  IPv4 addresses are carried) or 56 bytes (if IPv6 addresses are carried).
  The IP prefix and gateway IP address MUST be from the same IP address
  family, as described in Section 3.1 of [RFC9136].
 
and,

OLD:
  *  The IP prefix field is set to a 4-octet IPv4 address (with
      trailing 0 bits to make 32 bits in all) or 16-octet IPv6 address
      (with trailing 0 bits to make 128 bits in all).

  *  The Gateway (GW) IP Address field is set to a 4-octet IPv4 address
      or 16-octet IPv6 address if it's used as an Overlay Index for the
      IP prefixes.  If the GW IP Address is not being used, it must be
      set to 0 as described in Section 3.1 of [RFC9136].

NEW:
  *  The IP prefix field is set to a 4-octet IPv4 address (with
      trailing 0 bits to make 32 bits in all) or 16-octet IPv6 address
      (with trailing 0 bits to make 128 bits in all). The address family
      of this field is inferred from the sub-TLV length field, as
      discussed above.

  *  The Gateway (GW) IP Address field is set to a 4-octet IPv4 address
      or 16-octet IPv6 address if it's used as an Overlay Index for the
      IP prefixes.  If the GW IP Address is not being used, it must be
      set to 0 as described in Section 3.1 of [RFC9136]. The address
      family of this field is inferred from the sub-TLV length field, as
      discussed above.
     
I proposed the additional sentence in the two bulleted text items because, without that, there's no description *in the bullet list* of how to infer the address family, unlike RFC 9136 which does provide this context in the bullet list. In my experience, people referring to the document quickly can't necessarily be relied upon to carefully read the entire section. :-(

[Ballot comment]
Thanks for working on this document. Special thanks to Wesley Eddy for his TSVART review. Based on TSVART review and my read of the specification, I have not found transport related issues.

and I am supporting Jim's Discuss.

[Ballot comment]
I support Jim, Lars, and Éric's DISCUSSes.

I agree with Jim and Éric's comments to the effect that the copy editing of the document isn’t what should be expected for a "finished" document. There are various free spelling and grammar checkers which wouldn't fix all the problems, but would catch many of them.

[Ballot discuss]
### Section 4.4, IP Prefix sub-TLV

This might end up being implicit in Lars's DISCUSS points and/or Éric's question, but how does one even know whether the IP Prefix is 4 or 16 octets? Looking at RFC 9136, it's careful to tell us how to infer the address family of the RT-5: "The Length field of the BGP EVPN NLRI for an EVPN IP Prefix route MUST be either 34 (if IPv4 addresses are carried) or 58 (if IPv6 addresses are carried)." If a similar length-based technique is to be used here, I think this spec has to spell it out.

[Ballot comment]
I support Jim, Lars, and Éric's DISCUSSes.

I agree with Jim and Éric's comments to the effect that the copy editing of the document is what should be expected for a "finished" document. There are various free spelling and grammar checkers which wouldn't fix all the problems, but would catch many of them.

[Ballot comment]
Like Roman, I support the DISCUSS positions of Jim Guichard and Lars Eggert.

I'd also like to thank Di Ma for the DNS-DIR review.

[Ballot discuss]
# GEN AD review of draft-ietf-bess-evpn-lsp-ping-09

CC @larseggert

Thanks to Joel Halpern for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/o65AsTa-IlE5tq5kZy_2kZ80bfE).

## Discuss

### Section 4.1, paragraph 3
```
    The EVPN MAC/IP Sub-TLV fields are derived from the MAC/IP
    Advertisement route defined in [RFC7432] Section 7.2 and have the
    format as shown in Figure 1.  This Sub-TLV is included in the Echo
    Request sent by a PBB-EVPN/EVPN PE to a Peer PE.  IP Address field in
    this Sub-TLV is optional.
```
The field may be derived from the one in RFC7432 in terms of what it contains,
but this specification still needs to define it precisely, e.g., say what unit
the Mac Addr Len is in, what should be done with the MBZ field on receive, etc.

### Section 4.2, paragraph 1
```
    The EVPN Inclusive Multicast Sub-TLV fields are based on the EVPN
    Inclusive Multicast route defined in [RFC7432] Section 7.3.
```
As above, the field may be derived from the one in RFC7432,
but this specification still needs to define it precisely, e.g., say what unit
the IP Addr Len is in, etc.

### Section 4.4, paragraph 2
```
    The EVPN IP Prefix Sub-TLV fields are derived from the IP Prefix
    Route (RT-5) advertisement defined in [RFC9136] and applies to only
    EVPN.  This Sub-TLV has the format as shown in Figure 4.
```
As above, the field may be derived from the one in RFC9136,
but this specification still needs to define it precisely, e.g., say what unit
the IP Prefix Len is in, what should be done with the MBZ field on receive, etc.
Also, any reason why the order of Ethernet Tag ID and Ethernet Segment Identifier
is swapped compared to RFC9136 Section 3.1?

[Ballot comment]
## Comments

### Section 4.1, paragraph 4
```
                        Figure 1: EVPN MAC Sub-TLV format
```
Why are there two "Must Be Zero" bytes? RFC7432 doesn't seem to have these.

### Section 4.3, paragraph 5
```
                Figure 3: EVPN Ethernet Auto-Discovery Sub-TLV format
```
Why is there a "Must Be Zero" field?

### Section 4.4, paragraph 3
```
                      Figure 4: EVPN IP Prefix Sub-TLV format
```
Why is there a "Must Be Zero" field?

### Missing references

No reference entries found for these items, which were mentioned in the text:
`[RFC8174]` and `[RFC2119]`.

## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### Typos

#### "Abstract", paragraph 1
```
-    mechanisms for detecting data plane failures using LSP Ping in MPLS
+    mechanisms for detecting data plane failures using LSP Ping in MPLS-
+                                                                      +
```

#### Section 1, paragraph 1
```
-    [RFC7432] describes MPLS based Ethernet VPN (EVPN) technology.  An
-                            ^
+    [RFC7432] describes MPLS-based Ethernet VPN (EVPN) technology.  An
+                            ^
```

#### Section 1, paragraph 3
```
-    belonging to the same Forwarding Equivalent Classs (FEC).  The Echo
-                                                    -
```

#### Section 1, paragraph 3
```
-    packet contains sufficient infiormation to verify correctness of data
-                                  -
```

#### Section 3, paragraph 10
```
-    FEC: Forwarding Equivalent Classs
-                                    -
```

#### Section 4, paragraph 1
```
-    an indentifier for a given EVPN is programmed at the target node.
-        -
```

#### Section 4.3, paragraph 5
```
-    EVPN Ethernet AD Sub-TLV can be sent in the context of per-Ethernet
-    Segememnt (ES) or per-EVI.  When an operator performs a connectivity
-      -  -
+    EVPN Ethernet AD Sub-TLV can be sent in the context of per-Ethernet-
+                                                                      +
```

### Grammar/style

#### "Table of Contents", paragraph 1
```
E(s) in the control plane using multi-protocol BGP. EVPN enables multihoming
                                ^^^^^^^^^^^^^^
```
This word is normally spelled as one.

#### Section 1, paragraph 1
```
ing LSP Ping in MPLS network are well defined in [RFC8029] and [RFC6425]. The
                                ^^^^^^^^^^^^
```
This word is normally spelled with a hyphen.

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
[IRT]: https://github.com/larseggert/ietf-reviewtool

[Ballot discuss]
Thank you for the work put into this document, it can only help operations.

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

Special thanks to Matthew Bocci for the shepherd's detailed write-up including the WG consensus and the justification of the intended status.

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:

## Missing normative references

Even experienced authors sometimes forget to add normative references to RFC 2119 and RFC 8174 ;-)

## Section 4.4

Probably due to my lack of knowledge about EVPN and RFC 9136 et al, but I wonder how the length of the "IP Prefix" field can be known by the receiver ? There is a "IP Prefix length" field but it seems to indicate the prefix length, e.g., "IP Prefix Len" field could be 32 bit but the "IP Prefix" field itself could be the 128-bit value of 2001:db8::

May I strongly suggest adding clarification text if my understanding is incorrect ?

[Ballot comment]

# COMMENTS (non blocking)

## Typos

I had not the same patience as Jim Guichard for catching all typos... But, it is surprising that there are so many left at this stage of the publication process. Please run a proof reader.

## Section 1

Please expand "PBB" at first use.

## Section 4.1

Even if the old RFC 7432 (dated 8 years ago) only understands 48-bit MAC addresses, there are MAC addresses with different length. Should this document handle those MAC addresses ?

## Section 6.1

Is there a reason why the MAC addresses are not written in the IEEE standard way ? I.e., "00aa.00bb.00cc" should be written as "00-AA-00-BB-00-CC".

In 2023, I would have preferred to have an IPv6 example rather than an IPv4 one.

## Section 7

Are there mitigation techniques ?

[Ballot discuss]
Section 4.1: EVPN MAC/IP Sub-TLV
This Sub-TLV appears to be used for both EVPN MAC/IP and PBB-EVPN. The content of the TLV contains information for EVPN taken from [RFC7432] and PBB-EVPN taken from [RFC7623]. This begs the question as to why these are both merged into the same Sub-TLV rather than have separate Sub-TLVs. The name of the Sub-TLV implies it's for EVPN but it is not exclusively for that. Also, there are fields in the TLV such as Ethernet Tag ID that are relevant only to PBB-EVPN (or vice versa) so I assume that these would be set to zero if not used (?) but the document does not specify this.

Section 8:1: Sub-type TLV
  This document defines four new Sub-TLV type to be included in Target
  FEC Stack TLV (TLV Type 1, 16 and 21) [RFC8029] in Echo Request and
  Echo Reply messages in EVPN and PBB-EVPN network.

The reference to RFC8029 looks incorrect. I think this is referring to RFC9041 and if so, the reference should be corrected. The Target FEC Stack TLV sub-TLVs are in this registry https://www.iana.org/assignments/mpls-lsp-ping-parameters/mpls-lsp-ping-parameters.xhtml#sub-tlv-1-16-21.

  IANA is requested to assign lowest 4 free values for the four Sub-
  TLVs listed below from the Standards Track" (0-16383) range

If this is in fact referencing RFC9041 then the 0-16383 range is "Standards Action" NOT "Standards Track"

[Ballot comment]
Several issues are noted in the nits printout that should be fixed. The main one is the RFC2119 boilerplate. It is present in the document, but the references are not listed in the normative references section of the document.

Minor nits:
- Section 1:
    - First paragraph: "layer 2" should be hyphenated "layer-2".
    - First paragraph: a reference for multi-protocol BGP should be provided.
    - Third paragraph, 5th sentence: " infiormation" typo.
    - I would like to see a reference provided for the Target FEC Stack TLV. It appears to be defined in RFC8029.
    - In general, there are a lot of missing "an" and "the" in the gramma.

- Section 4:
    - The last sentence "These Target FEC Stack Sub-TLVs are described next" seems redundant and could be removed.

- Section 4.2:
    - The first sentence states "The EVPN Inclusive Multicast Sub-TLV fields are based on the EVPN Inclusive Multicast route defined in [RFC7432] Section 7.3.". RFC 4732 actually refers to this as "Inclusive Multicast
      Ethernet Tag route". Please correct the text to include "Tag".
- Section 4.3:
    - Typo "Segememnt" beginning of third paragraph.
- Section 5:
    - Last sentence "The code points for ipv4 and ipv6 channels are defiend in Generic Associated Channel (G-ACh) Parameters by IANA." should capitalize ipv4 and ipv6 and fix "defiend" typo.

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

The IANA Functions Operator has completed its review of draft-ietf-bess-evpn-lsp-ping-08. If any part of this review is inaccurate, please let us know.

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

First, in the Sub-TLVs for TLV Types 1, 16, and 21 subregistry of the TLVs registry on the Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters registry page located at:

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

four new registrations will be made in the Standards Track range (0-16383) as follows:

Sub-Type: [ TBD-at-Registration ]
Sub-TLV Name: EVPN MAC/IP Sub-TLV
Reference: [ RFC-to-be ]
Comment:

Sub-Type: [ TBD-at-Registration ]
Sub-TLV Name: EVPN Inclusive Multicast Sub-TLV
Reference: [ RFC-to-be ]
Comment:

Sub-Type: [ TBD-at-Registration ]
Sub-TLV Name: EVPN Auto-Discovery Sub-TLV
Reference: [ RFC-to-be ]
Comment:

Sub-Type: [ TBD-at-Registration ]
Sub-TLV Name: EVPN IP Prefix Sub-TLV
Reference: [ RFC-to-be ]
Comment:

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

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

two new return codes are to be registered as follows:

Value: [ TBD-at-Registration ]
Meaning: Replying router is egress for the FEC at the stack depth. In addition, the BUM packets are dropped on the ES corresponding to the ESI received in EVPN Ethernet AD Sub-TLV because of the Split Horizon Group filtering.
Reference: [ RFC-to-be ]

Value: [ TBD-at-Registration ]
Meaning: Replying router is egress for the FEC at the stack depth. In addition, the BUM packets are forwarded because there is no ES corresponding to the ESI received in EVPN Ethernet AD Sub-TLV.
Reference: [ RFC-to-be ]

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Please note that there is a typo in section 8.2: "IANA is requested to assign 2 lowest free values for the 2 [Retuen] Codes...".

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 Specialist

The following Last Call announcement was sent out (ends 2022-10-18):

From: The IESG
To: IETF-Announce
CC: Matthew Bocci , andrew-ietf@liquid.tech, bess-chairs@ietf.org, bess@ietf.org, draft-ietf-bess-evpn-lsp-ping@ietf.org, matthew.bocci@nokia.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (LSP-Ping Mechanisms for EVPN and PBB-EVPN) to Proposed Standard


The IESG has received a request from the BGP Enabled ServiceS WG (bess) to
consider the following document: - 'LSP-Ping Mechanisms for EVPN and PBB-EVPN'
  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
last-call@ietf.org mailing lists by 2022-10-18. 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


  LSP Ping is a widely deployed Operation, Administration, and
  Maintenance mechanism in MPLS networks.  This document describes
  mechanisms for detecting data plane failures using LSP Ping in MPLS
  based EVPN and PBB-EVPN networks.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-lsp-ping/



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

Document shepherd writeup for draft-ietf-bess-evpn-lsp-ping-07

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

Standards track. This is properly indicated in the header. This is the appropriate
classification since the document specifies normative procedures and requests the
creation of new IANA registries.


(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:

LSP Ping is a widely deployed Operation, Administration, and
  Maintenance mechanism in MPLS networks.  This document describes
  mechanisms for detecting data-plane failures using LSP Ping in MPLS
  based EVPN and PBB-EVPN networks.

Working Group Summary:

The BGP Enabled Services (BESS) working group is responsible for
defining, specifying, and extending network services based on BGP. A particularly
popular service is EVPN, which uses BGP signaling to provide an EThernet VPN (VPWS
or VPLS) service. EVPN services
have typically been deployed over MPLS networks, and there is a need to provide
OAM mechanisms to check connectivity in the data plane and also to check the
data plane/control plane consistency. Since MPLS is widely used as the underlying
PSN, it is convenient to reuse MPLS-based OAM mechanisms as much as possible.
LSP Ping [RFC8029] is one such mechanism and this draft provides a way of using
LSP Ping to detect data plane failures in the context of an EVPN.

The document was developed over a period of time in the BESS working group, and
was also reviewed with the MPLS working group.

Document Quality:

Both LSP Ping and EVPN are mature technologies. This document, describing
how to apply LSP Ping to EVPN has been well reviewed in both BESS and MPLS.

The draft received a number of comments during WG last call which were addressed.

I have no concerns about the quality of the document. Participants have
indicated knowledge of implementations.

Personnel:

Document Shepherd: Matthew Bocci (matthew.bocci@nokia.com)
Responsible Area Director: Martin Vigoureux (martin.vigoureux@nokia.com)

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

I reviewed Version 4 of the draft and made a number of editorial comments which have been
addressed.  It is clear and readable.

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

No concerns. The draft was reviewed by a number of participants during WG last call
and comments addressed. It was also cross-reviewed with
the MPLS working group at working group last call, and received comments from
one of the MPLS WG chairs which were addressed.

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

No formal reviews required.

(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? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

No specific concerns.

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

There are no IPR disclosures.

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

There is solid consensus behind the daft. There were a significant number
of participants who indicated support during the WG LC.


(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise 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 indicated.

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


ID nits passes.

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

No formal review requirements.

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

All normative references are to published RFCs or drafts with the IESG.


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

No

(16) Will publication of this document change the status of any existing
RFCs? Are those RFCs listed on the title page header, listed in the
abstract, and discussed in the introduction? If the RFCs are not listed
in the Abstract and Introduction, explain why, and point to the part of
the document where the relationship of this document to the other RFCs
is discussed. If this information is not in the document, explain why
the WG considers it unnecessary.

This document does not require a change to the status of any existing document.

(17) 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 protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 8126).


There are IANA actions as follows:
- Four new sub-TLV types for the target FEC stack TLV.
- Two new return codes for the echo reply.

The IANA actions and intended registries from which these are taken are properly indicated.


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

None

(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, YANG modules,
etc.

There are no sections written in a formal language.

(20) If the document contains a YANG module, has the module been checked
with any of the recommended validation tools
(https://trac.ietf.org/trac/ops/wiki/yang-review-tools) 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 RFC8342?

The document does not define any YANG modules.

Document shepherd writeup for draft-ietf-bess-evpn-lsp-ping-07

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

Standards track. This is properly indicated in the header. This is the appropriate
classification since the document specifies normative procedures and requests the
creation of new IANA registries.


(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:

LSP Ping is a widely deployed Operation, Administration, and
  Maintenance mechanism in MPLS networks.  This document describes
  mechanisms for detecting data-plane failures using LSP Ping in MPLS
  based EVPN and PBB-EVPN networks.

Working Group Summary:

The BGP Enabled Services (BESS) working group is responsible for
defining, specifying, and extending network services based on BGP. A particularly
popular service is EVPN, which uses BGP signaling to provide an EThernet VPN (VPWS
or VPLS) service. EVPN services
have typically been deployed over MPLS networks, and there is a need to provide
OAM mechanisms to check connectivity in the data plane and also to check the
data plane/control plane consistency. Since MPLS is widely used as the underlying
PSN, it is convenient to reuse MPLS-based OAM mechanisms as much as possible.
LSP Ping [RFC8029] is one such mechanism and this draft provides a way of using
LSP Ping to detect data plane failures in the context of an EVPN.

The document was developed over a period of time in the BESS working group, and
was also reviewed with the MPLS working group.

Document Quality:

Both LSP Ping and EVPN are mature technologies. This document, describing
how to apply LSP Ping to EVPN has been well reviewed in both BESS and MPLS.

The draft received a number of comments during WG last call which were addressed.

I have no concerns about the quality of the document. Participants have
indicated knowledge of implementations.

Personnel:

Document Shepherd: Matthew Bocci (matthew.bocci@nokia.com)
Responsible Area Director: Martin Vigoureux (martin.vigoureux@nokia.com)

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

I reviewed Version 4 of the draft and made a number of editorial comments which have been
addressed.  It is clear and readable.

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

No concerns. The draft was reviewed by a number of participants during WG last call
and comments addressed. It was also cross-reviewed with
the MPLS working group at working group last call, and received comments from
one of the MPLS WG chairs which were addressed.

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

No formal reviews required.

(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? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

No specific concerns.

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

There are no IPR disclosures.

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

There is solid consensus behind the daft. There were a significant number
of participants who indicated support during the WG LC.


(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise 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 indicated.

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


ID nits passes.

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

No formal review requirements.

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

All normative references are to published RFCs or drafts with the IESG.


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

No

(16) Will publication of this document change the status of any existing
RFCs? Are those RFCs listed on the title page header, listed in the
abstract, and discussed in the introduction? If the RFCs are not listed
in the Abstract and Introduction, explain why, and point to the part of
the document where the relationship of this document to the other RFCs
is discussed. If this information is not in the document, explain why
the WG considers it unnecessary.

This document does not require a change to the status of any existing document.

(17) 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 protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 8126).


There are IANA actions as follows:
- Four new sub-TLV types for the target FEC stack TLV.
- Two new return codes for the echo reply.

The IANA actions and intended registries from which these are taken are properly indicated.


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

None

(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, YANG modules,
etc.

There are no sections written in a formal language.

(20) If the document contains a YANG module, has the module been checked
with any of the recommended validation tools
(https://trac.ietf.org/trac/ops/wiki/yang-review-tools) 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 RFC8342?

The document does not define any YANG modules.