Re: [bess] [sfc] [mpls] Progress with draft-farrel-mpls-sfc

[Robert Raszuk]

Adrian,

> draft-farrel-mpls-sfc provides another transition tool on the migration
to RFC 8300.

Very honestly to me it looks like a road block to faster adoption of NSH
not as help to migrate to RFC 8300 in any way.

> It allows SFFs to be built as a minor mod to existing routers before
there is forwarding plane support for the NSH.

I don't agree with that. "MPLS support" in today's equipment is basic three
label operations IMPOSE, POP & SWAP. I don't see how hardware which can
support those three mechanisms can effectively play any role in what one
would expect from NSH alternative.

And as I mentioned before there is no such a thing like MPLS *only*
networks. One company tried to build MPLS only (without IP forwarding)
router but they dropped that plan. So basic IP can carry NSH front ended
packet to whichever device can process NSH headers.

Adding equivalent processing of now both NSH and MPLS headers (far from
basic pop,swap, impose) operations does not seems like a useful standards
and technology investment at this point.

Best,
Robert.







On Sun, Mar 18, 2018 at 11:10 AM, Adrian Farrel  wrote:

> Wim and Robert,
>
>
>
> [Dropping SPRING at this point as (as previously discussed) we have taken
> / are taking SR out of this document]
>
>
>
> I think that draft-ietf-bess-service-chaining is really important work:
> it expresses a technique that is implemented and shipping.
>
>
>
> On the other hand, this approach is not fully consistent with RFC 7665.
>
>
>
> But it does describe an actual SFC technology. Whether it remains in the
> field or is a migration technology only time (and operators) will tell.
>
>
>
> Now, if we want to support RFC 7665 and RFC 8300 and use a control plane
> to discover the SFFs and to which SFs they provide access and to install
> "forwarding state" for SFPs, then we also have draft-ietf-bess-nsh-bgp-
> control-plane.
>
>
>
> That draft was originally written with RFC 8300 in mind, but with the
> addition of one sub-TLV to indicate the encoding, it also supports draft-
> farrel-mpls-sfc. That should not be a surprise as draft-farrel-mpls-sfc
> attempts to model RFC 8300 as much as possible.
>
>
>
> And that brings us back to "Where do we end up, what transition tools
> should we have, and how many steps to transition are there?"
>
>
>
> draft-farrel-mpls-sfc provides another transition tool on the migration
> to RFC 8300. It allows SFFs to be built as a minor mod to existing routers
> before there is forwarding plane support for the NSH.
>
>
>
> But I want to reiterate that the discussion of wat encoding the SF
> supports is a red herring (certainly in the context of RFC 7665). An SF is
> either "SFC-aware" or not [RFC 7665 fig. 3], that is, it either can support
> the SFC encoding (such as NSH) or it can't. But also, an SF is either
> locally attached to the SFF or not. A local attachment is (of course)
> easier to operate and allows "bump in the wire" proxies very easily. A
> remote attached SF is (IMHO) attached via a tunnel.
>
>
>
> The question of "remotely attached SFs" is one that should concern all
> implementations of RFC 7665 because no one (as yet) has worked on a
> protocol to bind SFs to SFFs. Robert is right that providing bump in the
> wire proxy for remotely attached SFs means that it is hard to 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) [mailto:wim.henderickx@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 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: * on behalf of Robert Raszuk 
> *Date: *Saturday, 17 March 2018 at 19:13
> *To: *Adrian Farrel 
> *Cc: *"Henderickx, Wim (Nokia - BE/Antwerp)" ,
> mpls , SPRING WG List , "s...@ietf.org" <
> s...@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 have zero 

Re: [bess] [sfc] [mpls] Progress with draft-farrel-mpls-sfc

[Adrian Farrel]

Wim and Robert,
 
[Dropping SPRING at this point as (as previously discussed) we have taken / are 
taking SR out of this document]
 
I think that draft-ietf-bess-service-chaining is really important work: it 
expresses a technique that is implemented and shipping.
 
On the other hand, this approach is not fully consistent with RFC 7665. 
 
But it does describe an actual SFC technology. Whether it remains in the field 
or is a migration technology only time (and operators) will tell.
 
Now, if we want to support RFC 7665 and RFC 8300 and use a control plane to 
discover the SFFs and to which SFs they provide access and to install 
"forwarding state" for SFPs, then we also have 
draft-ietf-bess-nsh-bgp-control-plane.
 
That draft was originally written with RFC 8300 in mind, but with the addition 
of one sub-TLV to indicate the encoding, it also supports 
draft-farrel-mpls-sfc. That should not be a surprise as draft-farrel-mpls-sfc 
attempts to model RFC 8300 as much as possible.
 
And that brings us back to "Where do we end up, what transition tools should we 
have, and how many steps to transition are there?"
 
draft-farrel-mpls-sfc provides another transition tool on the migration to RFC 
8300. It allows SFFs to be built as a minor mod to existing routers before 
there is forwarding plane support for the NSH.
 
But I want to reiterate that the discussion of wat encoding the SF supports is 
a red herring (certainly in the context of RFC 7665). An SF is either 
"SFC-aware" or not [RFC 7665 fig. 3], that is, it either can support the SFC 
encoding (such as NSH) or it can't. But also, an SF is either locally attached 
to the SFF or not. A local attachment is (of course) easier to operate and 
allows "bump in the wire" proxies very easily. A remote attached SF is (IMHO) 
attached via a tunnel.
 
The question of "remotely attached SFs" is one that should concern all 
implementations of RFC 7665 because no one (as yet) has worked on a protocol to 
bind SFs to SFFs. Robert is right that providing bump in the wire proxy for 
remotely attached SFs means that it is hard to 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) [mailto: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 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:  on behalf of Robert Raszuk 
Date: Saturday, 17 March 2018 at 19:13
To: Adrian Farrel 
Cc: "Henderickx, Wim (Nokia - BE/Antwerp)" , mpls 
, SPRING WG List , "s...@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 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 <  
adr...@olddog.co.uk> 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 

[bess] Update: I-D Action: draft-ietf-bess-nsh-bgp-control-plane-03.txt

[Adrian Farrel]

A few nits and fixed a bug in the IANA section.

Adrian

> -Original Message-
> From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of internet-
> dra...@ietf.org
> Sent: 18 March 2018 09:10
> To: i-d-annou...@ietf.org
> Cc: bess@ietf.org
> Subject: [bess] I-D Action: draft-ietf-bess-nsh-bgp-control-plane-03.txt
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
directories.
> This draft is a work item of the BGP Enabled ServiceS WG of the IETF.
> 
> Title   : BGP Control Plane for NSH SFC
> Authors : Adrian Farrel
>   John Drake
>   Eric Rosen
>   Jim Uttaro
>   Luay Jalil
>   Filename: draft-ietf-bess-nsh-bgp-control-plane-03.txt
>   Pages   : 54
>   Date: 2018-03-18
> 
> Abstract:
>This document describes the use of BGP as a control plane for
>networks that support Service Function Chaining (SFC).  The document
>introduces a new BGP address family called the SFC AFI/SAFI with two
>route types.  One route type is originated by a node to advertise
>that it hosts a particular instance of a specified service function.
>This route type also provides "instructions" on how to send a packet
>to the hosting node in a way that indicates that the service function
>has to be applied to the packet.  The other route type is used by a
>Controller to advertise the paths of "chains" of service functions,
>and to give a unique designator to each such path so that they can be
>used in conjunction with the Network Service Header.
> 
>This document adopts the SFC architecture described in RFC 7665.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-bess-nsh-bgp-control-plane/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-bess-nsh-bgp-control-plane-03
> https://datatracker.ietf.org/doc/html/draft-ietf-bess-nsh-bgp-control-plane-03
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-nsh-bgp-control-plane-03
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> ___
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] [sfc] [mpls] Progress with draft-farrel-mpls-sfc

[Henderickx, Wim (Nokia - BE/Antwerp)]

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:  on behalf of Robert Raszuk 
Date: Saturday, 17 March 2018 at 19:13
To: Adrian Farrel 
Cc: "Henderickx, Wim (Nokia - BE/Antwerp)" , mpls 
, SPRING WG List , "s...@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 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 
> 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
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess