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

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

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 
Date: Tuesday, 6 November 2018 at 19:41
To: "Henderickx, Wim (Nokia - BE/Antwerp)" , 
"draft-ietf-bess-service-chain...@ietf.org" 
, "bess@ietf.org" 
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)" 
Date: Monday, November 5, 2018 at 2:17 AM
To: "draft-ietf-bess-service-chain...@ietf.org" 
, "bess@ietf.org" 
Subject: draft-ietf-bess-service-chaining
Resent-From: 
Resent-To: , , , 
, , 
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

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

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

[Stuart Mackie]

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)" 
Date: Monday, November 5, 2018 at 2:17 AM
To: "draft-ietf-bess-service-chain...@ietf.org" 
, "bess@ietf.org" 
Subject: draft-ietf-bess-service-chaining
Resent-From: 
Resent-To: , , , 
, , 
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

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

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

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

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

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