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

[bess] I-D Action: draft-ietf-bess-evpn-lsp-ping-09.txt

[internet-drafts]

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
  Ali Sajassi
  Samer Salam
  Sami Boutros
  Greg Mirsky
  Filename: draft-ietf-bess-evpn-lsp-ping-09.txt
  Pages   : 17
  Date: 2022-12-10

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


The 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-09

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-bess-evpn-lsp-ping-09


Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts


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