Med,
When I say simply, I am speaking as an operator. The
operations, systems, tools, institutional knowledge etc… in this space is
around MPLS. There is a simpler path to creating simple chains by using MPLS
instead of introducing a new encap.
Thanks,
Jim Uttaro
From: [email protected] [mailto:[email protected]]
Sent: Monday, March 19, 2018 10:03 AM
To: UTTARO, JAMES <[email protected]>; Henderickx, Wim (Nokia - BE/Antwerp)
<[email protected]>; Robert Raszuk <[email protected]>; Adrian Farrel
<[email protected]>
Cc: mpls <[email protected]>; SPRING WG List <[email protected]>; [email protected];
[email protected]
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 provide the simple functionality you need; that is the information to
identify a chain + avoid infinite loops. This is known as: MD Type 0x2 with
length is 0x2.
Of course you can encode that information using another channel, but still code
change is needed.
Please note that NSH is not at the same level as “GENEVE, VXLAN”.
Cheers,
Med
De : UTTARO, JAMES [mailto:[email protected]]
Envoyé : lundi 19 mars 2018 13:48
À : BOUCADAIR Mohamed IMT/OLN; Henderickx, Wim (Nokia - BE/Antwerp); Robert
Raszuk; Adrian Farrel
Cc : mpls; SPRING WG List; [email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>
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 to our WAN customers
and I want to keep it simple from a technology and operations POV.. At this
point I do not see the need to introduce NSH for what we need to do. I can
simply re-use MPLS.
Not sure why NSH is the winner here there are folks who advocate for GENEVE,
NSH, VXLAN etc… If IETF is pushing for one encap than it would be helpful to
define the set of requirements/criteria and compare the encaps.
Thanks,
Jim Uttaro
From: [email protected]<mailto:[email protected]>
[mailto:[email protected]]
Sent: Monday, March 19, 2018 9:22 AM
To: UTTARO, JAMES <[email protected]<mailto:[email protected]>>; Henderickx, Wim
(Nokia - BE/Antwerp)
<[email protected]<mailto:[email protected]>>; Robert Raszuk
<[email protected]<mailto:[email protected]>>; Adrian Farrel
<[email protected]<mailto:[email protected]>>
Cc: mpls <[email protected]<mailto:[email protected]>>; SPRING WG List
<[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>
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 network for SFC purposes.
What I’m saying is:
* the IETF has defined a generic SFC architecture and went with a
transport-agnostic approach that can be deployed in conjunction with one’s
favorite transport encapsulation protocol.
* Having a transport-agnostic approach get us away from redundant solutions to
solve the same problem, redundant codes, etc.
* If we allow to mimic NSH in MPLS, there is no reason to do this for MPLS only.
* Instead of mimic NSH, I would personally favor re-using NSH.
Cheers,
Med
De : UTTARO, JAMES [mailto:[email protected]]
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; [email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>
Objet : RE: [sfc] [mpls] Progress with draft-farrel-mpls-sfc
Where I get a little lost in this discussion is assuming that there must be one
encap for SFC chains.. IMO SFC should define encap agnostic behaviors, NSH is
an encap that has tons of functionality but if a simple chain is needed why is
it that an existing encap should be disallowed by the IETF?? I want to simplify
the network, when I say network it is all of the plumbing to realize a service
for a customer including, WAN, MAN, DC etc.… From an OpS POV having a single
encap across an integrated solution is quite attractive.
Thanks,
Jim Uttaro
From: sfc [mailto:[email protected]] On Behalf Of
[email protected]<mailto:[email protected]>
Sent: Monday, March 19, 2018 5:52 AM
To: Henderickx, Wim (Nokia - BE/Antwerp)
<[email protected]<mailto:[email protected]>>; Robert Raszuk
<[email protected]<mailto:[email protected]>>; Adrian Farrel
<[email protected]<mailto:[email protected]>>
Cc: mpls <[email protected]<mailto:[email protected]>>; SPRING WG List
<[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>
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 supply
additional data for SFC purposes.
Leveraging on existing code/capabilities is good for a vendor/implementer, but
the risk is that a given solution will need to support all/many of these
flavors. Which is not optimal.
The IETF has already a consensus on a transport-agnostic solution. If we open
the door for MPLS, we need to open it also for IPv6 EH and so on. Are we OK to
go that way? If yes, what is the NEW problem are we trying to solve?
Cheers,
Med
De : sfc [mailto:[email protected]] De la part de Henderickx, Wim (Nokia -
BE/Antwerp)
Envoyé : dimanche 18 mars 2018 07:26
À : Robert Raszuk; Adrian Farrel
Cc : mpls; SPRING WG List; [email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>
Objet : 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 what we have and draft-ietf-bess-service-chaining-04 is an example of how
you can use the existing data-plane for service chaining. draft-farrel-mpls-sfc
requires an implementation change in the data-plane, whether we like it or not
and an upgrade is required even in brownfield deployments. So, you better go
directly to the final solution defined in IETF SFC WG. If we standardize
draft-farrel-mpls-sfc we end up supporting both forever.
From: <[email protected]<mailto:[email protected]>> on behalf of Robert Raszuk
<[email protected]<mailto:[email protected]>>
Date: Saturday, 17 March 2018 at 19:13
To: Adrian Farrel <[email protected]<mailto:[email protected]>>
Cc: "Henderickx, Wim (Nokia - BE/Antwerp)"
<[email protected]<mailto:[email protected]>>, mpls
<[email protected]<mailto:[email protected]>>, SPRING WG List
<[email protected]<mailto:[email protected]>>,
"[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>,
"[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>
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 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 network service.
There must be associated control plane component attracting traffic to such
bump.
That mechanism with basic MPLS (where labels by based MPLS architecture are of
local significance) is available with L3VPN extensions as already progressing
in BESS (draft-ietf-bess-service-chaining-04) so why not use this for as you
state "interim" ?
No one really addressed that question yet and I think it is a critical one to
make any further judgement as to the future of this individual submission.
Cheers,
R.
On Sat, Mar 17, 2018 at 6:46 PM, Adrian Farrel
<[email protected]<mailto:[email protected]>> wrote:
Hi Wim,
Thanks for reading the draft so carefully.
> Adrian, on replacement of NSH. You will have to change the SF with this
> proposal
> in Non proxy case so this proposal does not solve a brownfield case. Which
> SF(s)
> support MPLS?
This is not about "replacing" the NSH. As you'll see from point 2, below, this
is about providing an interim / migration technology.
Clearly (and I think you agree) in the case where an SF is not SFC-aware, a
proxy must be used. That proxy may be a bump in the wire between the SFF and
SF, a module of the SFF, or a module of the SF. In the case of PNFs, only the
first two options are available. In the case of a VNF, all three options exist.
Now, let us recall where we are starting from. There are PNFs and there are
VNFs built to look like PNFs. These SFs do not support MPLS or NSH.
Similarly, there are routers that do not support the NSH.
Now, of course, we would all love to sell major upgrades so that every
component of the network is SFC-aware. But we would also like to start
deploying SFC into existing network infrastructure.
So your question misses the point. The question to ask is which brownfield
routers and SFs support NSH?
Cheers,
Adrian
_______________________________________________
BESS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bess
