Support as co-author.
Not aware of IPRs.
Thanks.
Jeffrey
From: slitkows.i...@gmail.com
Sent: Tuesday, December 1, 2020 4:31 AM
To: bess@ietf.org; draft-skr-bess-evpn-redundant-mcast-sou...@ietf.org
Subject: WG adoption for draft-skr-bess-evpn-redundant-mcast-source
[External Email. Be cautious
Hi Matthew, Stephane,
I’m not aware of any un-disclosed IPR.
I support publishing this draft as a standards track RFC. I would like to
report that Cisco has implemented the draft for L3VPNv4/v6, internet ipv4/v6
and EVPN services.
Regards
Swadesh
From: BESS on behalf of "Bocci, Matthew
Hi,
as a contributor I support the publication of this draft as standards track
RFC.
I am not aware of any undisclosed IPR(s).
Thanks,
Dirk
On Mon, Nov 30, 2020 at 7:15 PM Bocci, Matthew (Nokia - GB) <
matthew.bo...@nokia.com> wrote:
> This email starts a two-week working group last call for
Dear Gaurav Dawra, Clarence Filsfils, Ketan Talaulikar, Robert Raszuk, Bruno
Decraene, Shunwan Zhuang, Jorge Rabadan:
An IPR disclosure that pertains to your Internet-Draft entitled "SRv6 BGP
based Overlay services" (draft-ietf-bess-srv6-services) was submitted to the
IETF Secretariat on
Dear Gaurav Dawra, Clarence Filsfils, Ketan Talaulikar, Robert Raszuk, Bruno
Decraene, Shunwan Zhuang, Jorge Rabadan:
An IPR disclosure that pertains to your Internet-Draft entitled "SRv6 BGP
based Overlay services" (draft-ietf-bess-srv6-services) was submitted to the
IETF Secretariat on
Hi,
I’m not aware of any relevant IPR and as a contributor, I support the
publication of this document as standard track RFC.
Thanks
dan
From: "Bocci, Matthew (Nokia - GB)"
Date: Monday, November 30, 2020 at 12:15 PM
To: "draft-ietf-bess-srv6-servi...@ietf.org"
, "bess@ietf.org"
Subject: WG
Hi Haibo,
I agree with Ketan… furthermore, the spec clearly defines the structure
sub-sub-TLV, where the transposition length and offset are needed; it also
defines how to place those bits into the label field of the NLRI, irrespective
of the transposition length being 24 or 20 or anything
Hi Haibo,
This is not a change but a clarification to avoid exactly those kind of issues.
Thanks,
Ketan
From: Wanghaibo (Rainsword)
Sent: 03 December 2020 15:39
To: Ketan Talaulikar (ketant) ; Bocci, Matthew (Nokia - GB)
; draft-ietf-bess-srv6-servi...@ietf.org; bess@ietf.org
Subject: RE: WG
Hi Ketan,
Thanks for your reply.
RFC 8277 has clearly described that the label field is only 20 bits.
At the beginning, we consider it to use the 20-bits to do the transposition.
But in some interconnection tests, some vendors are use the 24-bits to do the
transposition.
So I’m
Hi Matthew, Stephane and WG,
I support publishing this draft as a standards track RFC.
I know that there are many deployment cases that have already been captured in
the document:
https://tools.ietf.org/id/draft-tian-spring-srv6-deployment-consideration-03.txt
Regards,
--Zhibo
From: Bocci,
Support publication. I am not aware of any undisclosed IPR as co-author.
Cheers,
Clarence
From: Bocci, Matthew (Nokia - GB)
Sent: Monday, November 30, 2020 18:16
To: draft-ietf-bess-srv6-servi...@ietf.org; bess@ietf.org
Subject: WG Last Call, IPR and Implementation Poll for
Hi Haibo,
This clarification was explicitly added based on feedback that the authors
received.
This document does not change the definition of the Label Field of RFC4364 and
so it has always been 20 bits. There has been this text about 24-bit in other
parts of the draft since RFC7432 allows
Hi Matthew & Stephane,
I support the publication of this draft as standards track RFC.
As a co-author, I am not aware of any undisclosed IPR(s).
Thank you,
Robert
On Mon, Nov 30, 2020 at 6:15 PM Bocci, Matthew (Nokia - GB) <
matthew.bo...@nokia.com> wrote:
> This email starts a
13 matches
Mail list logo
