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

From: "Gengxuesong (Geng Xuesong)" <[email-masked]>
Date: Tue, 12 May 2020 12:23:24 +0000

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

---

From: "Don Fedyk" <[email-masked]>
Date: Tue, 12 May 2020 15:42:41 -0400

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 <[email-masked]> On Behalf Of Gengxuesong (Geng
Xuesong)
Sent: Tuesday, May 12, 2020 8:23 AM
To: Don Fedyk <[email-masked]>
Cc: '유연철' <[email-masked]>; 'DetNet WG' <[email-masked]>; 'DetNet
Chairs' <[email-masked]>
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

---

From: "Gengxuesong (Geng Xuesong)" <[email-masked]>
Date: Sun, 17 May 2020 07:34:36 +0000

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:[email-masked]]
Sent: Wednesday, May 13, 2020 3:43 AM
To: Gengxuesong (Geng Xuesong) <[email-masked]>
Cc: '유연철' <[email-masked]>; 'DetNet WG' <[email-masked]>; 'DetNet Chairs' <[email-masked]>
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 <[email-masked]<mailto:[email-masked]>> On Behalf Of Gengxuesong (Geng Xuesong)
Sent: Tuesday, May 12, 2020 8:23 AM
To: Don Fedyk <[email-masked]<mailto:[email-masked]>>
Cc: '유연철' <[email-masked]<mailto:[email-masked]>>; 'DetNet WG' <[email-masked]<mailto:[email-masked]>>; 'DetNet Chairs' <[email-masked]<mailto:[email-masked]>>
Subject: [Detnet] [DetNet] DetNet YANG Model Update

Hi Don,

Best Regards
Xuesong

---

From: "Don Fedyk" <[email-masked]>
Date: Sun, 17 May 2020 21:33:34 -0400

Hi Xuesong

See [Don] inline.

Thanks Don

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

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

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

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:[email-masked]] 
Sent: Wednesday, May 13, 2020 3:43 AM
To: Gengxuesong (Geng Xuesong) <[email-masked]
<mailto:[email-masked]> >
Cc: '유연철' <[email-masked] <mailto:[email-masked]> >; 'DetNet
WG' <[email-masked] <mailto:[email-masked]> >; 'DetNet Chairs' <detnet-
[email-masked] <mailto:[email-masked]> >
Subject: RE: [Detnet] [DetNet] DetNet YANG Model Update

Hi Xuesong

Cheers

Don 

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

Hi Don,

 

 

Best Regards

Xuesong

---

From: "Don Fedyk" <[email-masked]>
Date: Sun, 17 May 2020 21:56:25 -0400

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.

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

Hi Don,

2.      Rank

3.      Classifier

5.      Aggregation

6.      Direction 

As showed in the slide: 

 

Best Regards

Xuesong

Hi Xuesong

Cheers

Don 

Hi Don,

 

 

Best Regards

Xuesong

---

From: "Gengxuesong (Geng Xuesong)" <[email-masked]>
Date: Mon, 18 May 2020 11:54:13 +0000

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:[email-masked]] On Behalf Of Don Fedyk
Sent: Monday, May 18, 2020 9:56 AM
To: Gengxuesong (Geng Xuesong) <[email-masked]>
Cc: '유연철' <[email-masked]>; 'DetNet WG' <[email-masked]>; 'DetNet Chairs' <[email-masked]>
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.

Hi Don,

2.      Rank

3.      Classifier

5.      Aggregation

6.      Direction
As showed in the slide:

Best Regards
Xuesong

To: Gengxuesong (Geng Xuesong) <[email-masked]<mailto:[email-masked]>>

Hi Xuesong

Cheers
Don

Hi Don,

Best Regards
Xuesong

---

From: 류정동 <[email-masked]>
Date: Tue, 19 May 2020 12:02:01 +0900 (KST)

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.&nbsp;

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

Best regards,
&nbsp;
Jeong-dong&nbsp;

-----Original Message-----
From: "Don Fedyk" &lt;[email-masked]&gt;
To: "'Gengxuesong (Geng Xuesong)'" &lt;[email-masked]&gt;;
Cc: "'유연철'" &lt;[email-masked]&gt;; "'DetNet WG'" &lt;[email-masked]&gt;; "'DetNet Chairs'" &lt;[email-masked]&gt;;
Sent: 2020-05-18 (월) 10:34:22 (UTC+09:00)
Subject: Re: [Detnet] [DetNet] DetNet YANG Model Update

Hi Xuesong
See&nbsp;[Don] inline.
&nbsp;
Thanks Don
From:&nbsp;Gengxuesong (Geng Xuesong) &lt;[email-masked]&gt; Sent: Sunday, May 17, 2020 3:35 AMTo: Don Fedyk &lt;[email-masked]&gt;Cc: '유연철' &lt;[email-masked]&gt;; 'DetNet WG' &lt;[email-masked]&gt;; 'DetNet Chairs' &lt;[email-masked]&gt;Subject: RE: [Detnet] [DetNet] DetNet YANG Model Update

