>; bess@ietf.org<mailto:bess@ietf.org>;
s...@ietf.org<mailto:s...@ietf.org>
Subject: Re: [bess] [sfc] [mpls] Progress with draft-farrel-mpls-sfc
Re-,
This is really a matter of taste.
Jim, whatever scheme we use for identifying service chains, there are
requirements/constraint
Raszuk <rob...@raszuk.net>; Adrian Farrel
<adr...@olddog.co.uk>
Cc: mpls <m...@ietf.org>; SPRING WG List <spr...@ietf.org>; bess@ietf.org;
s...@ietf.org
Subject: Re: [bess] [sfc] [mpls] Progress with draft-farrel-mpls-sfc
Re-,
This is really a matter of taste.
Jim, whatever scheme w
; bess@ietf.org; s...@ietf.org
Subject: Re: [bess] [sfc] [mpls] Progress with draft-farrel-mpls-sfc
I echo robert’s comment, while I agree that draft-ietf-bess-service-chaining is
useful work, we should not define yet another data-plane for it.
From: <rras...@gmail.com<mailto:rras...@gmail.c
. I’m wrong?
Cheers,
Med
De : UTTARO, JAMES [mailto:ju1...@att.com]
Envoyé : lundi 19 mars 2018 14:10
À : BOUCADAIR Mohamed IMT/OLN; Henderickx, Wim (Nokia - BE/Antwerp); Robert
Raszuk; Adrian Farrel
Cc : mpls; SPRING WG List; s...@ietf.org; bess@ietf.org
Objet : RE: [sfc] [mpls] Progress with draft
og.co.uk>
Cc: mpls <m...@ietf.org>; SPRING WG List <spr...@ietf.org>; s...@ietf.org;
bess@ietf.org
Subject: RE: [sfc] [mpls] Progress with draft-farrel-mpls-sfc
Re-,
I’m afraid that you cannot ‘simply’ re-use MPLS for chaining purposes without
any code upgrade.
NSH does provi
- BE/Antwerp); Robert
Raszuk; Adrian Farrel
Cc : mpls; SPRING WG List; s...@ietf.org; bess@ietf.org
Objet : RE: [sfc] [mpls] Progress with draft-farrel-mpls-sfc
Med,
We run an MPLS network so there is no NSH deployed anywhere. I
want to create simple chains that we can make available
og.co.uk>
Cc: mpls <m...@ietf.org>; SPRING WG List <spr...@ietf.org>; s...@ietf.org;
bess@ietf.org
Subject: RE: [sfc] [mpls] Progress with draft-farrel-mpls-sfc
Hi Jim,
Perhaps I missed your point, but I’m not asking to disallow whatever transport
encapsulation scheme deployed in a networ
personally favor re-using NSH.
Cheers,
Med
De : UTTARO, JAMES [mailto:ju1...@att.com]
Envoyé : lundi 19 mars 2018 12:33
À : BOUCADAIR Mohamed IMT/OLN; Henderickx, Wim (Nokia - BE/Antwerp); Robert
Raszuk; Adrian Farrel
Cc : mpls; SPRING WG List; s...@ietf.org; bess@ietf.org
Objet : RE: [sfc] [mpls
ist <spr...@ietf.org>; s...@ietf.org;
bess@ietf.org
Subject: Re: [sfc] [mpls] Progress with draft-farrel-mpls-sfc
Hi all,
Wim has a point here.
For all these proposals, a new behavior is needed to be followed by SFC-aware
nodes. What differs is the channel used to signal a chain and to s
Hi all,
Wim has a point here.
For all these proposals, a new behavior is needed to be followed by SFC-aware
nodes. What differs is the channel used to signal a chain and to supply
additional data for SFC purposes.
Leveraging on existing code/capabilities is good for a vendor/implementer,
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
lto:wim.henderi...@nokia.com]
Sent: 18 March 2018 07:26
To: Robert Raszuk; Adrian Farrel
Cc: mpls; SPRING WG List; s...@ietf.org; bess@ietf.org
Subject: Re: [sfc] [mpls] Progress with draft-farrel-mpls-sfc
Indeed, this is exactly my point. If you want an interim solution you want to
use wh
etf.org>, "bess@ietf.org" <bess@ietf.org>
Subject: Re: [sfc] [mpls] Progress with draft-farrel-mpls-sfc
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 h
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
14 matches
Mail list logo
