Re: [bess] WGLC, IPR and implementation poll for draft-ietf-bess-evpn-igmp-mld-proxy

[Mankamana Mishra (mankamis)]

Thanks Anoop for your valuable comment.  Really apricate you taking time to 
have quick call. As agreed on call, I have covered most of your view comment.  
It would be seen in next revision.

Thanks
Mankamana


From: Anoop Ghanwani 
Date: Sunday, June 30, 2019 at 10:05 AM
To: "Mankamana Mishra (mankamis)" 
Cc: "stephane.litkow...@orange.com" , 
"bess@ietf.org" , "bess-cha...@ietf.org" 
Subject: Re: [bess] WGLC, IPR and implementation poll for 
draft-ietf-bess-evpn-igmp-mld-proxy
Resent-From: 
Resent-To: , , 

Resent-Date: Sunday, June 30, 2019 at 10:05 AM

Hi Mankamana,

I sent the doc to the authors, and I have put a pdf version here:
https://anoop.updog.co/ietf/draft-ietf-bess-evpn-igmp-mld-proxy-AG.pdf

Thanks,
Anoop

On Sun, Jun 30, 2019 at 6:12 AM Mankamana Mishra (mankamis) 
mailto:manka...@cisco.com>> wrote:
Hi Anoop,
Please send it across. We are going to make changes about editorial comment 
right after WGLC and post updated version.

Thanks
Mankamana


From: Anoop Ghanwani mailto:an...@alumni.duke.edu>>
Date: Saturday, June 29, 2019 at 1:04 AM
To: "stephane.litkow...@orange.com" 
mailto:stephane.litkow...@orange.com>>
Cc: "bess@ietf.org" 
mailto:bess@ietf.org>>, 
"bess-cha...@ietf.org" 
mailto:bess-cha...@ietf.org>>
Subject: Re: [bess] WGLC, IPR and implementation poll for 
draft-ietf-bess-evpn-igmp-mld-proxy
Resent-From: mailto:alias-boun...@ietf.org>>
Resent-To: mailto:matthew.bo...@nokia.com>>, 
mailto:stephane.litkow...@orange.com>>, 
mailto:manka...@cisco.com>>
Resent-Date: Saturday, June 29, 2019 at 1:04 AM

I support the publication of the document as an RFC.

I have several editorial comments and I'll send them in a Word document markup 
to the authors.

If the mailing list accepts attachments, I'd be happy to post it here as well.

Thanks,
Anoop

On Mon, Jun 17, 2019 at 1:53 AM 
mailto:stephane.litkow...@orange.com>> wrote:

Hello Working Group,



This email starts a three weeks Working Group Last Call on  
draft-ietf-bess-evpn-igmp-mld-proxy [1].



This poll runs until *the 28th of June*.



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.



We have several IPRs already disclosed.



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



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



Thank you,

Stephane & Matthew


[1] https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-igmp-mld-proxy/

[2] https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw



[Orange logo]

Stephane Litkowski
Network Architect
Orange/SCE/EQUANT/OINIS/NET
Orange Expert Future Networks
phone: +33 2 23 06 49 83 

  NEW !
mobile: +33 6 71 63 27 50 

  NEW !
stephane.litkow...@orange.com


_



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

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

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

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



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

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

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

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

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

Re: [bess] WG adoption call and IPR poll for draft-rabadan-bess-vendor-evpn-route-07

[Oya Luengo, Roberto (Nokia - US/Mountain View)]

Support

Thanks
Roberto

From: BESS  on behalf of "UTTARO, JAMES" 
Date: Tuesday, August 27, 2019 at 8:37 AM
To: "Rabadan, Jorge (Nokia - US/Mountain View)" , 
Stephane Litkowski , "bess@ietf.org" 
Subject: Re: [bess] WG adoption call and IPR poll for 
draft-rabadan-bess-vendor-evpn-route-07

Support for WG adoption..

Thanks,
  Jim Uttaro

From: BESS  On Behalf Of Rabadan, Jorge (Nokia - 
US/Mountain View)
Sent: Saturday, August 24, 2019 6:41 AM
To: Stephane Litkowski ; bess@ietf.org
Subject: Re: [bess] WG adoption call and IPR poll for 
draft-rabadan-bess-vendor-evpn-route-07

