Re: [bess] John Scudder's No Objection on draft-ietf-bess-evpn-lsp-ping-10: (with COMMENT)

[Parag Jain (paragj)]

Hi John

Thank you for your comments to improve the document further. We agree with your 
input and will incorporate your suggestions in the next rev.

Regards,
Parag

From: John Scudder via Datatracker 
Date: Monday, May 15, 2023 at 11:22 AM
To: The IESG 
Cc: draft-ietf-bess-evpn-lsp-p...@ietf.org 
, bess-cha...@ietf.org 
, bess@ietf.org , Matthew Bocci 
, matthew.bo...@nokia.com 
Subject: John Scudder's No Objection on draft-ietf-bess-evpn-lsp-ping-10: (with 
COMMENT)
John Scudder has entered the following ballot position for
draft-ietf-bess-evpn-lsp-ping-10: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to 
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-lsp-ping/



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

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] John Scudder's Discuss on draft-ietf-bess-evpn-lsp-ping-09: (with DISCUSS and COMMENT)

[Parag Jain (paragj)]

Hi John

Thank you for your careful review and valuable comments. We have addressed them 
in version 10 of the draft.

Pls also see inline.

Thanks
Parag

From: BESS  on behalf of John Scudder via Datatracker 

Date: Tuesday, April 25, 2023 at 8:39 PM
To: The IESG 
Cc: draft-ietf-bess-evpn-lsp-p...@ietf.org 
, bess-cha...@ietf.org 
, bess@ietf.org , Matthew Bocci 
, matthew.bo...@nokia.com 
Subject: [bess] John Scudder's Discuss on draft-ietf-bess-evpn-lsp-ping-09: 
(with DISCUSS and COMMENT)
John Scudder has entered the following ballot position for
draft-ietf-bess-evpn-lsp-ping-09: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to 
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-lsp-ping/



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

Paragj>Added clarification text as follows:
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 if IPv4  addresses are carried or 56 if 
IPv6 addresses are carried.  The IP prefix and gateway IP address must be from 
the same IP address family.

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

paragj> done.  We have also addressed Jim, Lars and Eric’s comments in the new 
version.
Thanks, Parag

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] [EXTERNAL] Éric Vyncke's Discuss on draft-ietf-bess-evpn-lsp-ping-09: (with DISCUSS and COMMENT)

[Parag Jain (paragj)]

Hello Sacha

Thanks for providing the clarification. Much appreciated. We have clarified 
this in the new version of the draft.

Thanks
Parag


From: Alexander Vainshtein 
Date: Monday, April 24, 2023 at 8:47 AM
To: Eric Vyncke (evyncke) 
Cc: draft-ietf-bess-evpn-lsp-p...@ietf.org 
, bess-cha...@ietf.org 
, bess@ietf.org , Matthew Bocci 
, The IESG 
Subject: RE: [EXTERNAL] [bess] Éric Vyncke's Discuss on 
draft-ietf-bess-evpn-lsp-ping-09: (with DISCUSS and COMMENT)
Eric,
Regarding
Regarding your second DISCUSS point "I wonder how the length of the "IP Prefix" 
field can be known by the receiver ?"

This length can be unambiguously inferred from the length of the IP Prefix 
sub-TLV because in accordance with Section 3.1 of RFC 9136 the IP Prefix and 
the GW IP address in the NLRI of EVPN IP Prefix 9Type 5) routes MUST be from 
the same family (either both are IPv4 or both are IPv6).

At the same time I fully agree that this deserves explicit clarification by the 
authors.

Regards,
Sasha

-Original Message-
From: BESS  On Behalf Of ?ric Vyncke via Datatracker
Sent: Monday, April 24, 2023 1:02 PM
To: The IESG 
Cc: draft-ietf-bess-evpn-lsp-p...@ietf.org; bess-cha...@ietf.org; 
bess@ietf.org; Matthew Bocci ; matthew.bo...@nokia.com
Subject: [EXTERNAL] [bess] Éric Vyncke's Discuss on 
draft-ietf-bess-evpn-lsp-ping-09: (with DISCUSS and COMMENT)

Éric Vyncke has entered the following ballot position for
draft-ietf-bess-evpn-lsp-ping-09: Discuss

When responding, please keep the subject line intact and reply to all email 
addresses included in the To and CC lines. (Feel free to cut this introductory 
paragraph, however.)


Please refer to 
https://clicktime.symantec.com/15sM1Gc6AY26NeWG4mtjV?h=fMSSL2DZa8PWDKeoV_WU98RtZ1-L1Go5M78gceLKtvE==https://clicktime.symantec.com/15sM1Gc6AnEk2fPYRAnxP?h=rPr4T36xJXeX7CYjROGRv7E-Y3MeayQviNlHFtXZ8Tc==https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://clicktime.symantec.com/15sLvSQohvLVxhgLXDVas?h=rFOi45hn5CAcc0c3p0NleETW_n-OSK0Pf0DNfFoo42E==https://clicktime.symantec.com/15sLvSQoiAZ9ciZcscPom?h=Cr9Yso3cP5WwFFjth2L43SXrblZNgEgKKxzAH8vK6No==https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-lsp-ping/



--
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://clicktime.symantec.com/15sM66oNd9hgnbLBcLHt7?h=x8dkjmRZ81ni2AVC8joih18UQqV2oxAR7Em7a3BWl1A==https://clicktime.symantec.com/15sM66oNdPvLScDTxjC71?h=5XSWHNDO-opR1Y6OamjkBG1vzlnpfQlQ2CL4mkzUFqo==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 ?


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



___
BESS mailing list
BESS@ietf.org

Re: [bess] Warren Kumari's No Objection on draft-ietf-bess-evpn-lsp-ping-09: (with COMMENT)

[Parag Jain (paragj)]

Hi Warren

Thank you for the review and comments. We have addressed them in version 10 of 
the draft.

Regards,
Parag

From: Warren Kumari via Datatracker 
Date: Tuesday, April 25, 2023 at 8:08 PM
To: The IESG 
Cc: draft-ietf-bess-evpn-lsp-p...@ietf.org 
, bess-cha...@ietf.org 
, bess@ietf.org , Matthew Bocci 
, matthew.bo...@nokia.com , 
m...@juicybun.cn , dns...@ietf.org 
Subject: Warren Kumari's No Objection on draft-ietf-bess-evpn-lsp-ping-09: 
(with COMMENT)
Warren Kumari has entered the following ballot position for
draft-ietf-bess-evpn-lsp-ping-09: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to 
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-lsp-ping/



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


___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Éric Vyncke's Discuss on draft-ietf-bess-evpn-lsp-ping-09: (with DISCUSS and COMMENT)

[Parag Jain (paragj)]

Hello Eric

Thank you for your careful review and valuable comments. We have addressed them 
in version 10 of the draft.

Pls also see inline.


From: Éric Vyncke via Datatracker 
Date: Monday, April 24, 2023 at 6:02 AM
To: The IESG 
Cc: draft-ietf-bess-evpn-lsp-p...@ietf.org 
, bess-cha...@ietf.org 
, bess@ietf.org , Matthew Bocci 
, matthew.bo...@nokia.com 
Subject: Éric Vyncke's Discuss on draft-ietf-bess-evpn-lsp-ping-09: (with 
DISCUSS and COMMENT)
Éric Vyncke has entered the following ballot position for
draft-ietf-bess-evpn-lsp-ping-09: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to 
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-lsp-ping/



--
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 ;-)

Paragj> added reference to rfc2119 and rfc8174.

## 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 ?
Paragj>Added clarification text as follows:
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 if IPv4  addresses are carried or 56 if 
IPv6 addresses are carried.  The IP prefix and gateway IP address must be from 
the same IP address family.


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

Paragj> fixed.

## Section 1

Please expand "PBB" at first use.
Paragj> done


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

Paragj> updated the doc to state that only 48 bit mac addresses are supported.

## 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".

Paragj> done

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

Paragj>Fixed.

## Section 7

Are there mitigation techniques ?

paragj> added text.
Thanks
Parag
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Lars Eggert's Discuss on draft-ietf-bess-evpn-lsp-ping-09: (with DISCUSS and COMMENT)

[Parag Jain (paragj)]

Hi Lars

Thank you for your careful review and valuable comments. We have addressed them 
in version 10 of the draft.

Pls also see inline.

Thanks
Parag

From: Lars Eggert via Datatracker 
Date: Monday, April 24, 2023 at 9:29 AM
To: The IESG 
Cc: draft-ietf-bess-evpn-lsp-p...@ietf.org 
, bess-cha...@ietf.org 
, bess@ietf.org , Matthew Bocci 
, matthew.bo...@nokia.com 
Subject: Lars Eggert's Discuss on draft-ietf-bess-evpn-lsp-ping-09: (with 
DISCUSS and COMMENT)
Lars Eggert has entered the following ballot position for
draft-ietf-bess-evpn-lsp-ping-09: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to 
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-lsp-ping/



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

paragj> Added unit of mac addresses, prefix len and other fields in the 
sub-TLVs. Added description of the behavior for MBZ fields as follows:

The Must Be Zero fields are set to 0. The receiving PE should ignore the Must 
Be Zero fields.


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

paragj> described all the fields of the sub-TLVs.

### 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,
paragj> > described all the fields of the sub-TLVs.
what should be done with the MBZ field on receive, etc.
paragj> added description of the behavior for MBZ fields as follows:

The Must Be Zero fields are set to 0. The receiving PE should ignore the Must 
Be Zero fields.

Also, any reason why the order of Ethernet Tag ID and Ethernet Segment 
Identifier
is swapped compared to RFC9136 Section 3.1?

paragj> this was done for 32 bit alignment and also wanted  to keep IP Prefix 
Len and IP Prefix fields next to each other.

--
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.
Paragj> this is for 32 bit alignment of the EVPN MAC/IP Sub-TLV defined in this 
draft.


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

Paragj> this is for 32 bit alignment of the EVPN Ethernet Auto-Discovery 
Sub-TLV defined in this draft.

### Section 4.4, paragraph 3
```
   Figure 4: EVPN IP Prefix Sub-TLV format
```
Why is there a "Must Be Zero" field?
Paragj> this is for 32 bit alignment of the EVPN IP Prefix Sub-TLV defined in 
this draft.


### Missing references

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

## 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 

Re: [bess] Jim Guichard's Discuss on draft-ietf-bess-evpn-lsp-ping-09: (with DISCUSS and COMMENT)

[Parag Jain (paragj)]

Hi Jim

Thank you for your through review and valuable comments. We have addressed your 
comments in version 10.

Pls see inline.

Thanks
Parag

From: Parag Jain (paragj) 
Date: Wednesday, April 19, 2023 at 4:20 PM
To: Jim Guichard , The IESG 
Cc: draft-ietf-bess-evpn-lsp-p...@ietf.org 
, bess-cha...@ietf.org 
, bess@ietf.org , Matthew Bocci 

Subject: Re: Jim Guichard's Discuss on draft-ietf-bess-evpn-lsp-ping-09: (with 
DISCUSS and COMMENT)
Hi Jim

Thank you for the thorough review and comments. Let me address them and upload 
a new version.

Pls see inline for reply to one comment.

Thanks
Parag

From: Jim Guichard via Datatracker 
Date: Tuesday, April 18, 2023 at 3:49 PM
To: The IESG 
Cc: draft-ietf-bess-evpn-lsp-p...@ietf.org 
, bess-cha...@ietf.org 
, bess@ietf.org , Matthew Bocci 
, matthew.bo...@nokia.com 
Subject: Jim Guichard's Discuss on draft-ietf-bess-evpn-lsp-ping-09: (with 
DISCUSS and COMMENT)
Jim Guichard has entered the following ballot position for
draft-ietf-bess-evpn-lsp-ping-09: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to 
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-lsp-ping/