&nbsp;
Hi Don,
&nbsp;
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):
Traffic &nbsp;Requirement/Specification

These two groups of parameters exist in all three layers. What is the relationship between them: &nbsp;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 &nbsp;(bandwidth) some are min or maximum &nbsp;(Delay).&nbsp;
At the forwarding sub layer they would probably get represented as traffic engineering number is the respected media (eg MPLS). &nbsp;
&nbsp;
Rank

Quote from draft-ietf-detnet-flow-information-model-10#section-5.7:
“The DnFlowRank attribute provides the rank of this flow relative to
&nbsp; &nbsp;other flows in the DetNet domain. &nbsp;Rank (range: 0-255) is used by the
&nbsp; &nbsp;DetNet domain to decide which flows can and cannot exist when network
&nbsp; &nbsp;resources reach their limit. &nbsp;Rank is used to help to determine which
&nbsp; &nbsp;flows can be bumped (i.e., removed from node configuration thereby
&nbsp; &nbsp;releasing its resources) if for example a port of a node becomes
&nbsp; &nbsp;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.&nbsp;
It logically exists at the application layer by association. &nbsp;You have to decide which service sub-layer the application uses and rank is a consideration.
&nbsp;
&nbsp;
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?
&nbsp;
[Don] Logically the function exist at many places when we consider IP aggregation in the current documents.&nbsp;
It may exist the application to qualify flows. &nbsp;It may also be all traffic from a port or interfaces.
In the service sub-layer it is needed when sending traffic to the application.&nbsp;
It exists in the forwarding sub-layer when forwarding traffic to the service-sublayer
&nbsp;
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.&nbsp;
&nbsp;
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.&nbsp;
I think we need to walk through an IP case and an MPLS case.&nbsp;
&nbsp;
Direction&nbsp;
As showed in the slide:&nbsp;

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.&nbsp;
[Don] I have put it in the model I supplied. &nbsp;
&nbsp;
&nbsp;
Best Regards
Xuesong
&nbsp;
From:&nbsp;Don Fedyk [mailto:[email-masked] mailto:[email-masked]] Sent: Wednesday, May 13, 2020 3:43 AMTo: Gengxuesong (Geng Xuesong) &lt;[email-masked] mailto:[email-masked]&gt;Cc: '유연철' &lt;[email-masked] mailto:[email-masked]&gt;; 'DetNet WG' &lt;[email-masked] mailto:[email-masked]&gt;; 'DetNet Chairs' &lt;[email-masked] mailto:[email-masked]&gt;Subject: RE: [Detnet] [DetNet] DetNet YANG Model Update

&nbsp;
Hi Xuesong
&nbsp;
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.&nbsp;
Trying to put it all on one page may be confusing. &nbsp;
&nbsp;
Cheers
Don&nbsp;
&nbsp;
From:&nbsp;detnet &lt;[email-masked] mailto:[email-masked]&gt; On Behalf Of&nbsp;Gengxuesong (Geng Xuesong)Sent: Tuesday, May 12, 2020 8:23 AMTo: Don Fedyk &lt;[email-masked] mailto:[email-masked]&gt;Cc: '유연철' &lt;[email-masked] mailto:[email-masked]&gt;; 'DetNet WG' &lt;[email-masked] mailto:[email-masked]&gt;; 'DetNet Chairs' &lt;[email-masked] mailto:[email-masked]&gt;Subject: [Detnet] [DetNet] DetNet YANG Model Update

&nbsp;
Hi Don,
&nbsp;
&nbsp;

&nbsp;

&nbsp;
&nbsp;
&nbsp;
Best Regards
Xuesong
&nbsp;

_______________________________________________
detnet mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/detnet

---

From: "Don Fedyk" <[email-masked]>
Date: Tue, 19 May 2020 09:02:33 -0400

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: [email-masked] <[email-masked]> 
Sent: Monday, May 18, 2020 11:02 PM
To: 'Gengxuesong (Geng Xuesong)' <[email-masked]>; Don Fedyk <[email-masked]>
Cc: '유연철' <[email-masked]>; 'DetNet WG' <[email-masked]>; 'DetNet Chairs' <[email-masked]>
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" <[email-masked] <mailto:[email-masked]> >

To: "'Gengxuesong (Geng Xuesong)'" <[email-masked] <mailto:[email-masked]> >;

Cc: "'유연철'" <[email-masked] <mailto:[email-masked]> >; "'DetNet WG'" <[email-masked] <mailto:[email-masked]> >; "'DetNet Chairs'" <[email-masked] <mailto:[email-masked]> >;

Hi Xuesong

See [Don] inline.

Thanks Don

From: Gengxuesong (Geng Xuesong) <[email-masked] <mailto:[email-masked]> > 
Sent: Sunday, May 17, 2020 3:35 AM
To: Don Fedyk <[email-masked] <mailto:[email-masked]> >
Cc: '유연철' <[email-masked] <mailto:[email-masked]> >; 'DetNet WG' <[email-masked] <mailto:[email-masked]> >; 'DetNet Chairs' <[email-masked] <mailto:[email-masked]> >
Subject: RE: [Detnet] [DetNet] DetNet YANG Model Update

Hi Don,

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

2.      Rank

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

[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

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

5.      Aggregation

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

6.      Direction 

As showed in the slide: 

 

Best Regards

Xuesong

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

Hi Xuesong

Cheers

Don 

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

Hi Don,

 

 

Best Regards

Xuesong

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

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

---

From: Jeong-dong Ryoo <[email-masked]>
Date: Wed, 20 May 2020 15:21:38 +0900 (KST)

Hi, Don,

Thank you for your email.

Yes, that is one piece of text that I was referring to. In addition, there is another piece of text below Figure 1:"The dotted line around the Service component of the Relay Nodes indicates that the transit routers are DetNet service aware but do not perform any DetNet service sub-layer function, e.g., PREOF (Packet Replication, Elimination and Ordering Function)."Please, note that the DetNet IP nodes do not perform "any" DetNet service sub-layer function.

With those two parts of text, I can conclude that we don't need to have service sub-layer parameters in DetNet YANG.&nbsp;
I think it is ok for a DetNet service to require only one sub-layer, not all sub-layers.&nbsp;

I don't think aggregation is the property that only the service sublayer can have. Every sub-layer can do the aggregation,&nbsp;
and often times, multiple flows of a one sub-layer are presented to its server (underlying) sub-layer as one aggregated flow.

Anyway, we can put the IP aggregation in either place. I just wanted to see a YANG model that is more aligned with architecture and data plane documents.

Best regards,

Jeong-dong

-----Original Message-----
From: "Don Fedyk" &lt;[email-masked]&gt;
To: &lt;[email-masked]&gt;; "'Gengxuesong (Geng Xuesong)'" &lt;[email-masked]&gt;;
Cc: "'유연철'" &lt;[email-masked]&gt;; "'DetNet WG'" &lt;[email-masked]&gt;; "'DetNet Chairs'" &lt;[email-masked]&gt;;
Sent: 2020-05-19 (화) 22:02:57 (UTC+09:00)
Subject: RE: Re: [Detnet] [DetNet] DetNet YANG Model Update

Hi Jeong-dong
&nbsp;
I believe you are referring to this:
&nbsp;
“ The service sub-layer generally requires
&nbsp; &nbsp;additional header fields to provide its service; for example see
&nbsp; &nbsp;[I-D.ietf-detnet-mpls]. &nbsp;Since no DetNet-specific fields are added to
&nbsp; &nbsp;support DetNet IP flows, only the forwarding sub-layer functions are
&nbsp; &nbsp;supported using the DetNet IP defined by this document.”
&nbsp;
This means to me that the IP service sub-layer can only do functions that are allowed with the existing &nbsp;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 &nbsp;IP service sub-layer.
We already have sequencing only in the MPLS section. &nbsp;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.
&nbsp;
So I think we are ok.
Cheers,
Don
&nbsp;
&nbsp;
&nbsp;
From: [email-masked] &lt;[email-masked]&gt;Sent: Monday, May 18, 2020 11:02 PMTo: 'Gengxuesong (Geng Xuesong)' &lt;[email-masked]&gt;; Don Fedyk &lt;[email-masked]&gt;Cc: '유연철' &lt;[email-masked]&gt;; 'DetNet WG' &lt;[email-masked]&gt;; 'DetNet Chairs' &lt;[email-masked]&gt;Subject: RE: Re: [Detnet] [DetNet] DetNet YANG Model Update

&nbsp;
Don, Xuesong and all,

&nbsp;

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.&nbsp;
&nbsp;
In my opinion, DetNet IP flow aggregation should be done in the forwarding sub-layer. What do you think?&nbsp;
&nbsp;
Best regards,
&nbsp;

Jeong-dong&nbsp;
&nbsp;

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

From: "Don Fedyk" &lt;[email-masked] mailto:[email-masked]&gt;

To: "'Gengxuesong (Geng Xuesong)'" &lt;[email-masked] mailto:[email-masked]&gt;;

Cc: "'유연철'" &lt;[email-masked] mailto:[email-masked]&gt;; "'DetNet WG'" &lt;[email-masked] mailto:[email-masked]&gt;; "'DetNet Chairs'" &lt;[email-masked] mailto:[email-masked]&gt;;

&nbsp;

Hi Xuesong
See [Don] inline.
&nbsp;
Thanks Don
From: Gengxuesong (Geng Xuesong) &lt;[email-masked] mailto:[email-masked]&gt;Sent: Sunday, May 17, 2020 3:35 AMTo: Don Fedyk &lt;[email-masked] mailto:[email-masked]&gt;Cc: '유연철' &lt;[email-masked] mailto:[email-masked]&gt;; 'DetNet WG' &lt;[email-masked] mailto:[email-masked]&gt;; 'DetNet Chairs' &lt;[email-masked] mailto:[email-masked]&gt;Subject: RE: [Detnet] [DetNet] DetNet YANG Model Update

&nbsp;
Hi Don,
&nbsp;
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.&nbsp; &nbsp; &nbsp;&nbsp;Traffic &nbsp;Requirement/Specification

2.&nbsp; &nbsp; &nbsp;&nbsp;Rank

3.&nbsp; &nbsp; &nbsp;&nbsp;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?
&nbsp;
[Don] Logically the function exist at many places when we consider IP aggregation in the current documents.&nbsp;
1)&nbsp; &nbsp; &nbsp;&nbsp;It may exist the application to qualify flows. &nbsp;It may also be all traffic from a port or interfaces.
2)&nbsp; &nbsp; &nbsp;&nbsp;In the service sub-layer it is needed when sending traffic to the application.&nbsp;
3)&nbsp; &nbsp; &nbsp;&nbsp;It exists in the forwarding sub-layer when forwarding traffic to the service-sublayer
&nbsp;
4.&nbsp; &nbsp; &nbsp;&nbsp;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.&nbsp;
&nbsp;
5.&nbsp; &nbsp; &nbsp;&nbsp;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.&nbsp;
I think we need to walk through an IP case and an MPLS case.&nbsp;
&nbsp;
6.&nbsp; &nbsp; &nbsp;&nbsp;Direction&nbsp;
As showed in the slide:&nbsp;