As a co-author, I support this document for WG adoption.
I’m not aware of any IPR relevant to this document.

Thanks.
Jorge

From: BESS mailto:bess-boun...@ietf.org>> on behalf of 
Stephane Litkowski mailto:slitkows.i...@gmail.com>>
Date: Tuesday, August 20, 2019 at 11:15 AM
To: "bess@ietf.org" mailto:bess@ietf.org>>
Subject: [bess] WG adoption call and IPR poll for 
draft-rabadan-bess-vendor-evpn-route-07

Hi,

This email begins a two-weeks WG adoption poll for 
draft-rabadan-bess-vendor-evpn-route-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 won't progress 
without answers from all the authors and contributors.
Currently, there are no IPR disclosures against this document.

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

This poll for adoption closes on 2nd September 2019.

Regards,
Stephane and Matthew

[1] 
https://datatracker.ietf.org/doc/draft-rabadan-bess-vendor-evpn-route/
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] WG adoption call and IPR poll for draft-rabadan-bess-vendor-evpn-route-07

[UTTARO, JAMES]

Support for WG adoption..

Thanks,
  Jim Uttaro

From: BESS  On Behalf Of Rabadan, Jorge (Nokia - 
US/Mountain View)
Sent: Saturday, August 24, 2019 6:41 AM
To: Stephane Litkowski ; bess@ietf.org
Subject: Re: [bess] WG adoption call and IPR poll for 
draft-rabadan-bess-vendor-evpn-route-07

As a co-author, I support this document for WG adoption.
I’m not aware of any IPR relevant to this document.

Thanks.
Jorge

From: BESS mailto:bess-boun...@ietf.org>> on behalf of 
Stephane Litkowski mailto:slitkows.i...@gmail.com>>
Date: Tuesday, August 20, 2019 at 11:15 AM
To: "bess@ietf.org" mailto:bess@ietf.org>>
Subject: [bess] WG adoption call and IPR poll for 
draft-rabadan-bess-vendor-evpn-route-07

Hi,

This email begins a two-weeks WG adoption poll for 
draft-rabadan-bess-vendor-evpn-route-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 won't progress 
without answers from all the authors and contributors.
Currently, there are no IPR disclosures against this document.

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

This poll for adoption closes on 2nd September 2019.

Regards,
Stephane and Matthew

[1] 
https://datatracker.ietf.org/doc/draft-rabadan-bess-vendor-evpn-route/
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] WG adoption call and IPR poll for draft-rabadan-bess-vendor-evpn-route-07

[Van De Velde, Gunter (Nokia - BE/Antwerp)]

Support to adopt.
I think this work is useful for the WG and the industry to progress.

Brgds,
G/

From: BESS  On Behalf Of Stephane Litkowski
Sent: Monday, August 19, 2019 21:32
To: bess@ietf.org
Subject: [bess] WG adoption call and IPR poll for 
draft-rabadan-bess-vendor-evpn-route-07

Hi,

This email begins a two-weeks WG adoption poll for 
draft-rabadan-bess-vendor-evpn-route-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 won't progress 
without answers from all the authors and contributors.
Currently, there are no IPR disclosures against this document.

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

This poll for adoption closes on 2nd September 2019.

Regards,
Stephane and Matthew

[1] https://datatracker.ietf.org/doc/draft-rabadan-bess-vendor-evpn-route/
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] draft-ietf-bess-evpn-igmp-mld-proxy-03 shepherd's review

[stephane.litkowski]

Hi Mankamana,

Pls find additional feedbacks inline.

Brgds,

Stephane


From: Mankamana Mishra (mankamis) [mailto:manka...@cisco.com]
Sent: Tuesday, August 27, 2019 00:38
To: LITKOWSKI Stephane OBS/OINIS; draft-ietf-bess-evpn-igmp-mld-pr...@ietf.org; 
bess@ietf.org
Cc: Mankamana Mishra (mankamis)
Subject: Re: [bess] draft-ietf-bess-evpn-igmp-mld-proxy-03 shepherd's review

Hi Stephane,
Thanks for your review comment. Please find inline.

Thanks
Mankamana


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

