Re: [bess] WGLC, IPR and implementation poll for draft-ietf-bess-nsh-bgp-control-plane

2019-01-23 Thread Luay Jalil
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

Re: [bess] Question regarding RFC6625 and this draft-->//RE: I-D Action: draft-ietf-bess-mvpn-expl-track-13.txt

2019-01-23 Thread Jeffrey (Zhaohui) Zhang
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

[bess] I-D Action: draft-ietf-bess-evpn-irb-mcast-02.txt

2019-01-23 Thread internet-drafts
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the BGP Enabled ServiceS WG of the IETF. Title : EVPN Optimized Inter-Subnet Multicast (OISM) Forwarding Authors : Wen Lin

[bess] I-D Action: draft-ietf-bess-mvpn-yang-00.txt

2019-01-23 Thread internet-drafts
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the BGP Enabled ServiceS WG of the IETF. Title : Yang Data Model for Multicast in MPLS/BGP IP VPNs Authors : Yisong Liu Feng

Re: [bess] WGLC, IPR and implementation poll for draft-ietf-bess-nsh-bgp-control-plane

2019-01-23 Thread Adrian Farrel
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

Re: [bess] Question regarding RFC6625 and this draft-->//RE: I-D Action: draft-ietf-bess-mvpn-expl-track-13.txt

2019-01-23 Thread Xiejingrong
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

Re: [bess] Question regarding RFC6625 and this draft-->//RE: I-D Action: draft-ietf-bess-mvpn-expl-track-13.txt

2019-01-23 Thread Jeffrey (Zhaohui) Zhang
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 ;