&nbsp;
Hi Xuesong
&nbsp;
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.&nbsp;
Trying to put it all on one page may be confusing. &nbsp;
&nbsp;
Cheers
Don&nbsp;
&nbsp;
From: detnet &lt;[email-masked] mailto:[email-masked]&gt; On Behalf Of&nbsp;Gengxuesong (Geng Xuesong)Sent: Tuesday, May 12, 2020 8:23 AMTo: Don Fedyk &lt;[email-masked] mailto:[email-masked]&gt;Cc: '유연철' &lt;[email-masked] mailto:[email-masked]&gt;; 'DetNet WG' &lt;[email-masked] mailto:[email-masked]&gt;; 'DetNet Chairs' &lt;[email-masked] mailto:[email-masked]&gt;Subject: [Detnet] [DetNet] DetNet YANG Model Update

&nbsp;
Hi Don,
&nbsp;

&nbsp;

&nbsp;

_______________________________________________ detnet mailing list [email-masked] mailto:[email-masked] https://www.ietf.org/mailman/listinfo/detnet https://www.ietf.org/mailman/listinfo/detnet

&nbsp;

---

From: "Don Fedyk" <[email-masked]>
Date: Sun, 24 May 2020 22:48:42 -0400

Hi all

I have placed a walk through of a DetNet IP application over an MPLS DetNet
service highlighting the relevant pieces for each step in my flow model
YANG.

https://github.com/detnet-wg/draft-ietf-detnet-yang/issues/12

Perhaps if you could do the same for the current DetNet config model YANG
we could compare on the Monday (USA) call.  The Call is at the original
time. 

Thanks

Don

---

From: cheol's imac <[email-masked]>
Date: Mon, 25 May 2020 13:40:48 +0900

Thank you for uploading the material.

I have also placed a set of slides that contains some scenarios and examples of the current DetNet config model YANG.

https://github.com/detnet-wg/draft-ietf-detnet-yang/issues/11

Best Regards,

Yeoncheol

출발: detnet <[email-masked]>(Don Fedyk <[email-masked]> 대신)
날짜: 2020년 5월 25일 월요일 오후 12:04
받는 사람: "'Gengxuesong (Geng Xuesong)'" <[email-masked]>
참조: '유연철' <[email-masked]>, 'DetNet WG' <[email-masked]>, 'DetNet Chairs' <[email-masked]>
주제: Re: [Detnet] [DetNet] DetNet YANG Model Update

Hi all

I have placed a walk through of a DetNet IP application over an MPLS DetNet service highlighting the relevant pieces for each step in my flow model YANG.

Perhaps if you could do the same for the current DetNet config model YANG we could compare on the Monday (USA) call.  The Call is at the original time. 

Thanks

Don 

_______________________________________________ detnet mailing list [email-masked] https://www.ietf.org/mailman/listinfo/detnet