Perfect! Looking forward to it!
Kind Regards
Gyan
On Wed, Jul 14, 2021 at 11:01 PM Jeff Tantsura
wrote:
> I’m planning to have a presentation in RTGWG that would explain RTO based
> header changes/ aka self healing fabie (flow label in v6/ overlay
> transport layer source port in v4, in
I’m planning to have a presentation in RTGWG that would explain RTO based
header changes/ aka self healing fabie (flow label in v6/ overlay transport
layer source port in v4, in linux kernel since 2016), stay tuned.
This is mostly relevant to DC domain and while host based still a very
All
I think I figured out how “source port entropy” works and provides “better”
load balancing then traditional IGP & EGP based ECMP underlay algorithms
that
are subject to polarization.
So normally w/o source port entropy vxlan feature the overlay NVE Anycast
vtep tunnel as a tunnel source and
John Scudder has entered the following ballot position for
draft-ietf-bess-evpn-inter-subnet-forwarding-14: No Objection
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Hi,
Comments inline.
We are planning to publish a new version of the draft with our proposed
changes, on which John Scudder has graciously worked with us, once the
black-out has been lifted.
Yours Irrespectively,
John
Juniper Business Use Only
> -Original Message-
> From: John
Dear BESS Experts
?? On NVO3 VXLAN overlay encapsulation
My understanding of VXLAN source port entropy is to provide uniform load
balancing similar to RFC 6437 IPv6 flow label uniform stateful load
balancing, in NVO3 VXLAN context, using header 5-tuple L2/L3/L4 hash and
generating source port
All,
Primary agenda posted. As it happened in other IETF we have more request than
what we can handle.
https://datatracker.ietf.org/meeting/111/materials/agenda-111-bess-00
please let me know if something is missing.
Mankamana
___
BESS mailing list
Hey Srihari,
While you are right in the notion of original BGP spec I think the
definition of what is key for someone remains very loose.
Just take a look at RFC5575 where key is defined as opaque bit string :)
This NLRI is treated as an opaque bit string prefix by
BGP. Each bit string
Hello,
Looking at the archives on this topic, there was a small discussion about the
structure of the NLRI as proposed in the BGP CAR draft. The conversation was
not conclusive and here’s my thought and a question related to the topic.
While the proposed NLRI format enables NLRI types to be
