Hi,
Thank you for your comments.
As you mentioned, cloning is too much for only withdraw_flag.
I also believe adding paramter to notify withdraw and other information in the
future
is more suitable than cloning.
I applied your patch and confirmed that withdraw flag can be passed to my
applicati
On Fri, 27 Jun 2014 11:37:14 +0900
Hiroaki KAWAI wrote:
> OpenFlow spec describes "DSCP values that do not encode a drop
> precedence are not modified".
>
> Diffserv Assured Forwarding described in rfc2597(+rfc3260) has
> DSCP values which encodes "drop precedence".
>
> I think we'd better test
On Sun, 29 Jun 2014 20:55:42 +0900
FUJITA Tomonori wrote:
> The current code calls getpeername() and getsockname() at lots of
> places. The formats of the return values of getpeername() and
> getsockname() are different between ipv4 and v6. So the code became
> messy.
>
> Calling getpeername() a
Hi,
(2014/06/30 3:04), Digambar Patil wrote:
> Hi,
>
> Thanks for your reply.
>
> Yes I am following all the mails, as suggested I am looking at the given
> link & BGP & reading the blueprint also. I'll start contribution on the
> blueprints related to the RYU,
>
> RYU - I am reading all the st
Hi,
Thanks for your reply.
Yes I am following all the mails, as suggested I am looking at the given
link & BGP & reading the blueprint also. I'll start contribution on the
blueprints related to the RYU,
RYU - I am reading all the stuff related to the RYU, I am following RYU web
site http://osrg
On Wed, 25 Jun 2014 12:50:36 +
Zhonggen Sun wrote:
> As I understand about SDN, the controller will instruct the switches
> using FLOOD method to find the destination. Later, two hosts can
> directly communicate with each other after OpenFlow table
> established. However, the test result is
On Thu, 26 Jun 2014 18:19:41 +0900
Hiroshi Yokoi wrote:
> Set is_withdraw flag to True to notify _best_path_change_handler in BGPSpeaker
> that best path is lost.
>
> Signed-off-by: Hiroshi Yokoi
> ---
> ryu/services/protocols/bgp/info_base/ipv4.py | 2 +-
> 1 file changed, 1 insertion(+), 1 d
Hi,
On Sun, 29 Jun 2014 17:58:30 +0500
Zubair Hafeez wrote:
> Does Ryu controller have DHCP Server implementation or API. Through
> which the controller can assign Ip address dynamically to hosts on
> Open Flow enable switch,
Unfortunately, no.
Hello,
Does Ryu controller have DHCP Server implementation or API. Through which the
controller can assign Ip address dynamically to hosts on Open Flow enable
switch,
Regards
Zubair. --
Hi, please keep the mailing list in CC.
On Sun, 29 Jun 2014 14:38:26 +0200
yashas bharadwaj wrote:
> Yes. I would like to know links between switches.
Then, you need topology discovery feature:
https://github.com/osrg/ryu/tree/master/ryu/topology
You can find an example using the above featur
On Mon, 23 Jun 2014 19:31:09 +0300
Eugene Nuribekov wrote:
> Hi all!
>
> I'd like to add several additional match fields to protocol v1.3.
>
> How to do it in right way?
> In general I see that I need:
>
> Add EXPERIMENTER_ID in ofproto_common.py
> Make copy of ofproto_v1_3.py and add
Hi,
On Wed, 25 Jun 2014 12:52:39 +0200
"Yashas V Bharadwaj" wrote:
> I am currently working on a project to implement multicast using SDN. As
> part of the module I am required to identify the immediate neighbours of a
> switch.
You mean that you want to know the links between switches, right?
Hi,
On Wed, 25 Jun 2014 21:39:43 -0700
Srini Seetharaman wrote:
> From 086bf44986ce82e9afbf1504c0a0c76bfbb0fd5a Mon Sep 17 00:00:00 2001
> From: Srini Seetharaman
> Date: Wed, 25 Jun 2014 21:35:13 -0700
> Subject: [PATCH] Updating packet_in handler in simple_switch and
> simple_switch_13 to ig
On Wed, 25 Jun 2014 21:28:00 -0700
Srini Seetharaman wrote:
> From 99b2596d41a04c3be3d858226658f7418162c03a Mon Sep 17 00:00:00 2001
> From: Srini Seetharaman
> Date: Wed, 25 Jun 2014 21:24:41 -0700
> Subject: [PATCH] Initializing the variable 's' so that the get_desc_stats()
> call does not ca
Hey,
On Wed, 25 Jun 2014 11:49:42 +0200
Jaume Devesa wrote:
>> > 1. neighbor_add(*address*, *remote_as*, *enable_ipv4=True*,
>> > *enable_vpnv4=False*, *enable_vpnv6=False*) does not allow to set
>> next-hop
>> > value, it uses the machine's ip by default. It would be good to specify
>> as
>> >
Signed-off-by: FUJITA Tomonori
---
ryu/lib/packet/bgp.py | 15 ---
ryu/tests/unit/packet/test_bgp.py | 4 ++--
2 files changed, 14 insertions(+), 5 deletions(-)
diff --git a/ryu/lib/packet/bgp.py b/ryu/lib/packet/bgp.py
index 67ae58f..55bac82 100644
--- a/ryu/lib/packet/
neighbor_add method takes 'next_hop' parameter. If not specified, like
before, host's ip connected to the neighbor is used as a next hop.
Signed-off-by: FUJITA Tomonori
---
ryu/services/protocols/bgp/bgpspeaker.py | 7 ++-
ryu/services/protocols/bgp/peer.py | 5 -
ryu
For now, only Linux is supported.
Signed-off-by: FUJITA Tomonori
---
ryu/services/protocols/bgp/base.py | 33 --
ryu/services/protocols/bgp/bgpspeaker.py | 7 +-
ryu/services/protocols/bgp/peer.py | 4 +++-
ryu/services/protocols/bgp/rt
You can advertize IPv6 addresses to IPv6 neighbors.
Signed-off-by: FUJITA Tomonori
---
ryu/services/protocols/bgp/api/rtconf.py | 4 +-
ryu/services/protocols/bgp/base.py | 1 +
ryu/services/protocols/bgp/bgpspeaker.py | 19 -
.../protocols/bgp/core_mana
The current code calls getpeername() and getsockname() at lots of
places. The formats of the return values of getpeername() and
getsockname() are different between ipv4 and v6. So the code became
messy.
Calling getpeername() and getsockname() at one place and caching the
results is ideal. But that
20 matches
Mail list logo
