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

From: Robert Raszuk <[email-masked]>
Date: Sat, 17 Mar 2018 19:13:35 +0100

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-masked]> 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

---

From: "Henderickx, Wim (Nokia - BE/Antwerp)" <[email-masked]>
Date: Sun, 18 Mar 2018 07:25:31 +0000

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-masked]> on behalf of Robert Raszuk <[email-masked]>
Date: Saturday, 17 March 2018 at 19:13
To: Adrian Farrel <[email-masked]>
Cc: "Henderickx, Wim (Nokia - BE/Antwerp)" <[email-masked]>, mpls <[email-masked]>, SPRING WG List <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
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-masked]<mailto:[email-masked]>> wrote:
Hi Wim,

> 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.

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

---

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 18 Mar 2018 10:10:16 -0000

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:[email-masked]] 
Sent: 18 March 2018 07:26
To: Robert Raszuk; Adrian Farrel
Cc: mpls; SPRING WG List; [email-masked]; [email-masked]
Subject: Re: [sfc] [mpls] Progress with draft-farrel-mpls-sfc

 
Hi Adrian,

 

 
Cheers,
R. 

On Sat, Mar 17, 2018 at 6:46 PM, Adrian Farrel < <mailto:[email-masked]> [email-masked]> wrote:
Hi Wim,

Cheers,
Adrian

---

From: Robert Raszuk <[email-masked]>
Date: Sun, 18 Mar 2018 14:27:00 +0100

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 <[email-masked]> wrote:

> I think that draft-ietf-bess-service-chaining is really important work:
> it expresses a technique that is implemented and shipping.
>
>
>
> 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; [email-masked]; [email-masked]
>
> *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: *<[email-masked]> on behalf of Robert Raszuk <[email-masked]>
> *Date: *Saturday, 17 March 2018 at 19:13
> *To: *Adrian Farrel <[email-masked]>
> *Cc: *"Henderickx, Wim (Nokia - BE/Antwerp)" <[email-masked]>,
> mpls <[email-masked]>, SPRING WG List <[email-masked]>, "[email-masked]" <
> [email-masked]>, "[email-masked]" <[email-masked]>
> *Subject: *Re: [sfc] [mpls] Progress with draft-farrel-mpls-sfc
>
>
>
> Hi Adrian,
>
>
>
> That mechanism with basic MPLS (where labels by based MPLS architecture
> are of local significance) is available with L3VPN extensions as already

---

From: "Henderickx, Wim (Nokia - BE/Antwerp)" <[email-masked]>
Date: Sun, 18 Mar 2018 20:02:05 +0000

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: <[email-masked]> on behalf of Robert Raszuk <[email-masked]>
Date: Sunday, 18 March 2018 at 14:27
To: Adrian Farrel <[email-masked]>
Cc: "Henderickx, Wim (Nokia - BE/Antwerp)" <[email-masked]>, mpls <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [sfc] [mpls] Progress with draft-farrel-mpls-sfc

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 <[email-masked]<mailto:[email-masked]>> wrote:
Wim and Robert,

Cheers,
Adrian

From: Henderickx, Wim (Nokia - BE/Antwerp) [mailto:[email-masked]<mailto:[email-masked]>]
Sent: 18 March 2018 07:26
To: Robert Raszuk; Adrian Farrel
Cc: mpls; SPRING WG List; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

From: <[email-masked]<mailto:[email-masked]>> on behalf of Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Date: Saturday, 17 March 2018 at 19:13
To: Adrian Farrel <[email-masked]<mailto:[email-masked]>>
Cc: "Henderickx, Wim (Nokia - BE/Antwerp)" <[email-masked]<mailto:[email-masked]>>, mpls <[email-masked]<mailto:[email-masked]>>, SPRING WG List <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [sfc] [mpls] Progress with draft-farrel-mpls-sfc

Hi Adrian,

Cheers,
R.

Cheers,
Adrian

---

From: <[email-masked]>
Date: Mon, 19 Mar 2018 09:52:05 +0000

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-masked]] 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-masked]; [email-masked]
Objet : Re: [sfc] [mpls] Progress with draft-farrel-mpls-sfc

Hi Adrian,

Cheers,
R.

Cheers,
Adrian

---