--
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.
Paragj> RFC7623 states that MAC/IP Sub-TLVs defined by RFC7432 is used for 
B-MAC advertisements. That’s the reason we defined the same Sub-TLV for LSP 
Ping for both EVPN and PBB-EVPN.
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.
Paragj> described all the fields of the sub-TLVs including specifics of the 
PBB-EVPN.

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"

paragj> Changed to "Standards Action"

--
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".
paragj> done

 - First paragraph: a reference for multi-protocol BGP should be provided.
paragj> done

 - Third paragraph, 5th sentence: " infiormation" typo.
paragj> done

 - 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.
paragj> done

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

paragj> done

- 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".
paragj> done

- Section 4.3:
 - Typo "Segememnt" beginning of third paragraph.
paragj> done

- Section 5:
 - Last sentence "The code points for ipv4 and ip

Re: [bess] Jim Guichard's Discuss on draft-ietf-bess-evpn-lsp-ping-09: (with DISCUSS and COMMENT)

[Parag Jain (paragj)]

Hi Jim

Thank you for the thorough review and comments. Let me address them and upload 
a new version.

Pls see inline for reply to one comment.

Thanks
Parag

From: Jim Guichard via Datatracker 
Date: Tuesday, April 18, 2023 at 3:49 PM
To: The IESG 
Cc: draft-ietf-bess-evpn-lsp-p...@ietf.org 
, bess-cha...@ietf.org 
, bess@ietf.org , Matthew Bocci 
, matthew.bo...@nokia.com 
Subject: Jim Guichard's Discuss on draft-ietf-bess-evpn-lsp-ping-09: (with 
DISCUSS and COMMENT)
Jim Guichard has entered the following ballot position for
draft-ietf-bess-evpn-lsp-ping-09: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to 
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-lsp-ping/



--
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.
Paragj> RFC7623 states that MAC/IP Sub-TLVs defined by RFC7432 is used for 
B-MAC advertisements. That’s the reason we defined the same Sub-TLV for LSP 
Ping for both EVPN and PBB-EVPN.
Will address all other comments in the next version.
Thanks, Parag
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"


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


___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Secdir last call review of draft-ietf-bess-evpn-lsp-ping-08

[Parag Jain (paragj)]

Hi Rifaat

We have addressed your comments in the security section of the new version of 
the darft (draft-ietf-bess-evpn-lsp-ping-09).

Thanks
Parag


From: BESS  on behalf of Rifaat Shekh-Yusef via 
Datatracker 
Date: Tuesday, October 11, 2022 at 9:54 AM
To: sec...@ietf.org 
Cc: bess@ietf.org , draft-ietf-bess-evpn-lsp-ping@ietf.org 
, last-c...@ietf.org 

Subject: [bess] Secdir last call review of draft-ietf-bess-evpn-lsp-ping-08
Reviewer: Rifaat Shekh-Yusef
Review result: Has Nits

I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written primarily for the benefit of the security area directors.

Document editors and WG chairs should treat these comments just like any other
last call comments.

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 network

Summary: Ready

This document builds on top of an existing and widely deployed mechanism, by
adding new TLVs to the LSP Ping mechanism. The existing mechanism security
properties are well defined in existing standards, and this document does not
seem to make any changes that impacts the existing security properties.

I did not see any mention of potential impact of the new TLVs on privacy. It
would be nice if that could be addressed in the security considerations section.



___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Tsvart last call review of draft-ietf-bess-evpn-lsp-ping-08

[Parag Jain (paragj)]

Hi Wesley,

We have addressed your comments in the new version of the darft 
(draft-ietf-bess-evpn-lsp-ping-09).

Thanks
Parag


From: Wesley Eddy via Datatracker 
Date: Sunday, October 9, 2022 at 7:53 PM
To: tsv-...@ietf.org 
Cc: bess@ietf.org , draft-ietf-bess-evpn-lsp-ping@ietf.org 
, last-c...@ietf.org 

Subject: Tsvart last call review of draft-ietf-bess-evpn-lsp-ping-08
Reviewer: Wesley Eddy
Review result: Ready

This document has been reviewed as part of the transport area review team's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the document's
authors and WG to allow them to address any issues raised and also to the IETF
discussion list for information.

When done at the time of IETF Last Call, the authors should consider this
review as part of the last-call comments they receive. Please always CC
tsv-...@ietf.org if you reply to or forward this review.

Some comments:
(1) Is there an 'e' missing at the end of this sentence in Section 1?:
validate data plane against the control plan.
->
validate data plane against the control plane.

(2) It seems like some words are missing in this sentence in Section 4.1:
The EVPN MAC/IP Sub-TLV identifies the MAC or ARP/ND for an EVPN
->
The EVPN MAC/IP Sub-TLV identifies the target MAC address for ARP/ND for an EVPN

(3) For IP address used for examples (e.g. in Section 6.1), consider using the
documentation prefix (RFC 5737).


___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Genart last call review of draft-ietf-bess-evpn-lsp-ping-08

[Parag Jain (paragj)]

Hi Joel,

We have addressed your comments in the new version of the darft 
(draft-ietf-bess-evpn-lsp-ping-09).

Thanks
Parag

From: Joel Halpern via Datatracker 
Date: Friday, October 7, 2022 at 9:13 PM
To: gen-...@ietf.org 
Cc: bess@ietf.org , draft-ietf-bess-evpn-lsp-ping@ietf.org 
, last-c...@ietf.org 

Subject: Genart last call review of draft-ietf-bess-evpn-lsp-ping-08
Reviewer: Joel Halpern
Review result: Ready with Nits

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

.

Document: draft-ietf-bess-evpn-lsp-ping-08
Reviewer: Joel Halpern
Review Date: 2022-10-07
IETF LC End Date: 2022-10-18
IESG Telechat date: Not scheduled for a telechat

Summary: This document is ready for publication as a Proposed Standard RFC.

Major issues: N/A

Minor issues: N/A

Nits/editorial comments:
Should the RDs in section 6.1 and 6.2 use example IP addresses instead of
1.1.1.1 and 2.2.2.2?  (ID Nits called my attention to this, and I could not
decide if it was important.  So it is a nit here.)


___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] A question pertaining to validation of LSP Ping Echo requests in draft-ietf-bess-evpn-lsp-ping-08

[Parag Jain (paragj)]

Hi Sacha

We have addressed all your comments in the new version of the darft 
(draft-ietf-bess-evpn-lsp-ping-09).

Thanks
Parag

From: Ali Sajassi (sajassi) 
Date: Wednesday, November 30, 2022 at 1:12 PM
To: Alexander Vainshtein 
Cc: bess@ietf.org , Alexander Ferdman 
, Dmitry Valdman , Ron 
Sdayoor , Nitsan Dolev , 
draft-ietf-bess-evpn-lsp-p...@ietf.org 
Subject: Re: A question pertaining to validation of LSP Ping Echo requests in 
draft-ietf-bess-evpn-lsp-ping-08
Hi Sasha,

Please refer to my comments below:



AS>> EVPN-VPWS has multiple modes, and it may be better to cover it in a 
separate draft. I will talk to Parag about a write-up of a short draft about 
EVPN-VPWS and put a clarification statement that this draft is limited to EVPN 
and EVPN-IRB.
[[Sasha]] Can you please clarify what limiting the current draft to just EVPN 
and EVPN with IRB means.
Suppose that an egress PE that has advertised a per EVI EVPN Type 1 route with 
a certain NLRI (RD, ESI, Ethernet Tag ID, Label) for an interface of an 
EVPN-VPWS instance it contains receives an LP Ping Echo request with the EVPN 
Ethernet A-D Sub-TLV in the Target FEC TLV that matches RD, ESI and Ethernet 
Tag ID of this route and with the top label that matches the label in the 
advertised route. Which return code should t use in its reply?

AS> We need to look at all the modes in EVPN-VPWS, if we can cover it easily in 
the existing draft, we’ll cover it. If not, we’ll do it in another draft. Since 
for LSP ping, we are talking about MPLS service path only and not end-to-end 
forwarding path, my guess would be we should be able to cover it in the 
existing draft.


AS>> When an EVPN is configured for symmetric IRB mode, then ARP/ND is 
terminated locally and thus there is no need to verify it remotely (actually 
you cannot verify it remotely!). However, for asymmetric IRB, ARP/ND is 
processed remotely and thus should be verify it remotely. That’s why I have the 
text the way I have written it.

[[Sasha]] Suppose that two PEs are attached to an All-Active MH ES, and both 
are configured with a MAC-VRF attached to this MH ES and configured with a 
Symmetric EVPN IRB with anycast IP and MAC address. Suppose further that one 
(and it typically would be just one) of these PEs receives an P message with a 
certain IP→MAC pair in its sender part and advertises this pair in an EVPN Type 
2 route with Labl1 and Label2. What prevents the other PE from sending an LSP 
Ping Echo request with the EVPN MACIP Sub-TLV in the Target FEC stack TLV and 
with the label it has received in the Label1 field of the advertised route to 
the PE that has advertised this route, and what, if anything, prevents it from 
responding with return code 3 to such a request?

AS> That’s perfectly fine and the egress PE responds with return code 3. This 
follows the clarification text that I had earlier: “When the remote PE receives 
MAC/IP Sub-TLV containing both MAC and IP addresses and if the EVPN label 
points to a MAC-VRF, then it validates the MAC state and forwarding. If the 
remote PE is not configured in symmetric IRB mode, then it validates ARP/ND 
state as well.”

Cheers,
Ali
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] A question pertaining to validation of LSP Ping Echo requests in draft-ietf-bess-evpn-lsp-ping-08

[Parag Jain (paragj)]

Hi Sacha

Thank you for your question and comments. Yes, LSP Ping for EVPN VPWS service 
can be supported by defining and returning new return code in echo reply 
message. We will add the details in the next version of the draft and address 
all your comments.

Thanks
Parag

From: Alexander Vainshtein 
Date: Thursday, November 24, 2022 at 2:54 AM
To: Ali Sajassi (sajassi) 
Cc: bess@ietf.org , Alexander Ferdman 
, Dmitry Valdman , Ron 
Sdayoor , Nitsan Dolev , 
draft-ietf-bess-evpn-lsp-p...@ietf.org 
Subject: RE: A question pertaining to validation of LSP Ping Echo requests in 
draft-ietf-bess-evpn-lsp-ping-08
Hi Ali,
Lots of thanks for a prompt and very detailed response, and my sincere 
apologies for a delayed response.
Please see a short comment to your response marked [[Sasha]] inline below.


Please note also that I have recently added yet another question to my list, I 
am copying here it for your convenience:

RFC 8214 defines usage of per EVI EVPN A-D 
(Type 1) routes in EVPN-VPWS in addition to their usage for aliasing/backup 
path defined in RFC 7432.  Suppose that the operator tries to perform a 
connectivity check to the aliasing function of some EVI but the PE that 
receives an LSP Ping Echo request with the EVPN Ethernet AD sub-TLV in the 
target label stack and label has advertised this FEC and label for a specific 
Attachment Circuit of an EVPN-VPWS instance. Is there any way it can indicate 
in the Echo Reply message that the label matches the target FEC but this FEC 
and label are used for EVPN-VPWS and not for aliasing?

I see that the current version of the draft does not even mention RFC 8214
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] I-D Action: draft-saum-evpn-lsp-ping-extension-01.txt

[Parag Jain (paragj)]

Dear Authors,

I have following comments on the draft.


  1.  Problem description – premise of problem statement does not right to me. 
Section 4.1 and 4.2 mention complexity of remembering NLRI and FEC string by 
operator. Operator is not supposed to enter any of these. The ping 
implementation should be filling in  NLRI and FEC etc from protocols (e.g. evpn 
bgp). This is how lsp ping have been implemented industry wide for l3vpn, l2vpn 
etc.


  1.  Comment regarding CP checks, its up to the implementation to do CP checks 
or not. Router processing the ping packet can choose not do any CP checks.

Thanks
Parag


From: BESS  on behalf of Dikshit, Saumya 

Date: Thursday, July 14, 2022 at 4:46 AM
To: bess-cha...@ietf.org 
Cc: Loa Andersson , draft-saum-evpn-lsp-ping-extens...@ietf.org 
, BESS 
Subject: Re: [bess] I-D Action: draft-saum-evpn-lsp-ping-extension-01.txt
Hello Chairs,

This draft was written as part of review comments discussed on the 
https://datatracker.ietf.org/doc/html/draft-jain-bess-evpn-lsp-ping
as the authors of 
"https://datatracker.ietf.org/doc/html/draft-jain-bess-evpn-lsp-ping; wanted to 
keep the comments as new
requirements. Kindly review and suggest on taking this draft to conclusion.

Regards,
Saumya.

-Original Message-
From: Dikshit, Saumya
Sent: Friday, June 3, 2022 7:37 PM
To: 'bess-cha...@ietf.org' 
Cc: 'Loa Andersson' ; 'draft-saum-evpn-lsp-ping-extens...@ietf.org' 
; 'BESS' 
Subject: RE: [bess] I-D Action: draft-saum-evpn-lsp-ping-extension-01.txt

Hello Chairs,

It will be great if you can review this draft and include it as part of bess WG.
This draft surely helps solving issues which should help taking ensuring ease 
of serviceability from end-user point of view.

Regards,
Saumy.a

-Original Message-
From: Dikshit, Saumya
Sent: Friday, June 3, 2022 7:32 PM
To: 'Loa Andersson' ; draft-saum-evpn-lsp-ping-extens...@ietf.org; 
BESS 
Subject: RE: [bess] I-D Action: draft-saum-evpn-lsp-ping-extension-01.txt

Hi Loa,

Thanks for the comments. I will surely update the section in the next-version.

Regards,
Saumya.

-Original Message-
From: Loa Andersson [mailto:l...@pi.nu]
Sent: Friday, June 3, 2022 1:15 PM
To: Dikshit, Saumya ; 
draft-saum-evpn-lsp-ping-extens...@ietf.org; BESS 
Subject: Re: [bess] I-D Action: draft-saum-evpn-lsp-ping-extension-01.txt

Saumua,

Inline please (and yes I understand that this is nit-picking, but sometimes one 
could do that :) ).




On 2022-05-31 07:15, Dikshit, Saumya wrote:
> Hi Loa,
>
 Can you please explain what it means.
>  It implies any re-use of the values from  allocated via 
> [I-D.draft-ietf-bess-evpn-lsp-ping] when the same-parameter is referred to in 
> [I-D.draft-saum-evpn-lsp-ping-extension].

First,  if this text goes into the RFC, it is totally redundant.

Second, I can understand that this is useful information to have while this is 
an individual or a working group document. Though I think that "inherit" is 
misleading (for me it implies some type of ownership).

With some experience to guide documents through more or less trick IANA 
allocations I would change the the IANA Considerations to:

8.  IANA Considerations

 This document makes no request for IANA allocations.

 This document is dependent on the IANA considerations discussed in
 [I-D.draft-ietf-bess-evpn-lsp-ping].

 This section should be removed before publication as an RFC.


>
 . I would be appreciated if you notified the wg when you allocate 
 parameters from this registry, or notify our LSP Ping registry experts, 
 Carlos and Mach.
>  +1. It's the first cut of the document.

Yes, understood. I was really thinking about draft-ietf-bess-evpn-lsp-ping when 
I said that :). But down the line it is applicable to this draft also.

/Loa
Expecting few more changes based on further discussions and before firming-up 
on newly introduced parameters.
>
> Regards,
> Saumya.
>
> -Original Message-
> From: Loa Andersson [mailto:l...@pi.nu]
> Sent: Monday, May 30, 2022 5:36 PM
> To: draft-saum-evpn-lsp-ping-extens...@ietf.org; BESS 
> Subject: Re: I-D Action: draft-saum-evpn-lsp-ping-extension-01.txt
>
> Authors,
>
> the IANA section of this draft says:
>
>  This document inherits all the IANA considerations discussed in
>  [I-D.draft-ietf-bess-evpn-lsp-ping].
>
> Can you please explain what it means.
>
> WG Chairs
>
> The MPLS working group have put in quite a bit of effort to keep the LSP Ping 
> parameter registry consistent. I would be appreciated if you notified the wg 
> when you allocate parameters from this registry, or notify our LSP Ping 
> registry experts, Carlos and Mach.
>
> As for the allocations made in draft-ietf-bess-evpn-lsp-ping, I see no 
> problems.
>
> /Loa
>
>
> On 2022-05-30 13:36, internet-dra...@ietf.org wrote:
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts 
>> directories.
>>
>>
>>   Title   : EVPN Mpls Ping Extension
>>   

Re: [bess] Rtgdir last call review of draft-ietf-bess-evpn-lsp-ping-07

[Parag Jain (paragj)]

Hi Joel,

I have addressed your comments and uploaded a new version of the doc.

Thanks
Parag

From: Parag Jain (paragj) 
Date: Monday, June 20, 2022 at 10:26 AM
To: Joel Halpern , rtg-...@ietf.org 
Cc: bess@ietf.org , draft-ietf-bess-evpn-lsp-ping@ietf.org 
, last-c...@ietf.org 

Subject: Re: Rtgdir last call review of draft-ietf-bess-evpn-lsp-ping-07
Hi Joel

Thanks for the directorate review comments. Let me incorporate them and publish 
new version.

Thanks
Parag

From: Joel Halpern via Datatracker 
Date: Thursday, June 16, 2022 at 9:47 AM
To: rtg-...@ietf.org 
Cc: bess@ietf.org , draft-ietf-bess-evpn-lsp-ping@ietf.org 
, last-c...@ietf.org 

Subject: Rtgdir last call review of draft-ietf-bess-evpn-lsp-ping-07
Reviewer: Joel Halpern
Review result: Ready

This is a routing directorate review of draft-ietf-bess-evpn-lsp-ping-07
provided by Joel Halpern at the request of the routing directorate review team
leaders as input to the routing area directors.  Please treat as any other
review comments.

(Apologies for the delay.)

This document is Ready for publication as a Proposed Standard RFC.

Comments:
Major: None

Minor:
Section 4.1 describes the EVPN MAC Sub-TLV.  And states it is derived from
MAC/IP advertisement route.  I note that in RFC 7623 (PBB-EVPN) there are
restrictions on several of these fields.  Should this section note at least
that in the PBB-EVPN case those restrictions apply (probably with a
pointer, not repeating the restrictions)?

 Section 4.4 describes EVPN IP Prefix Sub-TLV.  From the wording I suspect
 that it applies only to the EVPN case and not to the PBB-EVPN case.  In
 4.3, the text was explicit about that applicability.  Could we be equally
 clear here?



___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Rtgdir last call review of draft-ietf-bess-evpn-lsp-ping-07

[Parag Jain (paragj)]

Hi Joel

Thanks for the directorate review comments. Let me incorporate them and publish 
new version.

Thanks
Parag

From: Joel Halpern via Datatracker 
Date: Thursday, June 16, 2022 at 9:47 AM
To: rtg-...@ietf.org 
Cc: bess@ietf.org , draft-ietf-bess-evpn-lsp-ping@ietf.org 
, last-c...@ietf.org 

Subject: Rtgdir last call review of draft-ietf-bess-evpn-lsp-ping-07
Reviewer: Joel Halpern
Review result: Ready

This is a routing directorate review of draft-ietf-bess-evpn-lsp-ping-07
provided by Joel Halpern at the request of the routing directorate review team
leaders as input to the routing area directors.  Please treat as any other
review comments.

(Apologies for the delay.)

This document is Ready for publication as a Proposed Standard RFC.

Comments:
Major: None

Minor:
Section 4.1 describes the EVPN MAC Sub-TLV.  And states it is derived from
MAC/IP advertisement route.  I note that in RFC 7623 (PBB-EVPN) there are
restrictions on several of these fields.  Should this section note at least
that in the PBB-EVPN case those restrictions apply (probably with a
pointer, not repeating the restrictions)?

 Section 4.4 describes EVPN IP Prefix Sub-TLV.  From the wording I suspect
 that it applies only to the EVPN case and not to the PBB-EVPN case.  In
 4.3, the text was explicit about that applicability.  Could we be equally
 clear here?


___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] ID-Nits for draft-ietf-bess-evpn-lsp-ping

[Parag Jain (paragj)]

Hi Matthew

Will do.

Thanks
Parag

From: "Bocci, Matthew (Nokia - GB)" 
Date: Wednesday, February 2, 2022 at 11:10 AM
To: "draft-ietf-bess-evpn-lsp-p...@ietf.org" 

Cc: "bess-cha...@ietf.org" , "bess@ietf.org" 

Subject: Re: ID-Nits for draft-ietf-bess-evpn-lsp-ping
Resent-From: 
Resent-To: , , , 
, 
Resent-Date: Wednesday, February 2, 2022 at 11:09 AM

Hi Authors

While going through this I have a couple of other comments:

Please can you clean up the use of RFC2119 language, in particular capitalizing 
SHOULD, MUST etc where appropriate. For example, I think the following in 
Section 4.3 should be corrected:


Ethernet Tag field value in EVPN Ethernet AD Sub-TLV, should be set

   according to the context:



   o  For per-ES context, the Ethernet Tag field in the sub-TLV must be

  set to the reserved MAX-ET value 
[RFC7432]



   o  For per-EVI context, the Ethernet Tag field in the sub-TLV must be

  set to the non-reserved value


Thanks
Matthew

From: Bocci, Matthew (Nokia - GB) 
Date: Wednesday, 2 February 2022 at 16:00
To: draft-ietf-bess-evpn-lsp-p...@ietf.org 

Cc: bess-cha...@ietf.org 
Subject: ID-Nits for draft-ietf-bess-evpn-lsp-ping
Hi Authors

I am finally doing the document shepherds write up for this draft. ID Nits 
throws up a few warnings, which I would appreciate if you could fix now before 
I request publication:

https://www.ietf.org/tools/idnits?url=https://www.ietf.org/archive/id/draft-ietf-bess-evpn-lsp-ping-06.txt


Thanks

Matthew
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] A question about draft-ietf-bess-evpn-lsp-ping

[Parag Jain (paragj)]

Hi Sacha

Pls see inline.

From: Alexander Vainshtein 
Date: Sunday, December 5, 2021 at 4:56 AM
To: "Parag Jain (paragj)" 
Cc: "bess@ietf.org" , 
"draft-ietf-bess-evpn-lsp-ping@ietf.org" 

Subject: RE: A question about draft-ietf-bess-evpn-lsp-ping

Parag,
Lots of thanks for your response.

The updates to the draft that you have suggested (in this and previous emails) 
look good to me

However, I am not sure your response to my last question really addresses it – 
please see inline below.

Regards,
Sasha

Office: +972-39266302
Cell:  +972-549266302
Email:   alexander.vainsht...@rbbn.com

From: Parag Jain (paragj) 
Sent: Friday, December 3, 2021 5:31 AM
To: Alexander Vainshtein 
Cc: bess@ietf.org; draft-ietf-bess-evpn-lsp-ping@ietf.org
Subject: [EXTERNAL] Re: A question about draft-ietf-bess-evpn-lsp-ping

