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

[Don Fedyk <[e-mail]>]

Hi Xuesong

See [Don] inline.

 

Thanks Don

From: Gengxuesong (Geng Xuesong) <[e-mail]> 
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?

[Don] The traffic requirements and traffic spec must exist at the Service
Sub-layer .

The can also exist at the application.

Some values are additive  (bandwidth) some are min or maximum  (Delay). 

At the forwarding sub layer they would probably get represented as traffic
engineering number is the respected media (eg MPLS).  

 

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.

[Don] Again it must exist at the service sub layer. 

It logically exists at the application layer by association.  You have to
decide which service sub-layer the application uses and rank is a
consideration.

 

 

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?

 

[Don] Logically the function exist at many places when we consider IP
aggregation in the current documents. 

1)      It may exist the application to qualify flows.  It may also be all
traffic from a port or interfaces.

2)      In the service sub-layer it is needed when sending traffic to the
application. 

3)      It exists in the forwarding sub-layer when forwarding traffic to
the service-sublayer

 

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.

[Don] Yes we only have to define the service sub-layer encap the forwarding
encap in MPLS exists. 

 

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.

[Don] I was thinking about this. We should be using the current data plane
documents. 

I think we need to walk through an IP case and an MPLS case. 

 

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. 

[Don] I have put it in the model I supplied.  

 

 

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