From: "UTTARO, JAMES" <[email-masked]>
Date: Mon, 19 Mar 2018 12:32:34 +0000

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-masked]] On Behalf Of [email-masked]
Sent: Monday, March 19, 2018 5:52 AM
To: Henderickx, Wim (Nokia - BE/Antwerp) <[email-masked]>; Robert Raszuk <[email-masked]>; Adrian Farrel <[email-masked]>
Cc: mpls <[email-masked]>; SPRING WG List <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [sfc] [mpls] Progress with draft-farrel-mpls-sfc

Hi all,

Wim has a point here.

Cheers,

Med

Cc : mpls; SPRING WG List; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

Hi Adrian,

Cheers,
R.

Cheers,
Adrian

---

From: <[email-masked]>
Date: Mon, 19 Mar 2018 13:21:44 +0000

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-masked]]
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-masked]; [email-masked]
Objet : RE: [sfc] [mpls] Progress with draft-farrel-mpls-sfc

Thanks,
                Jim Uttaro

From: sfc [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Monday, March 19, 2018 5:52 AM
To: Henderickx, Wim (Nokia - BE/Antwerp) <[email-masked]<mailto:[email-masked]>>; Robert Raszuk <[email-masked]<mailto:[email-masked]>>; Adrian Farrel <[email-masked]<mailto:[email-masked]>>
Cc: mpls <[email-masked]<mailto:[email-masked]>>; SPRING WG List <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [sfc] [mpls] Progress with draft-farrel-mpls-sfc

Hi all,

Wim has a point here.

Cheers,

Med

Hi Adrian,

Cheers,
R.

Cheers,
Adrian

---

From: "UTTARO, JAMES" <[email-masked]>
Date: Mon, 19 Mar 2018 13:47:43 +0000

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-masked] [mailto:[email-masked]]
Sent: Monday, March 19, 2018 9:22 AM
To: UTTARO, JAMES <[email-masked]>; Henderickx, Wim (Nokia - BE/Antwerp) <[email-masked]>; Robert Raszuk <[email-masked]>; Adrian Farrel <[email-masked]>
Cc: mpls <[email-masked]>; SPRING WG List <[email-masked]>; [email-masked]; [email-masked]
Subject: RE: [sfc] [mpls] Progress with draft-farrel-mpls-sfc

Hi Jim,

What I’m saying is:

Cheers,
Med

Cc : mpls; SPRING WG List; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

Thanks,
                Jim Uttaro

Hi all,

Wim has a point here.

Cheers,

Med

Hi Adrian,

Cheers,
R.

Cheers,
Adrian

---

From: <[email-masked]>
Date: Mon, 19 Mar 2018 14:03:17 +0000

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

Envoyé : lundi 19 mars 2018 13:48

Med,

Thanks,
                Jim Uttaro

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Monday, March 19, 2018 9:22 AM
To: UTTARO, JAMES <[email-masked]<mailto:[email-masked]>>; Henderickx, Wim (Nokia - BE/Antwerp) <[email-masked]<mailto:[email-masked]>>; Robert Raszuk <[email-masked]<mailto:[email-masked]>>; Adrian Farrel <[email-masked]<mailto:[email-masked]>>
Cc: mpls <[email-masked]<mailto:[email-masked]>>; SPRING WG List <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: [sfc] [mpls] Progress with draft-farrel-mpls-sfc

Hi Jim,

What I’m saying is:

Cheers,
Med

Thanks,
                Jim Uttaro

Hi all,

Wim has a point here.

Cheers,

Med

Hi Adrian,

Cheers,
R.

Cheers,
Adrian

---

From: "UTTARO, JAMES" <[email-masked]>
Date: Mon, 19 Mar 2018 14:09:30 +0000

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

Sent: Monday, March 19, 2018 10:03 AM

Re-,

Cheers,
Med

Med,

Thanks,
                Jim Uttaro

Hi Jim,

What I’m saying is:

Cheers,
Med

Thanks,
                Jim Uttaro

Hi all,

Wim has a point here.

Cheers,

Med

Hi Adrian,

Cheers,
R.

Cheers,
Adrian

---

From: <[email-masked]>
Date: Mon, 19 Mar 2018 14:25:01 +0000

Re-,

This is really a matter of taste.

Jim, whatever scheme we use for identifying service chains, there are requirements/constraints/new practices/new OAM procedures that need to be supported/honored for service chaining purposes.

