Re: [bess] WGLC, IPR and implementation poll for draft-ietf-bess-nsh-bgp-control-plane
Hi Stephane, I am not aware of any IPR that has not already been disclosed against this document. Thanks, Adrian From: BESS On Behalf Of stephane.litkow...@orange.com Sent: 21 January 2019 13:06 To: bess@ietf.org Cc: bess-cha...@ietf.org Subject: [bess] WGLC, IPR and implementation poll for draft-ietf-bess-nsh-bgp-control-plane Hello Working Group, This email starts a three weeks Working Group Last Call on draft-ietf-bess-nsh-bgp-control-plane [1]. This poll runs until *the 4th of February*. 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-nsh-bgp-control-plane/ [2] https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw _ 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] Question regarding RFC6625 and this draft-->//RE: I-D Action: draft-ietf-bess-mvpn-expl-track-13.txt
The receiver PE cannot keep its state to receive on both tunnels forever. After some time, it has to leave the old tunnel. Jeffrey > -Original Message- > From: Xiejingrong [mailto:xiejingr...@huawei.com] > Sent: Wednesday, January 23, 2019 9:09 PM > To: Jeffrey (Zhaohui) Zhang ; draft-ietf-bess-mvpn-expl- > tr...@ietf.org > Cc: bess@ietf.org > Subject: RE: Question regarding RFC6625 and this draft-->//RE: [bess] I-D > Action: draft-ietf-bess-mvpn-expl-track-13.txt > > Hi Jeffrey, > > Thanks for the explaination. > I have the same understanding "the text in RFC6625 is really/mainly about > which tunnel to send/receive on in a steady state." > What confusing me is the "which tunnel to receive" decision, obviously on > receiver site PE. > > In my opinion, the receiver site PE should not do the decision, but be > prepared > to *any possible tunnel* that will be used by the sender site PE for a > specific > (S,G) flow. > Even in a steady state the sender site PE are using the (S,G) PMSI-tunnel for > a > (S,G) flow, the preparation on the (*,*)PMSI-tunnel should be kept on the > receiver site PE. > > Below is the errata report I have raised, and I hope it can be clarified. > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc- > 2Deditor.org_errata_eid5605=DwIFAg=HAkYuh63rsuhr6Scbfh0UjBXeMK > - > ndb3voDTXcWzoCI=f7wsLGcfzAWDNS6XNTBZwj_OLAOsZZqdrR2IDAzeZqE& > m=uchRmclZ5z8wB9eN53Kr24c9zLtM9RBRe8OnA3FK1fM=cbCycqc2jZy8SjT > LHS4AEL_UhljIoaGGWAnycB0VvrY= > > > -Original Message- > From: Jeffrey (Zhaohui) Zhang [mailto:zzh...@juniper.net] > Sent: Thursday, January 24, 2019 12:32 AM > To: Xiejingrong ; draft-ietf-bess-mvpn-expl- > tr...@ietf.org > Cc: bess@ietf.org > Subject: RE: Question regarding RFC6625 and this draft-->//RE: [bess] I-D > Action: draft-ietf-bess-mvpn-expl-track-13.txt > > Hi Jingrong, > > You're right that to avoid disruption and duplication a switchover delay is > needed on the source PE and desired on the receiver PE, and that means the > forwarding state needs to accommodate that. > > However, the text is in RFC6625 is really/mainly about which tunnel to > send/receive on in a steady state. That's not explicitly spelled out, but > that's > the intention per my understanding. > > To be more accurate, the text is about which PMSI route to match. In theory a > PMSI can be instantiated with one particular tunnel at one time and then > switch to another tunnel. In that case the PMSI route is updated with a > different PTA - the match to sending/receiving does not change yet the > switchover delay referred to RFC6513 still applies. > > Jeffrey > > > -Original Message- > > From: Xiejingrong [mailto:xiejingr...@huawei.com] > > Sent: Tuesday, January 22, 2019 8:47 PM > > To: Jeffrey (Zhaohui) Zhang ; > > draft-ietf-bess-mvpn-expl- tr...@ietf.org > > Cc: bess@ietf.org > > Subject: RE: Question regarding RFC6625 and this draft-->//RE: [bess] > > I-D > > Action: draft-ietf-bess-mvpn-expl-track-13.txt > > > > Hi Jeffrey, > > > > The sender PE need to work on (*,*) tunnel for a while (switch-over > > timer) and then switch to the (S,G) tunnel. > > > > To quote RFC6513 section 7.1.1 > >The decision to bind a particular C-flow (designated as (C-S,C-G)) to > >a particular P-tunnel, or to switch a particular C-flow to a > >particular P-tunnel, is always made by the PE that is to transmit the > >C-flow onto the P-tunnel. > > > >When a C-flow is switched from one P-tunnel to another, the purpose > >of running a switch-over timer is to minimize packet loss without > >introducing packet duplication. > > > > Jingrong > > > > -Original Message- > > From: Jeffrey (Zhaohui) Zhang [mailto:zzh...@juniper.net] > > Sent: Saturday, January 12, 2019 3:29 AM > > To: Xiejingrong ; draft-ietf-bess-mvpn-expl- > > tr...@ietf.org > > Cc: bess@ietf.org > > Subject: RE: Question regarding RFC6625 and this draft-->//RE: [bess] > > I-D > > Action: draft-ietf-bess-mvpn-expl-track-13.txt > > > > Jingrong, > > > > > It is determined by the sender site PE whether to steer the flow of > > > (C-S, C-G) > > into (*,*) PMSI-tunnel or (S,G)PMSI-tunnel, and the receiver site PE > > should work correctly in any case. > > > > Why would the sender PE send into (*, *) when there is a match for (S,G)? > > > > Jeffrey > > > > > -Original Message- > > > From: Xiejingrong [mailto:xiejingr...@huawei.com] > > > Sent: Thursday, January 10, 2019 11:10 PM > > > To: draft-ietf-bess-mvpn-expl-tr...@ietf.org > > > Cc: bess@ietf.org > > > Subject: Question regarding RFC6625 and this draft-->//RE: [bess] I-D > Action: > > > draft-ietf-bess-mvpn-expl-track-13.txt > > > > > > Hi, > > > > > > I have a question regarding RFC6625 and this draft, since this draft > > > is based on the RFC6625. > > > > > > In RFC6625 section "3.2.1 Finding the match for (C-S,C-G) for Data > > > Reception": > > > It defined the rules for Finding the matched S-PMSI A-D route for a > > >
Re: [bess] Question regarding RFC6625 and this draft-->//RE: I-D Action: draft-ietf-bess-mvpn-expl-track-13.txt
Hi Jeffrey, Thanks for the explaination. I have the same understanding "the text in RFC6625 is really/mainly about which tunnel to send/receive on in a steady state." What confusing me is the "which tunnel to receive" decision, obviously on receiver site PE. In my opinion, the receiver site PE should not do the decision, but be prepared to *any possible tunnel* that will be used by the sender site PE for a specific (S,G) flow. Even in a steady state the sender site PE are using the (S,G) PMSI-tunnel for a (S,G) flow, the preparation on the (*,*)PMSI-tunnel should be kept on the receiver site PE. Below is the errata report I have raised, and I hope it can be clarified. https://www.rfc-editor.org/errata/eid5605 -Original Message- From: Jeffrey (Zhaohui) Zhang [mailto:zzh...@juniper.net] Sent: Thursday, January 24, 2019 12:32 AM To: Xiejingrong ; draft-ietf-bess-mvpn-expl-tr...@ietf.org Cc: bess@ietf.org Subject: RE: Question regarding RFC6625 and this draft-->//RE: [bess] I-D Action: draft-ietf-bess-mvpn-expl-track-13.txt Hi Jingrong, You're right that to avoid disruption and duplication a switchover delay is needed on the source PE and desired on the receiver PE, and that means the forwarding state needs to accommodate that. However, the text is in RFC6625 is really/mainly about which tunnel to send/receive on in a steady state. That's not explicitly spelled out, but that's the intention per my understanding. To be more accurate, the text is about which PMSI route to match. In theory a PMSI can be instantiated with one particular tunnel at one time and then switch to another tunnel. In that case the PMSI route is updated with a different PTA - the match to sending/receiving does not change yet the switchover delay referred to RFC6513 still applies. Jeffrey > -Original Message- > From: Xiejingrong [mailto:xiejingr...@huawei.com] > Sent: Tuesday, January 22, 2019 8:47 PM > To: Jeffrey (Zhaohui) Zhang ; > draft-ietf-bess-mvpn-expl- tr...@ietf.org > Cc: bess@ietf.org > Subject: RE: Question regarding RFC6625 and this draft-->//RE: [bess] > I-D > Action: draft-ietf-bess-mvpn-expl-track-13.txt > > Hi Jeffrey, > > The sender PE need to work on (*,*) tunnel for a while (switch-over > timer) and then switch to the (S,G) tunnel. > > To quote RFC6513 section 7.1.1 >The decision to bind a particular C-flow (designated as (C-S,C-G)) to >a particular P-tunnel, or to switch a particular C-flow to a >particular P-tunnel, is always made by the PE that is to transmit the >C-flow onto the P-tunnel. > >When a C-flow is switched from one P-tunnel to another, the purpose >of running a switch-over timer is to minimize packet loss without >introducing packet duplication. > > Jingrong > > -Original Message- > From: Jeffrey (Zhaohui) Zhang [mailto:zzh...@juniper.net] > Sent: Saturday, January 12, 2019 3:29 AM > To: Xiejingrong ; draft-ietf-bess-mvpn-expl- > tr...@ietf.org > Cc: bess@ietf.org > Subject: RE: Question regarding RFC6625 and this draft-->//RE: [bess] > I-D > Action: draft-ietf-bess-mvpn-expl-track-13.txt > > Jingrong, > > > It is determined by the sender site PE whether to steer the flow of > > (C-S, C-G) > into (*,*) PMSI-tunnel or (S,G)PMSI-tunnel, and the receiver site PE > should work correctly in any case. > > Why would the sender PE send into (*, *) when there is a match for (S,G)? > > Jeffrey > > > -Original Message- > > From: Xiejingrong [mailto:xiejingr...@huawei.com] > > Sent: Thursday, January 10, 2019 11:10 PM > > To: draft-ietf-bess-mvpn-expl-tr...@ietf.org > > Cc: bess@ietf.org > > Subject: Question regarding RFC6625 and this draft-->//RE: [bess] I-D > > Action: > > draft-ietf-bess-mvpn-expl-track-13.txt > > > > Hi, > > > > I have a question regarding RFC6625 and this draft, since this draft > > is based on the RFC6625. > > > > In RFC6625 section "3.2.1 Finding the match for (C-S,C-G) for Data > > Reception": > > It defined the rules for Finding the matched S-PMSI A-D route for a > > (C-S,C-G) state on a receiver site PE. > > It seems to me that, the receiver site PE will respond only to the > > *ONE* 'Match for Reception' S-PMSI A-D route, and setup the > > 'reception state' only for the 'Matched' S-PMSI A-D route. > > But it is not true for an inclusive-selective relation between > > S-PMSI A-D (*,*) and S-PMSI A-D(S,G). > > Thinking the S-PMSI A-D (*,*) as an Inclusive one, the receiver site > > PE with a > > (C-S,C-G) state should keep its join state on both the S-PMSI A-D > > (*,*) and S- PMSI A-D(S,G), and setup the 'reception state' on both > > the (*,*) PMSI-tunnel and (S,G) PMSI-tunnel. > > It is determined by the sender site PE whether to steer the flow of > > (C-S, C-G) into (*,*) PMSI-tunnel or (S,G)PMSI-tunnel, and the > > receiver site PE should work correctly in any case. > > > > My question: > > Is the section 3.2.1 or RFC6625 wrong and should the 'Match for Reception' > >
[bess] I-D Action: draft-ietf-bess-evpn-irb-mcast-02.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the BGP Enabled ServiceS WG of the IETF. Title : EVPN Optimized Inter-Subnet Multicast (OISM) Forwarding Authors : Wen Lin Zhaohui Zhang John Drake Eric C. Rosen Jorge Rabadan Ali Sajassi Filename: draft-ietf-bess-evpn-irb-mcast-02.txt Pages : 77 Date: 2019-01-23 Abstract: Ethernet VPN (EVPN) provides a service that allows a single Local Area Network (LAN), comprising a single IP subnet, to be divided into multiple "segments". Each segment may be located at a different site, and the segments are interconnected by an IP or MPLS backbone. Intra-subnet traffic (either unicast or multicast) always appears to the endusers to be bridged, even when it is actually carried over the IP or MPLS backbone. When a single "tenant" owns multiple such LANs, EVPN also allows IP unicast traffic to be routed between those LANs. This document specifies new procedures that allow inter-subnet IP multicast traffic to be routed among the LANs of a given tenant, while still making intra-subnet IP multicast traffic appear to be bridged. These procedures can provide optimal routing of the inter- subnet multicast traffic, and do not require any such traffic to leave a given router and then reenter that same router. These procedures also accommodate IP multicast traffic that needs to travel to or from systems that are outside the EVPN domain. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-irb-mcast/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-bess-evpn-irb-mcast-02 https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-irb-mcast-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-evpn-irb-mcast-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
Re: [bess] Question regarding RFC6625 and this draft-->//RE: I-D Action: draft-ietf-bess-mvpn-expl-track-13.txt
Hi Jingrong, You're right that to avoid disruption and duplication a switchover delay is needed on the source PE and desired on the receiver PE, and that means the forwarding state needs to accommodate that. However, the text is in RFC6625 is really/mainly about which tunnel to send/receive on in a steady state. That's not explicitly spelled out, but that's the intention per my understanding. To be more accurate, the text is about which PMSI route to match. In theory a PMSI can be instantiated with one particular tunnel at one time and then switch to another tunnel. In that case the PMSI route is updated with a different PTA - the match to sending/receiving does not change yet the switchover delay referred to RFC6513 still applies. Jeffrey > -Original Message- > From: Xiejingrong [mailto:xiejingr...@huawei.com] > Sent: Tuesday, January 22, 2019 8:47 PM > To: Jeffrey (Zhaohui) Zhang ; draft-ietf-bess-mvpn-expl- > tr...@ietf.org > Cc: bess@ietf.org > Subject: RE: Question regarding RFC6625 and this draft-->//RE: [bess] I-D > Action: draft-ietf-bess-mvpn-expl-track-13.txt > > Hi Jeffrey, > > The sender PE need to work on (*,*) tunnel for a while (switch-over timer) and > then switch to the (S,G) tunnel. > > To quote RFC6513 section 7.1.1 >The decision to bind a particular C-flow (designated as (C-S,C-G)) to >a particular P-tunnel, or to switch a particular C-flow to a >particular P-tunnel, is always made by the PE that is to transmit the >C-flow onto the P-tunnel. > >When a C-flow is switched from one P-tunnel to another, the purpose >of running a switch-over timer is to minimize packet loss without >introducing packet duplication. > > Jingrong > > -Original Message- > From: Jeffrey (Zhaohui) Zhang [mailto:zzh...@juniper.net] > Sent: Saturday, January 12, 2019 3:29 AM > To: Xiejingrong ; draft-ietf-bess-mvpn-expl- > tr...@ietf.org > Cc: bess@ietf.org > Subject: RE: Question regarding RFC6625 and this draft-->//RE: [bess] I-D > Action: draft-ietf-bess-mvpn-expl-track-13.txt > > Jingrong, > > > It is determined by the sender site PE whether to steer the flow of (C-S, > > C-G) > into (*,*) PMSI-tunnel or (S,G)PMSI-tunnel, and the receiver site PE should > work correctly in any case. > > Why would the sender PE send into (*, *) when there is a match for (S,G)? > > Jeffrey > > > -Original Message- > > From: Xiejingrong [mailto:xiejingr...@huawei.com] > > Sent: Thursday, January 10, 2019 11:10 PM > > To: draft-ietf-bess-mvpn-expl-tr...@ietf.org > > Cc: bess@ietf.org > > Subject: Question regarding RFC6625 and this draft-->//RE: [bess] I-D > > Action: > > draft-ietf-bess-mvpn-expl-track-13.txt > > > > Hi, > > > > I have a question regarding RFC6625 and this draft, since this draft > > is based on the RFC6625. > > > > In RFC6625 section "3.2.1 Finding the match for (C-S,C-G) for Data > > Reception": > > It defined the rules for Finding the matched S-PMSI A-D route for a > > (C-S,C-G) state on a receiver site PE. > > It seems to me that, the receiver site PE will respond only to the > > *ONE* 'Match for Reception' S-PMSI A-D route, and setup the 'reception > > state' only for the 'Matched' S-PMSI A-D route. > > But it is not true for an inclusive-selective relation between S-PMSI > > A-D (*,*) and S-PMSI A-D(S,G). > > Thinking the S-PMSI A-D (*,*) as an Inclusive one, the receiver site > > PE with a > > (C-S,C-G) state should keep its join state on both the S-PMSI A-D > > (*,*) and S- PMSI A-D(S,G), and setup the 'reception state' on both > > the (*,*) PMSI-tunnel and (S,G) PMSI-tunnel. > > It is determined by the sender site PE whether to steer the flow of > > (C-S, C-G) into (*,*) PMSI-tunnel or (S,G)PMSI-tunnel, and the > > receiver site PE should work correctly in any case. > > > > My question: > > Is the section 3.2.1 or RFC6625 wrong and should the 'Match for Reception' > > include *one or many* S-PMSI A-D routes ? > > Is it a problem that can affect this draft ? > > > > Thanks > > Jingrong. > > > > > > -Original Message- > > From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of internet- > > dra...@ietf.org > > Sent: Thursday, November 29, 2018 12:27 AM > > To: i-d-annou...@ietf.org > > Cc: bess@ietf.org > > Subject: [bess] I-D Action: draft-ietf-bess-mvpn-expl-track-13.txt > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > This draft is a work item of the BGP Enabled ServiceS WG of the IETF. > > > > Title : Explicit Tracking with Wild Card Routes in > > Multicast VPN > > Authors : Andrew Dolganow > > Jayant Kotalwar > > Eric C. Rosen > > Zhaohui Zhang > > Filename: draft-ietf-bess-mvpn-expl-track-13.txt > > Pages : 21 > > Date: 2018-11-28 > > > > Abstract: > >The Multicast VPN (MVPN) specifications provide procedures
Re: [bess] WGLC, IPR and implementation poll for draft-ietf-bess-nsh-bgp-control-plane
Not aware of any IPR Support (co-author) Luay On Jan 21, 2019 7:06 AM, wrote: Hello Working Group, This email starts a three weeks Working Group Last Call on draft-ietf-bess-nsh-bgp-control-plane [1]. This poll runs until *the 4th of February*. 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-nsh-bgp-control-plane/ [2] https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw _ 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 ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
[bess] I-D Action: draft-ietf-bess-mvpn-yang-00.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the BGP Enabled ServiceS WG of the IETF. Title : Yang Data Model for Multicast in MPLS/BGP IP VPNs Authors : Yisong Liu Feng Guo Stephane Litkowski Xufeng Liu Robert Kebler Mahesh Sivakumar Filename: draft-ietf-bess-mvpn-yang-00.txt Pages : 32 Date: 2019-01-22 Abstract: This document defines a YANG data model that can be used to configure and manage multicast in MPLS/BGP IP VPNs. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-yang/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-bess-mvpn-yang-00 https://datatracker.ietf.org/doc/html/draft-ietf-bess-mvpn-yang-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
