Re: [CCAMP] Comments on FlexE draft "draft-izh-ccamp-flexe-fwk-04"

Hi Dieter,

Thanks for your comments!

Please see my response inline...

> -----Original Message-----
> From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Dieter Beller
> Sent: Thursday, November 16, 2017 9:41 AM
> To: Loa Andersson <loa@pi.nu>
> Cc: ccamp@ietf.org
> Subject: [CCAMP] Comments on FlexE draft "draft-izh-ccamp-flexe-fwk-04"
> 
> Hi Loa,
> 
> please find as promised during the CCAMP session the two FlexE data plane
> issues I raised regarding draft-izh-ccamp-flexe-fwk-04:
> 
> It is unclear what the intend for the semantics of the administrative locking
> function is. Is the intention that the group can be carrying live traffic when the
> group is locked? The draft indicates that it is possible to add or remove PHYs
> from a group while the group is administratively locked. The FlexE IA says that

The administrative locking is to make sure the group is out of service and adding/removal PHYs can be done safely. 

> PHYs cannot be added or removed while the group is in service. Maybe the
> intent is that this would allow to temporarily ignore errors where the two ends
> temporarily think the group is composed of a different set of PHYs and not
> bring the group down. But there is more to it than that: you need to deskew
> across a different set of PHYs, which may mean adjusting the center point of
> the skew buffers to a different spot, which can’t be assured to be hitless
> bringing up a new group with a different set of PHYs.

It may work, but this is not defined in FlexE IA.

> 
> The biggest issue is with Figure 3 which illustrates FlexE client switching, which
> is not envisioned at all in the way FlexE is designed.

No, it's not the intention. 

Section 5.3 says:

"FlexE is a true link layer technology, i.e. it is not switched, this
   means that the FlexE Groups and FlexE Clients are terminated on the
   next-hop node, and that the switching needs to take place on a higher
   layer."

> What you can do is to have a
> FlexE group at the transport network ingress and another FlexE group at the
> transport network egress, mapping the FlexE client into an ODUflex which is
> switched as an LSP from one end to the other. But what they are illustrating is a
> set of network nodes that are interconnected by FlexE groups and daisy-
> chaining this together to create a path through the network. The difficulty is
> that a FlexE client has been designed to have the semantics of an Ethernet PHY,
> which is a link rather than a layer network. The nodes they are illustrating
> would have the semantics of a kind of crossbar switch interconnecting Ethernet
> PHYs in cut-through mode. This has a bunch of issues: you are carrying the 66B
> flow over multiple link segments without going through any Ethernet bridge
> that would discard MAC frames with bad MAC FCS and the MTTFPA can’t be
> maintained, and you also have no kind of OAM that will allow you to find where
> faults or errors occurred in the network.
> 
> The draft must not add any FlexE data plane functionality and the FlexE draft
> should strictly be scoped to GMPLS control plane aspects for a given data plane.

Yes, this is the intention, if there are some places that you think are not the case, would like to discuss and update when needed.

Best regards,
Mach
> 
> 
> Thanks,
> Dieter
> 
> _______________________________________________
> CCAMP mailing list
> CCAMP@ietf.org
> https://www.ietf.org/mailman/listinfo/ccamp