Hi Sacha,

Thanks for the thorough review of the draft and your comments  and questions. 
Please see inline.


From: Alexander Vainshtein 
mailto:alexander.vainsht...@rbbn.com>>
Date: Monday, November 22, 2021 at 11:18 AM
To: "Parag Jain (paragj)" mailto:par...@cisco.com>>
Cc: "bess@ietf.org<mailto:bess@ietf.org>" 
mailto:bess@ietf.org>>, 
"draft-ietf-bess-evpn-lsp-ping@ietf.org<mailto:draft-ietf-bess-evpn-lsp-ping@ietf.org>"
 
mailto:draft-ietf-bess-evpn-lsp-ping@ietf.org>>
Subject: RE: A question about draft-ietf-bess-evpn-lsp-ping

Parag and all,
A gentle reminder...

Regards,
Sasha

Office: +972-39266302
Cell:  +972-549266302
Email:   alexander.vainsht...@rbbn.com<mailto:alexander.vainsht...@rbbn.com>

From: Alexander Vainshtein
Sent: Sunday, October 31, 2021 12:44 PM
To: Parag Jain (paragj) mailto:par...@cisco.com>>
Cc: bess@ietf.org<mailto:bess@ietf.org>; 
draft-ietf-bess-evpn-lsp-ping@ietf.org<mailto:draft-ietf-bess-evpn-lsp-ping@ietf.org>
Subject: RE: A question about draft-ietf-bess-evpn-lsp-ping

Parag, and all,
A couple of additional questions dealing with the definition of  the EVPN AD 
sub-TLV in Section 4.3 of the 
draft<https://clicktime.symantec.com/3BF2Yofw2ibCfgs5o9Ggk7Q7GS?u=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-bess-evpn-lsp-ping%23section-4.3>.

  1.  I assume that this sub-TLV can be used to differentiate between per-ES 
and per-EVI EVPN Ethernet Auto-Discovery (Type 1) routes by the value of 
Ethernet Tag:
 *   For per-ES EVPN Type 1 routes the Ethernet Tag field in the sub-TLV 
must be set to the reserved MAX-ET value
 *   For per-EVI EVPN Type 1 routes the Ethernet Tag field in the sub-TLV 
must be set to the non-reserved value
If this assumption is correct, it would be nice to have this explicitly 
specified in the draft

Paragj> yes, this is right. Will update the draft to clarify.


  1.  There no references to the EVPN AD sub-TLV in the draft. Instead, there 
are two references to the Ethernet AD sub-TLV

Paragj> thanks for pointing this out. Will update the draft to replace all 
references to Ethernet AD sub-TLV  with EVPN Ethernet AD Sub-TLV.


 *   In the last para of Section 6.2.1 when it is included in the Target 
FEC TLV of an LSP Ping request while an ESI label advertised by the 
corresponding remote PE for the MH ES identified by the ESI value in the 
sub-TLV is included in the label stack. My guess is that in this case this 
sub-TLV refers to the per-ES EVPN Type 1 route – can you please confirm?

Paragj> yes, that’s right. Will update the draft to clarify.


 *   In Section 6.3 when this sub-TLV it is included in the Target FEC TLV 
of an LSP Ping request while the label stack includes the aliasing label 
advertised by the specific MAC-VRF of the remote PE for the MH ES identified by 
the ESI value in the sub-TLV is included in the label stack. My guess is that 
in this case this sub-TLV refers to the per-EVI EVPN Type 1 route – can you 
please confirm?
Paragj> yes, that’s right. Will update the draft to clarify.


  1.  Section 8.2 of RFC 
7432<https://clicktime.symantec.com/3FvUcdCR8RT35G7PAjqTsyr7GS?u=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc7432%23section-8.2>
 specifies that a per-ES EVPN Type 1 route for a given multi-homed ES may be 
advertises multiple times with different RD values because it may carry more 
Route Targets than could be fit into a single BGP Update message. Can you 
please explain which RD value should be used in the EVPN AD sub-TLV if it is 
used in association with a per-ES EVPN Type 1 route in (2b) above?

Paragj> The RD value should correspond to the RD received for the EVI in the 
per-ES EVPN Type-1 route. Will update the draft to clarify.
[[Sasha]] A per-ES EVPN Type 1 route is advertised with (export) RTs of all the 
EVI that are  attached to it, and multiple such routes for the same MH ES are 
advertised with different RD values in the NLRI if the list of RTs is too long 
to fit into a single BGP Update

Re: [bess] A question about draft-ietf-bess-evpn-lsp-ping

[Parag Jain (paragj)]

Hi Sacha,

Thanks for the thorough review of the draft and your comments  and questions. 
Please see inline.


From: Alexander Vainshtein 
Date: Monday, November 22, 2021 at 11:18 AM
To: "Parag Jain (paragj)" 
Cc: "bess@ietf.org" , 
"draft-ietf-bess-evpn-lsp-ping@ietf.org" 

Subject: RE: A question about draft-ietf-bess-evpn-lsp-ping

Parag and all,
A gentle reminder...

Regards,
Sasha

Office: +972-39266302
Cell:  +972-549266302
Email:   alexander.vainsht...@rbbn.com

From: Alexander Vainshtein
Sent: Sunday, October 31, 2021 12:44 PM
To: Parag Jain (paragj) 
Cc: bess@ietf.org; draft-ietf-bess-evpn-lsp-ping@ietf.org
Subject: RE: A question about draft-ietf-bess-evpn-lsp-ping

Parag, and all,
A couple of additional questions dealing with the definition of  the EVPN AD 
sub-TLV in Section 4.3 of the 
draft<https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-lsp-ping#section-4.3>.

  1.  I assume that this sub-TLV can be used to differentiate between per-ES 
and per-EVI EVPN Ethernet Auto-Discovery (Type 1) routes by the value of 
Ethernet Tag:
 *   For per-ES EVPN Type 1 routes the Ethernet Tag field in the sub-TLV 
must be set to the reserved MAX-ET value
 *   For per-EVI EVPN Type 1 routes the Ethernet Tag field in the sub-TLV 
must be set to the non-reserved value
If this assumption is correct, it would be nice to have this explicitly 
specified in the draft

Paragj> yes, this is right. Will update the draft to clarify.


  1.  There no references to the EVPN AD sub-TLV in the draft. Instead, there 
are two references to the Ethernet AD sub-TLV

Paragj> thanks for pointing this out. Will update the draft to replace all 
references to Ethernet AD sub-TLV  with EVPN Ethernet AD Sub-TLV.


 *   In the last para of Section 6.2.1 when it is included in the Target 
FEC TLV of an LSP Ping request while an ESI label advertised by the 
corresponding remote PE for the MH ES identified by the ESI value in the 
sub-TLV is included in the label stack. My guess is that in this case this 
sub-TLV refers to the per-ES EVPN Type 1 route – can you please confirm?

Paragj> yes, that’s right. Will update the draft to clarify.


 *   In Section 6.3 when this sub-TLV it is included in the Target FEC TLV 
of an LSP Ping request while the label stack includes the aliasing label 
advertised by the specific MAC-VRF of the remote PE for the MH ES identified by 
the ESI value in the sub-TLV is included in the label stack. My guess is that 
in this case this sub-TLV refers to the per-EVI EVPN Type 1 route – can you 
please confirm?
Paragj> yes, that’s right. Will update the draft to clarify.


  1.  Section 8.2 of RFC 
7432<https://datatracker.ietf.org/doc/html/rfc7432#section-8.2> specifies that 
a per-ES EVPN Type 1 route for a given multi-homed ES may be advertises 
multiple times with different RD values because it may carry more Route Targets 
than could be fit into a single BGP Update message. Can you please explain 
which RD value should be used in the EVPN AD sub-TLV if it is used in 
association with a per-ES EVPN Type 1 route in (2b) above?

Paragj> The RD value should correspond to the RD received for the EVI in the 
per-ES EVPN Type-1 route. Will update the draft to clarify.

Thanks
Parag

Regards,
Sasha

Office: +972-39266302
Cell:  +972-549266302
Email:   alexander.vainsht...@rbbn.com<mailto:alexander.vainsht...@rbbn.com>

From: Alexander Vainshtein
Sent: Sunday, October 31, 2021 12:03 PM
To: Parag Jain (paragj) mailto:par...@cisco.com>>
Cc: bess@ietf.org<mailto:bess@ietf.org>; 
draft-ietf-bess-evpn-lsp-ping@ietf.org<mailto:draft-ietf-bess-evpn-lsp-ping@ietf.org>
Subject: RE: A question about draft-ietf-bess-evpn-lsp-ping
Importance: High

Parag,
Lots of thanks for a prompt response.

At the same time your response does not resolve my concerns, since I have 
failed to understand why in Example#1 you propose responding with “return code 
3 - Replying router is an egress for the FEC at stack-depth” while in Example#2 
you propose responding with “return code corresponding to The FEC exists on the 
PE and the behavior is to drop the packet because of Split Horizon Filtering”.

In both cases a BUM packet received by PE-1 with the label stack described 
would not be discarded:

  *   In example 1 it would be sent towards CE-2 and CE-4 (but not to CE-2 
because PE-1 is not the DF on MH ES-1)
  *   In example 2 it still would be sent towards CE-4 (because it is a 
single-homed CE).

In any case I think that explicit definition of the scenarios in which any of 
the new return codes should be used in missing in the draft.

Regards,
Sasha

Office: +972-39266302
Cell:  +972-549266302
Email:   alexander.vainsht...@rbbn.com<mailto:alexander.vainsht...@rbbn.com>

From: Parag Jain (paragj) mailto:par...@cisco.com>>
Sent: Friday, October 29, 2021 5:34 AM
To: Alexander Vainshtein 
mailto:alexan

Re: [bess] A question about draft-ietf-bess-evpn-lsp-ping

[Parag Jain (paragj)]

Hi Sacha

Missed your earlier email.

Thanks for following up. Let me get back to you.

Thanks
Parag

From: Alexander Vainshtein 
Date: Monday, November 22, 2021 at 11:18 AM
To: "Parag Jain (paragj)" 
Cc: "bess@ietf.org" , 
"draft-ietf-bess-evpn-lsp-ping@ietf.org" 

Subject: RE: A question about draft-ietf-bess-evpn-lsp-ping

Parag and all,
A gentle reminder...

Regards,
Sasha

Office: +972-39266302
Cell:  +972-549266302
Email:   alexander.vainsht...@rbbn.com

From: Alexander Vainshtein
Sent: Sunday, October 31, 2021 12:44 PM
To: Parag Jain (paragj) 
Cc: bess@ietf.org; draft-ietf-bess-evpn-lsp-ping@ietf.org
Subject: RE: A question about draft-ietf-bess-evpn-lsp-ping

Parag, and all,
A couple of additional questions dealing with the definition of  the EVPN AD 
sub-TLV in Section 4.3 of the 
draft<https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-lsp-ping#section-4.3>.

  1.  I assume that this sub-TLV can be used to differentiate between per-ES 
and per-EVI EVPN Ethernet Auto-Discovery (Type 1) routes by the value of 
Ethernet Tag:
 *   For per-ES EVPN Type 1 routes the Ethernet Tag field in the sub-TLV 
must be set to the reserved MAX-ET value
 *   For per-EVI EVPN Type 1 routes the Ethernet Tag field in the sub-TLV 
must be set to the non-reserved value
If this assumption is correct, it would be nice to have this explicitly 
specified in the draft

  1.  There no references to the EVPN AD sub-TLV in the draft. Instead, there 
are two references to the Ethernet AD sub-TLV
 *   In the last para of Section 6.2.1 when it is included in the Target 
