Reviewer: Tony Przygienda
Review result: Has Issues
As first, technically sound except point 18. Rest of the commentes provided are
all for easier readability/clarity for a reader that may not be super
instrinsically familiar with the world of overlay multicast tunnels underlying
VPN technologies
,
> Ketan
>
>
> On Thu, Feb 17, 2022 at 3:40 PM Tony Przygienda
> wrote:
>
>>
>>
>>
>>>
>>>> But I'm prepared to learn why this wouldn't work or would be somehow
>>>> worse.
>>>>
>>>
>>> K
>
>> But I'm prepared to learn why this wouldn't work or would be somehow
>> worse.
>>
>
> KT> It isn't necessary nor required because SRv6 locators are just IPv6
> prefixes that are already covered by IGP/BGP extensions for IPv6 routing. A
> provider that uses global IPv6 addresses in their infras
support adoption
On Tue, Apr 13, 2021 at 3:38 PM Ron Bonica wrote:
>
>
> I support adoption.
>
>
>
> Ron
>
>
>
>
>
>
>
> Juniper Business Use Only
>
> *From:* BESS *On Behalf Of *Bocci, Matthew (Nokia
> - GB)
> *Sent:* Tuesday, April 13, 2021 5:37 AM
> *To:* draft-mishra-bess-deplo
any chance I get 10 (better 15) mins to present
https://tools.ietf.org/html/draft-head-rift-auto-evpn-00
?
thanks
-- tony
On Tue, Feb 16, 2021 at 4:58 PM Mankamana Mishra (mankamis) wrote:
> All,
>
> Agenda for IETF 110 is out. Please send request to take slot to present.
> We are meeting on
any chance I get 10 (better 15) mins to present
https://tools.ietf.org/html/draft-head-rift-auto-evpn-00
?
thanks
-- tony
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess
100+
> page draft. Now I really have to read it.
>
> Yes that would be great. Please unicast me on hayabusa...@gmail.com.
>
> Kind regards
>
> Gyan
>
> On Mon, Mar 9, 2020 at 11:31 AM Tony Przygienda
> wrote:
>
>> Gyan, the technology that you look for exists an
Gyan, the technology that you look for exists and is about to go standards
RFC (i.e. _scalable_ L3 multihoming to the host including bandwidth
load-balancing and many other things that need consideration in such case,
e.g. host asic table scalability). Please look @
https://datatracker.ietf.org/doc
not aware of any undisclosed IPR (in E/// where I was working on what are
now pieces of the draft) ...
thanks
--- tony
On Mon, Mar 26, 2018 at 7:21 AM, wrote:
> Hello working group,
>
>
>
> This email starts a two-week Working Group Last Call on
> draft-ietf-bess-evpn-df-election-framework-00
Ack, welcome, great to have more and more operators getting involved in the
sausage definition. This leads often to early discussions and better
appreciation of the challenges of ultimately pouring the resulting tapestry
of RFCs into bits and silicon ;-)
--- tony
On Fri, Dec 1, 2017 at 8:16 AM, A
support as co-author. Not aware of IPR ...
On Tue, Jun 6, 2017 at 6:44 AM, wrote:
> Hello working group,
>
> This email starts a two-week call for adoption on
> draft-rabadan-bess-evpn-pref-df-02 [1] as a Working Group Document.
>
> Please state on the list if you support the adoption or not (i
+1 adoption
On Mon, Mar 6, 2017 at 3:55 AM, Martin Vigoureux wrote:
> Hello working group,
>
> This email starts a two-week call for adoption on
> draft-mackie-bess-nsh-bgp-control-plane-04 [1] as a Working Group
> Document.
>
> Please state on the list if you support the adoption or not (in bot
+1 support
On Thu, Aug 25, 2016 at 6:19 PM, Jeff Tantsura
wrote:
> Yes/support
>
> Regards,
> Jeff
>
>
> On Tue, Aug 16, 2016 at 5:37 AM -0700, "Martin Vigoureux" <
> martin.vigour...@nokia.com> wrote:
>
> Hello working group,
>>
>> This email starts a two-week poll on adopting
>> draft-zzhang-b
> 1. When a new PE comes in the MH segment.
> [Satya] Yes, New PE needs to wait for 3 sec. According to RFC 7438, the
> receiving PEs also need to wait for 3 secs. But, ideally, a PE that is
> going from DF to non-DF or non-DF to non-DF should become the non-DF right
> away. Only the PE that is goi
14 matches
Mail list logo
