Re: [Detnet] Comments on ip-over-tsn, mpls-over-tsn, tsn-vpn-over-mpls

[Balázs Varga A <[e-mail]>]

Hi Lou,

Thanks for the comments. Changes were uploaded to github.
https://github.com/detnet-wg/data-plane-drafts/pull/127

Changes:
- nits are resolved (in all three drafts).
- 5.2: OK, redundant paragraph was dropped.
- 5.3: I have made some simplification and reference to [I-D.ietf-detnet-mpls].
However Service Proxy is not covered by [I-D.ietf-detnet-mpls] so some text
were kept to make clear at which point the Service Proxy is involved in packet
processing when an MPLS packet is received.

Cheers
Bala’zs


From: Lou Berger <[e-mail]>
Sent: Saturday, December 5, 2020 11:56 PM
To: Balázs Varga A <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]; DetNet WG <[e-mail]>
Subject: Re: [Detnet] Comments on ip-over-tsn, mpls-over-tsn, tsn-vpn-over-mpls


Hi,

Sorry for the slow response on this.

The documents look almost ready.  Please fix the nits in all three documents.  Also I don't think you need the references and related text to RFC2119 and 8174 in the informational documents.

I do have some comments on draft-ietf-detnet-tsn-vpn-over-mpls:
Section 5.2 says:

   The management or control function that provisions flow

   mapping SHALL ensure that adequate resources are allocated and

   configured to provide proper service requirements of the mapped

   flows.

and



   A MPLS DetNet flow is configured to carry any number of TSN flows.

   The DetNet flow specific bandwidth profile SHOULD match the required

   bandwidth of the App-flow aggregate.

The second paragraph seems inconsistent with the earlier sentence, specifically the usage of "SHOULD" vs "SHALL".  The paragraph also seems redundant, why not just drop it.

Section 5.3 says:



   The LSP used to forward the DetNet packet may be of any type (MPLS-

   LDP, MPLS-TE, MPLS-TP [RFC5921], or MPLS-SR [RFC8660]).  The LSP

   (F-Label) label and/or the S-Label may be used to indicate the queue

   processing as well as the forwarding parameters.



   When a PE receives a packet from the Service Proxy function it MUST

   add to the packet the DetNet flow-ID specific S-label and create a

   d-CW.  The PE MUST forward the packet according to the configured

   DetNet Service and Forwarding sub-layer rules to other PE nodes.



   When a PE receives an MPLS packet from a remote PE, then, after

   processing the MPLS label stack, if the top MPLS label ends up being

   a DetNet S-label that was advertised by this node, then the PE MUST

   forward the packet according to the configured DetNet Service and

   Forwarding sub-layer rules to other PE nodes or via the Detnet

   Service Proxy function towards locally connected CE(s).
Is there anything in these paragraphs not covered in [I-D.ietf-detnet-mpls]? Wouldn't it be better to simply say something along the lines of:


When a PE receives a packet from the Service Proxy function it MUST handle the packet as defined in [I-D.ietf-detnet-mpls]

That's it!

Thank you,

Lou

On 11/2/2020 12:01 PM, Balázs Varga A wrote:

Hi,



TSN related documents are updated as follows:

draft-ietf-detnet-ip-over-tsn AND draft-ietf-detnet-mpls-over-tsn

- type changed to informational

- overview shortened

- changing TSN related conformance language to informative text

- stating that mappings between DetNet and TSN management and control planes are out of scope of the document

- updating references



draft-ietf-detnet-tsn-vpn-over-mpls

- overview shortened

- fixing 5.1 and 5.2 (changing TSN related conformance language to informative text)

- stating that mappings between DetNet and TSN management and control planes are out of scope of the document

- updating references



I am looking forward to discuss the changes and any additional nits in an informal meeting if needed.



Cheers

Bala'zs



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

From: BRUNGARD, DEBORAH A <[e-mail]><mailto:[e-mail]>

Sent: Wednesday, October 14, 2020 5:56 PM

To: Lou Berger <[e-mail]><mailto:[e-mail]>; DetNet WG <[e-mail]><mailto:[e-mail]>

Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>

Subject: RE: [Detnet] Comments on ip-over-tsn, mpls-over-tsn, tsn-vpn-over-mpls



Hi,



Following up on Lou's comment on the status - my view - PS would be used when defining new extensions or if there was something specifically needed for interworking. A BCP is when there are already deployments and is used to define the best current practice. An informational would apply if there are no new protocol extensions needed and the document is describing "how to use".



Looking at mpls-over-tsn, I would say the current text fits more as an informational. It doesn't really "specify", it is more a description on "how to use". Here's another document somewhat similar:

https://protect2.fireeye.com/v1/url?k=68601c1c-36c0b2d1-68605c87-866132fe445e-4fb8ad89612fddcf&q=1&e=241de548-c07a-417d-b196-b234c01f1e70&u=https%3A%2F%2Fwww.rfc-editor.org%2Frfc%2Frfc8596.txt



Usually one of the following are included in the abstract:

" This informational document follows well-established xxxx procedures and does not require any actions by IANA or any new protocol extensions."

"This document does not define new procedures or processes.  Whenever this document makes requirements statements or recommendations, these are taken from normative text in the referenced RFCs."



IF the above statements apply, I'd recommend it be Informational.



Thanks!

Deborah



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

From: detnet <[e-mail]><mailto:[e-mail]> On Behalf Of Lou Berger

Sent: Tuesday, October 13, 2020 7:21 PM

To: DetNet WG <[e-mail]><mailto:[e-mail]>

Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>

Subject: [Detnet] Comments on ip-over-tsn, mpls-over-tsn, tsn-vpn-over-mpls



Hi,



     As I mentioned on the LC thread, I have some comments on these drafts as Shepherd that I think should be addressed before passing the documents along to the IESG.



Major comment:



In reviewing the other DetNet data plane documents, some members of the IESG asked what unique protocol processing was defined in those documents that justified those documents being on the Standards Track vs Informational.  I reviewed the three TSN related documents with this in mind. (FWIW my view of goes in a standard can be found in

https://protect2.fireeye.com/v1/url?k=5cfd5f3a-025df1f7-5cfd1fa1-866132fe445e-2679b740cc532bf9&q=1&e=241de548-c07a-417d-b196-b234c01f1e70&u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Ftrac.ietf.org%2Ftrac%2Fteas%2Fwiki%2FPSGuidelines__%3B%21%21BhdT%21wNUN9uklYMF-4hszjL-VTzsSw6XgPLx9ohRxBqxY4T8Sm_MT7HljNHyL6Y4RTKY%24  , albeit a bit dated.)



I found that, as written, both draft-ietf-detnet-ip-over-tsn-03 and

draft-ietf-detnet-mpls-over-tsn-03 say basically the same thing: That an mpls or ip over TSN node behaves as a TSN unaware talker combined with an internal TSN-relay.  This is covered in section 4.2 and Figure 3 of each document.



The text of these section do have conformance language, but the language relates to TSN standardized operation. So, for me use of IETF conformance language is not appropriate.  As far as I read it, there is no protocol processing defined beyond what is in the referenced TSN documents.  For this reason, I think these documents should be revised to remove conformance language and be published as BCPs (or even

informational) .  I'd like to confer with our AD to see if she has a preference on which.



draft-ietf-detnet-tsn-vpn-over-mpls-03 is in a slightly different position.  This document also contains some TSN-specific conformance language that should be removed (e.g., see section 5.1), but it also defines TSN over MPLS specific behaviors in section 5.2.  I think this definition as a PS is pretty thin and basically comes down to saying TSN Steams are mapped to DetNet AppFlows.  This said, there is a real interoperability issue being addressed as without even this thin definition, different implementations would not necessarily interoperate.    I recommend that this document also be revised to



(a) ensure it is not using conformance language for any TSN behaviors

-- describing what an IEEE reference requires is fine, but that's just informative text, and



(b) clearly define what processing/protocol behavior is required, and what management/controller information must be supported, to be conformant the the new proposed standard.



Minor comments:



- All the documents state that there are required mappings between DetNet and TSN management and control planes, but no details are given. Rather then make unsubstantiated comments, I suggest stating that such mappings are out of scope of the document.



- All three documents repeat/summarize behaviors from the other data plane documents in overview sections.  I suggest deleting these and just point the readers and these normative documents.



- somewhat related, conformance language from the detnet-mpls is partially repeated in section 5.3 of tsn-vpn-over-mpls.  It would be better to just point to required processing in detnet-mpls than do a partial repetition.



I'm happy to work with the authors, on list or in an informal meeting announced on the list,to review these comments and any proposed changes they may propose to resolve these  comments. (I'll also provide some additional less important nits.)



Lou



(as doc Shepherd)





_______________________________________________

detnet mailing list

[e-mail]<mailto:[e-mail]>

https://protect2.fireeye.com/v1/url?k=81c8347a-df689ab7-81c874e1-866132fe445e-1fcaea3f6a7e82e6&q=1&e=241de548-c07a-417d-b196-b234c01f1e70&u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdetnet__%3B%21%21BhdT%21wNUN9uklYMF-4hszjL-VTzsSw6XgPLx9ohRxBqxY4T8Sm_MT7HljNHyLNYfs2Eg%24