Date: Tuesday, August 20, 2019 at 6:20 AM
To: "draft-ietf-bess-evpn-igmp-mld-pr...@ietf.org" 
, "bess@ietf.org" 
Subject: [bess] draft-ietf-bess-evpn-igmp-mld-proxy-03 shepherd's review

Hi,

There are some Nits to fix:
https://www6.ietf.org/tools/idnits?url=https://www.ietf.org/archive/id/draft-ietf-bess-evpn-igmp-mld-proxy-03.txt


Here is my review of the document:

Abstract & Intro:
s/RFC 7432/ RFC7432.
The reference should be removed from the abstract (as per IDNits).
Mankamana:   Will be taken care of in next revision.

§2.1:
It may be good to change the paragraph name to IGMP/MLD proxy and use IGMP/MLD 
in the paragraph. This comment could apply to various other places of the 
document.
 Mankamana: Will take care for paragraph name. Inside paragraph we have used 
IGMP , and start of the document we did state that all of IGMP procedure are 
applicable for MLD too.  Is it ok ?
§2.1.1:

-“it only sends a single BGP
   message corresponding to the very first IGMP Join”.
[SLI] Do we really care about the IGMP message (first or second…) used as a 
source to build the EVPN route ? The important point is that we do it only one 
time.
   Mankamana:   changing text to “very first IGMP Join received”.  
Purpose of this text is to clarify that we send BGP route as soon as we process 
it for first time locally. Subsequent joins are not sent.
[SLI2] Could you add a statement about this goal of sending the 
BGP update asap ?




-  For MLD what is the expected behavior in term of flag setting in the 
SMET, do we set v2 for MLDv2 or do we consider that it is equivalent to IGMPv3 
and then we set v3 ?
   Mankamana:  Have text in terminology
“ This document also assumes familiarity with the 
terminology of
   [RFC7432]. Though most of the place this document uses term IGMP
   membership request (Joins), the text applies equally for MLD
   membership request too. Similarly, text for IGMPv2 applies to MLDv1
   and text for  IGMPv3 applies to MLDv2”

I hope this covers your comment.

[SLI2] It does partially, the thing that IGMPv2 is similar to MLDv1 does not 
explicitly say what we do it term of encoding of the version number. As the 
version encoding is clearly stated in §7.1, it would be better to point to this 
paragraph rather than giving an ambiguous/partial information there.



-  s/BGP is a statefull/BGP is a stateful  ?
Mankamana : Done.


-  In 1),  for clarity purpose, it would be good to separate the (*,G) 
and (S,G) case in two separate paragraphs. At the first read, when reading “In 
case of IGMPv3, exclude flag…”, I thought it was always applicable for IGMPv3 
which does not make sense, while it is applicable only “If the IGMP Join is for 
(*,G)”.
Mankamana: Across document (*,G) and (S,G) processing have been written 
together, do you think for consistency it might be good to keep it in single 
paragraph ?

[SLI2] They can remain in the same section, I just wanted to add an empty line 
just before “If the IGMP Join is for (S,G),”.



-  IMO, 1) 2) 3) and 4) should use normative language
Mankamana: Will be taken care in next update.



-  Wouldn’t it be better to present the encoding of SMET before ? 
Because the text talks about fields set in the route while it hasn’t been 
presented yet.
Mankamana:   Do you want to move BGP encoding before this section ?
[SLI2] Two options, you move the encoding before or you at least point to the 
section where the encoding is detailed.




-  5) talks about errors that SHOULD be logged, but from a BGP 
perspective, is it considered as a BGP error ? What is the expected behavior 
per RFC7606 ?
Mankamana: Would update this, and it SHOULD be considered as BGP error and 
should be handled as per RFC7606



-  7) is not clear about IGMPv3, the first part of the text tells that 
the IGMP Join must not be sent if there is no PIM router. While the end of the 
text tells that it is not a problem for IGMPv3. So is there a difference 
between IGMPv2 and IGMPv3 reports ?
Mankamana: This comment is not clear. Last part of the paragraph trying to 
explain that what is difference in behavior for IGMPv2 and IGMPv3 .  If you 
think text should be modified, it would be great if you could suggest expected 
text .
[SLI2] It is not clear to me if the IGMP suppression is applicable both to 
IGMPv3 and IGMPv2 or only to IGMPv2 as IGMPv3 does not