FEC TLV of an LSP Ping request while an ESI label advertised by the 
corresponding remote PE for the MH ES identified by the ESI value in the 
sub-TLV is included in the label stack. My guess is that in this case this 
sub-TLV refers to the per-ES EVPN Type 1 route – can you please confirm?
 *   In Section 6.3 when this sub-TLV it is included in the Target FEC TLV 
of an LSP Ping request while the label stack includes the aliasing label 
advertised by the specific MAC-VRF of the remote PE for the MH ES identified by 
the ESI value in the sub-TLV is included in the label stack. My guess is that 
in this case this sub-TLV refers to the per-EVI EVPN Type 1 route – can you 
please confirm?
  2.  Section 8.2 of RFC 
7432<https://datatracker.ietf.org/doc/html/rfc7432#section-8.2> specifies that 
a per-ES EVPN Type 1 route for a given multi-homed ES may be advertises 
multiple times with different RD values because it may carry more Route Targets 
than could be fit into a single BGP Update message. Can you please explain 
which RD value should be used in the EVPN AD sub-TLV if it is used in 
association with a per-ES EVPN Type 1 route in (2b) above?

Regards,
Sasha

Office: +972-39266302
Cell:  +972-549266302
Email:   alexander.vainsht...@rbbn.com<mailto:alexander.vainsht...@rbbn.com>

From: Alexander Vainshtein
Sent: Sunday, October 31, 2021 12:03 PM
To: Parag Jain (paragj) mailto:par...@cisco.com>>
Cc: bess@ietf.org<mailto:bess@ietf.org>; 
draft-ietf-bess-evpn-lsp-ping@ietf.org<mailto:draft-ietf-bess-evpn-lsp-ping@ietf.org>
Subject: RE: A question about draft-ietf-bess-evpn-lsp-ping
Importance: High

Parag,
Lots of thanks for a prompt response.

At the same time your response does not resolve my concerns, since I have 
failed to understand why in Example#1 you propose responding with “return code 
3 - Replying router is an egress for the FEC at stack-depth” while in Example#2 
you propose responding with “return code corresponding to The FEC exists on the 
PE and the behavior is to drop the packet because of Split Horizon Filtering”.

In both cases a BUM packet received by PE-1 with the label stack described 
would not be discarded:

  *   In example 1 it would be sent towards CE-2 and CE-4 (but not to CE-2 
because PE-1 is not the DF on MH ES-1)
  *   In example 2 it still would be sent towards CE-4 (because it is a 
single-homed CE).

In any case I think that explicit definition of the scenarios in which any of 
the new return codes should be used in missing in the draft.

Regards,
Sasha

Office: +972-39266302
Cell:  +972-549266302
Email:   alexander.vainsht...@rbbn.com<mailto:alexander.vainsht...@rbbn.com>

From: Parag Jain (paragj) mailto:par...@cisco.com>>
Sent: Friday, October 29, 2021 5:34 AM
To: Alexander Vainshtein 
mailto:alexander.vainsht...@rbbn.com>>; 
draft-ietf-bess-evpn-lsp-ping@ietf.org<mailto:draft-ietf-bess-evpn-lsp-ping@ietf.org>
Cc: bess@ietf.org<mailto:bess@ietf.org>
Subject: [EXTERNAL] Re: A question about draft-ietf-bess-evpn-lsp-ping
Importance: High

Hi Alexander,

Please see inline.


From: Alexander Vainshtein 
mailto:alexander.vainsht...@rbbn.com>>
Date: Tuesday, October 26, 2021 at 11:51 AM
To: 
"draft-ietf-bess-evpn-lsp-ping@ietf.org<mailto:draft-ietf-bess-evp

Re: [bess] Query/comments on draft-ietf-bess-evpn-lsp-ping-05

[Parag Jain (paragj)]

Hi Saumya

Thank you agreeing to progressing draft-ietf-bess-evpn-lsp-ping in the current 
state.

Thank you Saumya and Greg for closing on this.

I’ll be happy to participate in the new proposal discussions.

regards
Parag

From: "Dikshit, Saumya" 
Date: Wednesday, October 13, 2021 at 12:10 AM
To: Greg Mirsky , BESS 
Cc: "draft-ietf-bess-evpn-lsp-p...@ietf.org" 
, "Parag Jain (paragj)" 

Subject: RE: Query/comments on draft-ietf-bess-evpn-lsp-ping-05

Hi Greg,

Thank you for acknowledging.
I agree that a new extension draft should be written to include below proposals.

+1 on progressing with current state of this draft draft-ietf-bess-evpn-lsp-ping

Thanks
Saumya.

From: Greg Mirsky [mailto:gregimir...@gmail.com]
Sent: Tuesday, October 12, 2021 9:39 PM
To: Dikshit, Saumya ; BESS 
Cc: draft-ietf-bess-evpn-lsp-p...@ietf.org; Parag Jain (paragj) 

Subject: Re: Query/comments on draft-ietf-bess-evpn-lsp-ping-05

Hi Saumya,
thank you for sharing your ideas about extending EVNP LSP Ping functionality. 
These are interesting and useful proposals that, in my opinion, further extend 
the basic functionality of EVNP LSP Ping as defined in the draft. I'll be happy 
to discuss and work with you and others on a new document to introduce new 
extensions. In the meantime, progressing the current version of the EVPN LSP 
Ping document with the "classic" 8209-style scope is extremely important for 
network operators that need standard-based OAM tools in their toolboxes.
What is your opinion?

Regards,
Greg

On Tue, Sep 14, 2021 at 7:24 AM Dikshit, Saumya 
mailto:saumya.diks...@hpe.com>> wrote:
Multicasting it to authors of the draft, if the below use cases and (potential) 
solution can be made as part of this draft.

Thanks
Saumya.



From: BESS [mailto:bess-boun...@ietf.org<mailto:bess-boun...@ietf.org>] On 
Behalf Of Dikshit, Saumya
Sent: Monday, September 13, 2021 7:31 PM
To: Greg Mirsky mailto:gregimir...@gmail.com>>
Cc: 
draft-ietf-bess-evpn-lsp-p...@ietf.org<mailto:draft-ietf-bess-evpn-lsp-p...@ietf.org>;
 bess-cha...@ietf.org<mailto:bess-cha...@ietf.org>; Parag Jain (paragj) 
mailto:par...@cisco.com>>; bess@ietf.org<mailto:bess@ietf.org>
Subject: Re: [bess] Query/comments on draft-ietf-bess-evpn-lsp-ping-05

Thank you Greg.

+1 on this drafts compliance to RFC8209.

There are couple of requirements spelled out in the email below, summarizing it 
here as well:

1.   Allow wild-card/don’t-care values for attributes carried in the 
sub-TLVs as it will surely help when all details are not available. To draw 
parallels I see it equivalent to querying for an (potential) NLRI in a BGP-EVPN 
RIB via a management interface, where in all parameters hard to gather.

2. Test the reachability to tenant-VRF VRF_X (with EVPN mapped EVI) 
configured on the remote PE, PE1. VRF_X has no active IP/IPv6 interface 
configured and its sole usage is to obtain the leaked (via IVRL) routes from 
other VRFs (non-EVPN) and PE1 publishes this to other peers via EVPN control 
plane. Till the first prefix (learnt ) route is published (Route Type 5) by PE1 
for the EVI (mapped to VRF_X), the tunnels will not be provisioned on other 
PEs. Hence an lsp-ping to validate the configuration of VRF_X on remote PE 
should help here.
If this can be achieved by incremental changes to this draft, shall be helpful. 
#2 requirement is equally applicable to VRF-LITE as well and can be called out 
an extension to rfc8209.
Regards,
Saumya.

From: Greg Mirsky [mailto:gregimir...@gmail.com]
Sent: Monday, September 13, 2021 12:23 AM
To: Dikshit, Saumya mailto:saumya.diks...@hpe.com>>
Cc: Parag Jain (paragj) mailto:par...@cisco.com>>; 
draft-ietf-bess-evpn-lsp-p...@ietf.org<mailto:draft-ietf-bess-evpn-lsp-p...@ietf.org>;
 bess@ietf.org<mailto:bess@ietf.org>; 
bess-cha...@ietf.org<mailto:bess-cha...@ietf.org>
Subject: Re: Query/comments on draft-ietf-bess-evpn-lsp-ping-05

Hi Saumya,
thank you for your comments and questions.
As I understand the draft, it does not update RFC 8029 and, as a result, 
everything that has been defined in RFC 8029 is fully applicable and can be 
used in EVPN and MVPN environments. If there's any part of the text that is not 
clear, please let me know and we can work together on improving it.

Regards,
Greg

On Sun, Sep 12, 2021 at 10:02 AM Dikshit, Saumya 
mailto:saumya.diks...@hpe.com>> wrote:
Hi Parag,

Thank you for the response. Please see inline with tag [SD2] and provide your 
further inputs.

Thanks
Saumya.

From: Parag Jain (paragj) [mailto:par...@cisco.com<mailto:par...@cisco.com>]
Sent: Saturday, September 11, 2021 8:19 PM
To: Dikshit, Saumya mailto:saumya.diks...@hpe.com>>; 
draft-ietf-bess-evpn-lsp-p...@ietf.org<mailto:draft-ietf-bess-evpn-lsp-p...@ietf.org>;
 bess@ietf.org<mailto:bess@ietf.org>
Cc: bess-cha...@ietf.org<mailto:bess-cha...@ietf.org>
Subject: Re: Qu

Re: [bess] Query/comments on draft-ietf-bess-evpn-lsp-ping-05

[Parag Jain (paragj)]

Hi Saumya

Pls see inline.

From: "Dikshit, Saumya" 
Date: Thursday, September 9, 2021 at 3:54 AM
To: "Parag Jain (paragj)" , 
"draft-ietf-bess-evpn-lsp-p...@ietf.org" 
, "bess@ietf.org" 
Cc: "bess-cha...@ietf.org" 
Subject: RE: Query/comments on draft-ietf-bess-evpn-lsp-ping-05

Hi Parag,

Please see inline. Let me know your thoughts.

Thanks
Saumya.

From: Parag Jain (paragj) [mailto:par...@cisco.com]
Sent: Wednesday, September 8, 2021 11:43 PM
To: Dikshit, Saumya ; 
draft-ietf-bess-evpn-lsp-p...@ietf.org; bess@ietf.org
Cc: bess-cha...@ietf.org
Subject: Re: Query/comments on draft-ietf-bess-evpn-lsp-ping-05

Hi Saumya

Pls see inline.

From: "Dikshit, Saumya" mailto:saumya.diks...@hpe.com>>
Date: Tuesday, September 7, 2021 at 3:22 PM
To: "Parag Jain (paragj)" mailto:par...@cisco.com>>, 
"draft-ietf-bess-evpn-lsp-p...@ietf.org<mailto:draft-ietf-bess-evpn-lsp-p...@ietf.org>"
 
mailto:draft-ietf-bess-evpn-lsp-p...@ietf.org>>,
 "bess@ietf.org<mailto:bess@ietf.org>" mailto:bess@ietf.org>>
Cc: "bess-cha...@ietf.org<mailto:bess-cha...@ietf.org>" 
mailto:bess-cha...@ietf.org>>
Subject: RE: Query/comments on draft-ietf-bess-evpn-lsp-ping-05

Hi Parag,

Thanks for the response. I have few bullets on the same.
Please help clarify and if there is a need to call them out explicitly.


  1.  “Consistency checkers” feature-set does validates the CP-DP parity and 
can be leveraged via management interface to the box.
 *   Do you imply the consistency check between protocol RIB and the 
