Hi,
Apologies for writing only during WGLC, I am only just becoming familiar with
this draft.
I find the Abstract and Introduction are repetitive (copy paste).
Would the authors consider shortening/rewriting the Abstract, in favour of the
Introduction, to remove the duplication?
Regards,
Luc
Hi Jeffrey and Sasha,
The flows of E-tree services typically are P2MP conections,
But the flows of hub/spoke services typically are MP2MP connections,
the spoke PEs can connect to each other under the assistance of the hub PE.
The hub/spoke services is actually a special pattern of
Thanks Adrian!
I looked at the diffs and reviewed our exchange.
I’m clearing my DISCUSS.
Alvaro.
On August 19, 2020 at 6:11:27 PM, Adrian Farrel (adr...@olddog.co.uk) wrote:
Just coming back to you on this one, Alvaro
___
BESS mailing list
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 : Controller Based BGP Multicast Signaling
Authors : Zhaohui Zhang
Robert
Hub and spoke EVPN and E-tree are different.
However, draft-ietf-bess-evpn-virtual-hub should address the following two at
least:
* MPLS EVPN can't support hub/spoke usecase, where the spoke PEs can
only connect to each other through the hub PE. Especially when at
least two of
Dear authors of draft-wang-bess-evpn-context-label-04,
Section 2 "Problem Statement" of draft-wang-bess-evpn-context-label-04 states
that " MPLS EVPN can't support hub/spoke use case, where the spoke PEs can only
connect to each other through the hub PE. Especially when at least two of the
Ben,
Perhaps, although AFAIK the three values defined in RFC 4364 have not been
supplemented since it was published in 2006.
Yours Irrespectively,
John
Juniper Business Use Only
> -Original Message-
> From: Benjamin Kaduk
> Sent: Thursday, August 20, 2020 9:49 AM
> To: John E Drake
Hi John,
On Thu, Aug 20, 2020 at 01:43:34PM +, John E Drake wrote:
> Ben,
>
> An RD is encoded using the same format as an extended community but it isn't
> an extended community. Rather, it is actually part of the NLRI. The first
> octet is always zero whereas the first octet of an SFIR
Ben,
An RD is encoded using the same format as an extended community but it isn't an
extended community. Rather, it is actually part of the NLRI. The first octet
is always zero whereas the first octet of an SFIR Pool Identifier extended
community will always be non-zero (TBD6).
Yours
