Re: [bess] [Editorial Errata Reported] RFC7582 (6875)
Greetings, Errata (6875) has been deleted. Please resubmit your errata with the correct RFC number. Thank you. RFC Editor/cs > From: > Subject: RE: [Editorial Errata Reported] RFC7582 (6875) > Date: March 8, 2022 at 1:18:56 AM PST > To: RFC Errata System > Cc: "ero...@juniper.net" , "i...@cisco.com" > , "yiq...@microsoft.com" , > "ar...@boers.com" > > Dear RFC Editor, > > This errata is against RFC7285, not 7582. Can you please update the RFC > number? Thank you. > > Authors of RFC7582, apologies for the inconvenience. > > Cheers, > Med > On Mar 8, 2022, at 12:52 AM, RFC Errata System > wrote: > > The following errata report has been submitted for RFC7582, > "Multicast Virtual Private Network (MVPN): Using Bidirectional P-Tunnels". > > -- > You may review the report below and at: > https://www.rfc-editor.org/errata/eid6875 > > -- > Type: Editorial > Reported by: Mohamed Boucadair > > Section: 14.3 > > Original Text > - >+++ >| Identifier | Intended Semantics | >+++ >| pid| See Section 7.1.1 | >| priv: | Private use| >+++ > > Table 4: ALTO Endpoint Property Types > > Corrected Text > -- >+++ >| Identifier | Intended Semantics | >+++ >| pid| See Section 7.1.1 | >+++ > > Table 4: ALTO Endpoint Property Types > > Notes > - > priv is not an identifier, but a prefix. > > Instructions: > - > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party > can log in to change the status and edit the report, if necessary. > > -- > RFC7582 (draft-ietf-bess-mvpn-bidir-04) > -- > Title : Multicast Virtual Private Network (MVPN): Using > Bidirectional P-Tunnels > Publication Date: July 2015 > Author(s) : E. Rosen, IJ. Wijnands, Y. Cai, A. Boers > Category: PROPOSED STANDARD > Source : BGP Enabled ServiceS > Area: Routing > Stream : IETF > Verifying Party : IESG > ___ 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)
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 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
Re: [bess] John Scudder's Discuss on draft-ietf-bess-srv6-services-11: (with DISCUSS and COMMENT)
Dear Yao, The issue is not related to support or no support of a new feature although that is also not well addressed in current BGP-4 specification. The question is about coexistence of multiple transports and service encoding for the same application. I have a separate proposal on this, but did not post it before the cut off date. So expect more on this after IETF in Vienna. Best, R. On Tue, Mar 8, 2022 at 5:00 AM wrote: > Hi Robert, > > Thanks for sharing your detailed consideration on BGP capability and new > NLRI. > A few comments about the BGP capability solution. Please see inline [YAO]. > > > == > > In BGP protocol any new service deployment using existing AFI/SAFI is not > easy. Especially when you are modifying content of MP_REACH or MP_UNREACH > NLRI attributes. Main reason being is that using capabilities only goes one > hop. In full mesh it all works perfect, but the moment you put RR in > between BGP speakers things are getting ugly as capabilities are not > traversing BGP nodes. /* Even in full mesh mixing transports for the same > service is a serious challenge for routers when say multihomes sites are > advertised from different PEs with different transport options */. > > [YAO] As you mentioned, in the scenario multihomes sites are advertised > from different PEs with different transport options without RR, e.g, CE1 > are connected to PE1 and PE2, PE1 supports MPLS VPN while PE2 support SRv6 > VPN, PE3 is the peer of PE1 and PE2, imagine PE3 supports both > capabilities, I don't think this brings much difference between the > configuration approach and BGP capability approach. > If BGP capability is introduced, PE3 will receive both MPLS VPN and BGP > VPN routes, how to process them is based on user's requirement,e.g, > choosing one fixed type of routes, using the lastest routes, ECMP and so on. > If configuration approach is used, how to configure is based user's > requirement as well. Before configuration on PE1 and PE2, one should first > decide whether PE3 wants to receive only one type of route or to receive > both routes. And if PE3 receive both routes, the processing rule also > should be considered. > In a word, in scenario like this, the consideration on user's requirement > is similar in both approach. > > Imagine RR signals SRv6 Service Capability to the PE. Then this PE happily > sends a new format of the UPDATE messages. Well as today we also do not > have a notion of conditional capabilities (only send when received from > all) so if some of the RR peers do not support it you end up in partial > service. One can argue that in this case the only deterministic model is to > push the configuration from the management station and control partial > deployment of the new service from mgmt layer. > > [YAO] By saying "RR peers", do you mean that in the scenario that there're > multiple RRs, and they're peers of each other, if some of the RRs don't > support the new BGP capability, the SRv6 service routes will not be sent to > them thus result in losing part of the routes? > If this is the case, I don't think it's a serious problem. No matter what > new BGP capability one wants to introduce in this scenario, RRs are always > required to support it if we want to get it right. > If "RR peers" means other PEs, it is the expected result that PEs don't > support the new capability will not receive the new kind of UPDATE > messages. So the dropping the new routes sent to these PEs is not a > problem. > On the other hand, the management approach is always a practical option by > not sending new messages to these PEs . > > > Regards, > Yao > ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
[bess] [Editorial Errata Reported] RFC7582 (6875)
The following errata report has been submitted for RFC7582, "Multicast Virtual Private Network (MVPN): Using Bidirectional P-Tunnels". -- You may review the report below and at: https://www.rfc-editor.org/errata/eid6875 -- Type: Editorial Reported by: Mohamed Boucadair Section: 14.3 Original Text - +++ | Identifier | Intended Semantics | +++ | pid| See Section 7.1.1 | | priv: | Private use| +++ Table 4: ALTO Endpoint Property Types Corrected Text -- +++ | Identifier | Intended Semantics | +++ | pid| See Section 7.1.1 | +++ Table 4: ALTO Endpoint Property Types Notes - priv is not an identifier, but a prefix. Instructions: - This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -- RFC7582 (draft-ietf-bess-mvpn-bidir-04) -- Title : Multicast Virtual Private Network (MVPN): Using Bidirectional P-Tunnels Publication Date: July 2015 Author(s) : E. Rosen, IJ. Wijnands, Y. Cai, A. Boers Category: PROPOSED STANDARD Source : BGP Enabled ServiceS Area: Routing Stream : IETF Verifying Party : IESG ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