dataplane FIB, Or the consistency between Software FIB (slow path) and the 
LC-FIB
Paragj> CP would mean BGP/EVPN/RIB which ever CP component has the info 
included in the sub-TLVs.
[SD] I am little unclear, as to how running the Sub-TLV parameters through the 
RIB, will ensure that this RIB entry (NLRI) was CHOSEN as the FIB entry.
Essentially, the RIB entry mapping to the Sub-TLV, has to contend with other 
RIB entries and also with same route published by other protocols (or instances 
of protocol), eventually get picked as FIB entry.  Lsp ping to the sub-tlv may 
pan out differently in RIB and in FIB. But as I understand, that is not the 
purpose of this reachability check defined in this draft.

Paragj2> I also mentioned bgp and evpn CP components above.

We should call out this out specifically in the document or stick to validating 
the datapath.
Paragj2> DP-CP consistency check is an important part of lsp ping 
functionality. As RFC8029 states, the LSP echo message contains sufficient 
information to  verify correctness of DP operations and verify DP against CP to 
localize the fault.

Both RIB and FIB validation (leading to successful echo response), may not 
indicate that right RIB and FIB are consistent with respect to sub-tlv being 
carried.
I suggest that we keep lsp ping to just the data plane validation. 
Consistency-check will require lot of compute (might need a complete path 
calculation of BGP-EVPN), to indicate the consistency. Good to know if there 
are reference implementations optimizing this already.
This is one more reason to use wild card.


  1.  Parameters such as RD, shall not make it to the DP and their presence is 
restricted to the NLRI (entries/tables) in the protocol RIB.
 *   In case the RIB specific parameters need validation, then on receive 
side processing of ping, should run it through the RIB and FIB both ?
Paragj> yes.

 *   In case it’s just the dataplane validation (which I can gather from 
this draft), then RIB validation is not required and RD’s  can carry “don’t 
care”.
  1.  If a need be, to perform “reachability-check to a tenant vrf (EVI) on 
remote NVE”, for which no route has been published yet ?
Paragj> only vrf-existence is not checked by lsp ping.
[SD] That’s a good solution to have. I have mentioned the use-case in below 
email.
I propose that we leverage the existing “EVPN IP Prefix Sub-TLV”, with 
appropriate values (may be wild-card/don’t care) to realize this.

Paragj2> EVPN IP Prefix sub-tlv is for verifying ip prefix in a vrf. I am not 
sure it should/can be applied to the use case you  mention.

Thanks
Parag

as I mentioned in #2 of below email

 *   Is it possible to achieve that with lsp-ping check with existing 
sub-TLVs without “wild-card/don’t-care”

Thanks
Saumya.

From: Parag Jain (paragj) [mailto:par...@cisco.com]
Sent: Tuesday, September 7, 2021 11:56 PM
To: Dikshit, Saumya mailto:saumya.diks...@hpe.com>>; 
draft-ietf-bess-evpn-lsp-p...@ietf.org<mailto:draft-ietf-bess-evpn-lsp-p...@ietf.org>;
 bess@ietf.org<mailto:bess@ietf.org>
Cc: bess-cha...@ietf.org<mailto:bess-cha...@ietf.org>
Subject: Re: Query/comments on draft-ietf-bess-evpn-lsp-ping-05

Hi Saumya

The remote PE router processing the lsp ping packet, does consistency checks 
between data plane and contr

Re: [bess] Query/comments on draft-ietf-bess-evpn-lsp-ping-05

[Parag Jain (paragj)]

Hi Saumya

Pls see inline.

From: "Dikshit, Saumya" 
Date: Tuesday, September 7, 2021 at 3:22 PM
To: "Parag Jain (paragj)" , 
"draft-ietf-bess-evpn-lsp-p...@ietf.org" 
, "bess@ietf.org" 
Cc: "bess-cha...@ietf.org" 
Subject: RE: Query/comments on draft-ietf-bess-evpn-lsp-ping-05

Hi Parag,

Thanks for the response. I have few bullets on the same.
Please help clarify and if there is a need to call them out explicitly.


  1.  “Consistency checkers” feature-set does validates the CP-DP parity and 
can be leveraged via management interface to the box.
 *   Do you imply the consistency check between protocol RIB and the 
dataplane FIB, Or the consistency between Software FIB (slow path) and the 
LC-FIB
Paragj> CP would mean BGP/EVPN/RIB which ever CP component has the info 
included in the sub-TLVs.


  1.  Parameters such as RD, shall not make it to the DP and their presence is 
restricted to the NLRI (entries/tables) in the protocol RIB.
 *   In case the RIB specific parameters need validation, then on receive 
side processing of ping, should run it through the RIB and FIB both ?
Paragj> yes.

 *   In case it’s just the dataplane validation (which I can gather from 
this draft), then RIB validation is not required and RD’s  can carry “don’t 
care”.
  1.  If a need be, to perform “reachability-check to a tenant vrf (EVI) on 
remote NVE”, for which no route has been published yet ?
Paragj> only vrf-existence is not checked by lsp ping.

Thanks
Parag

as I mentioned in #2 of below email

 *   Is it possible to achieve that with lsp-ping check with existing 
sub-TLVs without “wild-card/don’t-care”

Thanks
Saumya.

From: Parag Jain (paragj) [mailto:par...@cisco.com]
Sent: Tuesday, September 7, 2021 11:56 PM
To: Dikshit, Saumya ; 
draft-ietf-bess-evpn-lsp-p...@ietf.org; bess@ietf.org
Cc: bess-cha...@ietf.org
Subject: Re: Query/comments on draft-ietf-bess-evpn-lsp-ping-05

Hi Saumya

The remote PE router processing the lsp ping packet, does consistency checks 
between data plane and control plane. RD, ESI fields along with other fields 
defined in the sub-tlvs are used for that purpose. Wildcard/don’t care values 
for these fields will defeat the purpose of DP-CP consistency checks.

Thanks
Parag

From: "Dikshit, Saumya" mailto:saumya.diks...@hpe.com>>
Date: Thursday, September 2, 2021 at 1:42 PM
To: 
"draft-ietf-bess-evpn-lsp-p...@ietf.org<mailto:draft-ietf-bess-evpn-lsp-p...@ietf.org>"
 
mailto:draft-ietf-bess-evpn-lsp-p...@ietf.org>>,
 "bess@ietf.org<mailto:bess@ietf.org>" mailto:bess@ietf.org>>
Cc: "bess-cha...@ietf.org<mailto:bess-cha...@ietf.org>" 
mailto:bess-cha...@ietf.org>>
Subject: Query/comments on draft-ietf-bess-evpn-lsp-ping-05
Resent-From: mailto:alias-boun...@ietf.org>>
Resent-To: mailto:par...@cisco.com>>, 
mailto:sbout...@ciena.com>>, 
mailto:gregimir...@gmail.com>>, 
mailto:saja...@cisco.com>>, 
mailto:ssa...@cisco.com>>
Resent-Date: Thursday, September 2, 2021 at 1:42 PM

[sending the queries in a different email with changed subject line]

Hello Authors of draft-ietf-bess-evpn-lsp-ping draft,

I have following queries regarding this draft:

>>>> Do we intend-to-use/call-out-usage-of “wild-card/don’t-care” values for 
>>>> attributes carried in the sub-TLVs ?
For example, If the admin intends  to check the reachability to host 
(MAC_X/IP_X) published (in route-type-2)  by remote PE.
The remote PE learnt it locally over ESI_X against Vlan X (mapped to BD_XYZ).

Is it possible, that the “EVPN MAC sub-tlv”  can carry the “Route 
Distinguisher” and “Ethernet Segment Identifier” as don’t care.

>>>> Another caseto handle would be test the reachability to tenant-VRF VRF_X 
>>>> (with EVPN mapped EVI) configured on the remote PE, PE1.
VRF_X has no active IP/IPv6 interface configured and its sole usage is to 
obtain the leaked (via IVRL) routes from other VRFs (non-EVPN) and PE1 
published this to other peers via EVPN control plane. Till the first prefix 
(learnt ) route is published (Route Type 5) by PE1 for the EVI (mapped to 
VRF_X), the tunnels will not be provisioned on other PEs.
In order to test the reachability to VRF_X (on PE1) from another PEs, let’s 
say, PE2 or a centralized-controller (which can emulate/supports MPLS),

It may need to carry all/subset-of attributes with “don’t-care/wild-card” in 
“EVPN IP Prefix Sub-TLV”.


Please let know your thoughts on above.

Thanks
Saumya.

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Query/comments on draft-ietf-bess-evpn-lsp-ping-05

[Parag Jain (paragj)]

Hi Saumya

The remote PE router processing the lsp ping packet, does consistency checks 
between data plane and control plane. RD, ESI fields along with other fields 
defined in the sub-tlvs are used for that purpose. Wildcard/don’t care values 
for these fields will defeat the purpose of DP-CP consistency checks.

Thanks
Parag

From: "Dikshit, Saumya" 
Date: Thursday, September 2, 2021 at 1:42 PM
To: "draft-ietf-bess-evpn-lsp-p...@ietf.org" 
, "bess@ietf.org" 
Cc: "bess-cha...@ietf.org" 
Subject: Query/comments on draft-ietf-bess-evpn-lsp-ping-05
Resent-From: 
Resent-To: , , , 
, 
Resent-Date: Thursday, September 2, 2021 at 1:42 PM

[sending the queries in a different email with changed subject line]

Hello Authors of draft-ietf-bess-evpn-lsp-ping draft,

I have following queries regarding this draft:

 Do we intend-to-use/call-out-usage-of “wild-card/don’t-care” values for 
 attributes carried in the sub-TLVs ?
For example, If the admin intends  to check the reachability to host 
(MAC_X/IP_X) published (in route-type-2)  by remote PE.
The remote PE learnt it locally over ESI_X against Vlan X (mapped to BD_XYZ).

Is it possible, that the “EVPN MAC sub-tlv”  can carry the “Route 
Distinguisher” and “Ethernet Segment Identifier” as don’t care.

 Another caseto handle would be test the reachability to tenant-VRF VRF_X 
 (with EVPN mapped EVI) configured on the remote PE, PE1.
VRF_X has no active IP/IPv6 interface configured and its sole usage is to 
obtain the leaked (via IVRL) routes from other VRFs (non-EVPN) and PE1 
published this to other peers via EVPN control plane. Till the first prefix 
(learnt ) route is published (Route Type 5) by PE1 for the EVI (mapped to 
VRF_X), the tunnels will not be provisioned on other PEs.
In order to test the reachability to VRF_X (on PE1) from another PEs, let’s 
say, PE2 or a centralized-controller (which can emulate/supports MPLS),

It may need to carry all/subset-of attributes with “don’t-care/wild-card” in 
“EVPN IP Prefix Sub-TLV”.


Please let know your thoughts on above.

Thanks
Saumya.

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Implementation poll for draft-ietf-bess-evpn-lsp-ping-05

[Parag Jain (paragj)]

Hi Matthew,

Cisco does not have a shipping implementation of the draft.

As Ali and many other experts replied, LSP ping is widely used for detecting 
data plane failures in mpls network. This draft defines necessary Target FEC 
sub-TLVs for EVPN and  I think this is an important draft that should proceed 
with publication.

Thanks
Parag

On 2021-08-09, 9:25 AM, "Bocci, Matthew (Nokia - GB)" 
 wrote:

WG and Authors

Unfortunately I have not seen any responses indicating that there are any 
known implementations of this draft. I also did not see any responses to 
Stephane's question if we should proceed regardless.

As per the BESS WG implementation policy 
(https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw/), 
please can you respond to this email indicating either:

- That you are aware of any implementations (ideally providing some details)
- If you are not aware of any, if you think the WG should proceed with the 
draft's publication and why.

I will close this poll on 25th August 2021.

Regards

