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

[Don Fedyk <[e-mail]>]

Hi Jeong-dong

 

I believe you are referring to this: 

 

“ The service sub-layer generally requires

   additional header fields to provide its service; for example see

   [I-D.ietf-detnet-mpls].  Since no DetNet-specific fields are added to

   support DetNet IP flows, only the forwarding sub-layer functions are

   supported using the DetNet IP defined by this document.”

 

This means to me that the IP service sub-layer can only do functions that are allowed with the existing  headers. 

Aggregation can be accomplished by using wildcards and 6 tuple. 

In IPv4 that is about it. 

In IPv6 the ability to use the flow label is also mentioned. 


Any functions that require sequence numbers for PREOF would be not available for the current definition of  IP service sub-layer. 

We already have sequencing only in the MPLS section.  The other attributes are not put in the packet but they are part of the service

context and should apply to the IP service sub-layer.

 

So I think we are ok.

Cheers,

Don 

 

 

 

From: [e-mail] <[e-mail]> 
Sent: Monday, May 18, 2020 11:02 PM
To: 'Gengxuesong (Geng Xuesong)' <[e-mail]>; Don Fedyk <[e-mail]>
Cc: '유연철' <[e-mail]>; 'DetNet WG' <[e-mail]>; 'DetNet Chairs' <[e-mail]>
Subject: RE: Re: [Detnet] [DetNet] DetNet YANG Model Update

 

Don, Xuesong and all,

 

In the figures below, the boxes that belong to “Service Sub-layer” for “ALL” should be moved to MPLS service sub-layer since there are no sub-layer functions that can apply to DetNet IP. According to Introduction section of draft-ietf-detnet-ip-06, only the forwarding sub-layer functions are supported using the DetNet IP defined by the DetNet IP draft. 

 

In my opinion, DetNet IP flow aggregation should be done in the forwarding sub-layer. What do you think? 

 

Best regards,

 

Jeong-dong 

 

-----Original Message-----

From: "Don Fedyk" <[e-mail] <mailto:[e-mail]> >

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]> >;

Sent: 2020-05-18 (월) 10:34:22 (UTC+09:00)

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

 

Hi Xuesong

See [Don] inline.

 

Thanks Don

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



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

 



 



 

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

 

 

Best Regards

Xuesong

 

_______________________________________________ detnet mailing list [e-mail] <mailto:[e-mail]>  https://www.ietf.org/mailman/listinfo/detnet


  <https://gov-dooray.com/mail-receipts?img=727439347877746b-255f338911948417-2621d65e6362abfa-2621d985623f1374.gif>