Those are not simple nor complex in MPLS vs. NSH over MPLS. I’m wrong?

Cheers,
Med

Envoyé : lundi 19 mars 2018 14:10

Med,

Thanks,
                Jim Uttaro

Re-,

Cheers,
Med

Med,

Thanks,
                Jim Uttaro

Hi Jim,

What I’m saying is:

Cheers,
Med

Thanks,
                Jim Uttaro

Hi all,

Wim has a point here.

Cheers,

Med

Hi Adrian,

Cheers,
R.

Cheers,
Adrian

---

From: <[email-masked]>
Date: Mon, 19 Mar 2018 14:37:46 +0000

Hi,

I’m worrying that MPLS based SFCs may slowdown implementations of NSH.
Vendors have usually a limited bandwidth to implement new features especially when the dataplane is involved. I would personally prefer to get the resources allocated to NSH rather than MPLS based SFCs.
This is not just a matter of operator preference, as if vendor#1 prioritizes MPLS SFC and vendor#2 prioritizes NSH, multiple operators may get stuck for a while when operating a multivendor network.

Whatever the encaps is, the operational team will have to ramp up on the SFC architecture and on the associated controlplane. The encaps/dataplane is a small part of the operational side.

I’m personally in favor to focus on NSH even if I’m an MPLS geek. We already have running SFCs that are based on bess-service-chaining as an interim solution.

Brgds,

Stephane

