protocols which run over TCP or UDP to sort of bless them for
running on such new transport then I think this is not achievable in our
short life time.
Best,
R.
On Tue, Feb 6, 2024 at 9:30 PM John Scudder wrote:
> > On Feb 6, 2024, at 2:48 PM, Robert Raszuk wrote:
> >
> > I have b
om it.
On Tue, Feb 6, 2024 at 8:39 PM John Scudder wrote:
> Hi Robert,
>
> > On Feb 6, 2024, at 1:49 PM, Robert Raszuk wrote:
> >
> > Hi John,
> >
> > https://datatracker.ietf.org/doc/draft-wirtgen-bgp-tls/
>
> See my earlier reply to Linda.
>
Hi John,
https://datatracker.ietf.org/doc/draft-wirtgen-bgp-tls/
And for DTLS ... isn't this simply TCP over DTLS which works just fine ?
Many thx,
R.
On Tue, Feb 6, 2024 at 4:38 PM John Scudder wrote:
> I haven’t done a full review of this document, but I did notice that Roman
> Danyliw
All,
Looking at all the drafts mentioned I do think there are actually two
different scenarios being considered and perhaps it is actually beneficial
to treat them separately.
Original draft allowed to signal link bw in situations where you peer from
different boxes. Path hiding is not an issue.
Hi,
> I agree that the use case presented should be addressed, but I don't
think the document is ready for WGLC,
Indeed.
In fact it is clear by now that
https://datatracker.ietf.org/doc/html/draft-ietf-idr-link-bandwidth-07
needs to be rewritten to accommodate both 4 octet ASNs (instead of
succinctly (in hopefully a short draft) and the rest is all simply
> informational material that can be clubbed together to perhaps make more
> efficient use of reviewers time.
>
> Thanks,
> Ketan
>
> [1]
> https://mailarchive.ietf.org/arch/msg/bess/Wj-Y_m-t7C0bZ90NM-h
Hi Ketan,
If you are referring to interconnecting v4 only sites draft I have number
of comments:
* The draft is not needed at all
* we can seamlessly interconnect v4 sites over v6 core using v4 mapped v6
addresses
* Zero control plane change is required/needed
* number of vendors are shipping
Hey Igor,
> [IM] Agree. I understood it well before I started drafting. My goal was as
> less as possible touch to VPN and other mechanics. BGP NH tracking allows
> us to implement changes (update boxes) only for MH PEs.
>
Some deployments have up to 5000 CEs hanging off the PEs. And those
Hi Igor,
Thank you for sharing your draft. I am cc-ing IDR as you are proposing
modifications to core BGP.
What you are proposing IMO will work fine and in fact I recall we had
number of discussions on this in the past some of which resulted in
definition of Edge_Discriminator Attribute as
ay a P node role.
Many thx,
R.
On Sun, Jul 17, 2022 at 12:10 PM Dhananjaya Rao (dhrao)
wrote:
> Hi Robert,
>
>
>
> Thank you for the rapid review and insightful comments, as usual.
>
>
>
> Please see inline (DR##)
>
>
>
> *From: *Robert Raszuk
> *Date: *
Hi,
It also needs to be observed that
draft-ietf-bess-bgp-multicast-controller has a broader scope and also
covers mLDP functionality what may be extremely useful for networks which
are not green field and would like to transition from current to new
multicast trees.
Having solution in IDR which
Dear Yao,
The issue is not related to support or no support of a new feature
although that is also not well addressed in current BGP-4 specification.
The question is about coexistence of multiple transports and
service encoding for the same application.
I have a separate proposal on this, but
Hi John,
You have highlighted below a very important point. It was discussed among
co-authors, but perhaps not sufficiently during the BESS process as the
issue is really not a BESS WG problem.
In BGP protocol any new service deployment using existing AFI/SAFI is not
easy. Especially when you
Hi John,
Question: SAFI 128 is called “MPLS-labeled VPN address” in the IANA SAFI
> registry. Shouldn’t this be renamed? I mean, I guess it should have been
> renamed as of RFC 8365, but better late than never. I’m not sure quite what
> the name should become, but “MPLS-labeled” is manifestly
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 ?
> >
> >
is encoded with:
>>>
>>>
>>>
>>>* AFI = 1
>>>
>>>
>>>
>>>* SAFI = 1
>>>
>>>
>>>
>>>* Length of Next Hop Address field = 16 (or 32)
>>>
>>>
>>>
>&g
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
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
>
>
>
> *From:* Robert
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
>>
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.
s 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-srv6-ser
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
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
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:
ead?
>
>
>
> 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 - US/
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
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
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
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.
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
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
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 ; BES
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
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
*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
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 .
>>
>>
>>
>&
AFI 128 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
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
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 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
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
/* 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
/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
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
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
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:* Re: [b
*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
ec 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
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
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
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] .
>
>
>
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
>
ns 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:
>
> Hi L
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”.
>
>
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
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
t; 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..
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
&
gt;
>
>
> 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
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 написал(а):
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,
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 -
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
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
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
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
ocument 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:
> On Wed, Sep 1
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
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
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
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
know/control
> 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) [ma
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
or per CE.
Cheers,
R.
On Tue, Jan 2, 2018 at 3:10 PM, Eric C Rosen <ero...@juniper.net> 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 e
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
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 <rob...@raszuk.net> wrote:
> Dear IDR and BESS WGs members,
>
> As you have either participat
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
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
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
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
for having separate 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 <mpls-boun...@ietf.org> on behalf of Robert Raszuk <
> rob...@ras
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
>
> Thanks,
> Acee
>
> From: Idr <idr-boun...@ietf.org> on behalf of Robert Raszuk <
> rob...@raszuk.net>
> Date: Friday, April 1, 2016 at 4:23 PM
> To: Eric C Rosen <ero...@juniper.net>
> Cc: Bruno Decraene <bruno.decra...@orange.com>, "m...@i
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
domains since router itself automatically
calculate value and add when routes advertised similar to AS PATH addition
operation.
- Reply message -
From: Richard Li renwei...@huawei.com
To: Duleep Thilakarathne dule...@mobitel.lk, UTTARO, JAMES
ju1...@att.com, 'Robert Raszuk' rob
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 dule...@mobitel.lk
wrote:
Hi,
I would like to suggest to consider
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 nordm...@acm.org wrote:
On 4/15/15 2:53 PM, Robert Raszuk wrote:
Erik,
How about /32 IPv4
for sure but I am not ware this is
supported at arp level.
From: Henderickx, Wim Henderickx
Date: Monday 30 March 2015 07:38
To: Robert Raszuk
Cc: Erik Nordmark, Antoni Przygienda, bess@ietf.org, Jorge Rabadan
Subject: Re: [bess] ARP ND draft
At interface level you get dad in most stacks
88 matches
Mail list logo