Matthew
 

On 14/06/2021, 17:38, "BESS on behalf of internet-dra...@ietf.org" 
 wrote:


A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the BGP Enabled ServiceS WG of the IETF.

Title   : LSP-Ping Mechanisms for EVPN and PBB-EVPN
Authors : Parag Jain
  Samer Salam
  Ali Sajassi
  Sami Boutros
  Greg Mirsky
Filename: draft-ietf-bess-evpn-lsp-ping-05.txt
Pages   : 15
Date: 2021-06-14

Abstract:
   LSP-Ping is a widely deployed Operation, Administration, and
   Maintenance (OAM) 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 IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-lsp-ping/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-lsp-ping-05

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-evpn-lsp-ping-05


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess



___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Document shepherd review of draft-ietf-bess-evpn-lsp-ping-04

[Parag Jain (paragj)]

Hi Mathew

Thank you for your comments. Let me incorporate them and publish a new version 
of the doc.

Thanks
Parag


From: "Bocci, Matthew (Nokia - GB)" 
Date: Wednesday, June 2, 2021 at 8:55 AM
To: "draft-ietf-bess-evpn-lsp-p...@ietf.org" 
, "bess@ietf.org" 
Subject: Document shepherd review of draft-ietf-bess-evpn-lsp-ping-04
Resent-From: 
Resent-To: , , , 
, 
Resent-Date: Wednesday, June 2, 2021 at 8:55 AM

Authors,

I am the document shepherd for this draft. As is customary, please find below 
by review. Please treat these comment as you would any other working group last 
call comments.

Best regards

Matthew

General Comments.


Implementation status: Please can you indicate if there are any known 
implementations of this draft, as per 
https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw

I think the document is readable and useful. I have a few comments below. These 
are mostly related to the clarity of the text or are minor spelling/grammar 
issues that would be better to resolve before we forward the document to the 
IESG. However, there are some more significant issues related to the clarity of 
the specification.

As a general high level comment, there is a lack of RFC2119 language used in 
the body of the document. For example, in section 5 you say that “packets are 
encapsulated” but I think it would be better to use mandatory language such as 
“packets MUST be encapsulated”. Elsewhere, it is not clear what the normative 
behavior is. Please go through and apply terms such as “MUST’, ‘SHOULD’ etc as 
needed. Maybe look at RFC4379 for an example of how to use this terminology for 
LSP ping when applied to a service.

The mechanisms in this draft are presumably based on RFC4379 / RFC8029 
(Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures), and I am 
assuming that an implementation must follow the basic rules in that RFC but use 
the EVPN identifiers in the target FEC stack. If so, perhaps you should make 
that clear.

There is a normative down reference to 
“draft-ietf-bess-evpn-prefix-advertisement-11”. This will delay the publication 
of the draft.

Please also check the use of the definite article (a, an, the, etc) in the 
draft. There are a few cases where it is used unnecessarily e.g. “the PE1”, or 
it is missing.

Detailed Comments


1. Introduction
[…]
BB-EVPN maintains the C-MAC learning in data plane
MB> Please expand ‘C-MAC’ on first use
[…]

This draft defines 4 new Sub-TLVs
MB> s/draft/document

[…]
2. Proposed Target FEC Stack Sub-TLVs

   This document introduces four new Target FEC Stack sub-TLVs that are
   included in the LSP-Ping Echo Request packet sent for detecting faults in 
data-plane connectivity in EVPN and PBB-EVPN networks.
   These Target FEC Stack sub-TLVs are described next.

MB> Maybe keep the purpose in line with RFC4385, which says the echo request is 
used to provide a connectivity check, rather than only saying we are detecting 
faults. Strictly speaking, we are detecting both a fault and the absence of a 
fault.

MB> Also, I suggest adding a sentence to clarify that what the target FEC stack 
TLVs are used for in the context of EVPN. Since we only introduce EVPN unicast 
FECs in draft-ietf-bess-evpn-oam-req-frmwk, maybe you can say something like 
“These MAY be used to validate that an identifier for a given EVPN is 
programmed at the target node.”

[…]

Throughout:
s/GAL label/GAL

The ‘L’ in the abbreviation means ‘Label’ so you don’t need to say it twice.

[…]


5.  Encapsulation of OAM Ping Packets

   The LSP Ping Echo request IPv4/UDP packets are encapsulated with the
   Transport and EVPN Label(s) followed by the Generic Associated
   Channel Label (GAL) [RFC6426] which is the bottom most label.  The
   GAL label is followed by IPv4(0x0021) or IPv6(0x0057) Associated
   Channel Header (ACH) [RFC4385].

MB> I think the references are incorrect. GAL is defined in RFC 5586, not 
RFC6426. RFC4385 is the reference for the PW ACH, not the G-ACH. RFC5586 gives 
you the format of the G-ACH that you use following the GAL. The code points for 
IPv4 and IPv6 channels are in Generic Associated Channel (G-ACh) Parameters 
(iana.org)
So you should probably change the second reference to [RFC5586] and then the 
IANA registry.
[…]

6.2.2.  Using P2MP P-tree
[…]
When using Aggregate Inclusive P-tree, a PE announces an upstream
   assigned MPLS label along with the P-tree ID, in that case both the
   p2mp p-tree MPLS transport label and the upstream MPLS label can be
   used to identify the L2 service.

MB> this does not parse well. I suggest rephrasing to:
“When using Aggregate Inclusive P-tree, a PE announces an upstream
   assigned MPLS label along with the P-tree ID, so both the
   p2mp p-tree MPLS transport label and the upstream MPLS label can be
   used to identify the L2 service.”

[…]
The Leaf PE(s) of the p2mp tree 

Re: [bess] WG adoption and IPR poll for draft-brissette-bess-evpn-l2gw-proto

[Parag Jain (paragj)]

Support the adoption.

Thanks
Parag

From: BESS  on behalf of "slitkows.i...@gmail.com" 

Date: Monday, March 29, 2021 at 3:13 AM
To: "bess@ietf.org" 
Subject: [bess] WG adoption and IPR poll for 
draft-brissette-bess-evpn-l2gw-proto

Hello,

This email begins a two-weeks WG adoption poll for 
draft-brissette-bess-evpn-l2gw-proto [1].

Please review the draft and post any comments to the BESS working group list.

We are also polling for knowledge of any undisclosed IPR that applies to this 
document, to ensure that IPR has been disclosed in compliance with IETF IPR 
rules (see RFCs 3979, 4879, 3669 and 5378 for more details).

If you are listed as an author or a contributor of this document, please 
respond to this email and indicate whether or not you are aware of any relevant 
undisclosed IPR, copying the BESS mailing list. The document will not  progress 
without answers from all of the authors and contributors.

Currently, there are no IPR disclosures against this document.

If you are not listed as an author or a contributor, then please explicitly 
respond only if you are aware of any IPR that has not yet been disclosed in 
conformance with IETF rules.

This poll for adoption closes on April 12th 2021.

Regards,
Matthew and Stephane


[1] https://datatracker.ietf.org/doc/draft-brissette-bess-evpn-l2gw-proto/

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] [mpls] FW: WGLC, IPR and implementation poll for draft-ietf-bess-evpn-lsp-ping

[Parag Jain (paragj)]

Hi Loa,

Thank you for your valuable comments and suggestions on the draft. I'll 
incorporate them and publish a new version.

Thanks 
Parag

On 2020-07-11, 11:49 PM, "Loa Andersson"  wrote:

Stephane and Matthew,

Thanks for sending this to the mpls wg, LSP Ping is one of of out key
protocols and assignments of LSP Ping code points should be reviewed by
the mpls working group.

bess wg, (mpls wg for info),

There are a few comments on the IANA section and the use of the code 
points you request that IANA shall allocate.

First, the scope of the sub-TLVs allocated from the "Sub-TLVs for TLV 
Types 1, 16, and 21" sub-registry. Code points from this registry are
valid for three TLVs (1, 16 and 21), it is the impression that the draft
try to allocate four sub-TLVs for TLV 1 only. If the sub-TLV is not
valid for TLVs 16 and 21 that needs to be carefully specified in the
document. If this is the case it would imply a not insignificant
implementation complexity.

Second, the registry from which the allocation will be done needs to
clearly pointed out.

The IANA section talks about:

   "Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs)
Parameters - TLVs" registry.

There is no such registry. I often use the following terminology to
get the registry names right, Name Space, Registry, sub-registry.


In your case the namespace would be "Multiprotocol Label Switching
(MPLS) Label Switched Paths (LSPs) Parameters"

The registry would be "TLVs"

And the sub-registry "Sub-TLVs for TLV Types 1, 16, and 21"


One way of clearly pointing out drom which sub-registry you wantt the
sub-TLVs to be appointed would be:
   "IANA is requested to assign value for the four sub-TLVs listed below
from the Standards Track" (0-16383) range, in the "Sub-TLVs for TLV
Types 1, 16, and 21" sub-registry, in the "TLVs" registry in the
"Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs)
Ping Parameters" name space."

You should also say that you want the lowest 4 free values.

Note 1: I had some communication with the editor that indicates that
this is the correct range.

Note 2: There is a draft that will soon be wglc'ed in the MPLS working
group, "draft-ietf-mpls-lsp-ping-registries-update". As far as I can
see none of the changes to the LSP Ping registers done in the mpls
draft has any effect on the allocation made by this draft.

I have consulted our registry experts (Carlos and Mach) to look at the
IANA registry in draft-ietf-bess-evpn-lsp-ping. The point that they
brought back was that the scope of the requested sub-TLVs (TLV 1 only or
TLV 1, 16 and 21) must be made very clear.

For the allocation "Return Codes" that is cledarer. Say "The Return
Codes" registry in the "Multiprotocol Label Switching (MPLS) Label
Switched Paths (LSPs) Ping Parameters" name space."  And that the two 
lowest standard actions code points should be allocated.

I would use bullets to list the return codes, using numbers might be
taken as that this is the values you want.

There are some language that should be considered, e.g. from section
8.2:

This document proposes two new Return Codes, which SHOULD be included
in the Echo Reply message by a PE in response to LSP Ping Echo
Request message:

This are rather general statement, and it is true only EVPN and PBB
context, right? Please make specific.

The same would be true for this from section 8.1.:

This document defines 4 new sub-TLV type to be included in Target FEC
Stack TLV (TLV Type 1) [RFC8029] in LSP Ping.

It is only included in EVPN and PBB context, and I would substitute
"LSP Ping" with "echo request and echo reply messages"


/Loa


On 03/07/2020 21:32, slitkows.i...@gmail.com wrote:
> Hi MPLS WG,
> 
> We have started a working group last call on 
> draft-ietf-bess-evpn-lsp-ping which we may be interested to have you 
> review and comments on. Please comment on the BESS mailing list as well 
> as MPLS mailing list.
> 
> Brgds,
> 
> Stephane
> 
> *From:*slitkows.i...@gmail.com 
> *Sent:* vendredi 3 juillet 2020 15:29
> *To:* bess@ietf.org; draft-ietf-bess-evpn-lsp-p...@ietf.org
> *Cc:* bess-cha...@ietf.org
> *Subject:* WGLC, IPR and implementation poll for 
> draft-ietf-bess-evpn-lsp-ping
> 
> Hello WG,
> 
> This email starts a two weeks Working Group Last Call on 
> draft-ietf-bess-evpn-lsp-ping-02 [1].
> 
> This poll runs until * the 20^th Of July *.
> 
> We are also polling for knowledge of any undisclosed IPR that applies to 
> this Document, to ensure 

Re: [bess] WGLC, IPR and implementation poll for draft-ietf-bess-evpn-lsp-ping

[Parag Jain (paragj)]

