Re: [bess] WG Last Call and IPR Poll for draft-ietf-bess-bgp-sdwan-usage-05

[Wanghaibo (Rainsword)]

Hi WG,
I support the publication of this draft.

Best wishes,
Haibo Wang

From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Bocci, Matthew (Nokia - 
GB)
Sent: Monday, September 26, 2022 7:06 PM
To: bess@ietf.org
Subject: [bess] WG Last Call and IPR Poll for draft-ietf-bess-bgp-sdwan-usage-05

This email starts a two-week working group last call for 
draft-ietf-bess-bgp-sdwan-usage-05 [1]

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

This poll runs until the 10th October 2022

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 are currently two IPR disclosures.


Thank you,
Matthew & Stephane


[1]  
draft-ietf-bess-bgp-sdwan-usage-05



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

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

[Joel Halpern via Datatracker]

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] Shepherd review Comment on draft-ietf-bess-evpn-redundant-mcast-source-03

[Rabadan, Jorge (Nokia - US/Sunnyvale)]

Hi Mankamana,

Thank you for your review. We’ve published version 04, which addresses your 
comments. Also incorporates Greg Mirsky’s comments (thanks Greg!) about the 
section that talks about the optional use of BFD in the solution. By the way, 
this section has a reference to draft-ietf-bess-evpn-bfd-03 - EVPN Network 
Layer Fault 
Management  which 
seems to be expired for some time. Any plans to refresh the draft and move it 
to WG LC soon?

Also, please check out my comments in-line with [jorge].

Thanks!
Jorge

From: Mankamana Mishra (mankamis) 
Date: Friday, July 15, 2022 at 2:56 AM
To: draft-ietf-bess-evpn-redundant-mcast-sou...@ietf.org 
, bess@ietf.org 

Subject: Shepherd review Comment on 
draft-ietf-bess-evpn-redundant-mcast-source-03
Authors,

Please find some  initial comments .

16  Abstract

18 EVPN supports intra and inter-subnet IP multicast forwarding.
19 However, EVPN (or conventional IP multicast techniques for that
20 matter) do not have a solution for the case where: a) a given
21 multicast group carries more than one flow (i.e., more than one
22 source), and b) it is desired that each receiver gets only one of the
23 several flows.  Existing multicast techniques assume there are no
24 redundant sources sending the same flow to the same IP multicast
25 group, and, in case there were redundant sources, the receiver's
26 application would deal with the received duplicated packets.  This
27 document extends the existing EVPN specifications and assumes that IP
28 Multicast source redundancy may exist.


Highlighted statement does not seems correct.  We do carry (S1, G) and (S2, G) 
where same group is carrying two different flows.  I assume the point which 
authors want to bring out that same content being sourced by different source 
and receiver want to receive only one of them. But this statement does not 
convey that message clearly.

[jorge] I tried to clarify it better, let me know if the modifications help:
However, EVPN (or conventional IP multicast techniques for that matter) do not 
have a solution for the case where the following two statements are true at the 
same time: a) a given multicast group carries more than one flow (i.e., more 
than one source), and b) it is desired that each receiver gets only one of the 
several flows.





[I-D.ietf-bess-evpn-igmp-mld-proxy]

Please replace this with RFC now.
[jorge] done




92  1.  Introduction



94 Intra and Inter-subnet IP Multicast forwarding are supported in EVPN

95 networks.  [I-D.ietf-bess-evpn-igmp-mld-proxy] describes the

96 procedures required to optimize the delivery of IP Multicast flows

97 when Sources and Receivers are connected to the same EVPN BD

98 (Broadcast Domain), whereas [I-D.ietf-bess-evpn-irb-mcast] specifies

99 the procedures to support Inter-subnet IP Multicast in a tenant

100network.  Inter-subnet IP Multicast means that IP Multicast Source

101and Receivers of the same multicast flow are connected to different

102BDs of the same tenant.

Should this also not give reference about 
https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-mvpn-seamless-interop-04
 and can mention that this document does not cover the cases about how 
redundant source would be handled with seamless draft.
[jorge] I added this in the introduction:
The procedures to handle redundant sources in solutions different than 
[RFC9251]
 or 
[I-D.ietf-bess-evpn-irb-mcast]
 are out of the scope of this document.



104[I-D.ietf-bess-evpn-igmp-mld-proxy], [I-D.ietf-bess-evpn-irb-mcast]

105or conventional IP multicast techniques do not have a solution for

106the case where a given multicast group carries more than one flow

107(i.e., more than one source) and it is desired that each receiver

108gets only one of the several flows.  Multicast techniques assume

109there are no redundant sources sending the same flows to the same IP

110multicast group, and, in case there were redundant sources, the

111receiver's application would deal with the received duplicated

112packets.

Same comment as first section, this statement is not bringing out the case 
clearly.
[jorge] changed along the same lines.



114As a workaround in conventional IP multicast (PIM or MVPN networks),

115if all the redundant sources are given the same IP address, each

116receiver will get only one flow.  The reason is that, in conventional

[bess] I-D Action: draft-ietf-bess-evpn-redundant-mcast-source-04.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   : Multicast Source Redundancy in EVPN Networks
Authors : Jorge Rabadan
  Jayant Kotalwar
  Senthil Sathappan
  Zhaohui Zhang
  Wen Lin
  Eric C. Rosen
  Filename: draft-ietf-bess-evpn-redundant-mcast-source-04.txt
  Pages   : 32
  Date: 2022-10-07

Abstract:
   EVPN supports intra and inter-subnet IP multicast forwarding.
   However, EVPN (or conventional IP multicast techniques for that
   matter) do not have a solution for the case where the following two
   statements are true at the same time: a) a given multicast group
   carries more than one flow (i.e., more than one source), and b) it is
   desired that each receiver gets only one of the several flows.
   Existing multicast techniques assume there are no redundant sources
   sending the same flow to the same IP multicast group, and, in case
   there were redundant sources, the receiver's application would deal
   with the received duplicated packets.  This document extends the
   existing EVPN specifications and assumes that IP Multicast source
   redundancy may exist.  It also assumes that, in case two or more
   sources send the same IP Multicast flows into the tenant domain, the
   EVPN PEs need to avoid that the receivers get packet duplication by
   following the described procedures.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-redundant-mcast-source/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-redundant-mcast-source-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-evpn-redundant-mcast-source-04


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