Re: [Detnet] [DetNet] DetNet YANG Model Update

["Gengxuesong (Geng Xuesong)" <[e-mail]>]

Hi Don,

Thank you for your response and contribution to the context! Let’s discuss it in today’s call meeting.
And also, considering that the limited left time, I would like to propose an agenda for the upcoming discussion:

1.      20 min: Go through the questions in the mailing list;

2.      20 min: Go through the material Cheol prepared;

3.      20 min: Go through the text and try to add them in the existing draft;
Anyone who wants to join the discussion or has comments/suggestions/questions are welcome.

Best Regards,
Xuesong

From: detnet [mailto:[e-mail]] On Behalf Of Don Fedyk
Sent: Monday, May 18, 2020 9:56 AM
To: Gengxuesong (Geng Xuesong) <[e-mail]>
Cc: '유연철' <[e-mail]>; 'DetNet WG' <[e-mail]>; 'DetNet Chairs' <[e-mail]>
Subject: Re: [Detnet] [DetNet] DetNet YANG Model Update

Hi

I started to update the draft with some text that we can include to explain our approach.
I’m using the current xml but here is some text we can discuss.

Thanks,
Don

Suggested text
3.1.  Conventions

                 This YANG model consists of three main instances: application,
                service sub-layer and forwarding sub-layer, that need references to
                the other DetNet stage in the DetNet network.  References act as
                pointers to give a forward/backwards association for each
                unidirectional relationship.  DetNet flows are unidirectional and
                they may be paired on a device to make a bidirectional flow.  The
                other direction may also be on a completely different device.  For
                example, by configuring a DetNet service-outbound reference on an
                application the application is associated with that service sub-layer
                for traffic towards that service.  The service sub-layer is also
                associated with that application as a read only reference.  DetNet
                Services are unidirectional and have configuration options based on
                the role they play and the types of traffic mappings.

                 DetNet services also depend on the type of role they are playing for
                a particular DetNet traffic type.  DetNet Edges have application,
                service and forwarding configuration.  DetNet Relays only use DetNet
                services sub-layer and forwarding sub-layer configuration.  DetNet
                Transit nodes may only have forwarding sub-layer configuration.  The
                behavior is DetNet service dependent, such that a a physical node may
                be an edge node for some flows, it may be a relay node for some flows
                and it may be a transit node for some flows.  The full YANG model is
                defined and only the relevant aspects are configured at each stage.

              3.1.1.  Aggregation

                 Aggregation may be configured at each of the instances.  Aggregation
                is data plane specific.  DetNet Service Sub-layer MPLS aggregation
                for example, from application to service adds a per Application
                Service sub-layer label.  If a DetNet service is aggregated to
                another DetNet service there are a couple ways this can be
                accomplished.

                 A service sub-layer can appear as an application to another service
                allowing aggregation.  A service sub-layer can appear as relay
                service peering with that service.  Relay functions are dependent in
                the traffic type.  In an MPLS case this would be a logical push of
                the service label and adding another service label.  Alternatively a
                service sub-layer can be presented to a next service sub-layer as a
                peer.  The Service label in this case would be swapped.  The reason
                for this would typically be where the Detnet service is interworking
                between two domains.  One way to handle this is a complete
                termination of the DetNet service at the domain boundary.  Another
                way to deal with this by interworking the service sub-layer swapping
                the service label but keeping the control word and sequence numbers.
                Suggest keeping this out of scope since it would require additional
                mechanisms to ensure co-ordination of elimination functions.

                 There is also an impact on agregation the way that IP services
                utilize classifiers.  IP headers that are used in place aggregate by
                allowing a broader address range (wild cards) or port range or DSCP
                filter.  These aggregating flows also require the reverse operation
                to disaggregate the traffic at the edge of the DetNet service.

                3.2.  DetNet Application Flow Configuration Attributes

   DetNet application flow is responsible for mapping between
   application flows and DetNet flows at the edge node(egress/ingress
   node).  Where the application flows can be either layer 2 or layer 3
   flows.  To map a flow at the User Network Interface (UNI), the
   corresponding attributes are defined in
   [I-D.ietf-detnet-flow-information-model].

   Application operations vary in terms of the native application flow
   types.  Ethernet flows can be classified from an application by port,
   vlan or MAC addresses.  These are then associated with a DetNet
   service by means of a reference pointer.