I support this draft as coauthor. I am not aware of any undisclosed IPRs 
related to this draft.

Thanks
Parag

From: BESS  on behalf of "slitkows.i...@gmail.com" 

Date: Friday, July 3, 2020 at 9:29 AM
To: "bess@ietf.org" , "draft-ietf-bess-evpn-lsp-p...@ietf.org" 

Cc: "bess-cha...@ietf.org" 
Subject: [bess] WGLC, IPR and implementation poll for 
draft-ietf-bess-evpn-lsp-ping

Hello WG,

This email starts a two weeks Working Group Last Call on 
draft-ietf-bess-evpn-lsp-ping-02 [1].

This poll runs until * the 20th Of July *.


We are also polling for knowledge of any undisclosed IPR that applies to this 
Document, to ensure that IPR has been disclosed in compliance with IETF IPR 
rules (see RFCs 3979, 4879, 3669 and 5378 for more details).

If you are listed as an Author or a Contributor of this Document please respond 
to this email and indicate whether or not you are aware of any relevant 
undisclosed IPR. The Document won't progress without answers from all the 
Authors and Contributors.

There is currently no IPR disclosed.



If you are not listed as an Author or a Contributor, then please explicitly 
respond only if you are aware of any IPR that has not yet been disclosed in 
conformance with IETF rules.



We are also polling for any existing implementation as per [2].



Thank you,

Stephane & Matthew

[1] https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-lsp-ping/
[2] https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] WG Last Call and IPR Poll for draft-ietf-bess-evpn-oam-req-frmwk-02

[Parag Jain (paragj)]

I support this draft for standard track.

Thanks
Parag


From: "Bocci, Matthew (Nokia - GB)" 
Date: Monday, June 15, 2020 at 3:55 AM
To: "draft-ietf-bess-evpn-oam-req-fr...@ietf.org" 
, "bess@ietf.org" 
Subject: WG Last Call and IPR Poll for draft-ietf-bess-evpn-oam-req-frmwk-02
Resent-From: 
Resent-To: , Cisco Employee , 
, , 
Resent-Date: Monday, June 15, 2020 at 3:55 AM

This email starts a two-week working group last call for 
draft-ietf-bess-evpn-oam-req-frmwk-02

Please review the draft and send any comments to the BESS list. Also, please 
indicate if you support publishing the draft as a standards track RFC.

This poll runs until Monday 29th June 2020.

We are also polling for knowledge of any undisclosed IPR that applies to this 
Document, to ensure that IPR has been disclosed in compliance with IETF IPR 
rules (see RFCs 3979, 4879, 3669 and 5378 for more details).
If you are listed as an Author or a Contributor of this document please respond 
to this email and indicate whether or not you are aware of any relevant 
undisclosed IPR. The Document won't progress without answers from all the 
Authors and Contributors.
There is currently no IPR disclosed.
Thank you,
Matthew & Stephane

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] WG adoption call & IPR poll for draft-jain-bess-evpn-lsp-ping

[Parag Jain (paragj)]

Forgot to add that I am not aware of any IPR related to this draft.

Thanks
Parag

From: BESS  on behalf of "Parag Jain (paragj)" 

Date: Tuesday, May 7, 2019 at 9:17 AM
To: "stephane.litkow...@orange.com" , 
"bess@ietf.org" 
Subject: Re: [bess] WG adoption call & IPR poll for 
draft-jain-bess-evpn-lsp-ping

Support as coauthor of the draft.

Thanks
Parag

From: BESS  on behalf of "stephane.litkow...@orange.com" 

Date: Tuesday, May 7, 2019 at 3:37 AM
To: "bess@ietf.org" 
Subject: [bess] WG adoption call & IPR poll for draft-jain-bess-evpn-lsp-ping

Hi,


This email begins a two-week poll for adoption of 
draft-jain-bess-evpn-lsp-ping-08[1]

Please review the draft and post any comments to the BESS working group list.

We are also polling for knowledge of any undisclosed IPR that applies to this 
Document, to ensure that IPR has been disclosed in compliance with IETF IPR 
rules (see RFCs 3979, 4879, 3669 and 5378 for more details).

If you are listed as an author or a contributor of this document, please 
respond to this email and indicate whether or not you are aware of any relevant 
undisclosed IPR, copying the BESS mailing list. The document won't progress 
without answers from all the authors and contributors.
Currently, there are no IPR disclosures against this document.

If you are not listed as an author or a contributor, then please explicitly 
respond only if you are aware of any IPR that has not yet been disclosed in 
conformance with IETF rules.

This poll for adoption closes on 21th May 2019.

Regards,
Stephane and Matthew

[1] https://datatracker.ietf.org/doc/draft-jain-bess-evpn-lsp-ping/

_



Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.



This message and its attachments may contain confidential or privileged 
information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete 
this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.

Thank you.
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] WG adoption call & IPR poll for draft-jain-bess-evpn-lsp-ping

[Parag Jain (paragj)]

Support as coauthor of the draft.

Thanks
Parag

From: BESS  on behalf of "stephane.litkow...@orange.com" 

Date: Tuesday, May 7, 2019 at 3:37 AM
To: "bess@ietf.org" 
Subject: [bess] WG adoption call & IPR poll for draft-jain-bess-evpn-lsp-ping

Hi,


This email begins a two-week poll for adoption of 
draft-jain-bess-evpn-lsp-ping-08[1]

Please review the draft and post any comments to the BESS working group list.

We are also polling for knowledge of any undisclosed IPR that applies to this 
Document, to ensure that IPR has been disclosed in compliance with IETF IPR 
rules (see RFCs 3979, 4879, 3669 and 5378 for more details).

If you are listed as an author or a contributor of this document, please 
respond to this email and indicate whether or not you are aware of any relevant 
undisclosed IPR, copying the BESS mailing list. The document won't progress 
without answers from all the authors and contributors.
Currently, there are no IPR disclosures against this document.

If you are not listed as an author or a contributor, then please explicitly 
respond only if you are aware of any IPR that has not yet been disclosed in 
conformance with IETF rules.

This poll for adoption closes on 21th May 2019.

Regards,
Stephane and Matthew

[1] https://datatracker.ietf.org/doc/draft-jain-bess-evpn-lsp-ping/

_



Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.



This message and its attachments may contain confidential or privileged 
information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete 
this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.

Thank you.
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] EVPN FECs in LSP Ping

[Parag Jain (paragj)]

Hi Sasha

There is an accompanying LSP ping draft for evpn:

https://datatracker.ietf.org/doc/draft-jain-bess-evpn-lsp-ping/

Thanks
Parag


On 2018-09-16, 6:43 PM, "BESS on behalf of Donald Eastlake" 
 wrote:

Hi Sasha,

Thanks for your questions. See below.

On Thu, Sep 6, 2018 at 9:58 AM Alexander Vainshtein
 wrote:
>
> Dear authors of the EVPN OAM requirements and Framework draft,
>
> I have looked up the draft, and it looks to me as a good starting
> point for work on EVPN OAM.

Thanks.

> I would like to clarify two points with regard to the draft:
>
> 1.  In order to pass unicast EAOM frames (LBM/LBR and LTR), the
> local MAC-VRF must learn the MAC address of the customer MEP and
> advertise it to remote PEs as a MAC/IP Advertisement route. Should
> this be considered as a special case of learning from the control
> plane (in addition to ARP/NDP/DHCP/DHCPv6 that are mentioned in RFC
> 7432)?

Yes, the MAC address of the customer MEP needs to be learned but
Section 9.1 of RFC 7432 includes the following text, which seems
adequate to me:

   The PEs in a particular EVPN instance MUST support local data-plane
   learning using standard IEEE Ethernet learning procedures.

> 2. The draft seems to propose extension of LSP Ping to test/verify
> connectivity to the FECs advertised as NRLI of EVPN routes. I have
> checked the IANA Registry, and no values for these FECs have been
> allocated yet.  Do you plan any specific work on this?

LSP Ping is one mechanism indirectly referenced in Section 2.4 of the
draft via the reference to RFC 6425 but there are others.

Since OAM messages need to follow the same path as data, as far as
practical, it seem to me there should not be any FECs allocated for
OAM beyond those already needed for data. Probably wording in the
draft related to FECs should be checked/adjusted.

Thanks,
Donald
===
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 1424 Pro Shop Court, Davenport, FL 33896 USA
 d3e...@gmail.com


> Regards,
> Sasha
>
> Office: +972-39266302
> Cell:   +972-549266302
> Email:  alexander.vainsht...@ecitele.com

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess


___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Slot requests for BESS WG session - IETF 102 - Montreal

[Parag Jain (paragj)]

Hi Stephane

I’ll like to request following slot:

draft-jain-bess-evpn-lsp-ping-07
Speaker: Parag Jain
Reason: WG adoption
Duration: 8 mins

Thanks
Parag

From: BESS  on behalf of "stephane.litkow...@orange.com" 

Date: Tuesday, June 12, 2018 at 3:13 AM
To: "bess@ietf.org" 
Subject: [bess] Slot requests for BESS WG session - IETF 102 - Montreal


All,



It is time we start building the BESS WG agenda for Montreal.



Please send us your request for a presentation slot, indicating draft name, 
speaker, and desired duration (covering presentation and discussion). If it is 
not the first presentation of the draft, please give a reason why it is 
required to have a new presentation slot.





Thank you



Stephane & Matthew




_



Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.



This message and its attachments may contain confidential or privileged 
information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete 
this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.

Thank you.
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Slots requests for BESS WG session - IETF 99 - Prague

[Parag Jain (paragj)]

Hi Martin

I like to request a slot to present the following evpn oam draft. I’ll post a 
new version of the draft soon.
 https://datatracker.ietf.org/doc/draft-jain-bess-evpn-lsp-ping/

Thanks
Parag

On 2017-06-21, 4:33 AM, "BESS on behalf of Martin Vigoureux" 
 wrote:

All,

it is time we start building the BESS WG agenda for Prague.
The IETF agenda (still preliminary) is available at:
https://datatracker.ietf.org/meeting/99/agenda.html

The BESS WG session (2h) is scheduled on
Thursday, July 20, 2017 / Afternoon session II / 15:50-17:50 (local 
time)

Please send us your request for a presentation slot, indicating
draft name, speaker, and desired duration (covering presentation and
discussion).

Please send the requests no later than the 5th of July.
Thank you

M

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess


___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess


___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

[bess] WG Adoption request for draft-jain-bess-evpn-lsp-ping-04

[Parag Jain (paragj)]

Hi Martin and Thomas,

We would like to request WG adoption for draft-jain-bess-evpn-lsp-ping-04 
draft. The draft was presented in IETF-93 (Prague). We had received comments on 
the draft and they were incorporated in the current version of the draft. FYI,  
the draft is planned to be  implemented.

Thanks,
Parag
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

[bess] Seeking Comments on LSP-Ping Mechanisms for EVPN and PBB-EVPN (Revision 02)

[Parag Jain (paragj)]

Hi

Seeking comments on the following draft. The version 01 of the draft was 
presented at IETF 93. EVPN RT-5 support has been added in this new version.

Name: draft-jain-bess-evpn-lsp-ping
Revision: 02
Title: LSP-Ping Mechanisms for EVPN and PBB-EVPN
Document date: 2015-10-16
Group: Individual Submission
Pages: 14
URL:
https://www.ietf.org/internet-drafts/draft-jain-bess-evpn-lsp-ping-02.txt
Status: https://datatracker.ietf.org/doc/draft-jain-bess-evpn-lsp-ping/
Htmlized:   https://tools.ietf.org/html/draft-jain-bess-evpn-lsp-ping-02
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-jain-bess-evpn-lsp-ping-02

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

Thanks
Parag
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess