[Detnet] FW: draft-ietf-detnet-yang-17: IP/MPLS over TSN

[Don Fedyk <[e-mail]>]

Hi John 
FYI This contains some addition context on your comments (as well as the comment from Florian) - I believe the previous email captures these as changes but I have not merged your comments as well as Yeoncheol did here.  This is merely for reference I started with these changes and merged int the source. 

Thanks
Don

-----Original Message-----
From: 유연철 <[e-mail]> 
Sent: Tuesday, June 13, 2023 6:20 AM
To: Don Fedyk <[e-mail]>; [e-mail]; [e-mail]; [e-mail]
Subject: Re: [Detnet] draft-ietf-detnet-yang-17: IP/MPLS over TSN

Hi Don,
I have attached the diff file to the attachments.
The attached diff file is the rest of the comments added based on the txt file written by xuesong. 
The additional comments I added are marked with yc.
Please check if the requested before and after comments are correct.
Thank

Best
Yeoncheol

2023. 6. 13. 오전 4:37, "Don Fedyk" <[e-mail] <mailto:[e-mail]>> 작성:


Hi Yeoncheol Can you propose a change with before and after as usual for editorial comments? 


Thanks
Don


-----Original Message-----
From: 유연철 <[e-mail] <mailto:[e-mail]>> 
Sent: Sunday, June 11, 2023 10:25 PM
To: [e-mail] <mailto:[e-mail]>; Don Fedyk <[e-mail] <mailto:[e-mail]>>; [e-mail] <mailto:[e-mail]>; [e-mail] <mailto:[e-mail]>
Subject: Re: [Detnet] draft-ietf-detnet-yang-17: IP/MPLS over TSN


Hi authors!


we got a good comment from "Florian Kauer" about the mandatory parameter of the YANG model.
When we first created the YANG model, it seems that mandatory statements were put in using the CASE statement, but after that, it seems that mandatory was not considered while changing to a Container without the CASE statement.
So, as in the comment, the egress node also has a problem in that app-flow/ingress/interface must be set to mandatory.
It seems that the mandatory parameter in the YANG model needs to be deleted or modified.
And looking at the egress container of App-flow, if multiple app-flows are aggregated in one service, there is no way to distinguish individual app-flows from both the service sub-layer and the app-flow. So, I think the app-flow identification part in the ingress container should be added to the egress container, what do you think?


Best regards
Yeoncheol






2023. 6. 6. 오전 4:28, "detnet(Florian Kauer 대신)" <[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>([e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>> 대신)> 작성:




Hi all,




On 03.05.23 12:25, Florian Kauer wrote:
> [...] 
> My second question is regarding the use of type inet:ip-prefix in draft-ietf-detnet-yang-17.




I was able to clarify my confusion about the ip-prefix as soon as I understood the first example only describes the configuration/operational state at the ingress node and not the network as a whole - for the ingress locally, the concrete endpoint IP address is of course not relevant and the IP prefix is sufficient for flow mapping. It only got clear to me after watching Don's talk from IETF110 where he talks about how the YANG model is "vertically" on a certain node instead of "horizontally" as the flow model. Maybe it is worth mentioning it more explicitly in the draft and/or providing examples for the other nodes in the network, too, to provide the full picture.




As a step into this direction, I tried to write down the configuration for the egress node for the A-1 example (see below), but I noticed a few things:
- The leaf app-flow->ingress->interface is mandatory in the model, but in my understanding that interface does not exist since the traffic is only incoming from the service layer.
- For the service sub-layer on destination side, I would assume an "incoming forwarding-sub-layer" corresponding to the "outgoing forwarding-sub-layer" on source side.
I have now specified a "service-id" instead, but it does not contain a reference to the forwarding sub-layer. Have I used it the way it is meant to be?
- In the A-1 example, only eth0 and eth2 are used. Should the others be removed from ietf-interfaces:interfaces for clarity or do I overlook something?




Greetings,
Florian




{
"ietf-detnet:detnet": {
"traffic-profile": [
{
"name": "pf-1",
"traffic-requirements": {
"min-bandwidth": "100000000",
"max-latency": 100000000,
"max-latency-variation": 200000000,
"max-loss": "0.0000001",
"max-consecutive-loss-tolerance": 5,
"max-misordering": 0
},
"traffic-spec": {
"interval": 5,
"max-pkts-per-interval": 10,
"max-payload-size": 1500,
"min-payload-size": 100,
"min-pkts-per-interval": 1
},
"member-app": [
"app-0",
"app-1"
]
},
{
"name": "pf-2",
"traffic-requirements": {
"min-bandwidth": "200000000",
"max-latency": 100000000,
"max-latency-variation": 200000000,
"max-loss": "0.000001",
"max-consecutive-loss-tolerance": 5,
"max-misordering": 0
},
"traffic-spec": {
"interval": 5,
"max-pkts-per-interval": 10,
"max-payload-size": 1500,
"min-payload-size": 100,
"min-pkts-per-interval": 1
},
"member-service": [
"ssl-1"
]
},
{
"name": "pf-3",
"traffic-spec": {
"interval": 5,
"max-pkts-per-interval": 10,
"max-payload-size": 1500
},
"member-fwd-sublayer": [
"fsl-1"
]
}
],
"app-flows": {
"app-flow": [
{
"name": "app-0",
"bidir-congruent": false,
"incoming-service": "ssl-1",
"traffic-profile": "pf-1",
"ingress": {
"interface": "unused0"
},
"egress": {
"ip-mpls": {
"outgoing-interface": "eth1",
"next-hop-address": "2001:db8::8"
}
}
},
{
"name": "app-1",
"bidir-congruent": false,
"incoming-service": "ssl-1",
"traffic-profile": "pf-1",
"ingress": {
"interface": "unused0"
},
"egress": {
"ip-mpls": {
"outgoing-interface": "eth1",
"next-hop-address": "2001:db8::8"
}
}
}
]
},
"service": {
"sub-layer": [
{
"name": "ssl-1",
"service-rank": 10,
"traffic-profile": "pf-2",
"service-protection": {
"protection": "none",
"sequence-number-length": "long-sn"
},
"operation": "termination",
"incoming": {
"service-id": {
"mpls-label-stack": {
"entry": [
{
"id": 0,
"label": 102
}
]
}
}
},
"outgoing": {
"app-flow": {
"flow": [
"app-0",
"app-1"
]
}
}
}
]
},
"forwarding": {
"sub-layer": [
{
"name": "fsl-1",
"traffic-profile": "pf-3",
"operation": "pop-and-lookup",
"incoming": {
"forwarding-id": {
"interface": "eth0",
"mpls-label-stack": {
"entry": [
{
"id": 0,
"label": 10005
}
]
}
}
},
"outgoing": {
"service-sub-layer": {
"sub-layer": [
"ssl-1"
]
}
}
}
]
}
},
"ietf-interfaces:interfaces": {
"interface": [
{
"name": "eth0",
"type": "iana-if-type:ethernetCsmacd",
"oper-status": "up",
"statistics": {
"discontinuity-time": "2020-12-18T18:59:00-05:00"
}
},
{
"name": "eth1",
"type": "iana-if-type:ethernetCsmacd",
"oper-status": "up",
"statistics": {
"discontinuity-time": "2020-12-18T18:59:00-05:00"
}
},
{
"name": "unused0",
"type": "iana-if-type:ethernetCsmacd",
"oper-status": "up",
"statistics": {
"discontinuity-time": "2020-12-18T18:59:00-05:00"
}
}
]
}
}




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