Re: [bess] Considering EVPN BFD as a candidate for the WG LC

[Mankamana Mishra (mankamis)]

Support it moving forward.

Mankamana

From: Matthew Bocci (Nokia) 
Date: Thursday, April 25, 2024 at 6:55 AM
To: Jeff Tantsura , Greg Mirsky 
Cc: bess-cha...@ietf.org , BESS , 
draft-ietf-bess-evpn-...@ietf.org 
Subject: Re: [bess] Considering EVPN BFD as a candidate for the WG LC
We’ve added this to the queue on the BESS WG WiKi (BESS WG - BGP Enabled 
ServiceS | IETF Community Wiki).

Authors, please can you also address Sasha’s comments/questions sent to the 
BESS list on 31st March.

Matthew

From: Jeff Tantsura 
Date: Friday, 22 March 2024 at 04:21
To: Greg Mirsky 
Cc: bess-cha...@ietf.org , BESS , 
draft-ietf-bess-evpn-...@ietf.org 
Subject: Re: [bess] Considering EVPN BFD as a candidate for the WG LC

CAUTION: This is an external email. Please be very careful when clicking links 
or opening attachments. See the URL nok.it/ext for additional information.



Support

> On Mar 20, 2024, at 17:12, Greg Mirsky  wrote:
>
> Hi,
> I concur with Donald regarding the state of the draft-ietf-evpn-bfd document. 
> The document is stable and ready for the WG LC. The authors are ready and 
> committed to work and address all questions and comments, ensuring the 
> expedient progress of the draft.
>
> Regards,
> Greg
> ___
> 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] RFC9251

[Mankamana Mishra (mankamis)]

Hi,
The forwarding rule for {S,G} or {*,G} remains the same as IGMP V3 spec.  Only 
difference is about setting up tunnels between EVPN PE.

Source IP address for Querier will be picked from local config or IRB. But this 
spec utilizes existing Querier config and procedures from IGMP implementation.

Mankamana

From: BESS  on behalf of Nitsan Dolev 

Date: Sunday, March 17, 2024 at 8:19 AM
To: rfc9...@ietf.org , bess@ietf.org 
Subject: [bess] RFC9251

Dear RFC9251 Co-authors,

Your help with the following questions will be most appreciated,


RFC 9251 seems to assume that the receiving PE will forward:

  1.  (S,G1) traffic only to those host who explicitly sent IGMPv3 report 
(S,G1) and  those who sent IGMPv3 Report (*,G1)
  2.  (*,G1) traffic only to those host who explicitly sent IGMPv3 report 
(*,G1) IGMPv2(G1)
Is this indeed the assumption?

Does it mean that the receiving PE shall do an IP Multicast lookup ? i.e. Has 
MFIB entry with
(S,G1)==> OIF( a, b, c ..) for all local AC ports from which IGMPv3 Report 
(S,G1)  OR
(*,G1)==> OIF( a, b, c ..) for all local AC ports from which IGMPv3 Report 
(*,G1) or IGMPv2 report (G1)

Another issue:
Referring to https://www.rfc-editor.org/rfc/rfc9251.html#name-proxy-querier

It says that “As mentioned in the previous sections, each PE MUST have proxy 
querier functionality for the following reasons:
to enable the collection of EVPN PEs providing Layer 2 Virtual Private Network 
(L2VPN) service to act as a distributed multicast router with an anycast IP 
address for all attached hosts in that subnet
to enable suppression of IGMP Membership Reports and Membership Queries over 
MPLS/IP core”
What shall be the source IP address of the IGMP queries?
Possible Alternatives: 1. The source IP of one of the Routers on the related PE 
BD  (if exists). 2. Some preconfigured dummy IRB Router Anycast IP address ?

Looking forward to getting your response,

Nitsan Dolev Elfassy
Ribbon Communications


Disclaimer

This e-mail together with any attachments may contain information of Ribbon 
Communications Inc. and its Affiliates that is confidential and/or proprietary 
for the sole use of the intended recipient. Any review, disclosure, reliance or 
distribution by others or forwarding without express permission is strictly 
prohibited. If you are not the intended recipient, please notify the sender 
immediately and then delete all copies, including any attachments.
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] rfc9251

[Mankamana Mishra (mankamis)]

Hi Shasha

Proxy querier behavior expects implementation to generate IGMP join locally on 
LAN after getting SMET joins. IP address depends on implementation. It can pick 
IP address from IRB or internal querier configuration.

Is there any specific case that has issue?

Mankamana

From: Alexander Vainshtein 
Date: Sunday, March 17, 2024 at 5:27 AM
To: Ali Sajassi (sajassi) , Samir Thoria (sthoria) 
, John E Drake , 
Mankamana Mishra (mankamis) , w...@juniper.net 

Cc: bess@ietf.org 
Subject: RE: rfc9251
Hi all,
Yet another question related to RFC 9251.

Section 4.2 of RFC 
9251<https://datatracker.ietf.org/doc/html/rfc9251#section-4.2> says:


As mentioned in the previous sections, each PE MUST have proxy querier 
functionality for the following reasons:

  1.  to enable the collection of EVPN PEs providing Layer 2 Virtual Private 
Network (L2VPN) service to act as a distributed multicast router with an 
anycast IP address for all attached hosts in that subnet
  2.  to enable suppression of IGMP Membership Reports and Membership Queries 
over MPLS/IP core

I wonder whether Source IP address of the queries mentioned above is presumed 
to be an IP address of an anycast EVPN IRB as defined in RFC 9135,  and, if 
yes, is this EVPN IRB assumed to be Symmetric or Asymmetric.

Regards, and lots of thanks in advance,
Sasha

From: Alexander Vainshtein
Sent: Sunday, March 17, 2024 2:06 PM
To: Ali Sajassi (sajassi) ; Samir Thoria (sthoria) 
; John E Drake ; 
'manka...@cisco.com' ; w...@juniper.net
Cc: 'bess@ietf.org' 
Subject: RE: rfc9251

Hi all,
Re-sending to the authors since the address : 
rfc9...@ietf.org<mailto:rfc9...@ietf.org> is invalid.

Regards,
Sasha

From: Alexander Vainshtein
Sent: Sunday, March 17, 2024 2:01 PM
To: rfc9...@ietf.org<mailto:rfc9...@ietf.org>
Cc: bess@ietf.org<mailto:bess@ietf.org>
Subject: rfc9251

Hi all,
I have a question regarding expected DP behavior in conjunction with RFC 9521: 
Are the PEs that support this RFC expected to decrement TTL in IP headers of 
multicast IP packets they forward?

This question is equally applicable to the “last mile” PEs that have received 
IGMP/MLD Joins and advertised them as SMET routes, and to the “first mile” PEs 
that receive and install these SMET routes.

The context for this question is my understanding that multicast IP traffic 
that is forwarded based on IMET route (e.g., to the PEs that have not 
advertised ability to advertise SMET routes)   does not undergo TTL decrement.

I have failed to find an answer to my question in the text of RFC 9251.

Your timely feedback would be highly appreciated.

Regards, and lots of thanks in advance,
Sasha



Disclaimer

This e-mail together with any attachments may contain information of Ribbon 
Communications Inc. and its Affiliates that is confidential and/or proprietary 
for the sole use of the intended recipient. Any review, disclosure, reliance or 
distribution by others or forwarding without express permission is strictly 
prohibited. If you are not the intended recipient, please notify the sender 
immediately and then delete all copies, including any attachments.
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

[bess] Meeting minutes IETF 119 uploaded

[Mankamana Mishra (mankamis)]

All,
Meeting minutes uploaded. Thanks Jorge for taking the notes.

https://datatracker.ietf.org/meeting/119/materials/minutes-119-bess-202403202330-00


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

[bess] Please share your deck for IETF 119

[Mankamana Mishra (mankamis)]

All,

All WG members who have a slot in IETF – 119, please share your deck.



Please copy chairs while sending the presentation, Due to a family emergency I 
may not have access to the network. So chairs being copied will allow other 
chairs to pick and upload the presentation.



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

[bess] IETF 119 Final agenda posted

[Mankamana Mishra (mankamis)]

All,
BESS final agenda posted now.

https://datatracker.ietf.org/doc/agenda-119-bess/

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

[bess] IETF 119 BESS WG preliminary agenda posted

[Mankamana Mishra (mankamis)]

All,
Have posted the preliminary agenda. If something is missing, please send me 
unicast.

https://datatracker.ietf.org/doc/agenda-119-bess/


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

[bess] please submit presentation request for IETF 119

[Mankamana Mishra (mankamis)]

All,
The preliminary agenda is ported, please send me a request for the slot.

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

Re: [bess] A couple of question about draft-ietf-bess-evpn-ac-aware-bundling

[Mankamana Mishra (mankamis)]

Will get back to you on these questions.

Mankamana

From: BESS  on behalf of Alexander Vainshtein 

Date: Tuesday, February 6, 2024 at 5:55 AM
To: draft-ietf-bess-evpn-ac-aware-bundl...@ietf.org 

Cc: bess@ietf.org 
Subject: Re: [bess] A couple of question about 
draft-ietf-bess-evpn-ac-aware-bundling
Hi,
Regarding my Q2:

I have encountered deployments in which an EVPN IRB is configured with multiple 
IP subnets while the single attachment circuit of the broadcast domain it uses 
is delimited by a single VLAN.

Regards,
Sasha

From: Alexander Vainshtein
Sent: Tuesday, February 6, 2024 3:51 PM
To: draft-ietf-bess-evpn-ac-aware-bundl...@ietf.org
Cc: bess@ietf.org
Subject: A couple of question about draft-ietf-bess-evpn-ac-aware-bundling
Importance: High

Hi,
I have a couple of question about the AC-aware bundling 
draft
 .
The background for these questions is given below.


Section 6.2 of RFC 
7432 that defines 
VLAN Bundle Service Interface says that “MAC addresses MUST be unique across 
all VLANs for that EVI in order for this service to work” .

This requirement is not limited to multihomed PEs

No mechanisms for enforcement of this requirement (e.g., by detecting and 
handling of possible violations) are defined

Any manipulation of VLAN tags is strictly prohibited with this service interface

The draft in question defines a similar requirement and effectively provides a 
way to enforce it. However:

Detection of misconfiguration is explicitly limited to just multihomed PEs (as 
can be seen from the title of Section 5)

The draft does not impose any limitations on VLAN manipulation (this is 
expected in the case of inter-subnet traffic (with each subnet differentiated 
by a VLAN) within a single broadcast domain)

The draft seems to deal just with the situation in which multiple subnets in 
the same broadcast domain are differentiated by VLANs.

And now my questions:

Q1: What is the rationale for restricting detection and handling of violation 
of the above-mentioned rule to just multi-homed PEs?
Q2: Does the draft support the situations in which multiple IP subnets in the 
same broadcast domain are NOT differentiated by different VLANs?
Q3: Is VLAN translation with AC-aware bundling service interface allowed for 
intra-subnet traffic that undergoes “pure Layer 2 switching” in the single 
broadcast domain?

Your feedback would be highly appreciated.

Regards, and lots of thanks in advance,
Sasha



Disclaimer

This e-mail together with any attachments may contain information of Ribbon 
Communications Inc. and its Affiliates that is confidential and/or proprietary 
for the sole use of the intended recipient. Any review, disclosure, reliance or 
distribution by others or forwarding without express permission is strictly 
prohibited. If you are not the intended recipient, please notify the sender 
immediately and then delete all copies, including any attachments.
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Genart early review of draft-ietf-bess-evpn-mvpn-seamless-interop-06

[Mankamana Mishra (mankamis)]

Thanks for reviewing, will update the draft soon.

Mankamana

From: Susan Hares via Datatracker 
Date: Tuesday, January 9, 2024 at 3:51 PM
To: gen-...@ietf.org 
Cc: bess@ietf.org , 
draft-ietf-bess-evpn-mvpn-seamless-interop@ietf.org 

Subject: Genart early review of draft-ietf-bess-evpn-mvpn-seamless-interop-06
Reviewer: Susan Hares
Review result: Almost Ready

GEN-ART review

Status: Almost ready

Summary Comment:
==
Multicast distribution can aid the network, so it is important to have a solid
standard.

Wow! This is an amazing amount of work to combine EVPN and MVPN.
I went between RFC6513, RFC6514, RFC7432, and RFC8542. You caught many of the
issues between the EVPN-MVPN.

I'm hopeful this will help catch a few additional issues.

Sue


Status Early Review: On the right track,
 6 technical issues, editorial issues

===
Summary of Technical issues:

1. Technical issue #1:  Section 5.3 - refers to section 8 and 9
How you do you restriction of importing the same type-5 Route to IPVPN VRF from
multiple PEs (Section 8.1)?

The issue is the same Route-5 from different PEs (MVPN PE or EVPN PE) into the
IPVPN cloud with the same VRF. If type-5  Route is sent from different PEs with
different VRFs, there is not a problem. If type-5 Route is sent once from
different PE with same VRF,  then route selection policy should handle the
resolution. If type-5 Route is sent multiple times from different PEs with Same
VRF, it can encounter the count to infinity problem.

Level: IDR chairs indicate this ia well-known issue, and can be noted in
manageability. Issue: No manageability section.

2. VXLAN tunnels under the MVPN network (Section 8.2.2)
Question: How does the network limit the reach of these tunnels to keep the
EVPN and MVPN?

level: Security/managemeability issue

3. Section 8.2.3 - It is unclear what tunnel types that this RFC draft supports.
Does it support VXLAN plus NVGRE (type = 9) , GRE (type = 2), GENEVE or GPE (?).
Are you supporting any other tunnel types for encapsulation?

Level: Clarity of what is supported in draft

4.  Section 9 – MVPN VPN overlay tunnel over DC network is terminated on
IP-VRF (rather than MAC-VRF/BTs).

Problem 1 – Does the split horizon for EVPN (RFC7432, section 8.3] require MPLS
forwarding in the EVPN-MVPN network? 4a) Does this functioning require MPLS
forwarding of traffic in EVPN--MVPN network? 4b) How is this BUM (Broadcast,
Unknown Unicast, and Multicast traffic) handled in the MVPN/EVPN gateway
(section 6.3) for three types of tunnels?

5. TTL decrement - the IDR chairs do not think this is a problem.

6. The Security section does not seem to cover all the security and
mangeability issue for the EVPN-MVPN?
==

Full Description of 6 Technical issues


Level: Split-horizon + effective split horizon (RFC8584)

===
Explanation of technical comments:

General overview:
The procedures in this draft are an extension of RFC6513 and RFC6514.
Figure 1-2 shows two ways to EVPN and MVPN in seamless operation.

Figure 1:
EVPN glued to MVPN via IP VRFs

EVPN PE1
 ++
   Src1 +|(MAC-VRF1)  |   MVPN PE3
  Rcvr1 +|  \ |+-+   ++
 |(IP-VRF)|| |---|(IP-VRF)|--- Rcvr5
 |  / || |   ++
   Rcvr2 +---|(MAC-VRF2)  || |
 ++| |
   |  MPLS/  |
EVPN PE2   |  IP |
 ++| |
   Rcvr3 +---|(MAC-VRF1)  || |MVPN PE4
 |   \|| |   ++
 |(IP-VRF)|| |---|(IP-VRF)|--- Rcvr6
 |   /|+-+   ++
   Rcvr4 +---|(MAC-VRF3)  |
 ++

   Figure 1:  MVPN PEs Seamless Interop

Figure 2:
EVPN as MVPN PEs

   EVPN PE1
 ++
   Src1 +|(MAC-VRF1)  |
 | \  |
  Rcvr1 +|  ++|+-+   ++
 |  |MVPN PE1||| |---|MVPN PE3|--- Rcvr5
 |  ++|| |   ++
 |  / || |
   Rcvr2 +---|(MAC-VRF2)  || |
 ++| |
   |  MPLS/  |
EVPN PE2   |  IP |
 ++| |
   Rcvr3 +---|(MAC-VRF1)  || |
 |   \|| |
 |  ++|| |   

[bess] Mail regarding draft-ietf-bess-rfc7432bis

[Mankamana Mishra (mankamis)]

Authors, WG

Can we add an explicit statement in the spec about what to do with multicast 
control packets in the EVPN domain?


  1.  IGMP snooping enabled :
 *   IGMP packets are terminated and not flooded over the EVPN domain
  2.  IGMP snooping disabled :
 *   IGMP and any other control packets will be flooded over EVPN domain.

Please let me know if we think otherwise.

Mankamana

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

[bess] FW: WG Adoption and IPR poll for draft-sajassi-bess-evpn-ip-aliasing-09

[Mankamana Mishra (mankamis)]

Forwarding it again on behalf of one of the co-author.

. I do not see this email in the list somehow.

From: Priyanka Warade 
Date: Thursday, November 30, 2023 at 11:03 AM
To: Mankamana Mishra (mankamis) 
Subject: Fwd: WG Adoption and IPR poll for 
draft-sajassi-bess-evpn-ip-aliasing-09


Priyanka

From: Priyanka Warade
Sent: Thursday, November 30, 2023 8:45:22 AM
To: Jeffrey (Zhaohui) Zhang ; 'BESS' 
Cc: 'bess-cha...@ietf.org' ; 
draft-sajassi-bess-evpn-ip-alias...@ietf.org 
; priyanka.war...@gmail.com 

Subject: Re: WG Adoption and IPR poll for draft-sajassi-bess-evpn-ip-aliasing-09


I support adoption of this document as a WG draft and I am not aware of any 
undisclosed IPR.



On 11/13/23, 3:50 AM, "Jeffrey (Zhaohui) Zhang"  wrote:

Hi,



