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

[Don Fedyk <[e-mail]>]

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]> On Behalf Of Gengxuesong (Geng
Xuesong)
Sent: Sunday, May 17, 2020 3:35 AM
To: Don Fedyk <[e-mail]>
Cc: '유연철' <[e-mail]>; 'DetNet WG' <[e-mail]>; 'DetNet
Chairs' <[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



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



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



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: 



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' <detnet-
[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' <detnet-
[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):

 



 



 

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

 

 

Best Regards

Xuesong