From: mpls [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, March 19, 2018 14:25
To: UTTARO, JAMES; Henderickx, Wim (Nokia - BE/Antwerp); Robert Raszuk; Adrian Farrel
Cc: mpls; SPRING WG List; [email-masked]; [email-masked]
Subject: Re: [mpls] [sfc] Progress with draft-farrel-mpls-sfc

Re-,

Cheers,
Med

Med,

Thanks,
                Jim Uttaro

Re-,

Cheers,
Med

Med,

Thanks,
                Jim Uttaro

Hi Jim,

What I’m saying is:

Cheers,
Med

Thanks,
                Jim Uttaro

Hi all,

Wim has a point here.

Cheers,

Med

Hi Adrian,

Cheers,
R.

Cheers,
Adrian

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: "NAPIERALA, MARIA H" <[email-masked]>
Date: Mon, 19 Mar 2018 14:12:13 +0000

I also would like to point out that the service chain forwarding defined by draft-ietf-bess-service-chaining is based on original IP packet header. This allows to attract the traffic into the chain based on existence of a route to the traffic destination. In other words, it allows to insert service chains from a routed network.

Maria

From: BESS [mailto:[email-masked]] On Behalf Of Henderickx, Wim (Nokia - BE/Antwerp)
Sent: Sunday, March 18, 2018 4:02 PM
To: Robert Raszuk <[email-masked]>; Adrian Farrel <[email-masked]>
Cc: mpls <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [bess] [sfc] [mpls] Progress with draft-farrel-mpls-sfc

Cc: "Henderickx, Wim (Nokia - BE/Antwerp)" <[email-masked]<mailto:[email-masked]>>, mpls <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>

Adrian,

Best,
Robert.

Cheers,
Adrian

Hi Adrian,

Cheers,
R.

Cheers,
Adrian

---

From: "LINGALA, AVINASH" <[email-masked]>
Date: Tue, 20 Mar 2018 10:05:59 +0000

I support this effort and I agree with Jim.  As an operator we would like to see various encapsulation options for SFC. This would help an operator to pick the suitable encapsulation option for their networks.

Same approach that IETF took for EVPN  with various encap options like MPLS, VXLAN, GENEVE,..

Thanks,
Avinash Lingala

From: BESS [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, March 19, 2018 10:25 AM
To: UTTARO, JAMES <[email-masked]>; Henderickx, Wim (Nokia - BE/Antwerp) <[email-masked]>; Robert Raszuk <[email-masked]>; Adrian Farrel <[email-masked]>
Cc: mpls <[email-masked]>; SPRING WG List <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [bess] [sfc] [mpls] Progress with draft-farrel-mpls-sfc

Re-,

Cheers,
Med

Med,

Thanks,
                Jim Uttaro

Re-,

Cheers,
Med

Med,

Thanks,
                Jim Uttaro

Hi Jim,

What I’m saying is:

Cheers,
Med

Thanks,
                Jim Uttaro

Hi all,

Wim has a point here.

Cheers,

Med

Hi Adrian,

Cheers,
R.

Cheers,
Adrian

---

From: <[email-masked]>
Date: Tue, 20 Mar 2018 10:24:37 +0000

> Same approach that IETF took for EVPN  with various encap options like MPLS, VXLAN, GENEVE,..

Well you do have the same thing with SFC/NSH, you can use any type of transport underneath: MPLS, VXLAN, GRE,UDP,…

In your example EVPN provides the service, then you pick the transport you want.
Here SFC/NSH may provide the service (chaining), then you pick also the transport you want.

From: mpls [mailto:[email-masked]] On Behalf Of LINGALA, AVINASH
Sent: Tuesday, March 20, 2018 10:06
To: BOUCADAIR Mohamed IMT/OLN; UTTARO, JAMES; Henderickx, Wim (Nokia - BE/Antwerp); Robert Raszuk; Adrian Farrel
Cc: mpls; SPRING WG List; [email-masked]; [email-masked]
Subject: Re: [mpls] [sfc] Progress with draft-farrel-mpls-sfc

Thanks,
Avinash Lingala

From: BESS [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Monday, March 19, 2018 10:25 AM
To: UTTARO, JAMES <[email-masked]<mailto:[email-masked]>>; Henderickx, Wim (Nokia - BE/Antwerp) <[email-masked]<mailto:[email-masked]>>; Robert Raszuk <[email-masked]<mailto:[email-masked]>>; Adrian Farrel <[email-masked]<mailto:[email-masked]>>
Cc: mpls <[email-masked]<mailto:[email-masked]>>; SPRING WG List <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [bess] [sfc] [mpls] Progress with draft-farrel-mpls-sfc

Re-,

Cheers,
Med

Med,

Thanks,
                Jim Uttaro

Re-,

Cheers,
Med

Med,

Thanks,
                Jim Uttaro

Hi Jim,

What I’m saying is:

Cheers,
Med

Thanks,
                Jim Uttaro

Hi all,

Wim has a point here.

Cheers,

Med

Hi Adrian,

Cheers,
R.

Cheers,
Adrian

---

From: <[email-masked]>
Date: Tue, 20 Mar 2018 10:28:37 +0000

Dear Avinash,

But these various encapsulation options (VXLAN, IP-in-IP,..) are already there thanks to the transport-agnostic approach endorsed by the SFC WG.

An alternative approach would be to mimic NSH for each of the mechanisms you listed. That approach is suboptimal, IMO.

FWIW, we used to have this text in the SFC Control Plane Requirements I-D:

   Various transport encapsulation schemes and/or versions of SFC header
   implementations may be supported by one or several nodes of an SFC-
   enabled domain.  For the sake of coherent configuration, the SFC
   control plane is responsible for instructing all the involved SFC
   data plane functional elements about the behavior to adopt to select
   the transport encapsulation scheme(s), the version of the SFC header
   to enable, etc.

Cheers,
Med

De : LINGALA, AVINASH [mailto:[email-masked]]
Envoyé : mardi 20 mars 2018 10:06
À : BOUCADAIR Mohamed IMT/OLN; UTTARO, JAMES; Henderickx, Wim (Nokia - BE/Antwerp); Robert Raszuk; Adrian Farrel
Cc : mpls; SPRING WG List; [email-masked]; [email-masked]
Objet : RE: [sfc] [mpls] Progress with draft-farrel-mpls-sfc

Thanks,
Avinash Lingala

Re-,

Cheers,
Med

Med,

Thanks,
                Jim Uttaro

Re-,

Cheers,
Med

Med,

Thanks,
                Jim Uttaro

Hi Jim,

What I’m saying is:

Cheers,
Med

Thanks,
                Jim Uttaro

Hi all,

Wim has a point here.

Cheers,

Med

Hi Adrian,

Cheers,
R.

Cheers,
Adrian

---

From: "Henderickx, Wim (Nokia - BE/Antwerp)" <[email-masked]>
Date: Tue, 20 Mar 2018 10:35:22 +0000

Jim and a few others started to document how we can use MPLS as transport to support service chaining with NSH.
The draft needs a lot of work and is right now focussed on SR but will also work on any MPLS transport: LDP, RSVP, SPRING, etc etc + how to use in IP-VPN/EVPN.
We will refine it and update it but for reference:
https://tools.ietf.org/html/draft-guichard-sfc-nsh-sr-00

From: Stephane Litkowski <[email-masked]>
Date: Tuesday, 20 March 2018 at 10:24
To: "LINGALA, AVINASH" <[email-masked]>, "mohamed. boucadair" <[email-masked]>, "UTTARO, JAMES" we <[email-masked]>, "Henderickx, Wim (Nokia - BE/Antwerp)" <[email-masked]>, Robert Raszuk <[email-masked]>, Adrian Farrel <[email-masked]>
Cc: mpls <[email-masked]>, SPRING WG List <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: [mpls] [sfc] Progress with draft-farrel-mpls-sfc

Thanks,
Avinash Lingala

Re-,

Cheers,
Med

Med,

Thanks,
                Jim Uttaro

Re-,

Cheers,
Med

Med,

Thanks,
                Jim Uttaro

Hi Jim,

What I’m saying is:

Cheers,
Med

Thanks,
                Jim Uttaro

Hi all,

Wim has a point here.

Cheers,

Med

Hi Adrian,

Cheers,
R.

Cheers,
Adrian

Thank you.

---

From: "Henderickx, Wim (Nokia - BE/Antwerp)" <[email-masked]>
Date: Tue, 20 Mar 2018 11:35:28 +0000

Jim whats wrong with this draft:
https://tools.ietf.org/html/draft-ietf-bess-service-chaining-04

It provides simple service chaining using MPLS techniques

From: "UTTARO, JAMES" <[email-masked]>
Date: Tuesday, 20 March 2018 at 11:30
To: Stephane Litkowski <[email-masked]>, "LINGALA, AVINASH" <[email-masked]>, "mohamed. boucadair" <[email-masked]>, "Henderickx, Wim (Nokia - BE/Antwerp)" <[email-masked]>, Robert Raszuk <[email-masked]>, Adrian Farrel <[email-masked]>
Cc: mpls <[email-masked]>, SPRING WG List <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: [mpls] [sfc] Progress with draft-farrel-mpls-sfc

I guess I am not being clear.

The issue as I see it is that I do not require NSH to realize the creation of simple chains. I simply need SR to realize the chain. Why is the IETF forcing me to adopt technology that I do not need, while at the same time reducing the number of vendors that I may use in my network as this encap will have to be supported by traditional OEMs and others looking to get into the business.

TBC I am not against NSH it addresses use cases where dynamic complex chains are required. The reality of my world is that I have lots of simpler chains i.e FW, LB  and do not need the additional OPEX and CAPEX  costs associated with deploying NSH.

Jim Uttaro

From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, March 20, 2018 6:25 AM
To: LINGALA, AVINASH <[email-masked]>; BOUCADAIR Mohamed IMT/OLN <[email-masked]>; UTTARO, JAMES <[email-masked]>; Henderickx, Wim (Nokia - BE/Antwerp) <[email-masked]>; Robert Raszuk <[email-masked]>; Adrian Farrel <[email-masked]>
Cc: mpls <[email-masked]>; SPRING WG List <[email-masked]>; [email-masked]; [email-masked]
Subject: RE: [mpls] [sfc] Progress with draft-farrel-mpls-sfc

Thanks,
Avinash Lingala

Re-,

Cheers,
Med

Med,

Thanks,
                Jim Uttaro

Re-,

Cheers,
Med

Med,

Thanks,
                Jim Uttaro

Hi Jim,

What I’m saying is:

Cheers,
Med

Thanks,
                Jim Uttaro

Hi all,

Wim has a point here.

Cheers,

Med

Hi Adrian,

Cheers,
R.

Cheers,
Adrian

Thank you.

---

From: <[email-masked]>
Date: Tue, 20 Mar 2018 11:40:44 +0000

For simple service chains, policy routing works fine as well (this was what was used before bess-service-chaining has come). It becomes a nightmare when the service chains are complex.

From: Henderickx, Wim (Nokia - BE/Antwerp) [mailto:[email-masked]]
Sent: Tuesday, March 20, 2018 11:35
To: UTTARO, JAMES; LITKOWSKI Stephane OBS/OINIS; LINGALA, AVINASH; BOUCADAIR Mohamed IMT/OLN; Robert Raszuk; Adrian Farrel
Cc: mpls; SPRING WG List; [email-masked]; [email-masked]
Subject: Re: [mpls] [sfc] Progress with draft-farrel-mpls-sfc

From: "UTTARO, JAMES" <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, 20 March 2018 at 11:30
To: Stephane Litkowski <[email-masked]<mailto:[email-masked]>>, "LINGALA, AVINASH" <[email-masked]<mailto:[email-masked]>>, "mohamed. boucadair" <[email-masked]<mailto:[email-masked]>>, "Henderickx, Wim (Nokia - BE/Antwerp)" <[email-masked]<mailto:[email-masked]>>, Robert Raszuk <[email-masked]<mailto:[email-masked]>>, Adrian Farrel <[email-masked]<mailto:[email-masked]>>
Cc: mpls <[email-masked]<mailto:[email-masked]>>, SPRING WG List <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [mpls] [sfc] Progress with draft-farrel-mpls-sfc

Jim Uttaro

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Tuesday, March 20, 2018 6:25 AM
To: LINGALA, AVINASH <[email-masked]<mailto:[email-masked]>>; BOUCADAIR Mohamed IMT/OLN <[email-masked]<mailto:[email-masked]>>; UTTARO, JAMES <[email-masked]<mailto:[email-masked]>>; Henderickx, Wim (Nokia - BE/Antwerp) <[email-masked]<mailto:[email-masked]>>; Robert Raszuk <[email-masked]<mailto:[email-masked]>>; Adrian Farrel <[email-masked]<mailto:[email-masked]>>
Cc: mpls <[email-masked]<mailto:[email-masked]>>; SPRING WG List <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: [mpls] [sfc] Progress with draft-farrel-mpls-sfc

Thanks,
Avinash Lingala

Re-,

Cheers,
Med

Med,

Thanks,
                Jim Uttaro

Re-,

Cheers,
Med

Med,

Thanks,
                Jim Uttaro

Hi Jim,

What I’m saying is:

Cheers,
Med

Thanks,
                Jim Uttaro

Hi all,

Wim has a point here.

Cheers,

Med

Hi Adrian,

Cheers,
R.

Cheers,
Adrian

Thank you.

---

From: "UTTARO, JAMES" <[email-masked]>
Date: Tue, 20 Mar 2018 11:29:42 +0000

Jim Uttaro

Thanks,
Avinash Lingala

Re-,

Cheers,
Med

Med,

Thanks,
                Jim Uttaro

Re-,

Cheers,
Med

Med,

Thanks,
                Jim Uttaro

Hi Jim,

What I’m saying is:

Cheers,
Med

Thanks,
                Jim Uttaro

Hi all,

Wim has a point here.

Cheers,

Med

Hi Adrian,

Cheers,
R.

Cheers,
Adrian

Thank you.

---

From: <[email-masked]>
Date: Tue, 20 Mar 2018 11:59:42 +0000

Jim,

You said that you “simply need SR to realize the chain”, but actually if you want a path to be steered relying upon some information conveyed in the packet and to invoke specific SFs, then you need to define the structure of such information and its meaning.

That is another piece of specification work to be yet done if you want it to be part of SR information itself.

Cheers,
Med

De : UTTARO, JAMES [mailto:[email-masked]]
Envoyé : mardi 20 mars 2018 11:30
À : LITKOWSKI Stephane OBS/OINIS; LINGALA, AVINASH; BOUCADAIR Mohamed IMT/OLN; Henderickx, Wim (Nokia - BE/Antwerp); Robert Raszuk; Adrian Farrel
Cc : mpls; SPRING WG List; [email-masked]; [email-masked]
Objet : RE: [mpls] [sfc] Progress with draft-farrel-mpls-sfc

Jim Uttaro

Thanks,
Avinash Lingala

Re-,

Cheers,
Med

Med,

Thanks,
                Jim Uttaro

Re-,

Cheers,
Med

Med,

Thanks,
                Jim Uttaro

Hi Jim,

What I’m saying is:

Cheers,
Med

Thanks,
                Jim Uttaro

Hi all,

Wim has a point here.

Cheers,

Med

Hi Adrian,

Cheers,
R.

Cheers,
Adrian

Thank you.

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 20 Mar 2018 12:59:58 +0100

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 global
meaning with SR references removed any more.

If so this draft in question is not required to dynamically signal a label
bound by operator to given service in a control plane. Just like you
advertise any other label which has local meaning by the node advertising
it. As we pointed out draft-ietf-bess-service-chaining-04 is one option to
signal this. They may be other options, but you either treat label as local
or as domain wide. You can't pretend that under the umbrella of doing
former you are effectively doing latter without admitting it.

Best,
Robert.

On Tue, Mar 20, 2018 at 12:29 PM, UTTARO, JAMES <[email-masked]> wrote:

> *I guess I am not being clear.*
>
>
>
> *The issue as I see it is that I do not require NSH to realize the
> creation of simple chains. I simply need SR to realize the chain. Why is
> the IETF forcing me to adopt technology that I do not need, while at the
> same time reducing the number of vendors that I may use in my network as
> this encap will have to be supported by traditional OEMs and others looking
> to get into the business.*
>
>
>
> *TBC I am not against NSH it addresses use cases where dynamic complex
> chains are required. The reality of my world is that I have lots of simpler
> chains i.e FW, LB  and do not need the additional OPEX and CAPEX  costs
> associated with deploying NSH. *
>
>
>
> *Jim Uttaro*
>

---

From: "Bernier, Daniel" <[email-masked]>
Date: Wed, 21 Mar 2018 00:53:29 +0000

+1 to Jim and Avinash

Same challenge on our side.

Our network is built upon a MPLS data plane. My current "network appliances" are connected to MPLS devices and service instantiation done through static pseudowires. It will be easier for me to introduce SRTE policy capabilities through software upgrades instead of certifying and introducing new hardware to enable a newer encap.

And by the time we get to leverage contextual metadata between functions, most probably, these will have also evolved (micro-services, hw/sw disaggregation) and new ways of conveying that metadata will have been proposed.

Thanks,

PS: I am also wondering why it is so badly seen to look at alternatives to NSH SFC while at the same time we introduce new WG to discuss DC routing (RIFT, LSVR, ...). If we accept multiplicity in that space, and I think we should, then we should allow it in chain composition and programming.

Cheers,

Daniel Bernier

________________________________
From: mpls <[email-masked]> on behalf of [email-masked] <[email-masked]>
Sent: Tuesday, March 20, 2018 7:59 AM
To: UTTARO, JAMES; LITKOWSKI Stephane OBS/OINIS; LINGALA, AVINASH; Henderickx, Wim (Nokia - BE/Antwerp); Robert Raszuk; Adrian Farrel
Cc: mpls; SPRING WG List; [email-masked]; [email-masked]
Subject: Re: [mpls] [sfc] Progress with draft-farrel-mpls-sfc

Jim,

Cheers,
Med

Jim Uttaro

Thanks,
Avinash Lingala

Re-,

Cheers,
Med

Med,

Thanks,
                Jim Uttaro

Re-,

Cheers,
Med

Med,

Thanks,
                Jim Uttaro

Hi Jim,

What I’m saying is:

Cheers,
Med

Thanks,
                Jim Uttaro

Hi all,

Wim has a point here.

Cheers,

Med

Hi Adrian,

Cheers,
R.

Cheers,
Adrian

Thank you.

---

From: <[email-masked]>
Date: Wed, 21 Mar 2018 08:51:29 +0000

Hi Daniel,

You may need to introduce new hardware as well for SRTE to handle the number of labels to push.
If your hardware is flexible (network processors), there is a chance that it can also handle NSH.

Now if you want just to use SR policies to perform a kind of service chaining, is there something really specific to develop ? Can’t you do this today with the “existing” SRTE machinery and SIDs that are available: you need Node-SID for transport compression, and a SID to forward to the VNF (similar to the EPE SID).

Brgds,

Stephane

From: Bernier, Daniel [mailto:[email-masked]]
Sent: Wednesday, March 21, 2018 00:53
To: BOUCADAIR Mohamed IMT/OLN; UTTARO, JAMES; LITKOWSKI Stephane OBS/OINIS; LINGALA, AVINASH; Henderickx, Wim (Nokia - BE/Antwerp); Robert Raszuk; Adrian Farrel
Cc: mpls; SPRING WG List; [email-masked]; [email-masked]
Subject: Re: [mpls] [sfc] Progress with draft-farrel-mpls-sfc

+1 to Jim and Avinash

Thanks,

Cheers,

Daniel Bernier

________________________________
From: mpls <[email-masked]<mailto:[email-masked]>> on behalf of [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, March 20, 2018 7:59 AM
To: UTTARO, JAMES; LITKOWSKI Stephane OBS/OINIS; LINGALA, AVINASH; Henderickx, Wim (Nokia - BE/Antwerp); Robert Raszuk; Adrian Farrel
Cc: mpls; SPRING WG List; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [mpls] [sfc] Progress with draft-farrel-mpls-sfc

Jim,

Cheers,
Med

Jim Uttaro

Thanks,
Avinash Lingala

Re-,

Cheers,
Med

Med,

Thanks,
                Jim Uttaro

Re-,

Cheers,
Med

Med,

Thanks,
                Jim Uttaro

Hi Jim,

What I’m saying is:

Cheers,
Med

Thanks,
                Jim Uttaro

Hi all,

Wim has a point here.

Cheers,

Med

Hi Adrian,

Cheers,
R.

Cheers,
Adrian

Thank you.

---

From: <[email-masked]>
Date: Wed, 21 Mar 2018 09:06:39 +0000

Hi Daniel,

I’m afraid that the comparison with DC routing is misleading here. It is still possible to use your favorite transport encapsulation with the approach endorsed by the IETF in 8300.

Re-using NSH instead of mimic it in each individual transport protocol is much more pragmatic. It avoids wasting extra specification in defining exactly the same set of information for each of one’s favorite transport encapsulating protocol.

Tests (including regression tests) are required anyway even in the case you mentioned.

Cheers,
Med

De : Bernier, Daniel [mailto:[email-masked]]
Envoyé : mercredi 21 mars 2018 00:53
À : BOUCADAIR Mohamed IMT/OLN; UTTARO, JAMES; LITKOWSKI Stephane OBS/OINIS; LINGALA, AVINASH; Henderickx, Wim (Nokia - BE/Antwerp); Robert Raszuk; Adrian Farrel
Cc : mpls; SPRING WG List; [email-masked]; [email-masked]
Objet : Re: [mpls] [sfc] Progress with draft-farrel-mpls-sfc

+1 to Jim and Avinash

Thanks,

Cheers,

Daniel Bernier

Jim,

Cheers,
Med

Jim Uttaro

Thanks,
Avinash Lingala

Re-,

Cheers,
Med

Med,

Thanks,
                Jim Uttaro

Re-,

Cheers,
Med

Med,

Thanks,
                Jim Uttaro

Hi Jim,

What I’m saying is:

Cheers,
Med

Thanks,
                Jim Uttaro

Hi all,

Wim has a point here.

Cheers,

Med

Hi Adrian,

Cheers,
R.

Cheers,
Adrian

Thank you.

---

From: "Bernier, Daniel" <[email-masked]>
Date: Wed, 21 Mar 2018 11:01:47 +0000

​Hi Med,

Please see inline

Cheers

Daniel Bernier

________________________________
From: [email-masked] <[email-masked]>
Sent: Wednesday, March 21, 2018 5:06 AM
To: Bernier, Daniel
Cc: mpls; SPRING WG List; [email-masked]; [email-masked]
Subject: RE: [mpls] [sfc] Progress with draft-farrel-mpls-sfc

Hi Daniel,

DB> ​But that means in that case I must use RFC8300, my view is there is an option for RFC8300 but there CAN be others.

DB> ​This is where I am not convinced there is a need to mimic NSH operations altogether. But we can sit together this week and discuss.

DB> Doing testing including regression on software is way less impactful than sending technicians to swap out linecards on devices.

Cheers,
Med

+1 to Jim and Avinash

Thanks,

Cheers,

Daniel Bernier

Jim,

Cheers,
Med

Jim Uttaro

Thanks,
Avinash Lingala

Re-,

Cheers,
Med

Med,

Thanks,
                Jim Uttaro

Re-,

Cheers,
Med

Med,

Thanks,
                Jim Uttaro

Hi Jim,

What I’m saying is:

Cheers,
Med

Thanks,
                Jim Uttaro

Hi all,

Wim has a point here.

Cheers,

Med

Hi Adrian,

Cheers,
R.

Cheers,
Adrian

Thank you.