This email begins a two-week WG adoption and IPR poll for 
draft-sajassi-bess-evpn-ip-aliasing-09 
(https://datatracker.ietf.org/doc/html/draft-sajassi-bess-evpn-ip-aliasing-09).



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 the authors and contributors.



If you are not listed as an author or a contributor, then please explicitly 
respond to the IPR poll 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 Monday, 27th of November, 2023.



Thanks.

Jeffrey



Juniper Business Use Only


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

Re: [bess] Rtgdir early review of draft-ietf-bess-evpn-mvpn-seamless-interop-06

[Mankamana Mishra (mankamis)]

Hi Mohamed,
Thanks for your comment. Will be sending an updated version towards the end of 
the week.

Mankamana

From: Mohamed Boucadair via Datatracker 
Date: Wednesday, November 29, 2023 at 10:16 AM
To: rtg-...@ietf.org 
Cc: bess@ietf.org , 
draft-ietf-bess-evpn-mvpn-seamless-interop@ietf.org 

Subject: Rtgdir early review of draft-ietf-bess-evpn-mvpn-seamless-interop-06
Reviewer: Mohamed Boucadair
Review result: Has Issues

Hi Ali, Kesavan, Samir, Ashutosh, and Luay,

Thanks for the effort put into this document. I'm impressed by your patience to
carry this effort for +6 years.

I do think that the overall document is in good track an its core contribution
is almost stable. No serious warnings but a set of items that I think are worth
clarifying (see the detailed review, fwiw).

* pdf:
https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/draft-ietf-bess-evpn-mvpn-seamless-interop-06-rev%20Med.pdf
* doc:
https://github.com/boucadair/IETF-Drafts-Reviews/raw/master/draft-ietf-bess-evpn-mvpn-seamless-interop-06-rev%20Med.doc

It would be helpful to include manageability aspects in one single section.

I'm not convinced that Sections 8/9 fit in the core document. Likewise, the set
of requirements are not linked to the rest of the document. I would expecting
some "assessment" of how these are met in the design.

Feel free to grab whatever you think useful in the review.

Cheers,
Med

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

[bess] Meeting minute IETF 118

[Mankamana Mishra (mankamis)]

All,
https://datatracker.ietf.org/meeting/118/materials/minutes-118-bess-202311061200-01

meeting minutes have been uploaded. If there is any comment please send me .

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

Re: [bess] Rtgdir early review of draft-ietf-bess-evpn-ac-aware-bundling-01

[Mankamana Mishra (mankamis)]

Thanks, not sure if something needs to be done. I see tracker still shows that 
it has issue.

From: Mach Chen 
Date: Thursday, October 26, 2023 at 7:25 PM
To: Mankamana Mishra (mankamis) , rtg-...@ietf.org 

Cc: bess@ietf.org , 
draft-ietf-bess-evpn-ac-aware-bundling@ietf.org 

Subject: RE: Rtgdir early review of draft-ietf-bess-evpn-ac-aware-bundling-01
Hi Mankamana,

I just checked the latest version, it addressed my comments.

Thanks,
Mach

From: Mankamana Mishra (mankamis) 
Sent: Friday, September 15, 2023 11:18 PM
To: Mach Chen ; rtg-...@ietf.org
Cc: bess@ietf.org; draft-ietf-bess-evpn-ac-aware-bundling@ietf.org
Subject: Re: Rtgdir early review of draft-ietf-bess-evpn-ac-aware-bundling-01

Had hit premature send button, all the review comments have been addressed.

From: Mankamana Mishra (mankamis) 
mailto:manka...@cisco.com>>
Date: Thursday, September 14, 2023 at 3:32 PM
To: Mach Chen mailto:mach.c...@huawei.com>>, 
rtg-...@ietf.org<mailto:rtg-...@ietf.org> 
mailto:rtg-...@ietf.org>>
Cc: bess@ietf.org<mailto:bess@ietf.org> mailto:bess@ietf.org>>, 
draft-ietf-bess-evpn-ac-aware-bundling@ietf.org<mailto:draft-ietf-bess-evpn-ac-aware-bundling@ietf.org>
 
mailto:draft-ietf-bess-evpn-ac-aware-bundling@ietf.org>>
Subject: [SUSPICIOUS] Re: Rtgdir early review of 
draft-ietf-bess-evpn-ac-aware-bundling-01
Sorry for delay in reply.  Have made the update in draft and below are the 
changes in 2nd version of draft getting uploaded today. Please let me know if 
this covers your comments.

From: Mach Chen via Datatracker mailto:nore...@ietf.org>>
Date: Thursday, July 13, 2023 at 2:00 AM
To: rtg-...@ietf.org<mailto:rtg-...@ietf.org> 
mailto:rtg-...@ietf.org>>
Cc: bess@ietf.org<mailto:bess@ietf.org> mailto:bess@ietf.org>>, 
draft-ietf-bess-evpn-ac-aware-bundling@ietf.org<mailto:draft-ietf-bess-evpn-ac-aware-bundling@ietf.org>
 
mailto:draft-ietf-bess-evpn-ac-aware-bundling@ietf.org>>
Subject: Rtgdir early review of draft-ietf-bess-evpn-ac-aware-bundling-01
Reviewer: Mach Chen
Review result: Has Issues

Summary:

I have some minor concerns about this document that I think should be resolved
before it is submitted to the IESG.

Here are my comments:

1. There are many different uses of multi-homing or the like in the draft,
e.g., "multi-homing", "multihoming", "multihome", "multi-homed", "multihomed";
"non multihoming" vs "non-multihome", etc. The author needs to check through
the document to make the usage consistent. There is a similar issue to
"Broadcast Domain" vs "broadcast domain", "all-active" vs "all active",
"Attachment Circuit" vs "attachment-circuit",etc.

Mankamana :
Multihoming – aligned with RFC7432 and draft 7432bis
Broadcast domain changed to consistently   - broadcast domain
All form of all active changed to align with RFC 7432 – All-Active
All form of attachment circuit changed to -  attachment circuit



2. For unwell-known acronyms, it's better to expand them upon their first use.
This helps readers understand the context and prevents confusion.
Mankamana : Expanded some of terms (aligned with RFC 7432 abstract). Did not 
expand some of well known terms vlan , mpls . please let me know if we think it 
need to be expanded too


3. There is a concept: multi-homed EVPN peers, but lack of definitions, some
places in the draft also use "multi-homed PEs", "multihomed peers", "multihome
peers", "peering PE", etc. I guess that they are the same meaning and should be
used consistently through the document.
Mankamana : Alighned with RFC 7432 where it uses term PE all of the places. 
There is peer used where it is appropriate


4.
Section 1.1
s/BD-1 has.../In Figure 1, BD-1 has...
s/belongs too/belongs to
Done


5.
Section 1.2
s/forearded to proper AC/forwarded to the proper AC
Done

6. Section 3
1) I assume that the "service interface" is the new defined service interface
in this document, am I right? If so, a "new" should be added before the
"service interface", just as the requirements 5, 6 do. 2) Requirement 1 seems
self-contridiction, multiple VLAN configured on an attachement-circuit, but
each VLAN is represented by a different AC, how to understand this? Rewording
or some clarification needed here. 3) Not sure the intention/meaning of
requirement 2, clarification needed here. 4) Requirement 3 has been stated in
the introduction section, IMHO, the entire section can be removed and put some
of the requirement to other places (e.g., the introduction seciton, the place
where the New service interface is defined.

Mankamana : Yes its new service interface. Added the new term. Thanks for 
catching the issue with first requirement , added statement that each of VLAN 
would be represented 

Re: [bess] Genart early review of draft-ietf-bess-evpn-ac-aware-bundling-03

[Mankamana Mishra (mankamis)]

Hi Russ
Thanks for the comment. I have published 4th version of the draft which 
addresses all of your comments.

Mankamana

From: Mankamana Mishra (mankamis) 
Date: Monday, October 23, 2023 at 2:12 PM
To: Russ Housley , gen-...@ietf.org 
Cc: bess@ietf.org , 
draft-ietf-bess-evpn-ac-aware-bundling@ietf.org 

Subject: Re: Genart early review of draft-ietf-bess-evpn-ac-aware-bundling-03
Thanks for your comment, will be pushing updated version as soon as window 
opens during IETF.

From: Russ Housley via Datatracker 
Date: Friday, October 20, 2023 at 9:02 AM
To: gen-...@ietf.org 
Cc: bess@ietf.org , 
draft-ietf-bess-evpn-ac-aware-bundling@ietf.org 

Subject: Genart early review of draft-ietf-bess-evpn-ac-aware-bundling-03
Reviewer: Russ Housley
Review result: Almost Ready

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 wait for direction from your
document shepherd or AD before posting a new version of the draft.

For more information, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Document: draft-ietf-bess-evpn-ac-aware-bundling-03
Reviewer: Russ Housley
Review Date: 2023-10-20
IETF LC End Date: unknown
IESG Telechat date: unknown

Summary: Almost Ready


Major Concerns:

Section 8: Please clearly identify the IANA registry.


Minor Concerns:

General: Several places, the document includes reference of the form
"[RFC7432] section x.y.z".  It would be much more clear to use the form
"Section x.y.z of [RFC7432]".

Section 6.1 has "attachment circuit ID Extended Community" below the
figure.  Is this a caption?  If so, please center the caption and add a
figure number.


Nits:

General: s/draft/document/ (prepare for publication as an RFC)

Abstract: s/EVPN (Ethernet VPNs) provides/An EVPN (Ethernet VPN) provides/

Section 1: s/This draft proposes/This document specifies/

Section 1.1: s/MAC-2 it can not determine which AC this MAC belongs to/
  /MAC-2, it can not determine the AC associated with this MAC/

Section 1.2: s/which subnet this IGMP membership request belong to/
  /which subnet this IGMP membership request belongs/

Section 1.2: s/forearded to/forwarded to/

Section 3: s/multiple VLAN are configured on/multiple VLAN are configured/

Section 3: s/defined in [RFC7432]/defined in [RFC7432]./

Section 4.1.1.2: s/non multihome/non-multihomed/

Section 4.1.1.2: s/defined in [RFC7432]/defined in [RFC7432]./

Section 4.2.1: s/section 13.1/Section 13.1./

Section 4.2.2: s/in [RFC7432]/in [RFC7432]./

Section 5: s/In this case/In this case,/

Section 6.2: s/is faily large/is fairly large/

Section 6.2: s/This approach is complexifying/This approach adds complexity to/

Section 6.2: s/There is drawback/There is a drawback/



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

Re: [bess] WG Adoption and IPR poll for draft-sajassi-bess-evpn-ip-aliasing-09

[Mankamana Mishra (mankamis)]

Support the adoption of this document.

Mankamana

From: Jeffrey (Zhaohui) Zhang 
Date: Monday, November 13, 2023 at 3:51 AM
To: 'BESS' 
Cc: 'bess-cha...@ietf.org' , 
draft-sajassi-bess-evpn-ip-alias...@ietf.org 

Subject: WG Adoption and IPR poll for draft-sajassi-bess-evpn-ip-aliasing-09
Hi,

This email begins a two-week WG adoption and IPR poll for 
draft-sajassi-bess-evpn-ip-aliasing-09 
(https://datatracker.ietf.org/doc/html/draft-sajassi-bess-evpn-ip-aliasing-09).

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 the authors and contributors.

If you are not listed as an author or a contributor, then please explicitly 
respond to the IPR poll 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 Monday, 27th of November, 2023.

Thanks.
Jeffrey

Juniper Business Use Only
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

[bess] BESS final agenda posted, Presenters please look at note

[Mankamana Mishra (mankamis)]

All,
BESS IETF 118 final agenda posted. You can find it

https://datatracker.ietf.org/meeting/118/materials/agenda-118-bess-01

Important note for the Presenter :


  1.  Please send me your presentation before Saturday
  2.  There are some drafts that are expired. Please refresh as soon as the 
window opens.


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

[bess] Primary agenda posted

[Mankamana Mishra (mankamis)]

All,
Have posted the primary agenda for BESS WG.  We have kept some buffer for 
discussion knowingly.

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

Re: [bess] Genart early review of draft-ietf-bess-evpn-ac-aware-bundling-03

[Mankamana Mishra (mankamis)]

Thanks for your comment, will be pushing updated version as soon as window 
opens during IETF.

From: Russ Housley via Datatracker 
Date: Friday, October 20, 2023 at 9:02 AM
To: gen-...@ietf.org 
Cc: bess@ietf.org , 
draft-ietf-bess-evpn-ac-aware-bundling@ietf.org 

Subject: Genart early review of draft-ietf-bess-evpn-ac-aware-bundling-03
Reviewer: Russ Housley
Review result: Almost Ready

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 wait for direction from your
document shepherd or AD before posting a new version of the draft.

For more information, please see the FAQ at
.

Document: draft-ietf-bess-evpn-ac-aware-bundling-03
Reviewer: Russ Housley
Review Date: 2023-10-20
IETF LC End Date: unknown
IESG Telechat date: unknown

Summary: Almost Ready


Major Concerns:

Section 8: Please clearly identify the IANA registry.


Minor Concerns:

General: Several places, the document includes reference of the form
"[RFC7432] section x.y.z".  It would be much more clear to use the form
"Section x.y.z of [RFC7432]".

Section 6.1 has "attachment circuit ID Extended Community" below the
figure.  Is this a caption?  If so, please center the caption and add a
figure number.


Nits:

General: s/draft/document/ (prepare for publication as an RFC)

Abstract: s/EVPN (Ethernet VPNs) provides/An EVPN (Ethernet VPN) provides/

Section 1: s/This draft proposes/This document specifies/

Section 1.1: s/MAC-2 it can not determine which AC this MAC belongs to/
  /MAC-2, it can not determine the AC associated with this MAC/

Section 1.2: s/which subnet this IGMP membership request belong to/
  /which subnet this IGMP membership request belongs/

Section 1.2: s/forearded to/forwarded to/

Section 3: s/multiple VLAN are configured on/multiple VLAN are configured/

Section 3: s/defined in [RFC7432]/defined in [RFC7432]./

Section 4.1.1.2: s/non multihome/non-multihomed/

Section 4.1.1.2: s/defined in [RFC7432]/defined in [RFC7432]./

Section 4.2.1: s/section 13.1/Section 13.1./

Section 4.2.2: s/in [RFC7432]/in [RFC7432]./

Section 5: s/In this case/In this case,/

Section 6.2: s/is faily large/is fairly large/

Section 6.2: s/This approach is complexifying/This approach adds complexity to/

Section 6.2: s/There is drawback/There is a drawback/


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

Re: [bess] WG Adoption Poll for draft-ietf-bess-bgp-sdwan-uasge-16

[Mankamana Mishra (mankamis)]

Support the adoption.

From: BESS  on behalf of Matthew Bocci (Nokia) 

Date: Thursday, October 5, 2023 at 3:46 AM
To: bess@ietf.org 
Cc: draft-ietf-bess-bgp-sdwan-us...@ietf.org 

Subject: [bess] WG Adoption Poll for draft-ietf-bess-bgp-sdwan-uasge-16
WG

This email starts a one-week WG adoption poll for 
draft-ietf-bess-bgp-sdwan-uasge-16 [1]

A little bit of history: A previous version was adopted, completed WG last 
call, and publication requested as an Informational RFC. v15 of this draft was 
reviewed by the IESG and found to have a restrictive clause in the boilerplate. 
This has now been removed, but since that clause was inconsistent with the 
draft having been adopted as a WG document in the first place, we have been 
asked to go through the process again.

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

This poll will close on Thursday 12th October.

Regards

Matthew

[1] draft-ietf-bess-bgp-sdwan-usage-16 - SD-WAN edge nodes are commonly 
interconnected by multiple types of underlay networks owned and managed by 
different network 
providers.
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

[bess] Please send slot request for IETF 118

[Mankamana Mishra (mankamis)]

All,
Primary agenda has been posted. Please send me slot request for BESS 118.

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

Re: [bess] WG adoption and IPR poll for draft-trr-bess-bgp-srv6-args-02

[Mankamana Mishra (mankamis)]

Support the adoption of this draft.

From: BESS  on behalf of Matthew Bocci (Nokia) 

Date: Thursday, September 28, 2023 at 7:51 AM
To: bess@ietf.org 
Cc: draft-trr-bess-bgp-srv6-a...@ietf.org 

Subject: [bess] WG adoption and IPR poll for draft-trr-bess-bgp-srv6-args-02
This email begins a two-week WG adoption and IPR poll for 
draft-trr-bess-bgp-srv6-args-02 [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 the authors and contributors.
Currently, there is currently no IPR disclosure against this document.

If you are not listed as an author or a contributor, then please explicitly 
respond to the IPR poll 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 Thursday 12th October 2023.

[1] draft-trr-bess-bgp-srv6-args-02 - SRv6 Argument Signaling for BGP Services 
(ietf.org)
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Rtgdir early review of draft-ietf-bess-evpn-ac-aware-bundling-01

[Mankamana Mishra (mankamis)]

Had hit premature send button, all the review comments have been addressed.

From: Mankamana Mishra (mankamis) 
Date: Thursday, September 14, 2023 at 3:32 PM
To: Mach Chen , rtg-...@ietf.org 
Cc: bess@ietf.org , 
draft-ietf-bess-evpn-ac-aware-bundling@ietf.org 

Subject: [SUSPICIOUS] Re: Rtgdir early review of 
draft-ietf-bess-evpn-ac-aware-bundling-01
Sorry for delay in reply.  Have made the update in draft and below are the 
changes in 2nd version of draft getting uploaded today. Please let me know if 
this covers your comments.

From: Mach Chen via Datatracker 
Date: Thursday, July 13, 2023 at 2:00 AM
To: rtg-...@ietf.org 
Cc: bess@ietf.org , 
draft-ietf-bess-evpn-ac-aware-bundling@ietf.org 

Subject: Rtgdir early review of draft-ietf-bess-evpn-ac-aware-bundling-01
Reviewer: Mach Chen
Review result: Has Issues

Summary:

I have some minor concerns about this document that I think should be resolved
before it is submitted to the IESG.

Here are my comments:

1. There are many different uses of multi-homing or the like in the draft,
e.g., "multi-homing", "multihoming", "multihome", "multi-homed", "multihomed";
"non multihoming" vs "non-multihome", etc. The author needs to check through
the document to make the usage consistent. There is a similar issue to
"Broadcast Domain" vs "broadcast domain", "all-active" vs "all active",
"Attachment Circuit" vs "attachment-circuit",etc.

Mankamana :
Multihoming – aligned with RFC7432 and draft 7432bis
Broadcast domain changed to consistently   - broadcast domain
All form of all active changed to align with RFC 7432 – All-Active
All form of attachment circuit changed to -  attachment circuit



2. For unwell-known acronyms, it's better to expand them upon their first use.
This helps readers understand the context and prevents confusion.
Mankamana : Expanded some of terms (aligned with RFC 7432 abstract). Did not 
expand some of well known terms vlan , mpls . please let me know if we think it 
need to be expanded too


3. There is a concept: multi-homed EVPN peers, but lack of definitions, some
places in the draft also use "multi-homed PEs", "multihomed peers", "multihome
peers", "peering PE", etc. I guess that they are the same meaning and should be
used consistently through the document.
Mankamana : Alighned with RFC 7432 where it uses term PE all of the places. 
There is peer used where it is appropriate


4.
Section 1.1
s/BD-1 has.../In Figure 1, BD-1 has...
s/belongs too/belongs to
Done


5.
Section 1.2
s/forearded to proper AC/forwarded to the proper AC
Done

6. Section 3
1) I assume that the "service interface" is the new defined service interface
in this document, am I right? If so, a "new" should be added before the
"service interface", just as the requirements 5, 6 do. 2) Requirement 1 seems
self-contridiction, multiple VLAN configured on an attachement-circuit, but
each VLAN is represented by a different AC, how to understand this? Rewording
or some clarification needed here. 3) Not sure the intention/meaning of
requirement 2, clarification needed here. 4) Requirement 3 has been stated in
the introduction section, IMHO, the entire section can be removed and put some
of the requirement to other places (e.g., the introduction seciton, the place
where the New service interface is defined.

Mankamana : Yes its new service interface. Added the new term. Thanks for 
catching the issue with first requirement , added statement that each of VLAN 
would be represented by AC ID .  removed the 2nd requirement.  I think this 
section helps to clearly get the summary of what this draft is presenting.


7.
Section 4.1.1.1
s/PEs where.../At those PEs where...
s/An attach Attachment.../An Attachment...
s/MAC/IP route.../The MAC/IP Advertisement route
s/to EVPN RT-2/to EVPN Route Type 2 (RT-2)

Done


8.
Section 4.1.1.2
s/to attach remote MAC address to appropriate AC/to associate the remote MAC
address to the appropriate AC

Done

9.
Section 4.1.2.1
Should the "local multihomed AC" be "local multihomed PE"?
s/must/MUST, same usage at other places, it needs to check through the whole
document.

Done


10.
Sectionn 4.1.2.2
"route MUST be programmed to correct subnet", what's the meanning of this
sentence? Rewording/clarification needed here.

Next few statement provides detail about it where subnet is nothing but the 
VLAN where the join came . reading next few lines along with this should 
clarify. If its still not clear please let me know.
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Rtgdir early review of draft-ietf-bess-evpn-ac-aware-bundling-01

[Mankamana Mishra (mankamis)]

Sorry for delay in reply.  Have made the update in draft and below are the 
changes in 2nd version of draft getting uploaded today. Please let me know if 
this covers your comments.

From: Mach Chen via Datatracker 
Date: Thursday, July 13, 2023 at 2:00 AM
To: rtg-...@ietf.org 
Cc: bess@ietf.org , 
draft-ietf-bess-evpn-ac-aware-bundling@ietf.org 

Subject: Rtgdir early review of draft-ietf-bess-evpn-ac-aware-bundling-01
Reviewer: Mach Chen
Review result: Has Issues

Summary:

I have some minor concerns about this document that I think should be resolved
before it is submitted to the IESG.

Here are my comments:

1. There are many different uses of multi-homing or the like in the draft,
e.g., "multi-homing", "multihoming", "multihome", "multi-homed", "multihomed";
"non multihoming" vs "non-multihome", etc. The author needs to check through
the document to make the usage consistent. There is a similar issue to
"Broadcast Domain" vs "broadcast domain", "all-active" vs "all active",
"Attachment Circuit" vs "attachment-circuit",etc.

Mankamana :
Multihoming – aligned with RFC7432 and draft 7432bis
Broadcast domain changed to consistently   - broadcast domain
All form of all active changed to align with RFC 7432 – All-Active
All form of attachment circuit changed to -  attachment circuit



2. For unwell-known acronyms, it's better to expand them upon their first use.
This helps readers understand the context and prevents confusion.
Mankamana : Expanded some of terms (aligned with RFC 7432 abstract). Did not 
expand some of well known terms vlan , mpls . please let me know if we think it 
need to be expanded too


3. There is a concept: multi-homed EVPN peers, but lack of definitions, some
places in the draft also use "multi-homed PEs", "multihomed peers", "multihome
peers", "peering PE", etc. I guess that they are the same meaning and should be
used consistently through the document.
Mankamana : Alighned with RFC 7432 where it uses term PE all of the places. 
There is peer used where it is appropriate


4.
Section 1.1
s/BD-1 has.../In Figure 1, BD-1 has...
s/belongs too/belongs to
Done


5.
Section 1.2
s/forearded to proper AC/forwarded to the proper AC
Done

6. Section 3
1) I assume that the "service interface" is the new defined service interface
in this document, am I right? If so, a "new" should be added before the
"service interface", just as the requirements 5, 6 do. 2) Requirement 1 seems
self-contridiction, multiple VLAN configured on an attachement-circuit, but
each VLAN is represented by a different AC, how to understand this? Rewording
or some clarification needed here. 3) Not sure the intention/meaning of
requirement 2, clarification needed here. 4) Requirement 3 has been stated in
the introduction section, IMHO, the entire section can be removed and put some
of the requirement to other places (e.g., the introduction seciton, the place
where the New service interface is defined.

Mankamana : Yes its new service interface. Added the new term. Thanks for 
catching the issue with first requirement , added statement that each of VLAN 
would be represented by AC ID .  removed the 2nd requirement.  I think this 
section helps to clearly get the summary of what this draft is presenting.


7.
Section 4.1.1.1
s/PEs where.../At those PEs where...
s/An attach Attachment.../An Attachment...
s/MAC/IP route.../The MAC/IP Advertisement route
s/to EVPN RT-2/to EVPN Route Type 2 (RT-2)

Done


8.
Section 4.1.1.2
s/to attach remote MAC address to appropriate AC/to associate the remote MAC
address to the appropriate AC

Done

9.
Section 4.1.2.1
Should the "local multihomed AC" be "local multihomed PE"?
s/must/MUST, same usage at other places, it needs to check through the whole
document.

Done


10.
Sectionn 4.1.2.2
"route MUST be programmed to correct subnet", what's the meanning of this
sentence? Rewording/clarification needed here.

Next few statement provides detail about it where subnet is nothing but the 
VLAN where the join came . reading next few lines along with this should 
clarify. If its still not clear please let me know.
.

11
Section 5
The current description looks like a general requirement, but does not define
how to achieve this. IMHO, it'e better to move this section Section 6, as
sub-section, and define the details on to detect this error with the BGP
protocol processing.

I think this would be relevant for for implementation. Next sections are mostly 
talking about BGP encoding errors but this section is specific about VLAN 
config issue where BGP route does not have problem but both peer are not 
configured with same set of VLAN.

12.
Section 6.1
s/A new EVPN BGP Extended Community/A new BGP Extended Community
s/...called Attachment Circuit ID/...called Attachment Circuit ID Extended
Community Given the Sub-Type is allocated by the INNA, the "TBD" in the text
and Figure should be update to specific value.

Updated

13.
There are 6 authors listed in the front page, according to the IESG/IETF

Re: [bess] IETF 117 BESS - IPv6 Only PE Design & IPv4 Only PE Design ALL SAFI Supported

[Mankamana Mishra (mankamis)]

Support the merger of document.

From: Acee Lindem 
Date: Monday, August 7, 2023 at 6:46 AM
To: Jeff Tantsura 
Cc: Gyan Mishra , BESS , 
bess-cha...@ietf.org , Dongjie (Jimmy) 

Subject: Re: [bess] IETF 117 BESS - IPv6 Only PE Design & IPv4 Only PE Design 
ALL SAFI Supported
I also support merger of the four documents with identification of common 
procedures.

Thanks,
Acee


On Aug 6, 2023, at 21:03, Jeff Tantsura  wrote:

As co-author I support the merge of the documents proposed, please do provide 
any objections you might have.

Cheers,
Jeff


On Jul 27, 2023, at 17:32, Gyan Mishra  wrote:

Dear BESS WG,

From my presentation today discussion on "merging" of drafts I  would like to 
poll the BESS WG on merging of the two drafts labeled #1 & #2 below into the WG 
document labeled #3 below:
Please respond  to this email.

Some history:
IPv6 Only PE design / ALL SAFI:
draft-ietf-bess-ipv6-only-pe-design-04 (BCP) (Original BCP testing draft with 
Cisco, Juniper, Nokia, Arista, Huawei) (WG document)
IPv6 Only PE design single IPv6 peer - testing SAFI 1,128,129
draft-mishra-bess-ipv6-only-pe-design-all-safi-04 (Standards Track) (New Draft) 
- Extended Standards Track to support ALL IPv4 SAFI

IPv4 Only PE design / ALL SAFI:
The below drafts were two separate drafts but I have combined into single draft 
since they both were not WG documents
draft-mishra-bess-ipv4-only-pe-design-02 -(BCP) (POC testing draft with Cisco, 
Juniper, Nokia, Arista, Huawei)
IPv4 Only PE design single IPv4 peer - testing SAFI 1,128,129
draft-mishra-bess-ipv4-only-pe-design-all-safi-05 (Standards track) (New Draft) 
- Extended Standards Track to support ALL IPv4 SAFI (Both v4 drafts have been 
combined into this Draft early this year)
(Introduces new IPv4 next hop encoding IANA capability codepoint 
standardization following RFC 8950 IPv4 next hop and not legacy IPv4 mapped 
IPv6 address next hop ::::1.1.1.1)
(Today there is a mix of IPv4 next hop and IPv4 mapped IPv6 next hop across all 
vendors and within same vendor platform -afi/safi matrix to be added to merged 
draft)

Combine these two drafts --> So now we are left with  these 2 new drafts that 
extend to support ALL SAFI

#1 draft-mishra-bess-ipv6-only-pe-design-all-safi-03 (Standards Track)
#2 draft-mishra-bess-ipv4-only-pe-design-all-safi-04 (Standard Track)

Into WG document below:

#3 draft-ietf-bess-ipv6-only-pe-design-04 (BCP)

And make the new combined draft "Standards Track" as it will have the 
operational process and procedure update for the alternative dual stacking 
method for all SAFI
as well as New IANA capability code point for IPv4 next hop encoding similar to 
RFC 8950.

NEW DRAFT NAME:

 draft-ietf-bess-v4-v6-pe-all-safi (Standards Track)

Why combine?

  *   Both IPv4 Only PE Design & IPv6 Only PE design are identical concepts of 
single IPv4 peer or single IPv6 peer carrying SAFI 1,128.129 for both v4 & v6 
prefixes being POC tested - can now be done in parallel
  *   Extensibility of both the IPv4 Only PE Design & IPv6 Only PE design 
extends to the same set of ALL IPv4 / IPv6 SAFI's
  *   Saves both WG time on progressing 3 separate drafts
  *   Single draft that has the entire v4 / v6 design & architecture in one 
spot versus being broken out into separate drafts added complexity

Thank you


[Image removed by sender.]
Gyan Mishra
Network Solutions Architect
Email gyan.s.mis...@verizon.com
M 301 502-1347

___
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] Meeting minutes uploaded

[Mankamana Mishra (mankamis)]

All,
Meeting minute uploaded for IETF 117. Thanks to Jorge and Krishna for helping 
out with minutes.

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

Re: [bess] Routing Directorate early review for draft-ietf-bess-evpn-per-mcast-flow-df-election-09

[Mankamana Mishra (mankamis)]

Hi Acee,
Thanks for reviewing and comment.  While I make changes to existing draft based 
on your comments,  I had question on some of the comments

  1. Precisely explain the hashing algorithm in section 4.1 and 4.2. As
 written, they subject to multiple interpretations. Provide a reference
 to CRC_32() and expand acronyms on first use (e.g., MSB).

  2. In addition to explaining the hashing algorithm, the document should
 provide a discussion on why this hashing algorithm provides a good
 distribiution of flows.

https://datatracker.ietf.org/doc/html/rfc8584#section-3 defines most of the 
base HRW draft and its benefit . Do you expect it to be repeated in this draft 
too ? This draft does not change the base HRW algorithm but adds flow 
information as also an input parameter to calculate the weight ?

Please let me know if you want only reference to be given or content to be 
copied here ?

Mankamana

From: Acee Lindem 
Date: Friday, July 21, 2023 at 2:43 PM
To: Routing ADs , 
draft-ietf-bess-evpn-per-mcast-flow-df-elect...@ietf.org 

Cc: bess@ietf.org , Routing Directorate 
Subject: Routing Directorate early review for 
draft-ietf-bess-evpn-per-mcast-flow-df-election-09
Hello,

I have been selected as the Routing Directorate reviewer for this draft.
The Routing Directorate seeks to review all routing or routing-related
drafts as they pass through IETF last call and IESG review, and
sometimes on special request. The purpose of the review is to provide
assistance to the Routing ADs. For more information about the Routing
Directorate, please see:

  http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Although these comments are primarily for the use of the Routing ADs,
it would be helpful if you could consider them along with any other
IETF Early Review/Last Call  comments that you receive, and strive to
resolve them through discussion or by updating the draft.

Document: draft-ietf-bess-evpn-per-mcast-flow-df-election-09
Reviewer: Acee Lindem
Review Date: 07/20/2023
IETF LC End Date: N/A
Intended Status: Standards Track

Summary:
This document describes a per-multicast-flow DF election mechanism
which support per multicast flow load-balancing of the EVPN ES
forwarding amongst PEs in a redundancy group. While the document describes
a fairly straightforward function, it really needs some editing and never
should have been adopted as a WG document in this condition. Consequently,
I have entered a “Not Ready” disposition for the review.


Major Issues:
  1. Precisely explain the hashing algorithm in section 4.1 and 4.2. As
 written, they subject to multiple interpretations. Provide a reference
 to CRC_32() and expand acronyms on first use (e.g., MSB).

  2. In addition to explaining the hashing algorithm, the document should
 provide a discussion on why this hashing algorithm provides a good
 distribiution of flows.

 3. While this is a minor comment, it also pertains to the hashing
algorithm. To better distribute the flows, why not exclude the current
BUM DF from the list of PEs from which to choose a per-flow DF??


Minor Issues:

  1. Acronyms from RFC 7432 and RFC 8584 used without first expansion.
 For example, none of the acronyms in the figures are defined. I'd
 suggest adding a glossary with terms from other documents.
  2. The acronym "Es" is used for Ethernet Segment when ES is used in
 other EVPN documents.
  3. Missing articles make the text unwieldy to read.
  4. Multiple problems with agreement of subject and verb.
  5. Define what is referred to by DFn. Presumably, this is the selected
 PE in the redundancy group.
  5. Number 5 in section 5 doesn't make sense as written. I was trying to
 fix it but it needs attention from the author.
  6. The abstract cannot include RFC references from the draft. However,
 the RFCs may be referenced without the braces.
  7. The security considerations for RFC 8584 are also applicable. Additionally,
 you that you are going to be asked for a discussion of how the existing
 security mechanisms apply to per-flow DF selection, so you might as well
 provide it now.


Nits: See diff below.

Thanks,
Acee


*** draft-ietf-bess-evpn-per-mcast-flow-df-election-09.txt.orig Wed Jul 19 
11:43:37 2023
--- draft-ietf-bess-evpn-per-mcast-flow-df-election-09.txt  Wed Jul 19 
12:21:57 2023
***
*** 18,33 

  Abstract

![RFC7432] describes mechanism to elect designated forwarder (DF) at
 the granularity of (ESI, EVI) which is per VLAN (or per group of
 VLANs in case of VLAN bundle or VLAN-aware bundle service).  However,
 the current level of granularity of per-VLAN is not adequate for some
!applications.[RFC8584] improves base line DF election by introducing
!HRW DF election.  [RFC9251] introduces applicability of EVPN to
!Multicast flows, routes to sync them and a default DF election.  This
!document is an extension to HRW base draft [RFC8584] and 

[bess] Primary agenda posted for BESS IETF 117

[Mankamana Mishra (mankamis)]

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

Re: [bess] Rtgdir early review of draft-ietf-bess-evpn-ac-aware-bundling-01

[Mankamana Mishra (mankamis)]

Thanks for your comments. Working on changes based on your comments. Will be 
sending the diff soon and I think new version uploads would be allowed only 
towards IETF date.

Mankamana

From: Mach Chen via Datatracker 
Date: Thursday, July 13, 2023 at 2:00 AM
To: rtg-...@ietf.org 
Cc: bess@ietf.org , 
draft-ietf-bess-evpn-ac-aware-bundling@ietf.org 

Subject: Rtgdir early review of draft-ietf-bess-evpn-ac-aware-bundling-01
Reviewer: Mach Chen
Review result: Has Issues

Summary:

I have some minor concerns about this document that I think should be resolved
before it is submitted to the IESG.

Here are my comments:

1. There are many different uses of multi-homing or the like in the draft,
e.g., "multi-homing", "multihoming", "multihome", "multi-homed", "multihomed";
"non multihoming" vs "non-multihome", etc. The author needs to check through
the document to make the usage consistent. There is a similar issue to
"Broadcast Domain" vs "broadcast domain", "all-active" vs "all active",
"Attachment Circuit" vs "attachment-circuit",etc.

2. For unwell-known acronyms, it's better to expand them upon their first use.
This helps readers understand the context and prevents confusion.

3. There is a concept: multi-homed EVPN peers, but lack of definitions, some
places in the draft also use "multi-homed PEs", "multihomed peers", "multihome
peers", "peering PE", etc. I guess that they are the same meaning and should be
used consistently through the document.

4.
Section 1.1
s/BD-1 has.../In Figure 1, BD-1 has...
s/belongs too/belongs to

5.
Section 1.2
s/forearded to proper AC/forwarded to the proper AC

6. Section 3
1) I assume that the "service interface" is the new defined service interface
in this document, am I right? If so, a "new" should be added before the
"service interface", just as the requirements 5, 6 do. 2) Requirement 1 seems
self-contridiction, multiple VLAN configured on an attachement-circuit, but
each VLAN is represented by a different AC, how to understand this? Rewording
or some clarification needed here. 3) Not sure the intention/meaning of
requirement 2, clarification needed here. 4) Requirement 3 has been stated in
the introduction section, IMHO, the entire section can be removed and put some
of the requirement to other places (e.g., the introduction seciton, the place
where the New service interface is defined.

7.
Section 4.1.1.1
s/PEs where.../At those PEs where...
s/An attach Attachment.../An Attachment...
s/MAC/IP route.../The MAC/IP Advertisement route
s/to EVPN RT-2/to EVPN Route Type 2 (RT-2)

8.
Section 4.1.1.2
s/to attach remote MAC address to appropriate AC/to associate the remote MAC
address to the appropriate AC

9.
Section 4.1.2.1
Should the "local multihomed AC" be "local multihomed PE"?
s/must/MUST, same usage at other places, it needs to check through the whole
document.

10.
Sectionn 4.1.2.2
"route MUST be programmed to correct subnet", what's the meanning of this
sentence? Rewording/clarification needed here.

11
Section 5
The current description looks like a general requirement, but does not define
how to achieve this. IMHO, it'e better to move this section Section 6, as
sub-section, and define the details on to detect this error with the BGP
protocol processing.

12.
Section 6.1
s/A new EVPN BGP Extended Community/A new BGP Extended Community
s/...called Attachment Circuit ID/...called Attachment Circuit ID Extended
Community Given the Sub-Type is allocated by the INNA, the "TBD" in the text
and Figure should be update to specific value.

13.
There are 6 authors listed in the front page, according to the IESG/IETF
policy, no more than 5 authors should be listed on the front page unless there
is reasonable cause.


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

[bess] Please send slot request for BESS IETF 117

[Mankamana Mishra (mankamis)]

All,
Primary agenda has been posted. Please send me slot request for IETF 117.

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

Re: [bess] WG Adoption and IPR poll for draft-sajassi-bess-secure-evpn-06

[Mankamana Mishra (mankamis)]

Support the adoption.

From: BESS  on behalf of Matthew Bocci (Nokia) 

Date: Thursday, May 25, 2023 at 3:36 AM
To: bess@ietf.org 
Cc: draft-sajassi-bess-secure-e...@ietf.org 
, bess-cha...@ietf.org 

Subject: [bess] WG Adoption and IPR poll for draft-sajassi-bess-secure-evpn-06
Hello,

This email begins a two-week WG adoption poll for 
draft-sajassi-bess-secure-evpn-06 [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 the authors and contributors.
Currently, there is currently no IPR disclosure 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 June 9th 2023

Regards,
Matthew and Stephane

[1] https://datatracker.ietf.org/doc/html/draft-sajassi-bess-secure-evpn

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

Re: [bess] WG adoption for draft-brissette-bess-evpn-vpws-seamless

[Mankamana Mishra (mankamis)]

Support the adoption .

From: slitkows.i...@gmail.com 
Date: Wednesday, May 24, 2023 at 1:02 AM
To: bess@ietf.org 
Cc: bess-cha...@ietf.org 
Subject: WG adoption for draft-brissette-bess-evpn-vpws-seamless
Hello,


This email begins a two-weeks WG adoption poll for 
draft-brissette-bess-evpn-vpws-seamless-07 [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 the authors and contributors.
Currently, there is currently no IPR disclosure 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 June 7th.

Regards,
Matthew and Stephane

[1] https://datatracker.ietf.org/doc/draft-brissette-bess-evpn-vpws-seamless/
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

[bess] Meeting minutes IETF 116 published

[Mankamana Mishra (mankamis)]

All,
https://notes.ietf.org/s/notes-ietf-116-bess#

please unicast me if there is any comment or modification needed.

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

Re: [bess] Adoption call for draft: Multicast VPN Upstream Designated Forwarder Selection

[Mankamana Mishra (mankamis)]

++ list .

Mankamana
From: Chensiyu (Susie) 
Date: Thursday, April 6, 2023 at 7:45 AM
To: bess-cha...@ietf.org 
Cc: duanfanghong , Yisong Liu 
, Mankamana Mishra (mankamis) 

Subject: Adoption call for draft: Multicast VPN Upstream Designated Forwarder 
Selection
Dear BESS WG chairs,
We've presented in IETF116 BESS Session about our draft 
"draft-wang-bess-mvpn-upstream-df-selection".
We think the solutions inside this draft are relatively complete and ready to 
be adopted.
Can this draft be added into this time's Adoption Queue?

Thanks
Siyu



-Original Message-
From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org]
Sent: Thursday, April 6, 2023 10:21 PM
To: duanfanghong ; Chensiyu (Susie) 
; Yisong Liu 
Subject: New Version Notification for 
draft-wang-bess-mvpn-upstream-df-selection-06.txt


A new version of I-D, draft-wang-bess-mvpn-upstream-df-selection-06.txt
has been successfully submitted by Siyu Chen and posted to the IETF repository.

Name:   draft-wang-bess-mvpn-upstream-df-selection
Revision:   06
Title:  Multicast VPN Upstream Designated Forwarder Selection
Document date:  2023-04-06
Group:  Individual Submission
Pages:  18
URL:
https://www.ietf.org/archive/id/draft-wang-bess-mvpn-upstream-df-selection-06.txt
Status: 
https://datatracker.ietf.org/doc/draft-wang-bess-mvpn-upstream-df-selection/
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-wang-bess-mvpn-upstream-df-selection
Diff:   
https://author-tools.ietf.org/iddiff?url2=draft-wang-bess-mvpn-upstream-df-selection-06

Abstract:
   This document defines Multicast Virtual Private Network (VPN)
   extensions and procedures of designated forwarder election performed
   between ingress PEs, which is different from the one described in
   [RFC9026] in which the upstream designated forwarder determined by
   using the "Standby PE Community" carried in the C-Multicast routes.
   Based on the DF election, the failure detection point discovery
   mechanism between DF and standby DF is extended in MVPN procedures to
   achieve fast failover by using BFD session to track the status of
   detection point.  To realize a stable "warm root standby", this
   document obsolete the P-Tunnel status determining procedure for
   downstream PEs in regular MVPN by introducing a RPF Set Checking
   mechanism as an instead.





The IETF Secretariat


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

[bess] Next 3 hours cut off for slide in BESS

[Mankamana Mishra (mankamis)]

All,
We still have slides missing from many. If slides not coming in next 3 hours,  
we would be removing request from agenda and backup drafts will be coming in 
agenda.

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

[bess] Please send slides for IETF 116 presentation before Sunday

[Mankamana Mishra (mankamis)]

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

[bess] IETF 116 primary agenda posted

[Mankamana Mishra (mankamis)]

All,
Primary agenda has been posted

https://datatracker.ietf.org/meeting/116/materials/agenda-116-bess-00

Few points to notice

  *   There were more request than what we could fit in agenda
  *   We have kept some buffer time based on last meetings where we run out of 
time or cut short the discussion in room.

Please send me note if you have any.

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

[bess] draft-ietf-bess-evpn-ac-aware-bundling ready for WGLC

[Mankamana Mishra (mankamis)]

Bess WG,

This draft has been around for some time and there is an implementation too. We 
authors think this draft is ready for WGLC. Please post comments if there is 
any. It was presented again in IETF 109 .


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

Re: [bess] Section 8.5 of draft-ietf-bess-rfc7432bis

[Mankamana Mishra (mankamis)]

I would think that based DF is good with simplest one. There are different type 
of deployments and different carving can be used.

Mankamana

From: BESS  on behalf of Gyan Mishra 

Date: Sunday, March 5, 2023 at 10:40 PM
To: Satya Mohanty (satyamoh) 
Cc: Jorge Rabadan (Nokia) , bess@ietf.org 
, mdodge 
Subject: Re: [bess] Section 8.5 of draft-ietf-bess-rfc7432bis
Hi Satya

Backwards compatibility is critical and completely understand.

However let’s say all routers are upgraded to support 8584 and Type 1 HRW and 
negotiate the AC-DF capability exchange codepoint P2P then would all routers 
supporting type 1 automatically start using Type 1 HRW Alg?

Kind Regards

Gyan

On Mon, Mar 6, 2023 at 12:21 AM Satya Mohanty (satyamoh) 
mailto:satya...@cisco.com>> wrote:
Thanks Jorge.

Gyan, indeed all the three algorithms have their use-cases.

As pointed out below in case of inconsistency (the “Alg type”) in the DF 
election extended community for a given ES, it was decided that the DF election 
must default to the modulo-based simply because modulo-based was proposed first 
and all existing deployments already had it, before the other two (Pref-based 
and HRW) came into existence. 
https://www.rfc-editor.org/rfc/rfc8584.html#section-2.2.1

Thanks,
--Satya

From: BESS mailto:bess-boun...@ietf.org>> on behalf of 
Jorge Rabadan (Nokia) mailto:jorge.raba...@nokia.com>>
Date: Friday, March 3, 2023 at 11:06 PM
To: Gyan Mishra mailto:hayabusa...@gmail.com>>
Cc: mdodge mailto:mdo...@drivenets.com>>, 
bess@ietf.org mailto:bess@ietf.org>>
Subject: Re: [bess] Section 8.5 of draft-ietf-bess-rfc7432bis
Hi Gyan,

I agree with your two first statements, but I’m afraid I don’t agree with this 
one:
“I would think HRW would be the new default algorithm used for DF election and 
would not be a knob as it fixes the major deficiencies with the modulus 
algorithm.”

The modulo-based DF algorithm remains the default algorithm in case of 
inconsistency in the Ethernet Segment peers. It uses DF Alg 0, while HRW uses 
type 1 and Preference type 2. HRW is not obsoleting the modulo-based or 
anything like that. The three algorithms are widely used in networks, and while 
the default one has limitations, it is simple and works out in many networks.

Thank you!
Jorge


From: Gyan Mishra mailto:hayabusa...@gmail.com>>
Date: Friday, March 3, 2023 at 11:50 PM
To: Jorge Rabadan (Nokia) 
mailto:jorge.raba...@nokia.com>>
Cc: Menachem Dodge mailto:mdo...@drivenets.com>>, 
bess@ietf.org mailto:bess@ietf.org>>
Subject: Re: [bess] Section 8.5 of draft-ietf-bess-rfc7432bis

CAUTION: This is an external email. Please be very careful when clicking links 
or opening attachments. See http://nok.it/ext for additional information.



Hi Jorge

As defined in RFC 8584 AC-DF and HRW are independent of each other.

RFC 8584 updates RFC 7432, however RFC 7432 bis does not update any aspect of 
RFC 8584 including HRW as you stated.

I would think HRW would be the new default algorithm used for DF election and 
would not be a knob as it fixes the major deficiencies with the modulus 
algorithm.

Thanks

Gyan
On Fri, Feb 10, 2023 at 2:01 PM Jorge Rabadan (Nokia) 
mailto:jorge.raba...@nokia.com>> wrote:
Hi Menachem,

The way I see it, draft-ietf-bess-rfc7432bis will obsolete RFC7432, but it does 
not update or change RFC8584, so I don’t think draft-ietf-bess-rfc7432bis needs 
to repeat the aspects of RFC8584.

In particular, the AC-DF, as the other capabilities defined in other documents, 
is a capability that can be turned on or off. While it is very useful in many 
cases, it actually needs to be disabled in some others, e.g., 
draft-ietf-bess-evpn-mh-pa-07

So the answer to your second question could be that the AC-DF capability should 
be configurable in the implementation, and used on all cases where issues with 
individual Attachment Circuits may create blackholes. However, it has to be 
disabled in case of port-active multi-homing.

My 2 cents..

Thanks.
Jorge


From: BESS mailto:bess-boun...@ietf.org>> on behalf of 
Menachem Dodge mailto:mdo...@drivenets.com>>
Date: Friday, February 10, 2023 at 8:10 AM
To: bess@ietf.org mailto:bess@ietf.org>>
Subject: [bess] Section 8.5 of draft-ietf-bess-rfc7432bis
Some people who received this message don't often get email from 
mdo...@drivenets.com. Learn why this is 
important
Hello All,

In section 8.5 of draft-ietf-bess-rfc7432bis there is a reference to the Finite 
State Machine in section 2.1 of RFC 8584.

However, in section 4 of RFC 8584 the AC Influenced DF Election Capability is 
described and it states that this updates Step 3 of the procedure for service 
carving of RFC 7432.

Shouldn’t this AC-DF update be mentioned in the procedures of section 8.5 of 
draft-ietf-bess-rfc7432bis?

Is AC Influenced DF 

[bess] Please send me unicast request for slot IETF 116

[Mankamana Mishra (mankamis)]

All,
Primary schedule is posted for IETF 116. Please send me request if you need to 
present any draft.

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

[bess] Meeting minutes IETF 115

[Mankamana Mishra (mankamis)]

All,
Meeting minutes published
https://notes.ietf.org/s/notes-ietf-115-bess#

feel free to send me unicast note if there is something missing.

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

[bess] Final agenda posted , Presenters please send me slide

[Mankamana Mishra (mankamis)]

All,
Final agenda has been posted

https://datatracker.ietf.org/meeting/115/materials/agenda-115-bess-01


Note :

  *   We were not able to accommodate all version 0 draft request. We recommend 
to have some discussion in mailing list as well.
  *   We have reduced time for many request, please make sure to adjust your 
slides accordingly.


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

[bess] Primary agenda IETF 115

[Mankamana Mishra (mankamis)]

All,
Please find primary agenda for IETF 115.  There are two more request which is 
not added, waiting for some input from authors.

If anyone’s request is missing, please unicast.

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

[bess] Please send me presentation slot request for IETF 115

[Mankamana Mishra (mankamis)]

All
Please send me slot request for IETF 115 . Agenda has been posted and we are 
scheduled on Friday .

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

Re: [bess] WG adoption poll and IPR poll for draft-sajassi-bess-evpn-ac-aware-bundling

[Mankamana Mishra (mankamis)]

Support as co-author , and not aware of IPR which are not disclosed already.

From: Stephane Litkowski (slitkows) 
Date: Monday, October 10, 2022 at 1:40 AM
To: bess-cha...@ietf.org , bess@ietf.org 
Subject: WG adoption poll and IPR poll for 
draft-sajassi-bess-evpn-ac-aware-bundling
Hello,

This email begins a two-weeks WG adoption poll for 
draft-sajassi-bess-evpn-ac-aware-bundling-06 [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 October 24th 2022.

Regards,
Matthew and Stephane


[1] https://datatracker.ietf.org/doc/draft-sajassi-bess-evpn-ac-aware-bundling/

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

[bess] Meeting minutes IETF-114 BESS session

[Mankamana Mishra (mankamis)]

All,
Please find uploaded meeting minutes for BESS-114 session.

https://datatracker.ietf.org/meeting/114/materials/minutes-114-bess-00

thanks Jorge for taking minutes.


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

[bess] Reminder for slide deck IETF 114

[Mankamana Mishra (mankamis)]

All,
We are meeting on Monday. Please share your slides soon.

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

[bess] Final agenda IETF 114 posted

[Mankamana Mishra (mankamis)]

All ,
Final agenda has been posted. Since we meeting on Monday, please send me your 
slides before Friday.

https://datatracker.ietf.org/meeting/114/materials/agenda-114-bess-01


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

[bess] Shepherd review Comment on draft-ietf-bess-evpn-redundant-mcast-source-03

[Mankamana Mishra (mankamis)]

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.




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

Please replace this with RFC now.



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.


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.


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

117IP multicast, (S,G) state is always created by the RP (Rendezvous

118Point), and sometimes by the Last Hop Router (LHR).

Always and sometimes are contradictory here.


The use of an anycast address assigned to multiple sources may

124be useful for warm standby redundancy solutions.  However, on one

125hand, it's not really helpful for hot standby redundancy solutions

126and on the other hand, configuring the same IP address (in particular

127IPv4 address) in multiple sources may bring issues if the sources

128need to be reached by IP unicast traffic or if the sources are

129attached to the same Broadcast Domain.

May be point to section which defines this. This document has not spoken about 
what hot standby is yet.


131In addition, in the scenario where several G-sources are attached via

132EVPN/OISM, there is not necessarily any (S,G) state created for the



Not defined yet.



Therefore, this document

135extends the above two specifications and assumes that IP Multicast

136source redundancy may exist.  It also assumes that, in case two or

137more sources send the same IP Multicast flows into the tenant domain,

138the EVPN PEs need to avoid that the receivers get packet duplication.

Please mention this document does not talk about how this should be handled for 
PIM or MVPN cases. And it mostly covers the EVPN use cases.


42 the upstream PEs attached to the redundant sources of the same

143tenant, make sure that only one source of the same flow can send

144multicast to the interested downstream PEs at the same time.  In HS

145the upstream PEs forward the redundant multicast flows to the

[bess] Primary agenda IETF 114

[Mankamana Mishra (mankamis)]

All
Primary agenda posted for BESS session. Please  unicast me if there is any 
change needed or anything missing.

https://datatracker.ietf.org/meeting/114/materials/agenda-114-bess-00


Mankamana

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

[bess] Please send slot request for IETF-114

[Mankamana Mishra (mankamis)]

All,
Please send me slot request for IETF 114. Primary agenda has been posted.

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

Re: [bess] WGLC Request for draft-ietf-bess-bgp-sdwan-usage-05

[Mankamana Mishra (mankamis)]

I would be adding it to queue. Chairs will pick from queue and do it one by one.

From: Linda Dunbar 
Date: Monday, April 18, 2022 at 11:45 AM
To: bess-cha...@ietf.org 
Cc: bess@ietf.org 
Subject: WGLC Request for draft-ietf-bess-bgp-sdwan-usage-05
Matthew and Stephane,

At the IETF113  BESS session, your slides stated that  
draft-ietf-bess-bgp-sdwan-usage is the candidate for WG LC.
Can you please let us know what actions we need to take to move the draft to 
WGLC?

Thank you very much,
Linda

From: Linda Dunbar
Sent: Friday, February 25, 2022 10:04 AM
To: bess-cha...@ietf.org
Cc: bess@ietf.org
Subject: RE: WGLC Request for draft-ietf-bess-bgp-sdwan-usage-04

Matthew and Stephane,

Can you please give a feedback on how to move forward?

Thank you
Linda

From: Linda Dunbar
Sent: Friday, January 21, 2022 10:46 AM
To: bess-cha...@ietf.org
Cc: bess@ietf.org
Subject: RE: WGLC Request for draft-ietf-bess-bgp-sdwan-usage-04

Matthew and Stephane,

Can you give some guidance on how to move the draft to WGLC? Is there anything 
authors can do? It has been 3 months since we sent the WGLC request.

Thank you very much,
Linda Dunbar



From: Linda Dunbar
Sent: Monday, October 18, 2021 1:44 PM
To: bess-cha...@ietf.org
Cc: bess@ietf.org
Subject: WGLC Request for draft-ietf-bess-bgp-sdwan-usage-04

Matthew and Stephane,

We think the draft-ietf-bess-bgp-sdwan-usage-04 is ready for WGLC.
https://datatracker.ietf.org/doc/draft-ietf-bess-bgp-sdwan-usage/

The document demonstrates how the BGP-based control plane is used for 
large-scale SDWAN overlay networks with little manual intervention.
It is very useful for the industry.

Thank you,

Linda Dunbar

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

[bess] Meeting minute updated

[Mankamana Mishra (mankamis)]

All,

  *   Meeting minute for IETF113 updated
  *   Few comments were not clear even in recording, if I missed some comment  
it may be good to provide comment for drafts in mailing list as well.
  *   Any comment in minute, please unicast me. I can take care of modification 
of it.

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

Re: [bess] Murray Kucherawy's No Objection on draft-ietf-bess-evpn-igmp-mld-proxy-20: (with COMMENT)

[Mankamana Mishra (mankamis)]

Thanks Murray. Version 21 covers all your comments as well.

Mankamana

From: Murray Kucherawy via Datatracker 
Date: Tuesday, March 22, 2022 at 5:12 AM
To: The IESG 
Cc: draft-ietf-bess-evpn-igmp-mld-pr...@ietf.org 
, bess-cha...@ietf.org 
, bess@ietf.org , slitkows.i...@gmail.com 

Subject: Murray Kucherawy's No Objection on 
draft-ietf-bess-evpn-igmp-mld-proxy-20: (with COMMENT)
Murray Kucherawy has entered the following ballot position for
draft-ietf-bess-evpn-igmp-mld-proxy-20: 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-igmp-mld-proxy/



--
COMMENT:
--

Preserved from my DISCUSS on -14:

I suggest making each of the actions you want to take (there are four) into
their own subsections of this section.

On revision -20:

Section 3 defines "MAC-VRF", but this term appears nowhere in the document.  It
also defines "PMSI", which is not used anywhere else except in the definition
of "S-PMSI", so I suggest merging these.  Lastly, the entire section is sorted
alphabetically except for the last two entries.


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

Re: [bess] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022)

[Mankamana Mishra (mankamis)]

Support adoption of this draft.

From: BESS  on behalf of Susan Hares 
Date: Thursday, March 10, 2022 at 6:56 AM
To: i...@ietf.org , p...@ietf.org , bess@ietf.org 

Subject: [bess] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022)
This begins a 2 week WG adoption call for:
draft-hb-idr-sr-p2mp-policy from (3/10 to 3/24/2022)

You can obtain the draft at:
https://datatracker.ietf.org/doc/draft-hb-idr-sr-p2mp-policy/

In your comments for this call please consider:

1)  Does this technology support the SR P2MP features
that distributes candidate paths which connect
a multicast distribution tree (tree to leaves).

