Subject: [sfc] comments on draft-fedyk-sfc-mac-chain-00

From: Anoop Ghanwani <[email-masked]>
Date: Mon, 26 Oct 2015 15:16:58 -0700

I have reviewed draft-fedyk-sfc-mac-chain-00, and had the following
comments.

Thanks,
Anoop

===

  Original L2, MAC Chaining without NSH
   +-------------------------------------------+--------------------+
   | Outer Ethernet, ET=0x****                 | original L2 frame  |
   +-------------------------------------------+--------------------+

If we have a different Ethertype, then we can't process these frames using
existing hardware, so then what's the benefit of this proposal vs just
using the NSH?  The operations required by Table 5, for instance, are not
supported by any existing standards and would most likely require new
hardware (for those that want to implement this function in hardware).

In all cases of MAC chaining after a frame (L2, L3, etc) has been
   classified the MAC chain begins by prepending the packet with an
   Ethernet L2 Frame header. The frame will also have a valid 4 byte CRC
   checksum.

Is this a separate CRC from that of a regular Ethernet frame?

   The DA

   is looked up in the context of Port 1 (a VN port) and the subsequent
   DA prime (DA' a CS-MAC used as the new frame DA if this segment is DA
   forwarding) and SA' (a CS-MAC used as the new frame SA if this
   segment is DA/SA forwarding) and egress Port 1 prime (1') are
   determined by the lookup.

What is the significant of DA vs DA/SA forwarding?  With DA forwarding,
does it mean that the SA remains unchanged?  Could that potentially cause
problems with MAC learning, especially given that:

   Devices in the path that are not MAC service
   chaining aware are free to bridge the frame normally or to route
   using any underlay Layer 3 or 2.5 VN encapsulation.

The document would benefit from a more detailed description for branching
in Section 4.2.  I couldn't get a good feel what exactly what operations
are being done when the branching bit is set.

In section 4.2.5

   Service
   Functions using DA/SA MAC chaining require only a single MAC address
   regardless of the number of chains passing through them.

It's not clear how you identify a chain using 2 MAC addresses which are
both unique.  If I have 2 service functions that are being shared by
several chains, how does this work?  How can tell the difference between
SFC A and SFC B when both of them include the same sequence of service
functions, say SF X and SF Y, even though they may have additional service
functions either before or after these functions?

---

From: "Bottorff, Paul" <[email-masked]>
Date: Tue, 27 Oct 2015 00:23:51 +0000

Hi Anoop:

See below,

Cheers,

Paul

From: sfc [mailto:[email-masked]] On Behalf Of Anoop Ghanwani
Sent: Monday, October 26, 2015 3:17 PM
To: [email-masked]
Subject: [sfc] comments on draft-fedyk-sfc-mac-chain-00

I have reviewed draft-fedyk-sfc-mac-chain-00, and had the following comments.

Thanks,
Anoop

===

If we have a different Ethertype, then we can't process these frames using existing hardware, so then what's the benefit of this proposal vs just using the NSH?  The operations required by Table 5, for instance, are not supported by any existing standards and would most likely require new hardware (for those that want to implement this function in hardware).
PB>In the normal case where we have an L3 service frame no further encapsulations are required. In addition, L2 cases where the MACs don’t need to be preserved also don’t need additional encapsulations.

   checksum.

Is this a separate CRC from that of a regular Ethernet frame?
PB>No, a normal MAC Chaining frame for and L3 service looks exactly like a normal Ethernet frame.

   The DA

What is the significant of DA vs DA/SA forwarding?  With DA forwarding, does it mean that the SA remains unchanged?  Could that potentially cause problems with MAC learning, especially given that:
PB>The two types of forwarding can be mixed in the same chain and are used to interface to different SF requirements. With DA forwarding the SF acts like any transparent pass through device (i.e. like a bridge) and therefore does not modify the SA. In DA/SA forwarding the SA is used to forward the frame to the next SFF (typically the sourcing SFF).

The document would benefit from a more detailed description for branching in Section 4.2.  I couldn't get a good feel what exactly what operations are being done when the branching bit is set.

In section 4.2.5

   Service

It's not clear how you identify a chain using 2 MAC addresses which are both unique.  If I have 2 service functions that are being shared by several chains, how does this work?  How can tell the difference between SFC A and SFC B when both of them include the same sequence of service functions, say SF X and SF Y, even though they may have additional service functions either before or after these functions?
PB>In this case of DA/SA forwarding the DA identifies the SF and the SA identifies the chain segment (and therefore the chain).

---

From: Anoop Ghanwani <[email-masked]>
Date: Mon, 26 Oct 2015 22:15:16 -0700

Thanks Paul.  Please see inline.

Anoop

On Mon, Oct 26, 2015 at 5:23 PM, Bottorff, Paul <[email-masked]>
wrote:

> Hi Anoop:
>
>
>
> See below,
>
>
>
> Cheers,
>
>
>
> Paul
>
>
>
> *From:* sfc [mailto:[email-masked]] *On Behalf Of *Anoop Ghanwani
> *Sent:* Monday, October 26, 2015 3:17 PM
> *To:* [email-masked]
> *Subject:* [sfc] comments on draft-fedyk-sfc-mac-chain-00
>
>
>
> PB>In the normal case where we have an L3 service frame no further
> encapsulations are required. In addition, L2 cases where the MACs don’t
> need to be preserved also don’t need additional encapsulations.
>
> [ag] I see this as the main useful use case for something like this.  Once
we get to new forwarding functions/encapsulations, we might as well use
NSH.  Is there a reason why I should prefer the MAC based approach with a
new encap over NSH?  The other concern I would have with this, is that if
there are any bridges between the SFFs, how do those learn the MAC
addresses?  Since chains are typically unidirectional, I may end up in
situations where the bridges always have to flood all traffic.

(Bunch of other stuff deleted.)

---

From: "Bottorff, Paul" <[email-masked]>
Date: Tue, 27 Oct 2015 17:10:12 +0000

Hi Annop:

Some additional comments.

Cheers,

Paul

From: [email-masked] [mailto:[email-masked]] On Behalf Of Anoop Ghanwani
Sent: Monday, October 26, 2015 10:15 PM
To: Bottorff, Paul
Cc: [email-masked]
Subject: Re: [sfc] comments on draft-fedyk-sfc-mac-chain-00

Anoop

On Mon, Oct 26, 2015 at 5:23 PM, Bottorff, Paul <[email-masked]<mailto:[email-masked]>> wrote:
Hi Anoop:

See below,

Cheers,

Paul

From: sfc [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Anoop Ghanwani
Sent: Monday, October 26, 2015 3:17 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [sfc] comments on draft-fedyk-sfc-mac-chain-00

Thanks,
Anoop

===

[ag] I see this as the main useful use case for something like this.  Once we get to new forwarding functions/encapsulations, we might as well use NSH.  Is there a reason why I should prefer the MAC based approach with a new encap over NSH?
PB>NSH is supported by MAC Chaining. For L2 service frames which preserve MAC addresses, MAC Chaining can use NSH as the encapsulation so I don’t see what the argument is here. For L3 service frame no encapsulation is required, however NSH can also be carried.
The other concern I would have with this, is that if there are any bridges between the SFFs, how do those learn the MAC addresses?
PB>This is not a problem unique to MAC Chaining. All chaining can have this problem. In some cases the MAC Chain will use the encapsulated MACs of an NVO3 encapsulation and router forwarding. In other cases SDN controllers will configure the path. Finally, it is possible for SFFs to advertise their destination addresses by periodic advertisements if they wish to update learn cashes. I would note that for DA/SA forwarding the SF would start as normal with a GARP.
Since chains are typically unidirectional, I may end up in situations where the bridges always have to flood all traffic.