Hi,
I have always had my opinion that Multicast Tree Building procedure is a very
dynamic procedure, however BGP is skilled at stable-data (like prefix, or
aggregated MVPN state on edge of a provider) driven “PUSH” thing.
I have almost forget the detail of the draft-ietf-bess-bgp-multicast-cont
with the processing of this draft even if I
think it is wrong direction to me as I see it from implementation view.
Thanks!
Jingrong
From: Jeffrey (Zhaohui) Zhang [mailto:zzh...@juniper.net]
Sent: Monday, May 10, 2021 10:28 PM
To: Xiejingrong (Jingrong) ; slitkows.i...@gmail.com;
bess@ietf.org
anks
Jingrong
From: Jeffrey (Zhaohui) Zhang [mailto:zzh...@juniper.net]
Sent: Tuesday, May 4, 2021 2:39 AM
To: Xiejingrong (Jingrong) ; slitkows.i...@gmail.com;
bess@ietf.org
Cc: bess-cha...@ietf.org
Subject: RE: [bess] Cross WG review request for draft-ietf-bier-evpn
Hi Jingrong, WG,
I some
Hi,
I have read the document and support the adoption.
Thanks,
Jingrong
From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Bocci, Matthew (Nokia -
GB)
Sent: Tuesday, April 13, 2021 5:37 PM
To: draft-mishra-bess-deployment-guide-ipv4nlri-ipv...@ietf.org; bess@ietf.org
Subject: [bess] WG Adop
Hi,
I have some comments on this draft.
1. There are 3 different encapsulations VXLAN/NVGRE/GENEVE defined in this
draft, but it is not clear if there is a mandatory one for interoperable
implementation, or all are mandatory ?
The effort to make BIER-EVPN "unified" with Unicast-EVPN (by using
Hi Eric,
You say "because of the use outside of a node of the IPv4-mapped IPv6 addresses
in section 3.1.6.1. A reply on this topic will be welcome."
I understand your point about using IPv4-mapped IPv6 address
":::127.0.0.0/104", as it is assumed to never leave a node and should never
be t
Yes, support publishing the draft.
Thanks
Jingrong
From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of slitkows.i...@gmail.com
Sent: Friday, December 11, 2020 11:53 PM
To: draft-ietf-bess-mvpn-evpn-aggregation-la...@ietf.org; bess@ietf.org
Cc: bess-cha...@ietf.org
Subject: [bess] WG Last Call
I think John’s point is very reasonable, especially when considering that the
current format of EVPN 8# route has been in current shape for many years.
The cleanest solution is to keep the format depicted in draft -04 (and its
predecessors) on code point 8, and to allocate a new code point for th
om; ya...@juniper.net; wim.henderi...@alcatel-lucent.be;
r...@huawei.com; db3...@att.com; aretana.i...@gmail.com;
martin.vigour...@nokia.com; martin.vigour...@alcatel-lucent.com;
thomas.mo...@orange.com
Cc: Xiejingrong ; l3...@ietf.org;
rfc-edi...@rfc-editor.org
Subject: [Technical Errata Reported] R
I support the adoption.
Thanks
Jingrong
From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of slitkows.i...@gmail.com
Sent: Monday, October 28, 2019 6:10 PM
To: bess@ietf.org
Cc: bess-cha...@ietf.org
Subject: [bess] WG adoption poll for
draft-sajassi-bess-evpn-mvpn-seamless-interop
Hello,
Thi
I support the adoption.
Thanks
Jingrong
From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Bocci, Matthew (Nokia -
GB)
Sent: Friday, September 27, 2019 7:00 PM
To: draft-dawra-bess-srv6-servi...@ietf.org; bess@ietf.org
Subject: [bess] WG adoption and IPR poll for draft-dawra-bess-srv6-servic
Hi
I didn't see the reply to my recent comments on the previous rev of this draft……
Thanks
Jingrong
发件人：Gaurav Dawra
收件人：bess-cha...@ietf.org ;bess@ietf.org
时间：2019-07-08 13:36:08
主 题：Re: [bess] New Version Notification for
draft-dawra-bess-srv6-services-01.txt
Hi Bess WG,
To facilitate the r
Hi
Thanks the authors to introduce this very useful, very clear draft.
I do think it deserves very much the adoption by the WG as an solution option.
Here are some minor comments after I read the latest draft (which I think does
not affect the adoption):
6. Solution Overview
This section de
Hi
I have read this documents several times.
I think it is useful and stable to advance as a solution of L3VPN/EVPN service
over IPv6 networks.
Here are some minor comments:
SRv6 Service SID refers to an SRv6 SID that MAY be associated with
one of the service specific behavior on the advert
s/6556/8556/g
7432 section 8.2.1
The MPLS label in the NLRI MUST be set to 0.
8556 section 3
The MPLS label field SHOULD be set to zero.
From:Xiejingrong
To:draft-dawra-bess-srv6-servi...@ietf.org
;bess@ietf.org
Date:2019-06-27 19:57:30
Subject:[bess] MPLS Label value 3 in
Hi folks,
One ques
Hi folks,
One question about MPLS Label value 3 used in
:
the Label value in any service route NLRI encoding MUST be set to Implicit NULL
[RFC3032].
Label = Implicit NULL
I think the more common use of MPLS Label to represent "invalid" is to use
zero, as in RFC7432 and RFC6556.
Why this doc
we like to the
rules. Old SAFIs follow the RFCs already defind.
(4) next hop length = 32 is bizarre, and so does length = 48 as in
section 3.2.
Thank you very much !
Jingrong
From: Robert Raszuk [mailto:rob...@raszuk.net]
Sent: Thursday, June 27, 2019 6:50 PM
To: Xiejingrong
Cc
PM
To: Xiejingrong ; Alexander Okonnikov
; Robert Raszuk ;
bess@ietf.org
Cc: softwi...@ietf.org; i...@ietf.org
Subject: Re: [Idr] [bess] [Softwires] Regarding the Next Hop Network Address
coding for IPv4 VPN over IPv6 Core in RFC5549
since we are discussing that topic,
maybe the WG would like
; Xiejingrong ;
softwi...@ietf.org; i...@ietf.org; ian.far...@telekom.de; bess@ietf.org;
ianfar...@gmx.com
Subject: Re: [Idr] [bess] [Softwires] Regarding the Next Hop Network Address
coding for IPv4 VPN over IPv6 Core in RFC5549
Hi Robert,
Sorry, I was not so precise :-) Of course, RD part in Next
Hi folks,
I guess this is an inconsistency due to past carelessness. Is there anyone can
tell us the history of this inconsistency ?
RFC4364(VPNv4 over IPv4 network) and RFC4659(VPNv6 over IPv4 or IPv6 network)
both require to use RD+IP(v4 or v6 respectively) as nexthop.
RFC5549(VPNv4/IPv4 over
Congratulations for the production of this RFC!
This draft is useful not only for MVPN using mLDP/RSVP-TE/IR(which is covered
by this RFC), but also for MVPN using BIER (which is covered by BIER-MVPN
draft).
It can be leveraged to Segmented MVPN too, by using a 'loose stitching' between
mLDP
leave the
Wildcard(*,*)/(*,G)/(S,*) S-PMSI tunnel either, because they are “partially
inclusive” tunnel.
Jingrong
From: Jeffrey (Zhaohui) Zhang [mailto:zzh...@juniper.net]
Sent: Thursday, January 24, 2019 9:50 PM
To: Robert Raszuk
Cc: Xiejingrong ;
draft-ietf-bess-mvpn-expl-tr...@ietf.org; bess
hould be kept on the
receiver site PE.
Below is the errata report I have raised, and I hope it can be clarified.
https://www.rfc-editor.org/errata/eid5605
-Original Message-
From: Jeffrey (Zhaohui) Zhang [mailto:zzh...@juniper.net]
Sent: Thursday, January 24, 2019 12:32 AM
To: Xiejingrong ;
Message-
From: Jeffrey (Zhaohui) Zhang [mailto:zzh...@juniper.net]
Sent: Saturday, January 12, 2019 3:29 AM
To: Xiejingrong ;
draft-ietf-bess-mvpn-expl-tr...@ietf.org
Cc: bess@ietf.org
Subject: RE: Question regarding RFC6625 and this draft-->//RE: [bess] I-D
Action: draft-ietf-bess-mvpn-e
Hi,
I have a question regarding RFC6625 and this draft, since this draft is based
on the RFC6625.
In RFC6625 section "3.2.1 Finding the match for (C-S,C-G) for Data Reception":
It defined the rules for Finding the matched S-PMSI A-D route for a (C-S,C-G)
state on a receiver site PE.
It seems to
CB-context-label,
do you think it helpful for an allocation of 'reserved' label (value from 0 to
15) to represent a 'Context-label' to make the interoperability mandatory ?
Jingrong
From: Jeffrey (Zhaohui) Zhang [mailto:zzh...@juniper.net]
Sent: Friday, December 14,
DCB-context-label for BIER/SegmentedMVPN
cases, but this can be discussed later.
Thanks,
Jingrong.
From: stephane.litkow...@orange.com [mailto:stephane.litkow...@orange.com]
Sent: Thursday, December 13, 2018 4:40 PM
To: Xiejingrong ; Jeffrey (Zhaohui) Zhang
; bess@ietf.org
Subject: RE: Poll
Hi Jeffrey,
Please see xjr3>> below.
From: Jeffrey (Zhaohui) Zhang [mailto:zzh...@juniper.net]
Sent: Thursday, December 13, 2018 10:32 PM
To: Xiejingrong ; stephane.litkow...@orange.com;
bess@ietf.org
Subject: RE: Poll for early allocation request for
draft-ietf-bess-mvpn-evpn-aggre
s/inter-area/intra-area/g
From: Xiejingrong
Sent: Thursday, December 13, 2018 10:22 AM
To: 'Jeffrey (Zhaohui) Zhang' ;
stephane.litkow...@orange.com; bess@ietf.org
Subject: RE: Poll for early allocation request for
draft-ietf-bess-mvpn-evpn-aggregation-label
Hi Jeffrey,
Let m
at it don't.
Thanks.
Jingrong
From: Jeffrey (Zhaohui) Zhang [mailto:zzh...@juniper.net]
Sent: Wednesday, December 12, 2018 10:42 PM
To: Xiejingrong ; stephane.litkow...@orange.com;
bess@ietf.org
Subject: RE: Poll for early allocation request for
draft-ietf-bess-mvpn-evpn-aggregatio
Objection.
I remember I have raised my concerns, but I didn't find the response.
Copy the concerns I have listed before:
1. The problem stated by this draft is valid, and the proposed method is
useful for some of the listed problem. For example, EVPN BUM who uses MPLS
identification and da
I support the adoption.
Thanks,
Jingrong
From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Bocci, Matthew (Nokia -
GB)
Sent: Monday, December 03, 2018 10:53 PM
To: bess@ietf.org
Cc: draft-liu-bess-mvpn-y...@ietf.org
Subject: [bess] Wg Adoption and IPR poll for draft-liu-bess-mvpn-yang-07
T
+1 support the adoption.
My comments:
1. The problem stated by this draft is valid, and the proposed method is
useful for some of the listed problem. For example, EVPN BUM who uses MPLS
identification and dataplane.
2. EVPN BUM using vxlan/vni identification may not need a MPLS label
BESS WG:
Had the IANA ack'ed the request of adding the value 2 (Name LIR-PF) ?
I have not seen it in
https://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml#pmsi-tunnel-attributes
Thanks.
Jingrong
-Original Message-
From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of in
Hi folks,
I have some comments on draft-sajassi-bess-evpn-mvpn-seamless-interop-01:
(1) For section 9.2.2 where it stated "The MPLS label in the PMSI Tunnel
Attribute MUST be the Virtual Network Identifier (VNI) associated with the
customer MVPN.",
I think the VNI need not being included in
-generate a S-PMSI(*,*) route with PTA to EgressPEs.
Through have got a nice clarification from Eirc about
, I found that this question still in my mind
:-)
Regards.
XieJingrong
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman
ll be good.
From: Eric C Rosen [mailto:ero...@juniper.net]
Sent: Thursday, February 01, 2018 2:49 AM
To: Xiejingrong ; bess@ietf.org
Subject: Re: [bess] Comments on draft-ietf-bess-mvpn-expl-track-03
Thanks for delving into the details here. This part of the writeup is very
confusing (for which I h
an't be used in Segmented P-tunnels scenario.
Its chap 2.2.2 requires that, LIR-pF Flag is used only when non segmented
P-tunnels are used.
Thanks.
XieJingrong
From: Eric C Rosen [mailto:ero...@juniper.net]
Sent: Thursday, January 18, 2018 11:49 PM
To: Xiejingrong ; bess@ietf.org
Subject: R
alled by
EgressABR, and then 'relay' back to IngressPE, and thus enable IngressPE
explicit tracking inside the ingress "segmentation domain" ?
Thanks.
XieJingrong
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess
39 matches
Mail list logo