2) Is the technology correctly specified for the
NLRI (AFI/SAFI) and the tunnel encapsulation attribute
additions (sections 2 and 3)?

3) Does the P2MP policy operation (section 4)
provide enough information for those implementing this
technology and those deploying the technology?

4) Do you think this multicast technology is a good
Place to start for P2MP policy advertisement via BGP?

5) Do you think this SR P2MP policies should not be advertised
via BGP?

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

Re: [bess] Alvaro Retana's Discuss on draft-ietf-bess-evpn-igmp-mld-proxy-14: (with DISCUSS and COMMENT)

[Mankamana Mishra (mankamis)]

Thanks Alvaro for comment. I have made the changes as per your comment. And its 
being uploaded in next few minutes (Tool is throwing some error, so working on 
it to get it published).

Mankamana

From: Alvaro Retana 
Date: Friday, March 11, 2022 at 7:35 AM
To: Mankamana Mishra (mankamis) 
Cc: draft-ietf-bess-evpn-igmp-mld-pr...@ietf.org 
, slitkows.i...@gmail.com 
, bess-cha...@ietf.org , 
bess@ietf.org , The IESG 
Subject: Re: Alvaro Retana's Discuss on draft-ietf-bess-evpn-igmp-mld-proxy-14: 
(with DISCUSS and COMMENT)
On January 13, 2022 at 5:11:26 PM, Mankamana Mishra wrote:

Mankamana:

Hi!  Sorry for the delay.

...
> Apart from that there were no concern from PIM WG .

I'm sad because we couldn't find interest in pim to do a thorough
review.  I don't translate that into "no concern", but that is just a
difference of opinion.

I'm going to change my ballot to ABSTAIN as I still think that not
requiring IGMPv1 contradicts the current IGMP standard.  By ABSTAINing
I'm basically removing my objection to the publication.


> Open Question :
>
> Statements about IGMP V1, there was no concern from PIM WG or BESS WG either.
> Do you want any thing specific to be mentioned in this draft ?