From: detnet <[e-mail]<mailto:[e-mail]>> On Behalf Of Gengxuesong (Geng Xuesong)
Sent: Sunday, May 17, 2020 3:35 AM
To: Don Fedyk <[e-mail]<mailto:[e-mail]>>
Cc: '유연철' <[e-mail]<mailto:[e-mail]>>; 'DetNet WG' <[e-mail]<mailto:[e-mail]>>; 'DetNet Chairs' <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Detnet] [DetNet] DetNet YANG Model Update

Hi Don,

Sorry for the delay of response. I agree to split the slides, and let’s do it in the call meeting of next Monday.
Here are some questions about the current version of the parameters. (in this email, please allow me to still keep them in the same figure for convenience):

1.      Traffic  Requirement/Specification
[cid:image001.jpg@01D62D4E.00E64BC0]
These two groups of parameters exist in all three layers. What is the relationship between them:  same, mapping with each other, or totally different?


2.      Rank
[cid:image002.jpg@01D62D4E.00E64BC0]
Quote from draft-ietf-detnet-flow-information-model-10#section-5.7:
“The DnFlowRank attribute provides the rank of this flow relative to
   other flows in the DetNet domain.  Rank (range: 0-255) is used by the
   DetNet domain to decide which flows can and cannot exist when network
   resources reach their limit.  Rank is used to help to determine which
   flows can be bumped (i.e., removed from node configuration thereby
   releasing its resources) if for example a port of a node becomes
   oversubscribed (e.g., due to network re-configuration).”
I think the meaning of “rank” here is the same as above. The question is whether it only exists in service sub-layer.


3.      Classifier
[cid:image003.jpg@01D62D4E.00E64BC0]
I think the “classifier” here is similar as “flow identification” in the existing YANG Model. If it is, why there is “classifier” in the forwarding sub-layer?
And there are two “classifier” in service sub-layer, what is the difference?


4.      Encapsulation/decapsulation
Why encap/decap only exists in service sub-layer?
I have asked this question in the last call meeting and I remember the answer is that in forwarding sub-layer, encap/decap will reuse the current YANG Model in IETF. I think even if that is the case, a proper reference should be included in forwarding sub-layer. So the element should not be lost.


5.      Aggregation
As we have discussed in the call meetings, different degree of aggregation should be allowed in the Yang Model. If I understand this right, it is implemented by the “Service sub-layer Ref” in service sub-layer and “forwarding sub-layer Ref” in forwarding sub-layer. I think more discussions are needed in this point, because aggregation may not need a brand new service sub-layer/forwarding sub-layer instance, and only limited parameters are necessary.


6.      Direction
As showed in the slide:
[cid:image004.jpg@01D62D4E.00E64BC0]
The direction of the flow influence the use of the parameters. In the existing YANG model, this is showed with “in-segment” and “out-segment”. It may require some discussions about how to do this in the new YANG Model.


Best Regards
Xuesong

From: Don Fedyk [mailto:[e-mail]]
Sent: Wednesday, May 13, 2020 3:43 AM
To: Gengxuesong (Geng Xuesong) <[e-mail]<mailto:[e-mail]>>
Cc: '유연철' <[e-mail]<mailto:[e-mail]>>; 'DetNet WG' <[e-mail]<mailto:[e-mail]>>; 'DetNet Chairs' <[e-mail]<mailto:[e-mail]>>
Subject: RE: [Detnet] [DetNet] DetNet YANG Model Update

Hi Xuesong

Yes that is one way to do it. I think maybe if we had a slide per IP/ MPLS/ and Ethernet that covers the current drafts it would be beneficial.
Trying to put it all on one page may be confusing.

Cheers
Don

From: detnet <[e-mail]<mailto:[e-mail]>> On Behalf Of Gengxuesong (Geng Xuesong)
Sent: Tuesday, May 12, 2020 8:23 AM
To: Don Fedyk <[e-mail]<mailto:[e-mail]>>
Cc: '유연철' <[e-mail]<mailto:[e-mail]>>; 'DetNet WG' <[e-mail]<mailto:[e-mail]>>; 'DetNet Chairs' <[e-mail]<mailto:[e-mail]>>
Subject: [Detnet] [DetNet] DetNet YANG Model Update

Hi Don,

As discussed in the call meeting yesterday, I reorganize the figure(the first one is the original one comes from your slide, and the second one is the updated one):

[cid:image005.jpg@01D62D4E.00E64BC0]

[cid:image006.jpg@01D62D4E.00E64BC0]

Please check whether it goes along with your intention. If it does, we could continue the discussion based on this figure.


Best Regards
Xuesong