Hi Benjamin,
> A general comment that we've been making on lots of documents in this
> space is that it would be nice to be in a place where the acronym "VPN"
> implies transport encryption.
Let me observe that for a lot of work in IETF term "VPN" does *not* imply
any form of either transport or
and once the
document passes WG validating its technical merits I have not heard of many
cases where IESG or IETF wide review would change the name itself of the
proposal. And maybe in some cases it should
Kind regards,
Robert.
On Sat, Sep 15, 2018 at 2:51 AM Benjamin Kaduk wrote:
>
Support
On Tue, Oct 30, 2018, 09:22 Hi WG,
>
>
>
> This email begins a two-week poll for BESS working group adoption
> draft-zzhang-bess-mvpn-evpn-aggregation-label-01 [1]
>
>
>
> Please review the draft and post any comments to the BESS working group
> list, stating whether or not you support ad
Hi Linda,
I have one comment to proposed encoding and one overall observation.
*Comment: *
Proposed "EncapsExt sub-TLV" defines as mandatory indication on NAT type.
Possible values are: NAT Type.without NAT; 1:1 static NAT; Full Cone;
Restricted Cone; Port Restricted Cone; or Symmetric.
You ve
Hi Linda,
There are some key differences: Skype and CDN overlay companies don’t have
> any intension to interoperate, but networking needs interoperability.
>
There is no issue about interoperability. Observe that that each endpoint
can today seamlessly be a member of N different SD-WAN orchestra
Hi Jeffrey,
Isn't this just a matter of how you would be implementing "tunneling" ?
For vast majority of decapsulations there is no state as such, but it is
just part of one of normal switching vectors in the router.
Best,
R.
On Wed, Jan 23, 2019, 21:40 Jeffrey (Zhaohui) Zhang The receiver PE
All,
RD is a property of the NLRI not next hop. I am not sure where in this
thread or some spec someone came to the conclusion that next hop field
should contain an RD. RD is not useful there and should never be part of
any next hop field.
Remember RD role is to make prefix unique - that's it - n
not be present at all
as it does not make sense for a given SAFI (ref 5575) and that in turn will
be indicated by zero nh length
Many thx,
R.
On Wed, Jun 26, 2019 at 3:06 PM UTTARO, JAMES wrote:
> *+1*
>
>
>
> *From:* Idr *On Behalf Of * Robert Raszuk
> *Sent:* Wednesday,
Next Hop
> field should match AFI. On the other hand, RFC 4760 says that Next Hop
> Field should match combination of AFI/SAFI. Also, drafts of RFC 4364 and
> RFC 4760 were being developed practically at the same time period.
>
> 26 июня 2019 г., в 16:05, UTTARO, JAMES написал(а):
>
>
> I think it may be helpful for to add
> the above text, and update RFC4364/4659/4760/5549, to eliminate the worries
> about interoperation. is there any worries about interoperation ?
>
>
>
> Thanks
>
> Jingrong
>
>
>
>
>
> *Fro
thop IPv4 the same, and interpret nexthop RD+IPv6 and nexthop
> > IPv6 the same.
> >
> > I think it may be helpful for to
> > add the above text, and update RFC4364/4659/4760/5549, to eliminate
> > the worries about interoperation. is there any worries about
&
partially supported RFC4659.
>
>
>
> Brgds,
>
>
>
>
>
>
>
> *From:* Idr [mailto:idr-boun...@ietf.org] *On Behalf Of *Robert Raszuk
> *Sent:* Thursday, June 27, 2019 12:50
> *To:* Xiejingrong
> *Cc:* softwi...@ietf.org; draft-dawra-bess-srv6-servi...@i
Hey Keyur,
I would like to share my perspective on your comment made at the BESS
yesterday.
What you pointed out that VPN demux should be removed or renewed when we
rewrite bgp next hop is very true in 4364 world or even in EVPN world where
VPN label is of local significance.
But in Srihari's pr
Linda,
SRv6 services is just a general term used here. Imagine one of such
service is L3VPN. VPN label (or pointer to it) is needed to be carried
somewhere in the packet as address space may be overlapping between VPN
customers and simple IP lookup will not be sufficient to determine VRF or
exit i
ere are nodes between Egress and Ingress PEs that
> do look into the VPN label carried by the packets for VRF & IP lookup,
> correct?
>
> I was just confused of the statement about “all nodes between Egress &
> Ingress PE are SR unaware plain IP forwarding nodes”.
>
>
estions you may have in
honest way, but just need to understand what the question really is.
Thx,
R.
On Fri, Oct 4, 2019 at 1:03 AM Gyan Mishra wrote:
>
> Hi Robert
>
> In-line question
>
> Sent from my iPhone
>
> On Oct 3, 2019, at 11:01 AM, Robert Raszuk wrote:
>
>
IMHO the question of SR-MPLS vs SRv6 is wrong as it all depends what are
you trying to accomplish in your network and what services you need to run
on it.
For example some networks need TE some do not.
Some may like to carry L2/L3VPNs some do not.
Some may think about requirements associated wit
Support (as co-author).
Also I am not aware of any undisclosed IPR related to this document.
Thx,
R.
On Fri, Sep 27, 2019 at 1:00 PM Bocci, Matthew (Nokia - GB) <
matthew.bo...@nokia.com> wrote:
> Hello,
>
>
>
> This email begins a two-weeks WG adoption poll for
> draft-dawra-bess-srv6-services
Hi Matthew, Stéphane,
I’m not aware of any non-disclosed IPR.
KInd regards,
Robert.
On Fri, Sep 27, 2019 at 1:00 PM Bocci, Matthew (Nokia - GB) <
matthew.bo...@nokia.com> wrote:
> Hello,
>
>
>
> This email begins a two-weeks WG adoption poll for
> draft-dawra-bess-srv6-services-02 [1] .
>
>
>
>
Hi Linda,
> Overlay, the multipoint to multipoint WAN is an overlay network. If using
IPsec
> Point to Point tunnel, there would be N*(N-1) tunnels, which is too many
to many.
Please observe that any to any encapsulated paths setup in good SDWAN is
day one requirement. And that is not only any sr
n each direction just over those *two* end points. 18 if you
> consider bidirectional traffic”
>
>
>
> Linda
>
>
>
> *From:* Robert Raszuk
> *Sent:* Monday, November 04, 2019 6:54 PM
> *To:* Linda Dunbar
> *Cc:* bess@ietf.org
> *Subject:* Re: [bess] Any protocols s
SA, it is tremendous amount of work.
>
>
>
> Linda
>
>
>
> *From:* Robert Raszuk
> *Sent:* Tuesday, November 05, 2019 3:15 PM
> *To:* Linda Dunbar
> *Cc:* bess@ietf.org
> *Subject:* Re: [bess] Any protocols suitable for Application Flow Based
> Segment
*I do not support this draft in the current form. *
This document instead of improving the original specification makes it
actually worse.
Point 1 -
Original RFC sec. 6.2:
o Network Address of Next Hop = IPv6 address of Next Hop
Proposed text:
o Network Address of Next Hop = VPN-IPv6 address
40 PM wrote:
> Hi Robert,
>
>
>
> Please see some replies inline.
>
>
>
> Brgds,
>
>
>
> *From:* Robert Raszuk
> *Sent:* mercredi 27 novembre 2019 22:18
> *To:* Bocci, Matthew (Nokia - GB)
> *Cc:* bess@ietf.org; bess-cha...@ietf.org
> *Subject:* R
em stand on their
> own merit. That way, if there were consensus, we could save those 8 bytes
> of RD. However, we shouldn’t mix this with the draft revising RFC 5549 to
> reflect the current implementations and deployments.
>
>
>
> Thanks,
>
> Acee
>
>
>
> *Fro
engage in a protracted debate and I don’t believe
> the WG wishes to delay publication of this draft. Your lone objection can
> be noted in the shepherds report.
>
>
>
> Thanks,
> Acee
>
>
>
>
>
> *From: *Robert Raszuk
> *Date: *Monday, December 2, 2019 at
/idr/wiki/Protocol%20implementations%20Reports
Example:
https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-optimal-route-reflection%20implementations
Thx,
R.
On Tue, Dec 3, 2019 at 5:24 PM Acee Lindem (acee) wrote:
> Hi Robert,
>
>
>
> *From: *Robert Raszuk
> *Date: *T
/* replacing IETF mailer with BESS */
Hi Michael,
Clearly you have discovered a bug in first implementation. Second
implementation "other platform" works correctly.
I assume you are doing next hop self on R2. Advertising labels have only
local significance to a box which is listed as next hop in
gt;
>
>
> Otherwise just using any dynamic label will not work.
>
>
>
> Thanks,
>
> --Satya
>
>
>
>
>
> *From: *BESS on behalf of Gyan Mishra <
> hayabusa...@gmail.com>
> *Date: *Thursday, December 12, 2019 at 11:01 AM
> *To:
Support as co-author.
Not aware of undisclosed IPR relevant to this draft.
Thanks!
Robert
On Mon, Jan 6, 2020 at 3:13 PM wrote:
> Hello,
>
>
>
> This email begins a two-weeks WG adoption poll for and
> draft-zzhang-bess-bgp-multicast-controller-02 [1] ..
>
> For information, it’s companio
Hi Gyan,
Similar architecture has been invented and shipped by Contrail team. Now
that project after they got acquired by Juniper has been renamed to
Tungsten Fabric https://tungsten.io/ while Juniper continued to keep the
original project's name and commercial flavor of it. No guarantees of any
p
able
> from that standpoint compare to L3 MLAG bundle XOR Src/Dest/Port hash.
>
> Other big down side is most enterprises have the hypervisor managed by
> server admins but if you run BGP now that ends up shifting to network.
> More complicated.
>
> Kind regards
>
> Gyan
&
Hi Linda,
I think you are mixing data plane and control plane.
In SDWAN data plane is of no issue as you are interconnecting sites in a
given VPN over mesh of secure tunnels.
You are asking how to keep control plane separate between VPN instances.
This is precisely what RFC4364 does already and
28 for VPN has the Label encoded in the NLRI field that is
> to be carried by the data packets. But SDWAN Instance ID is not carried by
> the Data Packets. Is it correct?
>
>
>
> Thank you.
>
> Linda
>
>
>
>
>
>
>
>
>
> *From:* Robert Raszuk
>
th a different name (say SDWAN Target ID). When the
>>SDWAN Target ID is used, the SAFI 128 can be used for routes for the SDWAN
>>instance, with the exception that the label in the NLRI is not the MPLS
>>label carried by the data packets .
>>
>>
>>
>&
*https://tools.ietf.org/html/draft-ietf-bess-evpn-ipvpn-interworking-02
> <https://tools.ietf.org/html/draft-ietf-bess-evpn-ipvpn-interworking-02> *
>
>
>
> *Thanks,*
>
> * Jim Uttaro*
>
>
>
> *From:* Idr *On Behalf Of * Robert Raszuk
> *Sent
Stephane,
Two points ..
1. It is not clear to me that draft-ietf-bess-datacenter-gateway recommends
to use RTC for anything - do they ? If not there is no issue.
2. Also note that RTC can be enabled on a per AF basis hence even if you
use it say for SAFI 128 you do not need to use it for SAFI 1.
Stephane,
Two points ..
1. It is not clear to me that draft-ietf-bess-datacenter-gateway recommends
to use RTC for anything - do they ? If not there is no issue.
2. Also note that RTC can be enabled on a per AF basis hence even if you
use it say for SAFI 128 you do not need to use it for SAFI 1.
4:48 PM wrote:
> Hi Robert,
>
>
>
> Thanks for your feedback.
>
> Please find some comments inline.
>
>
>
> Stephane
>
>
>
>
>
> *From:* Robert Raszuk
> *Sent:* lundi 8 juin 2020 11:55
> *To:* slitkows.i...@gmail.com
> *Cc:* idr@ietf. org
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 two-week
Hi John,
The way I understood this is intending to work in practice is simply to
create IBGP session between GW1 & GW2,
If we have this IBGP session then there are two cases:
* we receive route to X from peer GW so we know peer GW can reach X hence
it is safe to advertise X with both GWs as NHs
Gyan,
It is always helpful to an assessment into right scale.
Yes if you take few flows perhaps even a few big ones may suffer from
polarization. But the feature here is about hashing millions of micro
flows. With that in mind polarization effects are insignificant at
decent operational scale.
I
Hi Arie,
Draft draft-ietf-idr-link-bandwidth talks about advertising towards IBGP.
It does not talk about advertising over EBGP.
While I do support your use case I think it would be much cleaner to just
ask for new ext. community type.
Reason being that as you illustrate you may want to accumul
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 id
I agree with Jorge..
In fact I find the tone of the comment to be very inappropriate:
*> In case of best effort/flex algo we must mandate user to set
corresponding locator as BGP nexthop for srv6 routes.*
*No we MUST not mandate anything to the user. *
*We MUST provide flexibility to address al
ght read?
>
>
>
> Rgds
>
> Shraddha
>
>
>
>
>
> Juniper Business Use Only
>
> *From:* Robert Raszuk
> *Sent:* Tuesday, July 20, 2021 11:17 AM
> *To:* Shraddha Hegde
> *Cc:* Aissaoui, Mustapha (Nokia - CA/Ottawa) ;
> Rabadan, Jorge (Nokia
UTTARO, JAMES wrote:
> *Comments In-Line..*
>
>
>
> *Thanks,*
>
> * Jim Uttaro*
>
>
>
> *From:* spring *On Behalf Of *Shraddha Hegde
> *Sent:* Tuesday, July 20, 2021 5:56 AM
> *To:* Robert Raszuk
> *Cc:* spr...@ietf.org; bess@ietf.org
> *Subject:
IMO we could add to the draft a statement that implementation MUST/SHOULD
support fallback to any available forwarding plane. But I am not sure if
this will not turn out against some implementations which may have problem
with that.
Order of such fallback is a policy/cfg decision.
Likewise before
Support.
Thx,
R.
PS. I am not sure why this poll still is under old mailer address ..
adding BESS :)
On Sun, Oct 19, 2014 at 9:00 PM, Martin Vigoureux
wrote:
> Hello Working Group,
>
> This email starts a two-week poll on adopting
> draft-fang-l3vpn-virtual-pe-05 [1].
>
> Please send comments
Looking at this I am not sure what the problem is ?
If I am not mistaken none of the RFC7024 authors are associated with the
IPR disclosure neither are even listed in the ack section.
Chairs normally ask only authors for IPR statement.
Anyone can patent anything and this is even patent outside o
t has been
even started ? To blindly say yes or no to content of the IPR disclousure
no one posseses any knowledge of ?
r.
On Fri, Oct 24, 2014 at 12:00 AM, Martin Vigoureux <
martin.vigour...@alcatel-lucent.com> wrote:
> Robert
>
> Le 23/10/2014 21:22, Robert Raszuk a écrit :
Hi Thomas,
Are those really two separate documents ? I can't find the former while the
slides @ IDR really talk about the content of the latter :)
Cheers,
R.
On Fri, Nov 14, 2014 at 12:44 AM, Thomas Morin
wrote:
> Hi WG,
>
> A heads up...
>
> These two drafts relate to BESS and thus may be of
RT overlap is a configuration issue not a protocol design issue.
It is easy to avoid it by proper RT assignment for non congruent services.
Cheers,
R.
On Fri, Nov 14, 2014 at 9:06 AM, Haoweiguo wrote:
> Hi Bertrand,
> What's your solution for RT overlap issue or other possible
> issue?Somet
Jim,
And what now RTC has to do with this discussion ???
r.
On Fri, Nov 14, 2014 at 2:51 PM, UTTARO, JAMES wrote:
> IMO there are more important reasons why one does not deploy RTC.
>
> Jim Uttaro
>
> -Original Message-
> From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Mach Chen
y. *There is a precedent (RT-Constrain) that adopted the
> unified RT for all AFI/SAFI that bring many limitation when deploying RTC.*
>
>
>
> Best regards,
>
> Mach”
>
>
>
> *From:* rras...@gmail.com [mailto:rras...@gmail.com] *On Behalf Of *Robert
> Raszuk
> *Sen
Well I agree with Francois & Eric.
To me RFC4659 is an "amendment" to RFC4364 not an "update" or "errata"
I vote to reject.
Cheers,
R.
On Tue, Nov 18, 2014 at 7:10 AM, Francois Le Faucheur (flefauch) <
flefa...@cisco.com> wrote:
> Hi Wes and all,
>
> Based on my (possibly naive or outdated) u
Hi Jose,
Great signature :)
One observations. The draft says:
"When the bit value is 1, the PE is requesting the ability
to send a Pseudowire packet that includes a flow label."
How can PE "request the ability" by setting a bit flag ?
I recommend if you want to keep it you replace the "reque
Hi Wim,
What makes you say that in IPv4 there is no anycast ? All anycase I have
played so far is IPv4 :)
Cheers,
r.
On Sun, Mar 29, 2015 at 11:18 PM, Henderickx, Wim (Wim) <
wim.henderi...@alcatel-lucent.com> wrote:
> We will update the draft to highlight the IPv6 anycast behaviour better as
>
re is anycast at IPv4 level for sure but I am not ware this is
> supported at arp level.
>
> From: , Wim Henderickx
> Date: Monday 30 March 2015 07:38
> To: Robert Raszuk
> Cc: Erik Nordmark, Antoni Przygienda, "bess@ietf.org", Jorge Rabadan
>
> Subject: Re: [bes
Hi Osama,
> This would mean the other service provider will need to establish
> EBGP sessions possibly in thousands which is not practical.
That assertion is not correct.
Option C for route distribution scaling uses route reflection in each
cluster therefor eliminating the need to establish more
s,
>
> Osama
>
>
>
> *From:* rras...@gmail.com [mailto:rras...@gmail.com] *On Behalf Of *Robert
> Raszuk
> *Sent:* Friday, April 10, 2015 3:42 PM
> *To:* Osama Zia
> *Cc:* bess@ietf.org
> *Subject:* Re: [bess] draft-hao-bess-inter-nvo3-vpn
>
>
>
> Hi Osam
;
>
> *From:* rras...@gmail.com [mailto:rras...@gmail.com] *On Behalf Of *Robert
> Raszuk
> *Sent:* Saturday, April 11, 2015 3:03 AM
>
> *To:* Osama Zia
> *Cc:* bess@ietf.org
> *Subject:* Re: [bess] draft-hao-bess-inter-nvo3-vpn
>
>
>
> Osama,
>
>
>
>
t;
>
>
> Regards,
>
> Osama
>
>
>
> *From:* rras...@gmail.com [mailto:rras...@gmail.com] *On Behalf Of *Robert
> Raszuk
> *Sent:* Monday, April 13, 2015 7:42 AM
>
> *To:* Osama Zia
> *Cc:* bess@ietf.org
> *Subject:* Re: [bess] draft-hao-bess-inter-nvo3-
;
>
> Regards,
>
> Osama
>
>
>
>
>
> *From:* rras...@gmail.com [mailto:rras...@gmail.com] *On Behalf Of *Robert
> Raszuk
> *Sent:* Monday, April 13, 2015 8:49 AM
>
> *To:* Osama Zia
> *Cc:* bess@ietf.org
> *Subject:* Re: [bess] draft-hao-bess-inter-nvo3-vpn
case, which is one of
>> the points that Tony mentions below. In the use-case described at the
>> moment there is no anycast and duplicate IP detection is very important. We
>> will add the DC use case in the next rev as suggested by Robert and others.
>> Thanks.
&
would be to mention that
duplicate IPv4 address detection is scoped to the same ARP table (which may
not be the same as same subnet :).
Cheers,
r.
On Thu, Apr 16, 2015 at 12:44 AM, Erik Nordmark wrote:
> On 4/15/15 2:53 PM, Robert Raszuk wrote:
>
>> Erik,
>>
>> Ho
Hi Erik,
Just to clarify .. none of my comments where about dual NIC servers.
Address overload in linux happens on single NIC (unlike in good routers :))
Cheers,
R.
On Thu, Apr 16, 2015 at 10:35 PM, Erik Nordmark wrote:
> On 4/15/15 11:25 PM, Robert Raszuk wrote:
>
>> Ok I think t
Co-author - I am not aware of any relevant IPR.
Robert Raszuk
On Tuesday, May 19, 2015, Martin Vigoureux <
martin.vigour...@alcatel-lucent.com> wrote:
> Hello
>
> this email starts a Working Group Last Call on
> http://tools.ietf.org/html/draft-ietf-l3vpn-virtual-subnet
>
Hi Duleep,
Please consider RFC 7311 and provide feedback why you think it is not
sufficient for your objective.
https://tools.ietf.org/html/rfc7311
Best,
R.
On Sun, Jul 26, 2015 at 9:15 PM, Duleep Thilakarathne
wrote:
> Hi,
>
>
>
> I would like to suggest to consider geographic distance whe
;
>
> Regards
>
> Duleept
>
>
>
>
>
>
>
> *From:* UTTARO, JAMES [mailto:ju1...@att.com]
> *Sent:* Friday, August 7, 2015 4:09 PM
> *To:* Duleep Thilakarathne; 'Robert Raszuk'
>
> *Cc:* 'bess@ietf.org'
> *Subject:* Re: [bess] BGP route
rment to synchronize
> different administrative domains since router itself automatically
> calculate value and add when routes advertised similar to AS PATH addition
> operation.
>
>
>
>
>
> - Reply message -
> From: "Richard Li"
> To: "Duleep
Hi Eric,
I have read your proposed draft as well as watched this thread with a bit
of an interest.
To me the best compromise - which is to agree with Bruno's points as well
as address your intentions is simply to request new SAFI for 3107bis.
>From the draft you are really not updating 3107 base
cee
>
> From: Idr on behalf of Robert Raszuk <
> rob...@raszuk.net>
> Date: Friday, April 1, 2016 at 4:23 PM
> To: Eric C Rosen
> Cc: Bruno Decraene , "m...@ietf.org" <
> m...@ietf.org>, BESS , IDR List
> Subject: Re: [Idr] [bess] draft-rosen-mpls-rfc
Eric,
If as it turns out if the primary motivation for 3107bis is to distribute
label stack for segment routing that I do not think per destination prefix
is a sufficient granularity.
How with 3107(bis) you can match on the src of the packets ?
How you can match on the more granular information
Hi Eric,
While adoption call is sort of encouragement for further input before I
respond to Loa's mail I would like to get one additional answer from
3107bis authors and WGs members.
Those who spend years in mpls deployment know quite well that the biggest
issue with today's 3107 deployment is la
IP and MPLS
> topologies for the same set of prefixes. Then the WGs can evaluate the
> requirement and proposed solution independent of RFC 3107 BIS.
>
> Thanks,
> Acee
>
> From: mpls on behalf of Robert Raszuk <
> rob...@raszuk.net>
> Date: Wednesday, August 31, 20
Acee,
> The current capability is specific to support of multiple labels - not
> your parochial view on the interaction between SAFIs.
>
Since "bis" specification obsoletes the base document I was under the
assumption that new capability will also obsolete the current used.
It is no longer "
Hi,
Using BGP as control plane for arbitrary service topology creation is by
all means a good thing.
That is why in 2013 Keyur and myself have posted proposal describing it to
IETF in form of BGP Vector Routing:
https://tools.ietf.org/html/draft-patel-raszuk-bgp-vector-routing-00
I leave it to
Hi Warren,
This is clearly not unanimous/ not everyone is happy, but (in my view)
> there is *rough* consensus for this to progress.
>
The group of users of BGP which this update impacts the most are members
of BESS WG (cc-ed) and not IDR WG due to the fact that this proposal
applies to all AFI/
Dear IDR and BESS WGs members,
As you have either participated or seen from other email exchanges there is
ongoing communication about change in eBGP specification to mandate by
default use of policy in order to make all receive routes ineligible for
best path and to suppress sending them to your
Sorry one typo:
s/to make all receive routes ineligible for best path/to make all receive
routes eligible for best path/
Apologies,
r.
On Sat, May 6, 2017 at 7:10 PM, Robert Raszuk wrote:
> Dear IDR and BESS WGs members,
>
> As you have either participated or seen from other email
Hi Warren,
In the draft you have reviewed EVPN term is use interchangeably with term
[RFC7432] which in turn is also already listed and defined in the Normative
References section (2nd from the top).
Personally if you assume that the reader of this document is not familiar
with EVPN I would also
> is there any reason for the authirs *not* to make things easier for your
> readers by saying: "
> This document describes how EVPN [RFC7432] can be ..."?
>
That clearly is a good edit suggestion for all alone occurrences of
[RFC7432] in the draft.
That sounds like a fine idea - perhaps the
Hey Martin,
I think your link is a bit outdated ...
Instead it may be easier to follow this one:
https://datatracker.ietf.org/meeting/100/materials/agenda-100-bess/
Thx,
Robert.
On Mon, Nov 6, 2017 at 12:50 PM, Martin Vigoureux <
martin.vigour...@nokia.com> wrote:
> Presenters, WG,
>
> we ha
Hi Eric,
A lot of your comments are an indication that you treat SID to be IPv6
address fully responsible for demux to proper VRF or CE. This was never the
intention.
Imagine egress PE having /64 loopback. Then you have remaining 64 bits to
put there a 20 bit VPN label (as we know it :) and even
Ok let's start all over :)
This suggests that an IPv6 address has to be assigned to each VRF (for
> per-VRF "labeling"), or even to each CE (for per-CE labeling).
>
No one suggests that. VPN SID is not IPv6 address .. it is part of v6 SID
which when appended to IPv6 prefix forms a comp
or per CE.
Cheers,
R.
On Tue, Jan 2, 2018 at 3:10 PM, Eric C Rosen wrote:
> On 12/28/2017 1:55 PM, Robert Raszuk wrote:
>
> Ok let's start all over :)
>
>
> From the draft:
>
> The SRv6 VPN SID MAY be routable within the AS of the egress-PE and
> serves
Hi Adrian,
> That proxy may be a bump in the wire between the SFF and SF
I am not so sure about that ... If this would be just "bump in the wire"
you would have zero guarantees that all packets which need to go via given
function will actually hit that bump - so this is far from a reliable
networ
ol
> what goes where. But that problem exists to some extent for any remotely
> attached SF. For that reason (among others) I would implement the proxy as
> part of the SFF.
>
>
>
> Cheers,
>
> Adrian
>
>
>
> *From:* Henderickx, Wim (Nokia - BE/Antwerp) [mailto
Jim & Avinash,
Please let's observe that Adrian removed any references to Segment Routing.
What this means that the current proposal is based on vanilla MPLS labels
which by base MPLS architecture have **local significance*. *
You can't assume that out of the sudden label has domain wide or globa
Hello Stephane,
I read the draft with deep interest. In my opinion I completely have
opposite view to yours - "niche use case" - quite contrary connecting
customer sites over open infrastructure have already started to happen in
large scale globally.
It is not about adding IPSec tunnel here and t
e to have: most of
> customers do not need this.
>
>
>
>
>
> Brgds,
>
>
>
> Stephane
>
>
>
>
>
>
>
> *From:* rras...@gmail.com [mailto:rras...@gmail.com] *On Behalf Of *Robert
> Raszuk
> *Sent:* Thursday, June 14, 2018 11:13
> *To:* LITK
Hi Warren,
Thank you for your Discuss. But before we start discussing it perhaps it
would be good to align on what this document really defines as I am sensing
from your description there can be some disconnect (modulo some text may be
indeed misleading in the draft).
You said:
> However, we all
y this if that is what is required.
>
>
>
> Thanks
>
>
>
> Andrew
>
>
>
>
>
> *From:* iesg *On Behalf Of * Robert Raszuk
> *Sent:* Saturday, February 12, 2022 8:26 PM
> *To:* Warren Kumari
> *Cc:* Bocci, Matthew (Nokia - GB) ;
> draft-ietf-bess-srv
Gyan,
Section 5.3 and 5.4 cover GRT option and 5.3 using RFC 5549 next hop
> encoding. In this case using GRT transport underlay layer now carry’s the
> customer routes and that is what Warren and Andrew concern is as far as BGP
> leaks.
>
I would have the same concern so would VPN customers. No
Gyan,
MPLS is never sent in SAFI 1.
Thx,
R.
On Sun, Feb 13, 2022 at 5:47 AM Gyan Mishra wrote:
> Hi Robert
>
> On Sat, Feb 12, 2022 at 4:23 PM Robert Raszuk wrote:
>
>> Gyan,
>>
>> Section 5.3 and 5.4 cover GRT option and 5.3 using RFC 5549 next hop
>>
his is not providing
> equal functionality for MPLS – this is extending MPLS style functionality
> into SAFI 1, which, if my reading of Warren’s discuss is accurate, is
> pretty much the essence of the problem.
>
>
>
> Thanks
>
>
>
> Andrew
>
>
>
> *Fro
Hi John,
As you have quoted my note in point #4 I feel that I need to comment on it.
So yes original discussions and major contributions of this work were
focusing on VPN use case and I admit when carefully re- reading it to find
some text there beyond VPN use case.
So we discussed it among co-a
t;>
>>>The MP_REACH_NLRI is encoded with:
>>>
>>>
>>>
>>>* AFI = 1
>>>
>>>
>>>
>>>* SAFI = 1
>>>
>>>
>>>
>>>* Length of Next Hop Address field = 16 (or 32)
>&
t; you are receiving at least claims to be from within the limited domain.
>
> This has nothing to do with sr-policy.
>
> Yours,
> Joel
>
> On 2/17/2022 11:06 AM, Robert Raszuk wrote:
> > Joel,
> >
> > But we are back to per src policy then right ?
> >
>
1 - 100 of 116 matches
Mail list logo