I would be happier with the text as follows.  [Because I'm ABSTAINing
you don't have to change anything.]

OLD>
   10.  IGMP Version 1 Membership Report

   This document does not provide any detail about IGMPv1 processing.
   Multicast working group are in process of deprecating uses of IGMPv1.
   Implementations MUST only use IGMPv2 and above for IPv4 and MLDv1 and
   above for IPv6.  IGMP V1 routes MUST be considered as invalid and the
   PE MUST apply the "treat-as-withdraw" procedure as per [RFC7606].
   Initial version of document did mention use of IGMPv1 and flag had
   provision to support IGMPv1.  There may be an implementation which is
   deployed as initial version of document, to interop flag has not been
   changed.


NEW>
   10.  IGMP Version 1 Membership Report

   This document does not provide any detail about IGMPv1 processing.
   Implementations are expected to only use IGMPv2 and above for IPv4 and
   MLDv1 and above for IPv6. IGMPv1 routes are considered invalid and the
   PE MUST apply the "treat-as-withdraw" procedure as per [RFC7606].


> Later inline for flag question, I have one way to handle this. Please let me
> know your view and I can make the changes.

I'm fine with that.


Thanks!

Alvaro.
<<< text/html; name="Diff draft-ietf-bess-evpn-igmp-mld-proxy-19.txt - draft-ietf-bess-evpn-igmp-mld-proxy-20.txt.html": Unrecognized >>>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Fwd: Murray Kucherawy's Discuss on draft-ietf-bess-evpn-igmp-mld-proxy-14: (with DISCUSS and COMMENT)

[Mankamana Mishra (mankamis)]

Thanks Murray for comment. Attached diff is being published in next 15 min 
(sorry tool has some issue, so upload is failing).

It address your comment .

From: Murray S. Kucherawy 
Date: Monday, March 14, 2022 at 9:43 PM
To: John E Drake 
Cc: BESS , bess-cha...@ietf.org , 
Mankamana Mishra (mankamis) , Ali Sajassi (sajassi) 

Subject: Re: [bess] Fwd: Murray Kucherawy's Discuss on 
draft-ietf-bess-evpn-igmp-mld-proxy-14: (with DISCUSS and COMMENT)
On Mon, Mar 14, 2022 at 8:04 AM John E Drake 
mailto:jdr...@juniper.net>> wrote:

[JD]  We will change the SHOULD to a MUST in sections 9.1 and 9.1.3.  The 
SHOULD in sections 9.1.1, 9.2.1, and 9.3.1 are fine;  there are RDs of other 
types and everything will work if they are used but type 1 is preferred because 
it provides the address of the route originator.  If you would like, we can add 
this explanation to those sections


Yes, that would be ideal.  Thanks!

-MSK
<<< text/html; name="Diff draft-ietf-bess-evpn-igmp-mld-proxy-19.txt - draft-ietf-bess-evpn-igmp-mld-proxy-20.txt.html": Unrecognized >>>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

[bess] Bess IETF 113 , final agenda posted

[Mankamana Mishra (mankamis)]

All,
Here is the final agenda for BESS session.

https://datatracker.ietf.org/meeting/113/materials/agenda-113-bess-01


I have got some more new request to add topic, would get back soon.


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

[bess] Primary agenda posted, Final agenda would be posted mid of next week

[Mankamana Mishra (mankamis)]

All,

Please find primary agenda.

https://datatracker.ietf.org/meeting/113/materials/agenda-113-bess-00


If something got missed, please unicast me.


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

Re: [bess] Éric Vyncke's Discuss on draft-ietf-bess-evpn-igmp-mld-proxy-18: (with DISCUSS and COMMENT)

[Mankamana Mishra (mankamis)]

I would add Luc comment as soon as window open to submit.

From: Eric Vyncke (evyncke) 
Date: Monday, March 7, 2022 at 11:31 PM
To: Luc André Burdet , Mankamana Mishra (mankamis) 
, John E Drake , The IESG 

Cc: draft-ietf-bess-evpn-igmp-mld-pr...@ietf.org 
, bess-cha...@ietf.org 
, slitkows.i...@gmail.com , 
bess@ietf.org 
Subject: Re: Éric Vyncke's Discuss on draft-ietf-bess-evpn-igmp-mld-proxy-18: 
(with DISCUSS and COMMENT)
I like this wording Luc André as it is less clumsy than existing text.

Anyway, the -19 addresses my only remaining blocking DISCUSS point, so, I am 
clearing my DISCUSS in the following minutes.

I hope that all this discussion has improved the document.

Respectfully yours,

-éric



From: Luc André Burdet 
Date: Saturday, 5 March 2022 at 16:06
To: "Mankamana Mishra (mankamis)" , Eric 
Vyncke , John E Drake , 
The IESG 
Cc: "draft-ietf-bess-evpn-igmp-mld-pr...@ietf.org" 
, "bess-cha...@ietf.org" 
, "slitkows.i...@gmail.com" , 
"bess@ietf.org" 
Subject: Re: Éric Vyncke's Discuss on draft-ietf-bess-evpn-igmp-mld-proxy-18: 
(with DISCUSS and COMMENT)

Hi Éric, Mankamana & John,

Just read -19 viz this thread.
The IGMP/MLD duality has been seen before and in previous cases (RFC4604) it 
was explicitly called out also  (for good cause: IGMP Membership vs MLD 
Listener,  IGMP Leave vs MLD Done, etc)



RFC3376:

   In this document, unless otherwise qualified, the capitalized words

   "Query" and "Report" refer to IGMP Membership Queries and IGMP

   Version 3 Membership Reports, respectively.



RFC3810:

   In this document, unless otherwise qualified, the capitalized words

   "Query" and "Report" refer to MLD Multicast Listener Queries and MLD

   Version 2 Multicast Listener Reports, respectively.



RFC4604:

   Due to the commonality of function, the term "Group Management

   Protocol", or "GMP", will be used to refer to both IGMP and MLD.  The

   term "Source Filtering GMP", or "SFGMP", will be used to refer

   jointly to the IGMPv3 and MLDv2 group management protocols.




Could I propose just adding a small clarifying paragraph in Intro which does 
the same as those 3 and use that terminology?



The term "Group Management Protocol", or "GMP", was first defined in RFC4604 to 
address the commonality of function between IGMP and LMD.

In this document, unless otherwise qualified:

-the capitalized words "GMP Query" refer to IGMP Membership Queries and MLD 
Multicast Listener Queries; and

-the capitalized words "GMP Report" refer to IGMP Version X Membership 
Reports and MLD Version 2 Multicast Listener Reports.

s/ IGMP Membership Reports/GMP Reports/g


Regards,
Luc André

Luc André Burdet |  Cisco  |  laburdet.i...@gmail.com  |  Tel: +1 613 254 4814


From: BESS  on behalf of Mankamana Mishra (mankamis) 

Date: Friday, March 4, 2022 at 12:09
To: Eric Vyncke (evyncke) , John E Drake 
, The IESG 
Cc: draft-ietf-bess-evpn-igmp-mld-pr...@ietf.org 
, bess-cha...@ietf.org 
, slitkows.i...@gmail.com , 
bess@ietf.org 
Subject: Re: [bess] Éric Vyncke's Discuss on 
draft-ietf-bess-evpn-igmp-mld-proxy-18: (with DISCUSS and COMMENT)
Hi Eric,
Posted new revision addressing two of your comment

1.   Latest comment about adding IGMP / MLD before terminology

2.   Pending from last one, where section 4.1.1 numbers were getting reset 
without comment


Mankamana

From: Mankamana Mishra (mankamis) 
Date: Friday, March 4, 2022 at 7:42 AM
To: Eric Vyncke (evyncke) , John E Drake 
, The IESG 
Cc: draft-ietf-bess-evpn-igmp-mld-pr...@ietf.org 
, slitkows.i...@gmail.com 
, bess-cha...@ietf.org , 
bess@ietf.org 
Subject: Re: Éric Vyncke's Discuss on draft-ietf-bess-evpn-igmp-mld-proxy-18: 
(with DISCUSS and COMMENT)
Thanks, positing update in 30 min.

Mankamana

From: Eric Vyncke (evyncke) 
Date: Friday, March 4, 2022 at 7:36 AM
To: Mankamana Mishra (mankamis) , John E Drake 
, The IESG 
Cc: draft-ietf-bess-evpn-igmp-mld-pr...@ietf.org 
, slitkows.i...@gmail.com 
, bess-cha...@ietf.org , 
bess@ietf.org 
Subject: Re: Éric Vyncke's Discuss on draft-ietf-bess-evpn-igmp-mld-proxy-18: 
(with DISCUSS and COMMENT)
Correct this will address my DISCUSS point if you also modify the line below, 
i.e., replace all IGMP by IGMP/MLD in the text until the terminology section 
states "IGMP means IGMP or MLD" (sic).

Regards

-éric


From: "Mankamana Mishra (mankamis)" 
Date: Friday, 4 March 2022 at 16:33
To: Eric Vyncke , John E Drake 
, The IESG 
Cc: "draft-ietf-bess-evpn-igmp-mld-pr...@ietf.org" 
, "slitkows.i...@gmail.com" 
, "bess-cha...@ietf.org" , 
"bess@ietf.org" 
Subject: Re: Éric Vyncke's Discuss on draft-ietf-bess-evpn-igmp-mld-proxy-18: 
(with DISCUSS and COMMENT)

Hi Eric,

These hosts/VMs express their interests in multicast groups on a
 

Re: [bess] Éric Vyncke's Discuss on draft-ietf-bess-evpn-igmp-mld-proxy-18: (with DISCUSS and COMMENT)

[Mankamana Mishra (mankamis)]

Hi Eric,
Posted new revision addressing two of your comment

  1.  Latest comment about adding IGMP / MLD before terminology
  2.  Pending from last one, where section 4.1.1 numbers were getting reset 
without comment


Mankamana

From: Mankamana Mishra (mankamis) 
Date: Friday, March 4, 2022 at 7:42 AM
To: Eric Vyncke (evyncke) , John E Drake 
, The IESG 
Cc: draft-ietf-bess-evpn-igmp-mld-pr...@ietf.org 
, slitkows.i...@gmail.com 
, bess-cha...@ietf.org , 
bess@ietf.org 
Subject: Re: Éric Vyncke's Discuss on draft-ietf-bess-evpn-igmp-mld-proxy-18: 
(with DISCUSS and COMMENT)
Thanks, positing update in 30 min.

Mankamana

From: Eric Vyncke (evyncke) 
Date: Friday, March 4, 2022 at 7:36 AM
To: Mankamana Mishra (mankamis) , John E Drake 
, The IESG 
Cc: draft-ietf-bess-evpn-igmp-mld-pr...@ietf.org 
, slitkows.i...@gmail.com 
, bess-cha...@ietf.org , 
bess@ietf.org 
Subject: Re: Éric Vyncke's Discuss on draft-ietf-bess-evpn-igmp-mld-proxy-18: 
(with DISCUSS and COMMENT)
Correct this will address my DISCUSS point if you also modify the line below, 
i.e., replace all IGMP by IGMP/MLD in the text until the terminology section 
states "IGMP means IGMP or MLD" (sic).

Regards

-éric


From: "Mankamana Mishra (mankamis)" 
Date: Friday, 4 March 2022 at 16:33
To: Eric Vyncke , John E Drake 
, The IESG 
Cc: "draft-ietf-bess-evpn-igmp-mld-pr...@ietf.org" 
, "slitkows.i...@gmail.com" 
, "bess-cha...@ietf.org" , 
"bess@ietf.org" 
Subject: Re: Éric Vyncke's Discuss on draft-ietf-bess-evpn-igmp-mld-proxy-18: 
(with DISCUSS and COMMENT)

Hi Eric,

These hosts/VMs express their interests in multicast groups on a
   given subnet/VLAN by sending IGMP Membership Reports (Joins) for. >> Adding 
MLD here too ?
   their interested multicast group(s).  Furthermore, an IGMP router
   periodically sends membership queries to find out if there are hosts
   on that subnet that are still interested in receiving multicast
   traffic for that group.  The IGMP/MLD Proxy solution described in
   this draft accomplishes has three objectives:


does this change look ok ?

From: Eric Vyncke (evyncke) 
Date: Friday, March 4, 2022 at 7:29 AM
To: John E Drake , The IESG 
Cc: draft-ietf-bess-evpn-igmp-mld-pr...@ietf.org 
, slitkows.i...@gmail.com 
, bess-cha...@ietf.org , 
bess@ietf.org 
Subject: Re: Éric Vyncke's Discuss on draft-ietf-bess-evpn-igmp-mld-proxy-18: 
(with DISCUSS and COMMENT)
Hello John,

Thanks for your quick reply, even if I am unsure how to read " Yours 
Irrespectively," as I am not an English-native person.

Thank you for pointing me to the new sections 9.1.2 & others => I will update 
my DISCUSS on this point w/o sending another email.

But section 1 still mentions only IGMP and never MLD except for "IGMP/MLD" 
proxy, this is trivial to fix, so I suggest to the authors to update the draft.

Regards

-éric

-Original Message-
From: iesg  on behalf of John E Drake 

Date: Friday, 4 March 2022 at 15:01
To: Eric Vyncke , The IESG 
Cc: "draft-ietf-bess-evpn-igmp-mld-pr...@ietf.org" 
, "slitkows.i...@gmail.com" 
, "bess-cha...@ietf.org" , 
"bess@ietf.org" 
Subject: RE: Éric Vyncke's Discuss on draft-ietf-bess-evpn-igmp-mld-proxy-18: 
(with DISCUSS and COMMENT)

Hi,

Snipped, comments inline

Yours Irrespectively,

John


Juniper Business Use Only

> -Original Message-

> DISCUSS:
> --
>
> As Martin Vigoureux's term is near its end, I took the liberty to 
re-evaluate the
> ballot status of this document and clearing parts of my original block 
DISCUSS
> points and many of my original non-blocking COMMENT points.
>
> See below this line for updated version
> --
>
> Thank you for the work put into this document. I have to state that I am 
neither
> a EVPN expert not a multicast one.
>
> Please find below some blocking DISCUSS points (probably easy to address),
> some non-blocking COMMENT points (but replies would be appreciated even if
> only for my own education), and some nits.
>
> Special thanks to Stéphane Litkowski for his shepherd's write-up about 
the WG
> consensus.
>
> I hope that this helps to improve the document,
>
> Regards,
>
> -éric
>
> == DISCUSS ==
>
> The text covers in details how to map MLD/IGMP into BGP routes but does 
not
> say a word on how to recreate the MLD/IGMP packets. Should there be any 
such
> specification (e.g., in section 4.1) ?

[JD]  We added:

9.1.2.  Reconstructing IGMP / MLD Membership Reports from Selective 
Multicast Route

9.2.2.  Reconstructing IGMP / MLD Membership Reports 

Re: [bess] Éric Vyncke's Discuss on draft-ietf-bess-evpn-igmp-mld-proxy-18: (with DISCUSS and COMMENT)

[Mankamana Mishra (mankamis)]

Thanks, positing update in 30 min.

Mankamana

From: Eric Vyncke (evyncke) 
Date: Friday, March 4, 2022 at 7:36 AM
To: Mankamana Mishra (mankamis) , John E Drake 
, The IESG 
Cc: draft-ietf-bess-evpn-igmp-mld-pr...@ietf.org 
, slitkows.i...@gmail.com 
, bess-cha...@ietf.org , 
bess@ietf.org 
Subject: Re: Éric Vyncke's Discuss on draft-ietf-bess-evpn-igmp-mld-proxy-18: 
(with DISCUSS and COMMENT)
Correct this will address my DISCUSS point if you also modify the line below, 
i.e., replace all IGMP by IGMP/MLD in the text until the terminology section 
states "IGMP means IGMP or MLD" (sic).

Regards

-éric


From: "Mankamana Mishra (mankamis)" 
Date: Friday, 4 March 2022 at 16:33
To: Eric Vyncke , John E Drake 
, The IESG 
Cc: "draft-ietf-bess-evpn-igmp-mld-pr...@ietf.org" 
, "slitkows.i...@gmail.com" 
, "bess-cha...@ietf.org" , 
"bess@ietf.org" 
Subject: Re: Éric Vyncke's Discuss on draft-ietf-bess-evpn-igmp-mld-proxy-18: 
(with DISCUSS and COMMENT)

Hi Eric,

These hosts/VMs express their interests in multicast groups on a
   given subnet/VLAN by sending IGMP Membership Reports (Joins) for. >> Adding 
MLD here too ?
   their interested multicast group(s).  Furthermore, an IGMP router
   periodically sends membership queries to find out if there are hosts
   on that subnet that are still interested in receiving multicast
   traffic for that group.  The IGMP/MLD Proxy solution described in
   this draft accomplishes has three objectives:


does this change look ok ?

From: Eric Vyncke (evyncke) 
Date: Friday, March 4, 2022 at 7:29 AM
To: John E Drake , The IESG 
Cc: draft-ietf-bess-evpn-igmp-mld-pr...@ietf.org 
, slitkows.i...@gmail.com 
, bess-cha...@ietf.org , 
bess@ietf.org 
Subject: Re: Éric Vyncke's Discuss on draft-ietf-bess-evpn-igmp-mld-proxy-18: 
(with DISCUSS and COMMENT)
Hello John,

Thanks for your quick reply, even if I am unsure how to read " Yours 
Irrespectively," as I am not an English-native person.

Thank you for pointing me to the new sections 9.1.2 & others => I will update 
my DISCUSS on this point w/o sending another email.

But section 1 still mentions only IGMP and never MLD except for "IGMP/MLD" 
proxy, this is trivial to fix, so I suggest to the authors to update the draft.

Regards

-éric

-Original Message-
From: iesg  on behalf of John E Drake 

Date: Friday, 4 March 2022 at 15:01
To: Eric Vyncke , The IESG 
Cc: "draft-ietf-bess-evpn-igmp-mld-pr...@ietf.org" 
, "slitkows.i...@gmail.com" 
, "bess-cha...@ietf.org" , 
"bess@ietf.org" 
Subject: RE: Éric Vyncke's Discuss on draft-ietf-bess-evpn-igmp-mld-proxy-18: 
(with DISCUSS and COMMENT)

Hi,

Snipped, comments inline

Yours Irrespectively,

John


Juniper Business Use Only

> -Original Message-

> DISCUSS:
> --
>
> As Martin Vigoureux's term is near its end, I took the liberty to 
re-evaluate the
> ballot status of this document and clearing parts of my original block 
DISCUSS
> points and many of my original non-blocking COMMENT points.
>
> See below this line for updated version
> --
>
> Thank you for the work put into this document. I have to state that I am 
neither
> a EVPN expert not a multicast one.
>
> Please find below some blocking DISCUSS points (probably easy to address),
> some non-blocking COMMENT points (but replies would be appreciated even if
> only for my own education), and some nits.
>
> Special thanks to Stéphane Litkowski for his shepherd's write-up about 
the WG
> consensus.
>
> I hope that this helps to improve the document,
>
> Regards,
>
> -éric
>
> == DISCUSS ==
>
> The text covers in details how to map MLD/IGMP into BGP routes but does 
not
> say a word on how to recreate the MLD/IGMP packets. Should there be any 
such
> specification (e.g., in section 4.1) ?

[JD]  We added:

9.1.2.  Reconstructing IGMP / MLD Membership Reports from Selective 
Multicast Route

9.2.2.  Reconstructing IGMP / MLD Membership Reports from Multicast 
Membership Report Sync Route

9.3.2.  Reconstructing IGMP / MLD Leave from Multicast Leave Sync Route

>
> -- Section 1 --
> In the same vein, is it about IGMP only ? Or does it include MLD as well 
? It is
> really unclear.

[JD]  The Abstract states:   This document describes how to support 
efficiently endpoints running IGMP
(Internet Group Management Protocol) or MLD (Multicast Listener  Discovery) 
for the multicast services
over an EVPN network by incorporating IGMP/MLD proxy procedures on EVPN 
(Ethernet VPN) PEs.

 

Re: [bess] Éric Vyncke's Discuss on draft-ietf-bess-evpn-igmp-mld-proxy-18: (with DISCUSS and COMMENT)

[Mankamana Mishra (mankamis)]

Hi Eric,

These hosts/VMs express their interests in multicast groups on a
   given subnet/VLAN by sending IGMP Membership Reports (Joins) for. >> Adding 
MLD here too ?
   their interested multicast group(s).  Furthermore, an IGMP router
   periodically sends membership queries to find out if there are hosts
   on that subnet that are still interested in receiving multicast
   traffic for that group.  The IGMP/MLD Proxy solution described in
   this draft accomplishes has three objectives:


does this change look ok ?

From: Eric Vyncke (evyncke) 
Date: Friday, March 4, 2022 at 7:29 AM
To: John E Drake , The IESG 
Cc: draft-ietf-bess-evpn-igmp-mld-pr...@ietf.org 
, slitkows.i...@gmail.com 
, bess-cha...@ietf.org , 
bess@ietf.org 
Subject: Re: Éric Vyncke's Discuss on draft-ietf-bess-evpn-igmp-mld-proxy-18: 
(with DISCUSS and COMMENT)
Hello John,

Thanks for your quick reply, even if I am unsure how to read " Yours 
Irrespectively," as I am not an English-native person.

Thank you for pointing me to the new sections 9.1.2 & others => I will update 
my DISCUSS on this point w/o sending another email.

But section 1 still mentions only IGMP and never MLD except for "IGMP/MLD" 
proxy, this is trivial to fix, so I suggest to the authors to update the draft.

Regards

-éric

-Original Message-
From: iesg  on behalf of John E Drake 

Date: Friday, 4 March 2022 at 15:01
To: Eric Vyncke , The IESG 
Cc: "draft-ietf-bess-evpn-igmp-mld-pr...@ietf.org" 
, "slitkows.i...@gmail.com" 
, "bess-cha...@ietf.org" , 
"bess@ietf.org" 
Subject: RE: Éric Vyncke's Discuss on draft-ietf-bess-evpn-igmp-mld-proxy-18: 
(with DISCUSS and COMMENT)

Hi,

Snipped, comments inline

Yours Irrespectively,

John


Juniper Business Use Only

> -Original Message-

> DISCUSS:
> --
>
> As Martin Vigoureux's term is near its end, I took the liberty to 
re-evaluate the
> ballot status of this document and clearing parts of my original block 
DISCUSS
> points and many of my original non-blocking COMMENT points.
>
> See below this line for updated version
> --
>
> Thank you for the work put into this document. I have to state that I am 
neither
> a EVPN expert not a multicast one.
>
> Please find below some blocking DISCUSS points (probably easy to address),
> some non-blocking COMMENT points (but replies would be appreciated even if
> only for my own education), and some nits.
>
> Special thanks to Stéphane Litkowski for his shepherd's write-up about 
the WG
> consensus.
>
> I hope that this helps to improve the document,
>
> Regards,
>
> -éric
>
> == DISCUSS ==
>
> The text covers in details how to map MLD/IGMP into BGP routes but does 
not
> say a word on how to recreate the MLD/IGMP packets. Should there be any 
such
> specification (e.g., in section 4.1) ?

[JD]  We added:

9.1.2.  Reconstructing IGMP / MLD Membership Reports from Selective 
Multicast Route

9.2.2.  Reconstructing IGMP / MLD Membership Reports from Multicast 
Membership Report Sync Route

9.3.2.  Reconstructing IGMP / MLD Leave from Multicast Leave Sync Route

>
> -- Section 1 --
> In the same vein, is it about IGMP only ? Or does it include MLD as well 
? It is
> really unclear.

[JD]  The Abstract states:   This document describes how to support 
efficiently endpoints running IGMP
(Internet Group Management Protocol) or MLD (Multicast Listener  Discovery) 
for the multicast services
over an EVPN network by incorporating IGMP/MLD proxy procedures on EVPN 
(Ethernet VPN) PEs.

We also added this paragraph to section 3 at Ben's behest:

It is important to note when there is text considering whether a PE 
indicates support for IGMP proxying,
the corresponding behavior has a natural analogue for indication of support 
for MLD proxying, and the
analogous requirements apply as well.
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

[bess] Bess session would be in person as well as remote

[Mankamana Mishra (mankamis)]

All,
Just wanted to update on last email to group, that we have been able to 
identify one WG member who is going to be present insite. So now we would have 
BESS session in person as well as remote. Both chairs would be remote only .

If there is any question about logistics , please send it across.

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

[bess] Please send me slot request for IETF 113 (BESS is only remote )

[Mankamana Mishra (mankamis)]

All,
Please send me slot request for IETF 113. Please note BESS session would be 
only remote since none of the chairs are able to travel in person this time.


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

Re: [bess] Benjamin Kaduk's Discuss on draft-ietf-bess-evpn-igmp-mld-proxy-13: (with DISCUSS and COMMENT)

[Mankamana Mishra (mankamis)]

Thanks john for providing input. New version of draft accommodated all of these 
changes.

Mankamana

From: John E Drake 
Date: Friday, February 11, 2022 at 8:13 AM
To: Mankamana Mishra (mankamis) , Benjamin Kaduk 

Cc: The IESG , draft-ietf-bess-evpn-igmp-mld-pr...@ietf.org 
, bess-cha...@ietf.org 
, bess@ietf.org , slitkows.i...@gmail.com 

Subject: RE: Benjamin Kaduk's Discuss on 
draft-ietf-bess-evpn-igmp-mld-proxy-13: (with DISCUSS and COMMENT)
Hi,

Here are my proposed changes:

8<https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-igmp-mld-proxy-06#section-8>.
  Selective Multicast Procedures for IR tunnels

   If an ingress PE uses ingress replication, then for a given (x,G)
   group in a given BD:

   1.  It sends (x,G) traffic to the set of PEs not supporting IGMP
   Proxy.  This set consists of any PE that has advertised an
   Inclusive Multicast Tag route for the BD without the "IGMP Proxy
   Support" flag.

*JD  This set consists of any PE that has advertised an IMET route for the 
BD
without a  Multicast Flags extended community or with a Multicast Flags extended
community in which neither the IGMP Proxy support nor the  MLD Proxy support
flags are set.

   2.  It sends (x,G) traffic to the set of PEs supporting IGMP Proxy
   and having listeners for that (x,G) group in that BD.  This set
   consists of any PE that has advertised an Inclusive Multicast Tag
   route for the BD with the "IGMP Proxy Support" flag and that has
   advertised a SMET route for that (x,G) group in that BD.

*JD  This set consists of any PE that has advertised an IMET route for the 
BD
with a Multicast Flags extended community in which the IGMP Proxy support and/or
the  MLD Proxy support flags are set and that has advertised a SMET route for 
that (x,G)
group in that BD.

   If an ingress PE's Selective P-Tunnel for a given BD uses P2MP and
   all of the PEs in the BD support that tunnel type and IGMP proxy,

*JD and IGMP and/or MLD proxy,

   then for a given (x,G) group in a given BD it sends (x,G) traffic
   using the Selective P-Tunnel for that (x,G) group in that BD.  This
   tunnel includes those PEs that have advertised a SMET route for that
   (x,G) group on that BD (for Selective P-tunnel) but it may include
   other PEs as well (for Aggregate Selective P-tunnel).

9.4<https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-igmp-mld-proxy-06#section-9.4>.
  Multicast Flags Extended Community

   The 'Multicast Flags' extended community is a new EVPN extended
   community.  EVPN extended communities are transitive extended
   communities with a Type field value of 6.  IANA will assign a Sub-
   Type from the 'EVPN Extended Community Sub-Types' registry.

   A PE that supports IGMP proxy on a given BD MUST attach this extended
   community to the Inclusive Multicast Ethernet Tag (IMET) route it
   advertises for that BD and it MUST set the IGMP Proxy Support flag to
   1.  Note that an [RFC7432<https://datatracker.ietf.org/doc/html/rfc7432>] 
compliant PE will not advertise this
   extended community so its absence indicates that the advertising PE
   does not support IGMP Proxy.

*JD A PE that supports IGMP and/or MLD Proxy on a given BD
MUST attach this extended community to the IMET route it advertises
advertises for that BD and it MUST set the IGMP and/or MLD Proxy
Support flags to 1.  Note that an 
[RFC7432<https://datatracker.ietf.org/doc/html/rfc7432>] compliant PE will not 
advertise this
extended community so its absence indicates that the advertising PE
does not support either IGMP or MLD Proxy.


Yours Irrespectively,

John



Juniper Business Use Only
From: Mankamana Mishra (mankamis) 
Sent: Friday, February 11, 2022 11:02 AM
To: John E Drake ; Benjamin Kaduk 
Cc: The IESG ; draft-ietf-bess-evpn-igmp-mld-pr...@ietf.org; 
bess-cha...@ietf.org; bess@ietf.org; slitkows.i...@gmail.com
Subject: Re: Benjamin Kaduk's Discuss on 
draft-ietf-bess-evpn-igmp-mld-proxy-13: (with DISCUSS and COMMENT)

[External Email. Be cautious of content]

Hi Ben,
Making the changes as you suggested. Attached diff which I would be pushing 
today.

One question

> §8 now talks about an "IGMP or MLD Proxy Support" flag, but we actually have
> separate "IGMP Proxy Support" and "MLD Proxy Support" flags.

Does IGMP or MLD Proxy Support not mean that either of them can be set / unset. 
Any thing specific you want to be added here ?

Mankamana

From: John E Drake mailto:jdr...@juniper.net>>
Date: Monday, February 7, 2022 at 7:17 AM
To: Benjamin Kaduk mailto:ka...@mit.edu>>
Cc: The IESG mailto:i...@ietf.org>>, 
draft-ietf-bess-evpn-igmp-mld-pr...@ietf.org<mailto:draft-ietf-bess-evpn-igmp-mld-pr...@ietf.org>
 
mailto:draft-ietf-bess-evpn-igmp-mld-pr...@ietf.org>>,
 bess-cha...@ietf.org<mailto:bess-cha...@ietf.org> 
mailto:bess-cha...@ietf.org>

Re: [bess] Éric Vyncke's Discuss on draft-ietf-bess-evpn-igmp-mld-proxy-13: (with DISCUSS and COMMENT)

[Mankamana Mishra (mankamis)]

Hi Eric,
Thanks, uploaded the new version addressing your comment.

Pending:

  1.  About number restarting – There was comment by Alvaro where he wanted 
these numbers to be restarting to differentiate sender and receiver processing
EV> I am sure that Alvaro will not mind have some text, even just 4 words, 
separating the sender / receiver processing

MM : It was not my day to get this logic work in XML. Will figure out some 
expert to enter section there to articulate two different sub topic (sender 
side processing and receiving side processing )

Rest other comment have been addressed.

Mankamana


From: Eric Vyncke (evyncke) 
Date: Friday, February 11, 2022 at 5:39 AM
To: Mankamana Mishra (mankamis) , The IESG 
Cc: draft-ietf-bess-evpn-igmp-mld-pr...@ietf.org 
, bess-cha...@ietf.org 
, bess@ietf.org , slitkows.i...@gmail.com 

Subject: Re: Éric Vyncke's Discuss on draft-ietf-bess-evpn-igmp-mld-proxy-13: 
(with DISCUSS and COMMENT)
Hello Mankamana,

Thanks for your reply, see below for EV> (I have elided the original DISCUSS 
part). As soon as a revised I-D is uploaded, then I am clearing my DISCUSS.

Regards

-éric


From: "Mankamana Mishra (mankamis)" 
Date: Friday, 11 February 2022 at 00:33
To: Eric Vyncke , The IESG 
Cc: "draft-ietf-bess-evpn-igmp-mld-pr...@ietf.org" 
, "bess-cha...@ietf.org" 
, "bess@ietf.org" , 
"slitkows.i...@gmail.com" 
Subject: Re: Éric Vyncke's Discuss on draft-ietf-bess-evpn-igmp-mld-proxy-13: 
(with DISCUSS and COMMENT)

Hi Eric,
Thanks for comment.


  1.  For text which talks about how to decode BGP routes back , will it be ok 
to have common section after BPG encoding 
(https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-igmp-mld-proxy-16#section-9)
 ? which talks about fact that receiving PE need to decode it back and consider 
it as IGMP membership request and process it ?
EV> adding sections 9.1.3 / 9.2.3 / 9.3.3 "reconstructing the MLD/IGMP" per 
route type would be preferred of course, but a common subsection on 
reconstruction either after 9.3 (preferred) or after 9.1 would be OK (in the 
sense that it addresses my DISCUSS but is less easy for the 
readers/implementers)


  1.  About number restarting – There was comment by Alvaro where he wanted 
these numbers to be restarting to differentiate sender and receiver processing
EV> I am sure that Alvaro will not mind have some text, even just 4 words, 
separating the sender / receiver processing


  1.  SMET, I would take care of it in terminology.
EV> thanks


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

Re: [bess] Éric Vyncke's Discuss on draft-ietf-bess-evpn-igmp-mld-proxy-13: (with DISCUSS and COMMENT)

[Mankamana Mishra (mankamis)]

Hi Eric,
Thanks for comment.


  1.  For text which talks about how to decode BGP routes back , will it be ok 
to have common section after BPG encoding 
(https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-igmp-mld-proxy-16#section-9)
 ? which talks about fact that receiving PE need to decode it back and consider 
it as IGMP membership request and process it ?
  2.  About number restarting – There was comment by Alvaro where he wanted 
these numbers to be restarting to differentiate sender and receiver processing
  3.  SMET, I would take care of it in terminology.

Mankamana

From: Eric Vyncke (evyncke) 
Date: Monday, February 7, 2022 at 7:11 AM
To: Mankamana Mishra (mankamis) , The IESG 
Cc: draft-ietf-bess-evpn-igmp-mld-pr...@ietf.org 
, bess-cha...@ietf.org 
, bess@ietf.org , slitkows.i...@gmail.com 

Subject: Re: Éric Vyncke's Discuss on draft-ietf-bess-evpn-igmp-mld-proxy-13: 
(with DISCUSS and COMMENT)
Hello Mankamana and other authors,

Is there a plan to solve my remaining blocking DISCUSS point ? I.e., how can a 
recipient EVPN speaker can translate back the BGP information into MLD/IGMP 
packets?

Section 4.1 contains " The information is again translated back to IGMP message 
at the recipient EVPN speaker." But the translation is not specified. This 
should be required in a proposed standard document. I.e., multiple sections are 
about MLD/IGMP messages received by a PE, format of the BGP messages, but never 
how to generate MLD/IGMP from those routes. Even if trivial for the authors, 
some description, even short, is really required.

BTW, in section 4.1.1 of revision -16, I find the numbering of the rules really 
confusing as it restarts from 1. Strongly suggest adding a preamble between 
rule 4 and rule 1.

BTW2, "SMET" is used in the text before its expansion in section 9.1.1 (first 
use in section 4.1.1).

I still hope that the above email helps improving this document,

Regards

-éric


From: Eric Vyncke 
Date: Thursday, 28 October 2021 at 13:49
To: "Mankamana Mishra (mankamis)" , The IESG 
Cc: "draft-ietf-bess-evpn-igmp-mld-pr...@ietf.org" 
, "bess-cha...@ietf.org" 
, "bess@ietf.org" , 
"slitkows.i...@gmail.com" 
Subject: Re: Éric Vyncke's Discuss on draft-ietf-bess-evpn-igmp-mld-proxy-13: 
(with DISCUSS and COMMENT)

Hello Mankamana,

Thank you for your constructive reply, please see below for EV> as I am afraid 
that your answers do not address completely my concerns.

Regards

-éric

From: "Mankamana Mishra (mankamis)" 
Date: Monday, 25 October 2021 at 20:26
To: Eric Vyncke , The IESG 
Cc: "draft-ietf-bess-evpn-igmp-mld-pr...@ietf.org" 
, "bess-cha...@ietf.org" 
, "bess@ietf.org" , 
"slitkows.i...@gmail.com" 
Subject: Re: Éric Vyncke's Discuss on draft-ietf-bess-evpn-igmp-mld-proxy-13: 
(with DISCUSS and COMMENT)

Hi Eric,
Thanks for comment. Please find inline comment for blocking disucss .

Mankamana

From: Éric Vyncke via Datatracker 
Date: Wednesday, October 20, 2021 at 1:28 AM
To: The IESG 
Cc: draft-ietf-bess-evpn-igmp-mld-pr...@ietf.org 
, bess-cha...@ietf.org 
, bess@ietf.org , slitkows.i...@gmail.com 

Subject: Éric Vyncke's Discuss on draft-ietf-bess-evpn-igmp-mld-proxy-13: (with 
DISCUSS and COMMENT)
Éric Vyncke has entered the following ballot position for
draft-ietf-bess-evpn-igmp-mld-proxy-13: 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/blog/handling-iesg-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-igmp-mld-proxy/



--
DISCUSS:
--

Thank you for the work put into this document. I have to state that I am
neither a EVPN expert not a multicast one.

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

Special thanks to Stéphane Litkowski for his shepherd's write-up about the WG
consensus.

I hope that this helps to improve the document,

Regards,

-éric

== DISCUSS ==

The text covers in details how to map MLD/IGMP into BGP routes but does not say
a word on how to recreate the MLD/IGMP packets. Should there be any such
specification ?
Mankamana :  This draft covers what is EVPN related procedures. IGMP / MLD 
packets are generated by multicast host. And this document does not define any 
procedure about what needs to be done at host. Host is not even aware of 
presense of EVPN
EV> AFAIK, MLD/IGMP packets are also generated

Re: [bess] WGLC, IPR and Implementation Poll for draft-ietf-bess-evpn-fast-df-recovery-03

[Mankamana Mishra (mankamis)]

Support the publication of draft.

Mankamana

From: Bocci, Matthew (Nokia - GB) 
Date: Monday, January 31, 2022 at 5:58 AM
To: draft-ietf-bess-evpn-fast-df-recov...@ietf.org 
, bess@ietf.org 
Cc: bess-cha...@ietf.org 
Subject: WGLC, IPR and Implementation Poll for 
draft-ietf-bess-evpn-fast-df-recovery-03
Hi WG,

This email starts a two-week Working Group Last Call on 
draft-ietf-bess-evpn-fast-df-recovery-03 [1].

This poll runs until Monday 14th February 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 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]. Please indicate 
if you are aware of any implementations.

Thank you,
Matthew & Stephane

[1] draft-ietf-bess-evpn-fast-df-recovery-03 - Fast Recovery for EVPN DF 
Election
[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] Alvaro Retana's Discuss on draft-ietf-bess-evpn-igmp-mld-proxy-14: (with DISCUSS and COMMENT)

[Mankamana Mishra (mankamis)]

Hi Alvaro,
Here is the updated version and update on what changes are being incorporated 
(Version 16 of draft).

PIM WG Review comment :  There were only two comment received from PIM working 
group and both are being addressed.

  1.  Comment was to add terminology DC
  2.  Second comment was same as your about immediate leave

Apart from that there were no concern from PIM WG .

Open Question :

  1.  Statements about IGMP V1, there was no concern from PIM WG or BESS WG 
either. Do you want any thing specific to be mentioned in this draft ?
  2.  Later inline for flag question, I have one way to handle this. Please let 
me know your view and I can make the changes.


Based on your comments :

  *   IGMP join are changed to Membership Report
  *   Inline comments also handled

Some of the comment inline about accepted changes.

From: Mankamana Mishra (mankamis) 
Date: Wednesday, December 8, 2021 at 3:14 PM
To: Alvaro Retana , The IESG 
Cc: draft-ietf-bess-evpn-igmp-mld-pr...@ietf.org 
, slitkows.i...@gmail.com 
, bess-cha...@ietf.org , 
bess@ietf.org 
Subject: Re: Alvaro Retana's Discuss on draft-ietf-bess-evpn-igmp-mld-proxy-14: 
(with DISCUSS and COMMENT)
Hi Alvaro,
while i wait for PIM working group to provide and submit the next revision this 
Friday. I have question about one of the comment. Please let me know if these 
changes are something you expecting.


  *   IGMP Join changes to Membership Report
  *   IGMP Join Sync changes to Membership Report Sync
  *   All mention of Join changes to Membership Report



Since IGMP Join Sync has been terminology getting used for long with this 
draft, wanted to make sure this is ok before i publish the changed version.
Though i was trying to see if RFC3376 uses term Join. It looks like it does. 
but many places it uses Membership reports for actual packet on wire.

Mankamana

On 11/18/21 12:50 PM, Alvaro Retana wrote:

On November 17, 2021 at 3:11:49 PM, Mankamana Mishra wrote:





Mankamana:



Hi!





...

--

DISCUSS:

--



First of all, I am surprised that a document related to IGMP/MLD was not sent

to the pim WG for review. I can't find any mention of this draft in the pim

WG's archive.





Mankamana: As in contributor to this document, all the procedures are very

much limited to BGP overlay signaling. Not sure which aspect would be

reviewed by PIM WG. This draft does not change any behavior of PIM or IGMP .



This document is about proxying IGMP/MLD through an EVPN domain to

"reduce the flooding of IGMP messages", which implies that the

messages are received and recreated [*] based on the BGP information.

The routers are them acting as both a multicast router and group

member -- this behavior, including the operation of multiple versions

of IGMP on the same link has already bee specified in rfc3376.  The

mechanism described in this document don't seem to be in line with

that -- starting with the requirement to consider IGMPv1 as invalid.



So, yes, there are no changes to the protocols, but the behavior

specified is not in line with the existing standards.  That is what I

want the pim to look at.



[*] That is part of Eric's DISCUSS.







...

I am balloting DISCUSS because this document is not in line with other

consensus documents (specifically the IGMP specification). To clear, I will

want the document reviewed by the pim WG.



Mankamana : Do you expect it to be reviewed by PIM WG or we should remove

section talking about use of V1 ? Based on current work in PIM WG, our

understanding is that “v1 will become deprecated, v2 will still be proposed

standard, and v3 will become internet standard.”



I expect the document to be reviewed by pim.



As I mentioned before, the current work in pim is to move rfc3376 to

Internet Standard, which would still be backwards compatible with

IGMPv1.



Mankamana : Document has been reviewed by PIM WG and there were no concern 
towards IGMP V1 text.

...

--

COMMENT:

--



(1) The terminology section should include IGMP/MLD-related terminology or at

least a pointer to the relevant RFCs.



Mankamana: Added text pointing to IGMP V2 and V3 RFC



Also, the messages are called Membership Reports, and not "Join" or "IGMP

Reports". Similar comment related to "IGMP Queries" and "Membership Requests"

(should be Membership Query).



[I will not make other comments below about this same point.]





Mankamana : will change IGMP join to Membership Request



An "IGMP join" should be a "Membership Report" (not a request).  There

are no "requests", just "Membership Queries".



Mankamana: Updated all joins and IGMP Query





(2)

[L

Re: [bess] Review of draft-ietf-bess-evpn-igmp-mld-proxy

[Mankamana Mishra (mankamis)]

PIM WG,

Happy new year .
I have not received any more comment in this.  Please provide comment by 
weekend if there is any. Since I would have final version posting this weekend 
addressing any known comment.

Mankamana

From: pim  on behalf of Michael McBride 

Date: Thursday, December 2, 2021 at 1:04 PM
To: p...@ietf.org 
Cc: bess@ietf.org 
Subject: [pim] Review of draft-ietf-bess-evpn-igmp-mld-proxy
Hi team pim,

Per request from the bess wg chairs, please review 
https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-igmp-mld-proxy, 
which is in IESG evaluation, and provide any feedback by responding to this 
email.

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

Re: [bess] Erik Kline's No Objection on draft-ietf-bess-evpn-igmp-mld-proxy-14: (with COMMENT)

[Mankamana Mishra (mankamis)]

Thanks .

From: Erik Kline 
Date: Friday, December 24, 2021 at 4:03 PM
To: Mankamana Mishra (mankamis) 
Cc: The IESG , draft-ietf-bess-evpn-igmp-mld-pr...@ietf.org 
, bess-cha...@ietf.org 
, bess@ietf.org , slitkows.i...@gmail.com 

Subject: Re: Erik Kline's No Objection on 
draft-ietf-bess-evpn-igmp-mld-proxy-14: (with COMMENT)
All good by me, thanks.  I don't think any of my comments were of the
"must be addressed" variety.

Regards,
-ek

On Wed, Dec 8, 2021 at 3:20 PM Mankamana Mishra (mankamis)
 wrote:
>
> Hi Eric,
>
> Please let me know if explanation are acceptable.
>
>
>
> Mankamana
>
>
>
> From: Mankamana Mishra (mankamis) 
> Date: Wednesday, November 17, 2021 at 12:06 PM
> To: Erik Kline , The IESG 
> Cc: draft-ietf-bess-evpn-igmp-mld-pr...@ietf.org 
> , bess-cha...@ietf.org 
> , bess@ietf.org , 
> slitkows.i...@gmail.com 
> Subject: Re: Erik Kline's No Objection on 
> draft-ietf-bess-evpn-igmp-mld-proxy-14: (with COMMENT)
>
> Hi Erik,
>
> Thanks for comment . Please find inline comment.  Please let me know if you 
> have additional comment
>
>
>
>
>
> From: Erik Kline via Datatracker 
> Date: Wednesday, October 27, 2021 at 6:18 PM
> To: The IESG 
> Cc: draft-ietf-bess-evpn-igmp-mld-pr...@ietf.org 
> , bess-cha...@ietf.org 
> , bess@ietf.org , 
> slitkows.i...@gmail.com 
> Subject: Erik Kline's No Objection on draft-ietf-bess-evpn-igmp-mld-proxy-14: 
> (with COMMENT)
>
> Erik Kline has entered the following ballot position for
> draft-ietf-bess-evpn-igmp-mld-proxy-14: 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/blog/handling-iesg-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-igmp-mld-proxy/
>
>
>
> --
> COMMENT:
> --
>
> Generally no useful comments that others haven't already made.  Thank
> you for your patience, since I had pushed this out another week.
>
> [S4, comment]
>
> * I feel like some representative diagram to refer to throughout the
>   document might be useful earlier in the document, even if it's just
>   duplication of Figure 1 from section 5.
>
> Mankamana : Looking at other base document RFC 7432, 6613, 6614 I do not 
> think too many reference diagram are needed. Is there any specific area where 
> you think having diagram would help ?
>
>
>
>
>
> [S9.*]
>
> * Should it be said that if the Multicast Source Length is not zero
>   then it MUST be equal to the Multicast Group Length?  I.e. no
>   mixing and matching IPv4 and IPv6 source/group addresses by accident?
>
> Mankamana :  originally carrying multicast route over BGP is defined in RFC 
> 6513 and RFC6514.I did not find any clarification in these document as well, 
> do we really need to be explicit that mix and match not allowed or go with 
> standard practice ? Mix and match not working are true for PIM as well.
>
>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Alvaro Retana's Discuss on draft-ietf-bess-evpn-igmp-mld-proxy-14: (with DISCUSS and COMMENT)

[Mankamana Mishra (mankamis)]

Thanks, changed version on the way .

From: Alvaro Retana 
Date: Thursday, December 9, 2021 at 12:58 PM
To: Mankamana Mishra (mankamis) , The IESG 
Cc: draft-ietf-bess-evpn-igmp-mld-pr...@ietf.org 
, slitkows.i...@gmail.com 
, bess-cha...@ietf.org , 
bess@ietf.org 
Subject: Re: Alvaro Retana's Discuss on draft-ietf-bess-evpn-igmp-mld-proxy-14: 
(with DISCUSS and COMMENT)
Hi!

Yes, please use terminology consistent with the existing RFCs.


Thanks!

Alvaro.



On December 8, 2021 at 6:14:34 PM, Mankamana Mishra (mankamis) (
manka...@cisco.com) wrote:

Hi Alvaro,
while i wait for PIM working group to provide and submit the next revision
this Friday. I have question about one of the comment. Please let me know
if these changes are something you expecting.


   - IGMP Join changes to Membership Report
   - IGMP Join Sync changes to Membership Report Sync
   - All mention of Join changes to Membership Report


Since IGMP Join Sync has been terminology getting used for long with this
draft, wanted to make sure this is ok before i publish the changed version.
Though i was trying to see if RFC3376 uses term Join. It looks like it
does. but many places it uses Membership reports for actual packet on wire.

Mankamana

On 11/18/21 12:50 PM, Alvaro Retana wrote:

On November 17, 2021 at 3:11:49 PM, Mankamana Mishra wrote:


Mankamana:

Hi!


...

--
DISCUSS:
--

First of all, I am surprised that a document related to IGMP/MLD was not sent
to the pim WG for review. I can't find any mention of this draft in the pim
WG's archive.


Mankamana: As in contributor to this document, all the procedures are very
much limited to BGP overlay signaling. Not sure which aspect would be
reviewed by PIM WG. This draft does not change any behavior of PIM or IGMP
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Francesca Palombini's No Objection on draft-ietf-bess-evpn-igmp-mld-proxy-14: (with COMMENT)

[Mankamana Mishra (mankamis)]

Hi Francesca
Thanks for comment. I apologies for missing this email.   Please find inline 
comment.

Mankamana

From: Francesca Palombini via Datatracker 
Date: Thursday, October 28, 2021 at 7:12 AM
To: The IESG 
Cc: draft-ietf-bess-evpn-igmp-mld-pr...@ietf.org 
, bess-cha...@ietf.org 
, bess@ietf.org , slitkows.i...@gmail.com 

Subject: Francesca Palombini's No Objection on 
draft-ietf-bess-evpn-igmp-mld-proxy-14: (with COMMENT)
Francesca Palombini has entered the following ballot position for
draft-ietf-bess-evpn-igmp-mld-proxy-14: 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/blog/handling-iesg-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-igmp-mld-proxy/



--
COMMENT:
--

Thanks for the work on this document.

As in draft-ietf-bess-evpn-optimized-ir, I have to comment on the overuse of
abbreviations and the assumptions that the reader is familiar with all concepts
and terms used make the document really hard to read for non-expert in the
field. I'll also point out that having a terminology section with expansion but
with no references is not as useful as one with proper descriptions and
references.

Mankamana :  This document builds on top of RFC7432. And does use many 
terminology from basic multicast. Adding all possible terminology may be 
overkill for draft. Please let me know if any thing specific is missing.


Here as well, there is a several uses of SHOULD and should in a way that either
is requiring more context (what are the conditions when it is acceptable to not
follow the SHOULD recommendations):

   o  Reserved bits MUST be set to 0 by sender.  And receiver SHOULD
  ignore the Reserved bits.

 and cases where IMO the term would better be replaced by something else,
 possibly more descriptive:
Mankamana: Please let me know if you looking for specific description here.


> The registration policy should be "First Come First Served".

> The registry should be initialized as follows:
Mankamana :  There was comment during WG discussion and it was decided to keep 
it as “FCFS”


I don't have any other comment that has not already been flagged by my fellow
ADs: I scanned for ART issues but did not find any significant ones. (Please do
fix Lars non-blocking points as well).

Francesca


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

Re: [bess] Robert Wilton's No Objection on draft-ietf-bess-evpn-igmp-mld-proxy-14: (with COMMENT)

[Mankamana Mishra (mankamis)]

Hi Rob,
Thanks for comment. Sorry, some how my outlook messed and this email was lost. 
Please find inline.  There is one modification based on your comment. Please 
let me know if change text looks ok to you. I will push the new revision.

Mankamana

From: Robert Wilton via Datatracker 
Date: Thursday, October 28, 2021 at 7:16 AM
To: The IESG 
Cc: draft-ietf-bess-evpn-igmp-mld-pr...@ietf.org 
, bess-cha...@ietf.org 
, bess@ietf.org , slitkows.i...@gmail.com 

Subject: Robert Wilton's No Objection on 
draft-ietf-bess-evpn-igmp-mld-proxy-14: (with COMMENT)
Robert Wilton has entered the following ballot position for
draft-ietf-bess-evpn-igmp-mld-proxy-14: 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/blog/handling-iesg-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-igmp-mld-proxy/



--
COMMENT:
--

Hi,

Thanks for this document.  I have to say that I found that the heavier use of
acronyms made this document somewhat harder to read.  I'm also not an expert in
these technologies.

My main question isn't directly actionably on this document, but I wanted to
check whether any updates to the EVPN YANG module are required to support this
functionality, and if so, is that work in progress, or planned?
Mankamana : Yang work in BESS working group are paused for now. So if there is 
any config change, it would be addressed once Yang model resumes.


Otherwise, I just had a couple of minor comments:

On 4.1.1.  IGMP/MLD Membership Report Advertisement in BGP

   When a PE wants to advertise an IGMP Membership Report (Join) using
   the BGP EVPN route, it follows the following rules (BGP encoding
   stated in Section 9):

   1.    This is because BGP is a stateful protocol and
   no further transmission of the same report is needed.  If the
   IGMP Membership Request is for (*,G), then multicast group
   address MUST be sent along with the corresponding version flag
   (v2 or v3) set.

This implies to me that either the v2 or v3 flag is exclusively set, but
presumably it could also be both.  Would "add/or" be better than or?
Mankamana: in case of membership report with source filter, it would not be 
possible to set both version in same route. Later in document it has been 
mentioned that if (*,G) join for different version are received, we can set 
both flag.


Does OIF need to be an acronym, it doesn't seem worth it, and makes the text
harder to parse.  Is this a standard term used in other related docs?

Mankamana :  There was comment from IESG to better mention what OIF is, so it 
was added.

5.  Operation

In the paragraph of text above the diagram, perhaps more clearly indicate that
S1, S2 indicate multicast sources and R1 indicates a multicast router, and Hx
indicates hosts.
Mankamana:
Modified as “
  Consider the EVPN network of Figure-1, 
where there is an EVPN
   instance configured across 
the PEs shown in this figure (namely PE1,
   PE2, and PE3). Let's 
consider that this EVPN instance consists of a
   single bridge domain (single 
subnet) with all the hosts, sources, and
   the multicast router 
connected to this subnet. PE1 only has hosts(host denoted by Hx)
   connected to it. PE2 has a 
mix of hosts and a multicast source. PE3
   has a mix of hosts, a 
multicast source (source denoted by Sx), and a multicast router (router denoted 
by Rx).
   Furthermore, let's consider 
that for (S1,G1), R1 is used as the
   multicast router. The 
following subsections describe the IGMP proxy
   operation in different PEs 
with regard to whether the locally
   attached devices for that 
subnet are:”


9.1.  Selective Multicast Ethernet Tag Route

Rather than writing things like "second least significant bit", just writing
"bit 6" would seem to be clearer.
Mankamana :  I see similar terminology used even in base RFC7432. So may be it 
would be ok to keep it consistent.


9.1.1.  Constructing the Selective Multicast Ethernet Tag route

I was surprised that the lengths are specified in bits, not bytes.  I presume
that 

Re: [bess] Murray Kucherawy's Discuss on draft-ietf-bess-evpn-igmp-mld-proxy-14: (with DISCUSS and COMMENT)

[Mankamana Mishra (mankamis)]

Hi Murray,
new version uploaded where  NV and NVO removed since they were not 
used.   Please let me know if you have any comment.

Mankamana

On 11/22/21 2:14 AM, slitkows.i...@gmail.com wrote:
> Hi Murray,
>
>> There's an IPR disclosure on this document.  In the shepherd writeup, where 
>> a summary of the discussion of it is requested, it simply says "There are 3 
>> IPRs disclosed".  I'd like to hear that summary, or at least confirm the 
>> discussion was had and there were no concerns as a result.
>
> The WG didn't raised any concern about the IPR disclosed for this document.
>
> Brgds,
>
> Stephane
>
>
> -Original Message-
> From: Murray Kucherawy via Datatracker 
> Sent: jeudi 28 octobre 2021 08:34
> To: The IESG 
> Cc: draft-ietf-bess-evpn-igmp-mld-pr...@ietf.org; bess-cha...@ietf.org; 
> bess@ietf.org; slitkows.i...@gmail.com
> Subject: Murray Kucherawy's Discuss on 
> draft-ietf-bess-evpn-igmp-mld-proxy-14: (with DISCUSS and COMMENT)
>
> Murray Kucherawy has entered the following ballot position for
> draft-ietf-bess-evpn-igmp-mld-proxy-14: 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/blog/handling-iesg-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-igmp-mld-proxy/
>
>
>
> --
> DISCUSS:
> --
>
> There's an IPR disclosure on this document.  In the shepherd writeup, where a 
> summary of the discussion of it is requested, it simply says "There are 3 
> IPRs disclosed".  I'd like to hear that summary, or at least confirm the 
> discussion was had and there were no concerns as a result.
>
> The IANA Considerations section needs some work:
>
> (0) I suggest making each of the actions you want to take (there are four) 
> into their own subsections of this section.
>
> (1) "EVPN Extended Community sub-types registry" should be "EVPN Extended 
> Community Sub-Types sub-registry of the BGP Extended Communities registry", 
> which makes it easier to find.
>
> (2) "Multicast Flags Extended Community" appears to be a new registry you're 
> creating in the final action here.  BCP 26, for a First Come First Served 
> registry, advises that a change controller column be included.  Are you 
> intentionally omitting this here?  Or if this is referring to an existing 
> registry, I wasn't able to find it.
>
>
> --
> COMMENT:
> --
>
> Section 3 defines "NV" and "NVO", but these terms appear nowhere in the 
> document.
>
> Every SHOULD in this document, other than the ones that talk about logging, 
> left me wondering why an implementer might decide not to follow that advice.
> Since SHOULD presents a choice, I suggest including some guidance about why 
> it's a SHOULD, i.e., when one might decide not to do what it says and still 
> expect to interoperate.  Or should some of these really be MUSTs?
>
>
>
>

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

Re: [bess] Erik Kline's No Objection on draft-ietf-bess-evpn-igmp-mld-proxy-14: (with COMMENT)

[Mankamana Mishra (mankamis)]

Hi Eric,
Please let me know if explanation are acceptable.

Mankamana

From: Mankamana Mishra (mankamis) 
Date: Wednesday, November 17, 2021 at 12:06 PM
To: Erik Kline , The IESG 
Cc: draft-ietf-bess-evpn-igmp-mld-pr...@ietf.org 
, bess-cha...@ietf.org 
, bess@ietf.org , slitkows.i...@gmail.com 

Subject: Re: Erik Kline's No Objection on 
draft-ietf-bess-evpn-igmp-mld-proxy-14: (with COMMENT)
Hi Erik,
Thanks for comment . Please find inline comment.  Please let me know if you 
have additional comment


From: Erik Kline via Datatracker 
Date: Wednesday, October 27, 2021 at 6:18 PM
To: The IESG 
Cc: draft-ietf-bess-evpn-igmp-mld-pr...@ietf.org 
, bess-cha...@ietf.org 
, bess@ietf.org , slitkows.i...@gmail.com 

Subject: Erik Kline's No Objection on draft-ietf-bess-evpn-igmp-mld-proxy-14: 
(with COMMENT)
Erik Kline has entered the following ballot position for
draft-ietf-bess-evpn-igmp-mld-proxy-14: 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/blog/handling-iesg-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-igmp-mld-proxy/



--
COMMENT:
--

Generally no useful comments that others haven't already made.  Thank
you for your patience, since I had pushed this out another week.

[S4, comment]

* I feel like some representative diagram to refer to throughout the
  document might be useful earlier in the document, even if it's just
  duplication of Figure 1 from section 5.
Mankamana : Looking at other base document RFC 7432, 6613, 6614 I do not think 
too many reference diagram are needed. Is there any specific area where you 
think having diagram would help ?



[S9.*]

* Should it be said that if the Multicast Source Length is not zero
  then it MUST be equal to the Multicast Group Length?  I.e. no
  mixing and matching IPv4 and IPv6 source/group addresses by accident?

Mankamana :  originally carrying multicast route over BGP is defined in RFC 
6513 and RFC6514.I did not find any clarification in these document as well, do 
we really need to be explicit that mix and match not allowed or go with 
standard practice ? Mix and match not working are true for PIM as well.

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

Re: [bess] Alvaro Retana's Discuss on draft-ietf-bess-evpn-igmp-mld-proxy-14: (with DISCUSS and COMMENT)

[Mankamana Mishra (mankamis)]

Hi Alvaro,
while i wait for PIM working group to provide and submit the next revision this 
Friday. I have question about one of the comment. Please let me know if these 
changes are something you expecting.


  *   IGMP Join changes to Membership Report
  *   IGMP Join Sync changes to Membership Report Sync
  *   All mention of Join changes to Membership Report


Since IGMP Join Sync has been terminology getting used for long with this 
draft, wanted to make sure this is ok before i publish the changed version.

Though i was trying to see if RFC3376 uses term Join. It looks like it does. 
but many places it uses Membership reports for actual packet on wire.

Mankamana

On 11/18/21 12:50 PM, Alvaro Retana wrote:

On November 17, 2021 at 3:11:49 PM, Mankamana Mishra wrote:


Mankamana:

Hi!


...


--
DISCUSS:
--

First of all, I am surprised that a document related to IGMP/MLD was not sent
to the pim WG for review. I can't find any mention of this draft in the pim
WG's archive.


Mankamana: As in contributor to this document, all the procedures are very
much limited to BGP overlay signaling. Not sure which aspect would be
reviewed by PIM WG. This draft does not change any behavior of PIM or IGMP .



This document is about proxying IGMP/MLD through an EVPN domain to
"reduce the flooding of IGMP messages", which implies that the
messages are received and recreated [*] based on the BGP information.
The routers are them acting as both a multicast router and group
member -- this behavior, including the operation of multiple versions
of IGMP on the same link has already bee specified in rfc3376.  The
mechanism described in this document don't seem to be in line with
that -- starting with the requirement to consider IGMPv1 as invalid.

So, yes, there are no changes to the protocols, but the behavior
specified is not in line with the existing standards.  That is what I
want the pim to look at.

[*] That is part of Eric's DISCUSS.



...


I am balloting DISCUSS because this document is not in line with other
consensus documents (specifically the IGMP specification). To clear, I will
want the document reviewed by the pim WG.

Mankamana : Do you expect it to be reviewed by PIM WG or we should remove
section talking about use of V1 ? Based on current work in PIM WG, our
understanding is that “v1 will become deprecated, v2 will still be proposed
standard, and v3 will become internet standard.”



I expect the document to be reviewed by pim.

As I mentioned before, the current work in pim is to move rfc3376 to
Internet Standard, which would still be backwards compatible with
IGMPv1.


...


--
COMMENT:
--

(1) The terminology section should include IGMP/MLD-related terminology or at
least a pointer to the relevant RFCs.

Also, the messages are called Membership Reports, and not "Join" or "IGMP
Reports". Similar comment related to "IGMP Queries" and "Membership Requests"
(should be Membership Query).

[I will not make other comments below about this same point.]


Mankamana : will change IGMP join to Membership Request



An "IGMP join" should be a "Membership Report" (not a request).  There
are no "requests", just "Membership Queries".





(2)
[Line numbers from idnits.]

260 1. When the first hop PE receives several IGMP Membership Reports
261 (Joins), belonging to the same IGMP version, from different
262 attached hosts for the same (*,G) or (S,G), it SHOULD send a
263 single BGP message corresponding to the very first IGMP
264 Membership Request (BGP update as soon as possible) for that
265 (*,G) or (S,G). This is because BGP is a stateful protocol and
266 no further transmission of the same report is needed. If the

The behavior in this rule is not required. Under what circumstances is it ok
for the PE to not wait for several Membership Reports from multiple hosts
before sending a BGP message?

Waiting for multiple messages can clearly result in a delay for an interested
host in receiving the multicast service. Note that rfc3376 says that
"Multicast routers need to know only that *at least one* system on an attached
network is interested..."


Mankamana :


it SHOULD send a
263 single BGP message corresponding to the very first IGMP
264 Membership Request (BGP update as soon as possible) for that


does this not mean, BGP update should be sent ASAP. It does not state to wait
for many ?



The first part of that sentence says: "When the first hop PE receives
several IGMP Membership Reports..."  The action is predicated (in the
text) by receiving multiple messages -- after that you're right, the
message would be send ASAP.






(3)

269 (v2 or v3) set. In case of IGMPv3, the exclude flag MUST also be
270 set to indicate that no source IP address 

Re: [bess] [pim] Review of draft-ietf-bess-evpn-igmp-mld-proxy

[Mankamana Mishra (mankamis)]

Thanks for comment, taking care of it in next revision.

Mankamana

From: Hongji Zhao 
Date: Monday, December 6, 2021 at 10:32 PM
To: draft-ietf-bess-evpn-igmp-mld-proxy.auth...@ietf.org 

Cc: p...@ietf.org , bess@ietf.org 
Subject: RE: [pim] Review of draft-ietf-bess-evpn-igmp-mld-proxy
Hi authors,

Here is a minor comment about Section 10.  IGMP/MLD Immediate Leave
It might be 'fast leave', not 'Immediate Leave'. Because 'fast leave' is 
mentioned in rfc2236(igmpv2), rfc3376(igmpv3) and rfc8652(igmp & mld model).

BR/Hongji

Message: 2
Date: Thu, 2 Dec 2021 21:04:26 +
From: Michael McBride 
To: "p...@ietf.org" 
Cc: "bess@ietf.org" 
Subject: [pim] Review of draft-ietf-bess-evpn-igmp-mld-proxy
Message-ID:



Content-Type: text/plain; charset="us-ascii"

Hi team pim,

Per request from the bess wg chairs, please review 
https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-igmp-mld-proxy, 
which is in IESG evaluation, and provide any feedback by responding to this 
email.

Thank you.
mike
-- next part --
An HTML attachment was scrubbed...
URL: 


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

[bess] Meeting minutes uploaded

[Mankamana Mishra (mankamis)]

All,
Meeting minutes for IETF 112 uploaded.

https://datatracker.ietf.org/meeting/112/materials/minutes-112-bess-00


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

Re: [bess] Alvaro Retana's Discuss on draft-ietf-bess-evpn-igmp-mld-proxy-14: (with DISCUSS and COMMENT)

[Mankamana Mishra (mankamis)]

Hi Alvaro,
Thanks for detail comment. Please find inline response.

From: Alvaro Retana via Datatracker 
Date: Wednesday, October 27, 2021 at 10:23 AM
To: The IESG 
Cc: draft-ietf-bess-evpn-igmp-mld-pr...@ietf.org 
, bess-cha...@ietf.org 
, bess@ietf.org , slitkows.i...@gmail.com 

Subject: Alvaro Retana's Discuss on draft-ietf-bess-evpn-igmp-mld-proxy-14: 
(with DISCUSS and COMMENT)
Alvaro Retana has entered the following ballot position for
draft-ietf-bess-evpn-igmp-mld-proxy-14: 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/blog/handling-iesg-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-igmp-mld-proxy/



--
DISCUSS:
--

First of all, I am surprised that a document related to IGMP/MLD was not sent
to the pim WG for review.  I can't find any mention of this draft in the pim
WG's archive.
Mankamana:  As in contributor to this document, all the procedures are very 
much limited to BGP overlay signaling. Not sure which aspect would be reviewed 
by PIM WG. This draft does not change any behavior of PIM or IGMP .



§11 says this:

   This document does not provide any detail about IGMPv1 processing.
   Multicast working group are in process of deprecating uses of IGMPv1.
   Implementations MUST only use IGMPv2 and above for IPv4 and MLDv1 and
   above for IPv6.  IGMP V1 routes MUST be considered as invalid and the
   PE MUST apply the "treat-as-withdraw" procedure as per [RFC7606].
   Initial version of document did mention use of IGMPv1 and flag had
   provision to support IGMPv1.  There may be an implementation which is
   deployed as initial version of document, to interop flag has not been
   changed.

Note that the "Multicast working group" mentioned above is in fact the pim WG.
There's no current WG to deprecate IGMPv1, but draft-ietf-pim-3376bis was
recently adopted with the intent to progress IGMPv3 to Internet Standard.  This
text is from draft-ietf-pim-3376bis (it is the same text as in rfc3376):

   IGMPv3 is backward compatible with previous versions of the IGMP
   protocol.  In order to remain backward compatible with older IGMP
   systems, IGMPv3 multicast routers MUST also implement versions 1 and
   2 of the protocol (see section Section 7).

(Section 7/draft-ietf-pim-3376bis talks about interoperability with older
versions.)

All this is to say that requiring that IGMPv1 not be used contradicts the
IGMPv3 specification, which requires the support.  The interoperation between
the different versions is already considered in rfc3376, so the extra
complexity added to this document (tracking the versions in the BGP updates) is
not needed from the router side.

I am balloting DISCUSS because this document is not in line with other
consensus documents (specifically the IGMP specification).  To clear, I will
want the document reviewed by the pim WG.

Mankamana : Do you expect it to be reviewed by PIM WG or we should remove 
section talking about use of V1 ? Based on current work in PIM WG, our 
understanding is that “v1 will become deprecated, v2 will still be proposed 
standard, and v3 will become internet standard.”


--
COMMENT:
--

(1) The terminology section should include IGMP/MLD-related terminology or at
least a pointer to the relevant RFCs.

Also, the messages are called Membership Reports, and not "Join" or "IGMP
Reports".  Similar comment related to "IGMP Queries" and "Membership Requests"
(should be Membership Query).

[I will not make other comments below about this same point.]
Mankamana : will change IGMP join to Membership Request

(2)
[Line numbers from idnits.]

260   1.  When the first hop PE receives several IGMP Membership Reports
261   (Joins), belonging to the same IGMP version, from different
262   attached hosts for the same (*,G) or (S,G), it SHOULD send a
263   single BGP message corresponding to the very first IGMP
264   Membership Request (BGP update as soon as possible) for that
265   (*,G) or (S,G).  This is because BGP is a stateful protocol and
266   no further transmission of the same report is needed.  If the

The behavior in this rule is not required.  Under what circumstances is it ok
for the PE to not wait for several Membership Reports from multiple hosts
before sending a BGP message?

Waiting for multiple messages can clearly result in a delay for an interested
host in receiving the multicast service. 

Re: [bess] Erik Kline's No Objection on draft-ietf-bess-evpn-igmp-mld-proxy-14: (with COMMENT)

[Mankamana Mishra (mankamis)]

Hi Erik,
Thanks for comment . Please find inline comment.  Please let me know if you 
have additional comment


From: Erik Kline via Datatracker 
Date: Wednesday, October 27, 2021 at 6:18 PM
To: The IESG 
Cc: draft-ietf-bess-evpn-igmp-mld-pr...@ietf.org 
, bess-cha...@ietf.org 
, bess@ietf.org , slitkows.i...@gmail.com 

Subject: Erik Kline's No Objection on draft-ietf-bess-evpn-igmp-mld-proxy-14: 
(with COMMENT)
Erik Kline has entered the following ballot position for
draft-ietf-bess-evpn-igmp-mld-proxy-14: 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/blog/handling-iesg-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-igmp-mld-proxy/



--
COMMENT:
--

Generally no useful comments that others haven't already made.  Thank
you for your patience, since I had pushed this out another week.

[S4, comment]

* I feel like some representative diagram to refer to throughout the
  document might be useful earlier in the document, even if it's just
  duplication of Figure 1 from section 5.
Mankamana : Looking at other base document RFC 7432, 6613, 6614 I do not think 
too many reference diagram are needed. Is there any specific area where you 
think having diagram would help ?



[S9.*]

* Should it be said that if the Multicast Source Length is not zero
  then it MUST be equal to the Multicast Group Length?  I.e. no
  mixing and matching IPv4 and IPv6 source/group addresses by accident?

Mankamana :  originally carrying multicast route over BGP is defined in RFC 
6513 and RFC6514.I did not find any clarification in these document as well, do 
we really need to be explicit that mix and match not allowed or go with 
standard practice ? Mix and match not working are true for PIM as well.

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

Re: [bess] Murray Kucherawy's Discuss on draft-ietf-bess-evpn-igmp-mld-proxy-14: (with DISCUSS and COMMENT)

[Mankamana Mishra (mankamis)]

Hi Murray,
Thanks for comment . Please find inlinecomment.

From: Murray Kucherawy via Datatracker 
Date: Wednesday, October 27, 2021 at 11:34 PM
To: The IESG 
Cc: draft-ietf-bess-evpn-igmp-mld-pr...@ietf.org 
, bess-cha...@ietf.org 
, bess@ietf.org , slitkows.i...@gmail.com 

Subject: Murray Kucherawy's Discuss on draft-ietf-bess-evpn-igmp-mld-proxy-14: 
(with DISCUSS and COMMENT)
Murray Kucherawy has entered the following ballot position for
draft-ietf-bess-evpn-igmp-mld-proxy-14: 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/blog/handling-iesg-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-igmp-mld-proxy/



--
DISCUSS:
--

There's an IPR disclosure on this document.  In the shepherd writeup, where a
summary of the discussion of it is requested, it simply says "There are 3 IPRs
disclosed".  I'd like to hear that summary, or at least confirm the discussion
was had and there were no concerns as a result.

Mankamana : @Stephane Litkowski (slitkows) to 
address this comment.


The IANA Considerations section needs some work:

(0) I suggest making each of the actions you want to take (there are four) into
their own subsections of this section.

(1) "EVPN Extended Community sub-types registry" should be "EVPN Extended
Community Sub-Types sub-registry of the BGP Extended Communities registry",
which makes it easier to find.

(2) "Multicast Flags Extended Community" appears to be a new registry you're
creating in the final action here.  BCP 26, for a First Come First Served
registry, advises that a change controller column be included.  Are you
intentionally omitting this here?  Or if this is referring to an existing
registry, I wasn't able to find it.

Mankamana :The registry in (1), above, is also FCFS and it does not have a 
change controller column.

--
COMMENT:
--

Section 3 defines "NV" and "NVO", but these terms appear nowhere in the
document.

Every SHOULD in this document, other than the ones that talk about logging,
left me wondering why an implementer might decide not to follow that advice.
Since SHOULD presents a choice, I suggest including some guidance about why
it's a SHOULD, i.e., when one might decide not to do what it says and still
expect to interoperate.  Or should some of these really be MUSTs?

Mankamana : My understanding should gives more flexibility to implementation to 
make choices. And may not be good idea to make every thing MUST until without 
it protocol breaks. Is there any specific instance which you want to make MUST ?



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

[bess] IETF 112 final agenda

[Mankamana Mishra (mankamis)]

All,
Final agenda has been posted
https://datatracker.ietf.org/meeting/112/materials/agenda-112-bess-01


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

Re: [bess] Please send slot request for IETF 112

[Mankamana Mishra (mankamis)]

Thanks for your request. At this time we already have more request than 
available time. We may not be able to accommodate . I would keep in mind, in 
case something changes .

From: duanfanghong 
Date: Thursday, November 4, 2021 at 6:59 AM
To: Mankamana Mishra (mankamis) , 
bess@ietf.org 
Cc: bess-cha...@ietf.org 
Subject: RE: [bess] Please send slot request for IETF 112
Hi Mankamana,


 I would like to request one slot:

Draft:BGP MVPN in IPv6 Infrastructure Networks: Problems and 
Solution Approaches

Document:  https://datatracker.ietf.org/doc/draft-duan-bess-mvpn-ipv6-infras/ 
<https://datatracker.ietf.org/doc/draft-duan-bess-mvpn-ipv6-infras/%20>

Speaker:  Fanghong Duan

Time:   10 minutes

Regards,
Fanghong

From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Mankamana Mishra 
(mankamis)
Sent: Friday, October 15, 2021 5:33 AM
To: bess@ietf.org
Subject: [bess] Please send slot request for IETF 112

All,
Primary schedule has been already posted for IETF. Please send me slot request 
for IETF112.

If this is for draft which has been already presented in previous IETF, please 
provide write up as well about what changed and why it would be presented again.


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

[bess] BESS WG preliminary agenda

[Mankamana Mishra (mankamis)]

All,
Here is preliminary agenda. Please watch out for final agenda early next week.

https://datatracker.ietf.org/doc/agenda-112-bess/


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

Re: [bess] Benjamin Kaduk's Discuss on draft-ietf-bess-evpn-igmp-mld-proxy-13: (with DISCUSS and COMMENT)

[Mankamana Mishra (mankamis)]

Thanks john. Uploading version 14th which covers rest other Discuss comment. I 
would be addressing this one and send diff before publishing.

Mankamana

From: John E Drake 
Date: Friday, October 22, 2021 at 7:32 AM
To: Benjamin Kaduk 
Cc: The IESG , draft-ietf-bess-evpn-igmp-mld-pr...@ietf.org 
, bess-cha...@ietf.org 
, bess@ietf.org , slitkows.i...@gmail.com 

Subject: RE: Benjamin Kaduk's Discuss on 
draft-ietf-bess-evpn-igmp-mld-proxy-13: (with DISCUSS and COMMENT)
Ben,

Thanks for your reply.  Mankamana said that he will make the changes you 
suggested and re-publish the draft today.

Yours Irrespectively,

John


Juniper Business Use Only

> -Original Message-
> From: Benjamin Kaduk 
> Sent: Thursday, October 21, 2021 10:08 PM
> To: John E Drake 
> Cc: The IESG ; draft-ietf-bess-evpn-igmp-mld-pr...@ietf.org;
> bess-cha...@ietf.org; bess@ietf.org; slitkows.i...@gmail.com
> Subject: Re: Benjamin Kaduk's Discuss on draft-ietf-bess-evpn-igmp-mld-proxy-
> 13: (with DISCUSS and COMMENT)
>
> [External Email. Be cautious of content]
>
>
> Hi John,
>
> Thanks for helping clarify.  Also inline.
>
> On Thu, Oct 21, 2021 at 06:35:43PM +, John E Drake wrote:
> > Ben,
> >
> > Comments inline.
> >
> > Yours Irrespectively,
> >
> > John
> >
> >
> > Juniper Business Use Only
> >
> > > -Original Message-
> > > From: Benjamin Kaduk via Datatracker 
> > > Sent: Wednesday, October 20, 2021 8:49 PM
> > > To: The IESG 
> > > Cc: draft-ietf-bess-evpn-igmp-mld-pr...@ietf.org;
> > > bess-cha...@ietf.org; bess@ietf.org; slitkows.i...@gmail.com
> > > Subject: Benjamin Kaduk's Discuss on draft-ietf-bess-evpn-igmp-mld-proxy-
> 13:
> > > (with DISCUSS and COMMENT)
> > >
> > > [External Email. Be cautious of content]
> > >
> > >
> > > Benjamin Kaduk has entered the following ballot position for
> > > draft-ietf-bess-evpn-igmp-mld-proxy-13: 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://urldefense.com/v3/__https://www.ietf.org/blog/handling-iesg-
> > > ballot-
> > > positions/__;!!NEt6yMaO-
> > >
> gk!RdAYIQJzeV4Zo3HeoU6yFlhxJGC56JOC41jC9lqSbJyT7Gw448bi3rPSRrxQJ1U$
> > > for more information about how to handle DISCUSS and COMMENT
> positions.
> > >
> > >
> > > The document, along with other ballot positions, can be found here:
> > > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-i
> > > etf-bess-
> > > evpn-igmp-mld-proxy/__;!!NEt6yMaO-
> > >
> gk!RdAYIQJzeV4Zo3HeoU6yFlhxJGC56JOC41jC9lqSbJyT7Gw448bi3rPSbOB2k3E$
> > >
> > >
> > >
> > > 
> > > --
> > > DISCUSS:
> > > 
> > > --
> > >
> > > (1) Apparently each PE is supposed to store version flags for each
> > > other PE in the EVI (I guess on a per-route basis?), but this is
> > > mentioned just once, in passing, in step 2 of the Leave Group procedures 
> > > in
> §4.1.2.
> >
> > [JD]  The first hop PE keeps track of which IGMP or MLD versions are active 
> > on
> the ESes to which it is attached and announces this via the BGP SMET route.
>
> Yes.  Should this statement (or something like it) be in the document itself?
> (Where?)
>
> > > Similarly, §6.1 defines, somewhat in passing, some "local IGMP
> > > Membership Request (x,G) state" that must be maintained in some cases
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Murray Kucherawy's Discuss on draft-ietf-bess-evpn-igmp-mld-proxy-13: (with DISCUSS and COMMENT)

[Mankamana Mishra (mankamis)]

Hi Murry,
Thanks for comment. Please find inline comment / questions.

Mankamana

From: Murray Kucherawy via Datatracker 
Date: Thursday, October 21, 2021 at 7:23 AM
To: The IESG 
Cc: draft-ietf-bess-evpn-igmp-mld-pr...@ietf.org 
, bess-cha...@ietf.org 
, bess@ietf.org , slitkows.i...@gmail.com 

Subject: Murray Kucherawy's Discuss on draft-ietf-bess-evpn-igmp-mld-proxy-13: 
(with DISCUSS and COMMENT)
Murray Kucherawy has entered the following ballot position for
draft-ietf-bess-evpn-igmp-mld-proxy-13: 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/blog/handling-iesg-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-igmp-mld-proxy/



--
DISCUSS:
--

The IANA Considerations section needs some work:

(0) I suggest making each of the actions you want to take (there are four) into
their own subsections of this section.


This is not clear, are we expecting to have
section 13.1 Multicast Flags Extended Community
0x09Multicast Flags Extended Community   [this document]
Section 13.2 EVI-RT Type 0
0x0AEVI-RT Type 0[this document]
Section 13.3 EVI-RT Type 1
0x0BEVI-RT Type 1[this document]
Section 13.4 EVI-RT Type 2
0x0CEVI-RT Type 2[this document]
Please advice.

(1) "EVPN Extended Community sub-types registry" should be "EVPN Extended
Community Sub-Types sub-registry of the BGP Extended Communities registry",
which makes it easier to find.
Done


(2) "Multicast Flags Extended Community" appears to be a new registry you're
creating in the final action here.  BCP 26, for a First Come First Served
registry, advises that a change controller column be included.  Are you
intentionally omitting this here?

you expect one more column and what details to be added ?
--
COMMENT:
--

My review is not yet complete, but I was pointed to this document's IANA
Considerations section from another document about which I had related
questions.  I'll update this once my full review is done.


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

Re: [bess] Éric Vyncke's Discuss on draft-ietf-bess-evpn-igmp-mld-proxy-13: (with DISCUSS and COMMENT)

[Mankamana Mishra (mankamis)]

Hi Eric,
Thanks for comment. Please find inline comment for blocking disucss .

Mankamana

From: Éric Vyncke via Datatracker 
Date: Wednesday, October 20, 2021 at 1:28 AM
To: The IESG 
Cc: draft-ietf-bess-evpn-igmp-mld-pr...@ietf.org 
, bess-cha...@ietf.org 
, bess@ietf.org , slitkows.i...@gmail.com 

Subject: Éric Vyncke's Discuss on draft-ietf-bess-evpn-igmp-mld-proxy-13: (with 
DISCUSS and COMMENT)
Éric Vyncke has entered the following ballot position for
draft-ietf-bess-evpn-igmp-mld-proxy-13: 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/blog/handling-iesg-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-igmp-mld-proxy/



--
DISCUSS:
--

Thank you for the work put into this document. I have to state that I am
neither a EVPN expert not a multicast one.

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

Special thanks to Stéphane Litkowski for his shepherd's write-up about the WG
consensus.

I hope that this helps to improve the document,

Regards,

-éric

== DISCUSS ==

The text covers in details how to map MLD/IGMP into BGP routes but does not say
a word on how to recreate the MLD/IGMP packets. Should there be any such
specification ?
Mankamana :  This draft covers what is EVPN related procedures. IGMP / MLD 
packets are generated by multicast host. And this document does not define any 
procedure about what needs to be done at host. Host is not even aware of 
presense of EVPN


Are all multicast group address treated as the same ? I would have appreciated
some text about link-local multicast as well as global multicast groups
addresses.
Mankamana : Since this draft transport all Valid IGMP / MLD join over BGP. It 
does not differentiate between different group range. All verification and 
handeling would be still IGMP / MLD router responsibility, so I do not think we 
would need to mention any of this.


-- Abstract --
While this point is pretty light for a blocking DISCUSS, let's fix it:
- the abstract should also mention MLD and not only IGMP
- what are 'the above services' ?

-- Section 1 --
In the same vein, is it about IGMP only ? Or does it include MLD as well ? It
is really unclear.

Mankamana : Added MLD in abstract. But later in terminology, it has been 
mentioned that even though we have used term IGMP, its valid for MLD too. For 
better redability, MLD has been not used in rest of document.


--
COMMENT:
--

A very generic comment (but no need to reply): how can an IETF draft still
prefers to use "IGMP" rather than "MLD" in the text in 2021 ? ...

-- Section 1 --
When reading this section, I really and genuinely wonder what is "distributed
anycast multicast router" ? AFAIK "any cast" and "multicast" addresses are
vastly different.

Anycast multicast is well known , and do not think there is need to mention it 
more in document about it.

-- Section 3 --
Is there any reason why the terminology is not alphabetically sorted ?

Please also add 'BD'.

Usually a terminology section is not only about acronym expansions but also
about definitions.
Done


-- Section 4.1 --
What is the definition of a 'first hop PE'? What is the difference with a EVPN
PE ?

EVPN PE  is PE were EVPN is enabled. Not adding detail for some of obvious 
terminology.

-- Section 4.2 --
May be that I overlooked it, but what is a 'proxy querier' ?
IGMP spec defines need for Querier on LAN. EVPN provides mechanism to extend 
layer-2 network across core.  And this draft defines mechanism to convert these 
local IGMP / MLD join to BGP routes and send it across core. Each of these 
location should have own Querier configured and refresh joins on behalf of 
other sites.


What is the difference between "EVPN core" and "MPLS/IP core" ?
EVPN core is generic term, it could be SR / SRv6 / MPLS or IP underlay based.


-- Section 5.1 --
What is "viz" ? (Sorry not being a native English speaker)


viz introduce examples or further details to illustrate a point

-- Section 8 --
Is there a difference between (*, G) and (x, G) ?
(x,G) is generic term to denote both (S,G) and (*,G).
-- Section 9.1 --
Please formally specify "IE" as "include/exclude" (if not mistaken).
done

I find the description of the bits for MLD confusing, it really appears as a
last-minute add-on to the text. Why not 

Re: [bess] Roman Danyliw's No Objection on draft-ietf-bess-evpn-igmp-mld-proxy-13: (with COMMENT)

[Mankamana Mishra (mankamis)]

Thanks for comment. I have modified your recommendation for next revision.

Mankamana

From: Roman Danyliw via Datatracker 
Date: Tuesday, October 19, 2021 at 1:05 PM
To: The IESG 
Cc: draft-ietf-bess-evpn-igmp-mld-pr...@ietf.org 
, bess-cha...@ietf.org 
, bess@ietf.org , slitkows.i...@gmail.com 

Subject: Roman Danyliw's No Objection on 
draft-ietf-bess-evpn-igmp-mld-proxy-13: (with COMMENT)
Roman Danyliw has entered the following ballot position for
draft-ietf-bess-evpn-igmp-mld-proxy-13: 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/blog/handling-iesg-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-igmp-mld-proxy/



--
COMMENT:
--

** Section 12.  Recommend being clearer on the purpose of the long list of
SecCon references (and few typos)

OLD
TThis document does not add any new security considirattions, Same
   security considerations as [RFC7432], [RFC2236], [RFC3376],
   [RFC2710], [RFC3810], [RFC6513], [RFC6514] are applicable.

NEW (feel free to polish)
This document describes a means to efficiently operate IGMP and MLD on a subnet
constructed across multiple PODs or DCs via an EVPN solution.  The security
considerations for the operation of the underlying EVPN and BGP substrate are
described in [RFC7432], and specific multicast considerations are outlined in
[RFC6513] and [RFC6514].  The EVPN and associated IGMP proxy provides a single
broadcast domain so the same security considerations of IGMPv2 [RFC2246],
IGMPv3 [RFC3376], MLD [RFC2710], or MLDv2 [RFC3810] apply.

** Editorial
-- Section 9.4.  Typo. s/associated associated/associated/

-- Section 11.  Typo. s/implemention/implementation/


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

Re: [bess] Lars Eggert's No Objection on draft-ietf-bess-evpn-igmp-mld-proxy-13: (with COMMENT)

[Mankamana Mishra (mankamis)]

Hi Lars,
Please find inline .  fixing major comment in next revision.

From: Lars Eggert via Datatracker 
Date: Monday, October 18, 2021 at 4:40 AM
To: The IESG 
Cc: draft-ietf-bess-evpn-igmp-mld-pr...@ietf.org 
, bess-cha...@ietf.org 
, bess@ietf.org , slitkows.i...@gmail.com 

Subject: Lars Eggert's No Objection on draft-ietf-bess-evpn-igmp-mld-proxy-13: 
(with COMMENT)
Lars Eggert has entered the following ballot position for
draft-ietf-bess-evpn-igmp-mld-proxy-13: 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/blog/handling-iesg-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-igmp-mld-proxy/



--
COMMENT:
--

"Abstract", paragraph 1, comment:
>This document describes how to support efficiently endpoints running
>IGMP for the above services over an EVPN network by incorporating
>IGMP proxy procedures on EVPN PEs.

It would be nice if acronyms were spelled out at least in the abstract (esp.
since it doesn't say where to go for further reading.) Also, "for the above
services"? Above where?

Mankamana :  modified,  spelled acronyms too

Section 9.4. , paragraph 6, comment:
> 0   1   2   3
> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>| Type=0x06   |  Sub-Type=0x09|   Flags (2 Octets)  |M|I|
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>|   Reserved=0  |
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The "Type" field is only seven bits long - that seems to be an error?
Mankamana :  Thanks for catching, fixed one bit which was moved at wrong place


Section 9.5. , paragraph 20, comment:
>  1   2   3
>  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>  | Type=0x06   |  Sub-Type=n   |   RT associated with EVI  |
>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>  | RT associated with the EVI  (cont.) |
>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

This diagram is only 31 bits wide?
Mankamana : Thanks for catching, fixed one bit which was missing.


You might want to use something like https://www.luismg.com/protocol/ to make
sure your header diagrams are accurate.

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

Section 11. , paragraph 2, nit:
-provision to support IGMPv1.  There may be an implemention which is
+provision to support IGMPv1.  There may be an implementation which is
+   ++

Section 12. , paragraph 2, nit:
-TThis document does not add any new security considirattions, Same
-   ^  -
+ This document does not add any new security considerations, Same
+-  ^

"Table of Contents", paragraph 2, nit:
>  . . . . . . 18 9.2. Multicast Join Synch Route . . . . . . . . . . . . . . .
> ^
Do not mix variants of the same word ("synch" and "sync") within a single text.

"Table of Contents", paragraph 2, nit:
> on of servers and switches are self contained and may have their own control
>^^
This word is normally spelled with a hyphen.

Section 3. , paragraph 18, nit:
> triggering mechanism for the PEs to setup their underlay multicast tunnels.
> ^
The verb "set up" is spelled as two words. The noun "setup" is spelled as one.

Section 3. , paragraph 23, nit:
> sage at the recipient EVPN speaker. Thus it helps create an IGMP overlay subn
> 
A comma may be missing after the conjunctive/linking adverb "Thus".

Section 4.1.1. , paragraph 3, nit:
> et (and v2 reset). The IE flag also need to be 

Re: [bess] Martin Duke's No Objection on draft-ietf-bess-evpn-igmp-mld-proxy-13: (with COMMENT)

[Mankamana Mishra (mankamis)]

Hi Martin,
Thanks for comment, please find inline comment .

Mankamana

From: Martin Duke via Datatracker 
Date: Monday, October 11, 2021 at 4:15 PM
To: The IESG 
Cc: draft-ietf-bess-evpn-igmp-mld-pr...@ietf.org 
, bess-cha...@ietf.org 
, bess@ietf.org , slitkows.i...@gmail.com 

Subject: Martin Duke's No Objection on draft-ietf-bess-evpn-igmp-mld-proxy-13: 
(with COMMENT)
Martin Duke has entered the following ballot position for
draft-ietf-bess-evpn-igmp-mld-proxy-13: 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/blog/handling-iesg-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-igmp-mld-proxy/



--
COMMENT:
--

- It does not appear that you have fully addressed the TSVART comments (thanks
Brian Trammell). Specifically, the (S,G) (*,G) definition is still not there.
Mankamana : I looked at mVPN RFC (6513) , PIM RFC (7761) . all of them do use 
these terminology. But I could not find definition in either of them. Do we 
really need to define it ? want to make sure we do not put some definition 
which restricts the meaning of these generic terminology used in multicast 
across different documents.
 Will this be ok to add ?
(*,G) – Any source multicast flow
(S,G) – Multicast flow with source S and group G.
Please advice.

- In the abstract, it refers to "the above services" and I have no idea what
that is referring to.

Mankamana : Will change it to multicast service

- Please expand MLD, NLRI, and DF on first use or in the glossary.
Mankamana : will update


(4.1.1) 1.  When the first hop PE receives several IGMP Membership Reports
   (Joins), belonging to the same IGMP version, from different
   attached hosts for the same (*,G) or (S,G), it SHOULD send a
   single BGP message corresponding to the very first IGMP
   Membership Request (BGP update as soon as possible) for that
   (*,G) or (S,G).

This is confusingly phrased, enough that I think it threw off the TSVART
reviewer. There is no delay waiting for multiple joins; the PE just sends BGP
for the first and ignores the rest. Or perhaps I've misunderstood? Please
rephrase.
Mankamana: Membership request are going to be received by IGMP (host protocol). 
If there are multiple ports locally, we may receive joins in each of the port. 
But BGP update is going to be done once. And it should be done ASAP .  please 
let me know if this is still not clear.


- Relatedly, if a PE receives (S, G) and later (*, G), should it withdraw the
(S, G), since the latter join is a superset of the former?
Mankamana: IGMP V3 RFC defines the group state in case of different joins being 
received on port. This draft does not change the base behavior. Rather let IGMP 
host protocol change the group state based on different joins.


(9) It appears most of the fields in 9.1 through 9.3 are identical; it would
shorten things dramatically if you either had a common section defining them or
simply referred to Sec 9.1. Moreover, as this appears to be cut-and-paste,
there are mistakes like 9.3 referring to "joins" when it's talking about leaves.
These section
Mankamana- Though content of these section are looking like identical, but they 
talk about different routes.

  *   Selective multicast (routes needs to be processed by each supporting PE 
participating in same EVPN instance)
  *   Multicast join sync (limited to multi-home peer only)
  *   Multicast leave sync (limited to multi-home peer only)
Making one common section would lead to too much of confusion for 
implementation.
Thanks for catching typo, will change the join to leave.

(9) as you observe that the Source Length can be zero-length for (*,G) routes,
it would be useful to say that the group length can also be zero for (*,*)
joins. (it might also to constrain it so that if the group length is zero, the
source length MUST also be zero, unless (S, *) joins are possible).

Mankamana – For IGMP driven join we would never have (*,*) join. But only for 
selective multicast we can have (*,*). I would update the selective multicast 
section.
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

[bess] Please send slot request for IETF 112

[Mankamana Mishra (mankamis)]

All,
Primary schedule has been already posted for IETF. Please send me slot request 
for IETF112.

If this is for draft which has been already presented in previous IETF, please 
provide write up as well about what changed and why it would be presented again.


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

Re: [bess] WG Last Call, IPR and Implementation Poll for draft-ietf-bess-evpn-vpws-fxc

[Mankamana Mishra (mankamis)]

Support publication of this document.

From: slitkows.i...@gmail.com 
Date: Monday, September 27, 2021 at 11:02 PM
To: 'BESS' 
Cc: bess-cha...@ietf.org 
Subject: WG Last Call, IPR and Implementation Poll for 
draft-ietf-bess-evpn-vpws-fxc

Hi,



This email starts a two-week working group last call for 
draft-ietf-bess-evpn-vpws-fxc [1]



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 the 12th October 2021.



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.



In addition, we are polling for knowledge of implementations of this draft, per 
the BESS policy in [2].



Thank you,

Matthew & Stephane





[1] https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-vpws-fxc/

[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] Tsvart last call review of draft-ietf-bess-evpn-igmp-mld-proxy-12

[Mankamana Mishra (mankamis)]

Hi Brian,
Thanks for comment. Please find inline comment.  Waiting on some more review 
comments before publish the next version of document.

AI from this comment :

  *   Add reference to RFC6513, RFC6514 in terminology section
  *   Define (S,G), (*,G) in terminology section

Mankamana

From: Brian Trammell via Datatracker 
Date: Wednesday, September 8, 2021 at 12:12 AM
To: tsv-...@ietf.org 
Cc: bess@ietf.org , 
draft-ietf-bess-evpn-igmp-mld-proxy@ietf.org 
, last-c...@ietf.org 

Subject: Tsvart last call review of draft-ietf-bess-evpn-igmp-mld-proxy-12
Reviewer: Brian Trammell
Review result: Ready with Issues

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.

Caveat:

I've reviewed this document primarily for transport-related issues. I have not
made an effort to comprehensively review the architectural context in which
it is defined; this review assumes that the operation of IGMP and Ethernet and
IP multicast over EVPN is fundamentally sound.

tl;dr: This document is acceptable from a transport standpoint: the algorithm 
used
to reduce IGMP flooding seems safe within the limits of the specification's 
scope,
recovery aspects are addressed, and though there is some fuzziness with respect
to some implicit temporal limits I don't see anything that would impact the
transport layer inordinately.

However, from an editorial standpoint, it was not a joy to review, because it 
appears
to assume a fairly deep familiarity with terminology and notation used in some
context (which I assume is local to the BESS WG).  Most of my issues are 
therefore
editorial, and assume that the document is intended for general consumption. 
I'll start
with the design and specification level questions first.

General observation: the correctness of design of a system such as this tends to
hang on the interactions among various timers. The only timer I see defined
in this document is the Maximum Response Timer, which handles leave group
timeouts. There are temporal interactions in other parts of the specification
which remain implicit or undefined, though:  for instance, Step 1 in section
4.1.1 specifies that IGMP messages should be grouped, but specifies no temporal
limit to this process. I assume that the temporal scope is "the corresponding
BGP session", but it would be nice to make this explicit in the document
(especially if I'm wrong).
This document does not define any new timer.  And does not change any process 
of IGMP host / router processing. It does mention concepts from IGMP V2 (RFC 
2236) and IGMP V3 (RFC3376).


The algorithm (and that in section 4.1.2) assume statefulness on the proxy, but
since both BGP and IGMP are fundamentally stateful that's perfectly fine.
Section 6.3 adequately addresses the  failure recovery aspects of this, but
it would also be nice to see some guidance as to the temporal limits of the
recovery process (e.g. if the proxy immediately group queries on link down,
it seems like a link flap could lead to a group query flood).
There are two parts .

  1.  IGMP host side processing : This is not stateful. Periodic query would be 
sent and state would be refreshed. All the processing here are again from IGMP 
RFC no change.
  2.  BGP route processing : This is stateful state. Once routes have been 
advertised, no more refresh or update until something changes. So all the 
processing defined in this document is to make sure how do we react to 
processing of step1 here.


Editorial nit: the Terminology section does not define most of its terms, 
instead
providing only expansions. This does not serve the reader well, and reinforces 
the
impression of RFCs as acronym soup. If I don't know what Ingress Replication
means in a BESS context, then "IR: Ingress Replication" serves only to tell the
reader that we're not discussing infrared radiation. Please either provide 
definitions
(with references; e.g. IGMP has a set of supporting RFCs), or reference another 
EVPN
document providing definitions (as it is perfectly acceptable for a 
multi-document
protocol suite like EVPN to have an introductory document). Even with the list 
of
acronym expansions, some acronyms are missing: I had to google NLRI, for
instance, and I'm assuming ES means Ethernet Segment. Indeed, I was pleasantly
surprised to see Maximum Response Timer not abbreviated to MRT. This document
needs a thorough review of acronym usage, expansion, and definition before it 
can be
published for a general audience.
This document does refer to main EVPN 

Re: [bess] Rtgdir last call review of draft-ietf-bess-evpn-igmp-mld-proxy-12

[Mankamana Mishra (mankamis)]

Hi Henning,
Thanks for comment. Please find inline comments.

From: Henning Rogge via Datatracker 
Date: Tuesday, September 14, 2021 at 12:51 AM
To: rtg-...@ietf.org 
Cc: bess@ietf.org , 
draft-ietf-bess-evpn-igmp-mld-proxy@ietf.org 
, last-c...@ietf.org 

Subject: Rtgdir last call review of draft-ietf-bess-evpn-igmp-mld-proxy-12
Reviewer: Henning Rogge
Review result: Has Nits

Hi,

the RTGDIR asked me to do a review on draft-ietf-bess-evpn-igmp-mld-proxy
(which is currently in revision 12).

I do not follow the BESS WG (I mostly work with mesh routing protocols), but I
am familiar with the issue of "linklocal protocols" (like IGMP/ARP) flooding
larger layer2-networks with unnecessary traffic, especially in wireless meshes
and high performance networks.

In general I think the mechanism in this draft will help to reduce the overhead
of multicast traffic and increase the performance in EVPN. I am also
(personally) curious if this could help to solve parts of the multicast issues
we have in MANET (which is mostly still unsolved).

I also think that more figures/tables in this draft should get a footer with a
reference number.
Most of Standard document (similar to this RFC6513, RFC6514, RFC7432) do not 
contain too many of figure. Is there any specific case where you think figure 
would make sense ?


Some comments to specific chapters:

the 2-item list at the end of chapter 4 feel a bit unnecessary, because they
just repeat the following sub-chapter names. Maybe this should be transformed
just into a descriptive sentence.

4th section provides summary of overall procedures. Where as subsequent 
sections are providing more detail.

Chapter 9.1, 9.2 and 9.3 contain a figure/graphic that seem to define a packet
format. If this a typical way to do this for BGP with one field (with variable
octet length) per line? Compare to the more formal way to define a byteformat
in the table in chapter 9.4.
Looking at precedence in WG and other document 
(https://datatracker.ietf.org/doc/html/rfc6514#section-4.6) format looks 
aligned.


The flags field also always contain a bit for an IGMP version 1. chapter 9.1
says this is deprecated, chapter 9.2/9.3 don't. If version 1 is not to be
supported, why not skip the bit completely? Or is this a flags-field that has
already been defined in a different document?
When this draft was written initially , there was provision made for IGMP V1 in 
route. While WG progressed this document, PIM working group is working on 
deprecating IGMP V1.  Some of the older implementation of draft may have 
already used the bit. So we wanted to make sure those bits are not changed now 
. and WG had decided to add statement about V1 in document.


The list of new ECs in chapter 9.5 could be converted into a table for improved
readability.

The format of the tables in chapter 13 seem to be unusual (nor border, no
lines, no heading). Maybe they can be converted into standard tables?


Format of information in this section also is same as 
https://datatracker.ietf.org/doc/html/rfc7432#section-20 . please let me know 
if there is specific format you want it to be changed to.


The draft contains an (informative) reference to an ID
(I-D.ietf-bess-evpn-bum-procedure-updates). I assume this will be changed when
both this draft and the reference become an RFC?
Yes.


Henning Rogge

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

Re: [bess] Genart last call review of draft-ietf-bess-evpn-igmp-mld-proxy-12

[Mankamana Mishra (mankamis)]

Hi Matt,
I would submit the changes which I had mentioned in below email. Some of the 
open questions not addressed in this version. Would wait to hear back from you.

Mankamana

From: Mankamana Mishra (mankamis) 
Date: Tuesday, September 7, 2021 at 6:03 AM
To: Matt Joras , gen-...@ietf.org 
Cc: bess@ietf.org , 
draft-ietf-bess-evpn-igmp-mld-proxy@ietf.org 
, last-c...@ietf.org 

Subject: Re: Genart last call review of draft-ietf-bess-evpn-igmp-mld-proxy-12
Hi Matt,
Thanks for comment. Most of comments I have taken care.  Please find inline 
questions.

From: Matt Joras via Datatracker 
Date: Friday, August 27, 2021 at 8:39 AM
To: gen-...@ietf.org 
Cc: bess@ietf.org , 
draft-ietf-bess-evpn-igmp-mld-proxy@ietf.org 
, last-c...@ietf.org 

Subject: Genart last call review of draft-ietf-bess-evpn-igmp-mld-proxy-12
Reviewer: Matt Joras
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

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-bess-evpn-igmp-mld-proxy-??
Reviewer: Matt Joras
Review Date: 2021-08-26
IETF LC End Date: 2021-09-07
IESG Telechat date: Not scheduled for a telechat

Review

   Ethernet Virtual Private Network (EVPN) solution is becoming
   pervasive in data center (DC) applications for Network Virtualization
   Overlay (NVO) and DC interconnect (DCI) services, and in service
   provider (SP) applications for next generation virtual private LAN
   services.

This intro to the abstract could use some rewording. For example, "is becoming"
does not read well in a standards document. It is sufficient to describe what
this document is specifying. Also "next generation" is overused and doesn't
usually read well retrospectively.

   This draft describes how to support efficiently endpoints running
   IGMP for the above services over an EVPN network by incorporating
   IGMP proxy procedures on EVPN PEs.

Avoid using the term "draft" as this will have to be edited out since the idea
is for this to be standards track.

Modified

  *   Removed the first para from abstract
  *   Changed draft to document across document


1.  Introduction

   Ethernet Virtual Private Network (EVPN) solution [RFC7432] is
   becoming pervasive in data center (DC) applications for Network
   Virtualization Overlay (NVO) and DC interconnect (DCI) services, and
   in service provider (SP) applications for next generation virtual
   private LAN services.

This is a copy of the abstract, and has similar issues. The introduction serves
a different purpose beyond the abstract, it also has the same grammatical
issues as the abstract.
Modified

  *   Removed this part

   In DC applications, a point of delivery (POD) can consist of a
   collection of servers supported by several top of rack (TOR) and
   Spine switches.  This collection of servers and switches are self
   contained and may have their own control protocol for intra-POD
   communication and orchestration.  However, EVPN is used as standard
   way of inter-POD communication for both intra-DC and inter-DC.  A
   subnet can span across multiple PODs and DCs.  EVPN provides robust
   multi-tenant solution with extensive multi-homing capabilities to
   stretch a subnet (VLAN) across multiple PODs and DCs.  There can be
   many hosts/VMs(virtual machine) (several hundreds) attached to a
   subnet that is stretched across several PODs and DCs.

Why is "Spine" capitalized? I'm also wondering whether another term might be
appropriate here that doesn't imply a certain topology. Also,  "provides robust
multi-tenant solution" should probably be "provides a robust multi-tenant
solution".
Modified

  *   Spine / spine
  *   About using different term, since this para talking about DC, in context 
of DC it looks ok. Considering usually Service provider uses term PE and P , DC 
uses term spine / leaf / TOR
  *   provides robust
multi-tenant solution" should probably be "provides a robust multi-tenant
solution"

   These hosts/VMs express their interests in multicast groups on a
   given subnet/VLAN by sending IGMP Membership Reports (Joins) for
   their interested multicast group(s).  Furthermore, an IGMP router
   periodically sends membership queries to find out if there are hosts
   on that subnet that are still interested in receiving multicast
   traffic for that group.  The IGMP/MLD Proxy solution described in
   this draft accomplishes three objectives:

I don't think you need "/VMs". They are a kind of host. There is also another
use of "draft" in this paragraph.
Using VM along with host, does it not server purpose where it articulating that 
host and VM are denoting similar device ? so

Re: [bess] WG adoption poll and IPR poll for draft-mohanty-bess-ebgp-dmz-03 [1].

[Mankamana Mishra (mankamis)]

Support adoption.

From: BESS  on behalf of Bocci, Matthew (Nokia - GB) 

Date: Tuesday, September 7, 2021 at 5:42 AM
To: bess@ietf.org 
Cc: draft-mohanty-bess-ebgp-...@ietf.org 
Subject: [bess] WG adoption poll and IPR poll for 
draft-mohanty-bess-ebgp-dmz-03 [1].
Hello,

This email begins a two-week WG adoption poll for 
draft-mohanty-bess-ebgp-dmz-03 [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 September 21st 2021.

Regards,
Matthew and Stephane


[1] https://datatracker.ietf.org/doc/draft-mohanty-bess-ebgp-dmz-03/


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

Re: [bess] Genart last call review of draft-ietf-bess-evpn-igmp-mld-proxy-12

[Mankamana Mishra (mankamis)]

Hi Matt,
Thanks for comment. Most of comments I have taken care.  Please find inline 
questions.

From: Matt Joras via Datatracker 
Date: Friday, August 27, 2021 at 8:39 AM
To: gen-...@ietf.org 
Cc: bess@ietf.org , 
draft-ietf-bess-evpn-igmp-mld-proxy@ietf.org 
, last-c...@ietf.org 

Subject: Genart last call review of draft-ietf-bess-evpn-igmp-mld-proxy-12
Reviewer: Matt Joras
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-igmp-mld-proxy-??
Reviewer: Matt Joras
Review Date: 2021-08-26
IETF LC End Date: 2021-09-07
IESG Telechat date: Not scheduled for a telechat

Review

   Ethernet Virtual Private Network (EVPN) solution is becoming
   pervasive in data center (DC) applications for Network Virtualization
   Overlay (NVO) and DC interconnect (DCI) services, and in service
   provider (SP) applications for next generation virtual private LAN
   services.

This intro to the abstract could use some rewording. For example, "is becoming"
does not read well in a standards document. It is sufficient to describe what
this document is specifying. Also "next generation" is overused and doesn't
usually read well retrospectively.

   This draft describes how to support efficiently endpoints running
   IGMP for the above services over an EVPN network by incorporating
   IGMP proxy procedures on EVPN PEs.

Avoid using the term "draft" as this will have to be edited out since the idea
is for this to be standards track.

Modified


1.  Introduction

   Ethernet Virtual Private Network (EVPN) solution [RFC7432] is
   becoming pervasive in data center (DC) applications for Network
   Virtualization Overlay (NVO) and DC interconnect (DCI) services, and
   in service provider (SP) applications for next generation virtual
   private LAN services.

This is a copy of the abstract, and has similar issues. The introduction serves
a different purpose beyond the abstract, it also has the same grammatical
issues as the abstract.
Modified

   In DC applications, a point of delivery (POD) can consist of a
   collection of servers supported by several top of rack (TOR) and
   Spine switches.  This collection of servers and switches are self
   contained and may have their own control protocol for intra-POD
   communication and orchestration.  However, EVPN is used as standard
   way of inter-POD communication for both intra-DC and inter-DC.  A
   subnet can span across multiple PODs and DCs.  EVPN provides robust
   multi-tenant solution with extensive multi-homing capabilities to
   stretch a subnet (VLAN) across multiple PODs and DCs.  There can be
   many hosts/VMs(virtual machine) (several hundreds) attached to a
   subnet that is stretched across several PODs and DCs.

Why is "Spine" capitalized? I'm also wondering whether another term might be
appropriate here that doesn't imply a certain topology. Also,  "provides robust
multi-tenant solution" should probably be "provides a robust multi-tenant
solution".
Modified

   These hosts/VMs express their interests in multicast groups on a
   given subnet/VLAN by sending IGMP Membership Reports (Joins) for
   their interested multicast group(s).  Furthermore, an IGMP router
   periodically sends membership queries to find out if there are hosts
   on that subnet that are still interested in receiving multicast
   traffic for that group.  The IGMP/MLD Proxy solution described in
   this draft accomplishes three objectives:

I don't think you need "/VMs". They are a kind of host. There is also another
use of "draft" in this paragraph.
Using VM along with host, does it not server purpose where it articulating that 
host and VM are denoting similar device ? something similar to subnet/VLAN ?, I 
am ok to remove the VM.


   3.  Selective Multicast: to forward multicast traffic over EVPN
   network such that it only gets forwarded to the PEs that have
   interest in the multicast group(s), multicast traffic will not be
   forwarded to the PEs that have no receivers attached to them for
   that multicast group.  This draft shows how this objective may be
   achieved when Ingress Replication is used to distribute the
   multicast traffic among the PEs.  Procedures for supporting
   selective multicast using P2MP tunnels can be found in
   [I-D.ietf-bess-evpn-bum-procedure-updates]

The first sentence is very long and could probably be reworded to be less
redundant. Also there is another instance of "draft".
Modified


   The first two objectives are achieved by using IGMP/MLD proxy on the
   PE and the third objective is achieved by setting up a multicast
   tunnel (e.g., ingress replication) only among the PEs that