Re: [bess] draft-ietf-bess-service-chaining

["Henderickx, Wim (Nokia - BE/Antwerp)" <[e-mail]>]

Stuart thanks, we also support this but wanted to ensure some things that are obvious to some people are not for others and hence I believe we have a duty in IETF to make people aware about these things. Thx

From: Stuart Mackie <[e-mail]>
Date: Tuesday, 6 November 2018 at 19:41
To: "Henderickx, Wim (Nokia - BE/Antwerp)" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Re: draft-ietf-bess-service-chaining

Hi Wim,

Stephane had alerted me to these comments you made a while ago, but which I missed at the time. Sorry for the delay in getting back to you.

*   The doc is much focused on the VRF constructions and architecture, but in some use cases we need to program the SF, which is not always clear and we should be a bit more explicit about it in the draft
SM> Agreed that programming the SF will almost always be required, but there isn’t any standard way of doing this. I can add a comment to that effect.
*   If a SF is L2 vs L3 we need to program the static NH and IP@ a bit different and we should clarify this
SM> I don’t think there is any difference for L3 routes  between L2 and L3 SFs – at a service egress the next hop is the forwarder where the next service is running with a label that identifies the ingress interface. There is a difference in that the VRF has to add an Ethernet header before sending into an L2 SF, which for non-transparent would be that of the ingress SF interface (known from when the SF was instantiated). For an L2 transparent service, the ingress VRF would put the MAC address of the egress forwarder (which since they can all be the same, would be the simplest), and then the egress forwarder rewrites the L2 destination if forwarding out of the service chain. I’ll add some detail on this.
*   A question I have is if in this architecture a SFF could be shared using the same interface/sub-interface with other service chains or not. Based on this it would also be good to document the things the SFC architecture allows and are supported or not with this proposal.
SM> Sharing can be done for transparent L2 SFs, where VLANs can be used to identify which virtual network a packet came from (already supported in Contrail), and for L3 SFs could potentially be supported using next-table policies in VRFs (similar to floating IP addresses). However, that depends on service chains being tied to subnets, which isn’t the scenario that is usually discussed in mobility applications where the chosen service chain is based on subscriber/application. I can add a couple of sentences on this.

Regards

Stuart
-914 886 2534

From: "Henderickx, Wim (Nokia - BE/Antwerp)" <[e-mail]>
Date: Monday, November 5, 2018 at 2:17 AM
To: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: draft-ietf-bess-service-chaining
Resent-From: <[e-mail]>
Resent-To: <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
Resent-Date: Monday, November 5, 2018 at 2:17 AM

Attached were my comments which I sent at the time which were not addressed so far in the doc.
Would be good if we can incorporate them before WG last call

https://www.ietf.org/mail-archive/web/bess/current/msg00791.html<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_bess_current_msg00791.html&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=iVavQx6gb7x-wiXKtJ7ryhHWVzNbV-FpJD1JlIhEm6s&m=uWaX1cs3QGWIWutYoveySsQRYlCX8sh7sALiGa91osk&s=2YXOxs06X6-NwAP3gYDrtB27peSlBZsN21WaSSE3pwc&e=>