[Teas] Re: NRP RE: Re: Late WGLC review of draft-ietf-teas-5g-ns-ip-mpls

[Krzysztof Szarkowicz <[e-mail]>]

Hi All,


The current version of the draft is -08:

https://datatracker.ietf.org/doc/html/draft-ietf-teas-5g-ns-ip-mpls-08


Since we didn’t received any comments since a while, we assume all comments are addressed in this version.



Dear Chairs,

Please let us known, what are the next steps.


Thanks,
Krzysztof

> On Jun 11, 2024, at 08:32, [e-mail] wrote:
> 
> Hi all, 
> 
> FWIW, I submitted an erratum to avoid the ambiguity in the definition. 
> 
> Cheers,
> Med
> 
>> -----Message d'origine-----
>> De : BOUCADAIR Mohamed INNOV/NET
>> Envoyé : lundi 3 juin 2024 09:07
>> À : 'tom petch' <[e-mail]>; Krzysztof Szarkowicz
>> <kszarkowicz=[e-mail]>; Adrian Farrel
>> <[e-mail]>
>> Cc : TEAS WG <[e-mail]>; draft-ietf-teas-5g-ns-ip-
>> [e-mail]
>> Objet : RE: [Teas] Re: NRP RE: Re: Late WGLC review of draft-
>> ietf-teas-5g-ns-ip-mpls
>> 
>> Hi Tom, all
>> 
>>> <tp>
>>> English is a wonderfully expressive language capable of
>> creating great
>>> works of literature by its ambiguity. I think that here 'and'
>> is
>>> ambiguous.  In a mathematical or scientific context, then yes,
>> 'and'
>>> is like the mathematical boolean requiring both sides to be
>> true for
>>> the result to be true.  In common English parlance, 'and' can
>> be just
>>> a synonym for 'or'.  In writing an engineering specification,
>> then it
>>> is worth spelling out which meaning is intended IMHO.  Thus if
>> this
>>> were 'both ... and ...'
>>> then I think that the boolean meaning is indicated. 'and' on
>> its own
>>> is capable of misinterpretation.  I do not see the same
>> ambiguity with
>>> 'or'.
>> 
>> English is my fourth language, so all these subtleties are good
>> to know. So, Thank you.
>> 
>> I don't think "or" does make sense in this specific context
>> because:
>> 
>> * Saying that the slice realization can be unambiguously defined
>> as "applying certain ." does not bring much value as realizing
>> anything in the network is about applying some techniques/tools
>> in the network.
>> 
>> * Also, partitioning only does not realize a slice because many
>> tweaking is needed to bind flows to a partition + control how
>> these flows will stay within a partition, etc.
>> 
>> Cheers,
>> Med
>> 
>>> -----Message d'origine-----
>>> De : tom petch <[e-mail]>
>>> Envoyé : dimanche 2 juin 2024 11:35
>>> À : Krzysztof Szarkowicz
>>> <kszarkowicz=[e-mail]>; Adrian Farrel
>>> <[e-mail]> Cc : BOUCADAIR Mohamed INNOV/NET
>>> <[e-mail]>; TEAS WG <[e-mail]>;
>>> [e-mail]
>>> Objet : Re: [Teas] Re: NRP RE: Re: Late WGLC review of draft-
>>> ietf-teas-5g-ns-ip-mpls
>>> 
>>> 
>>> From: Krzysztof Szarkowicz
>>> <kszarkowicz=[e-mail]>
>>> Sent: 31 May 2024 20:38
>>> 
>>> Hi Adrian,
>>> 
>>> Please see inline.
>>> 
>>> Cheers
>>> Krzysztof
>>> 
>>> On May 31, 2024, at 17:25, Adrian Farrel <[e-mail]>
>>> wrote:
>>> 
>>> [External Email. Be cautious of content]
>>> 
>>> Thanks Krzysztof,
>>> 
>>> A bit of careful snipping.
>>> 
>>> AF> Basically, we are ping-ponging between "It's an NRP" and
>>> "It's a slice."
>>> 
>>> [Krzysztof] I don't think so, we are ping-ponging. We have
>> constantly
>>> stated that 'transport plane'/'transfer plane' is neither NRP,
>> nor
>>> slice.
>>> 
>>> According to RFC 9543 slice is:
>>> 
>>> IETF Network Slice:
>>> The realization of the service in the provider's network
>> achieved by
>>> partitioning network resources and by applying certain tools
>> and
>>> techniques within the network ...>
>>> 
>>> Where do you see, that for example flex-algo 128 using IGP
>> metric for
>>> path calculation and flex-algo 129 using latency metric for
>> path
>>> calculation results in 'partitioning network resources'?
>>> What resources and how are partitioned in this case?
>>> 
>>> [AF] I don't see it as partitioning beyond "using some
>> resources and
>>> not others".
>>> [AF] But I do see it as "applying certain tools and techniques
>> within
>>> the network."
>>> [AF] So the "and" in the text you quote does not mean "you must
>>> partition the network resources such that only some of them are
>>> available for the network slice". I think it means "there are a
>> set of
>>> things available to you when you realize the service:
>>> these include partitioning the resources, applying tools,
>> applying
>>> techniques."
>>> 
>>> [Krzysztof] I am not native English speaker. However, my
>> understanding
>>> of 'and' is that both expressions (expression on the left hand
>> side
>>> from 'and', and expression on the right hand side from the
>> 'and') must
>>> be valid for the result to be valid. In fact, I have consulted
>> couple
>>> of my scripts to be sure, that and I can confirm, that both
>>> expressions must be true for the result to be true. As the text
>> is
>>> formulated today in RFC 9543, in order to call something
>> 'slice', both
>>> 'partitioning network resources'
>>> and 'applying certain tools and techniques' must be fulfilled.
>>> Hence, the 'transport/transfer plane' cannot be called 'slice',
>> based
>>> on current text in RFC 9543, as it doesn't involve any
>> partitioning of
>>> network resources. Multiple 'transport/transfer planes' use the
>> same
>>> resources, and not some 'other resources'.
>>> 
>>> <tp>
>>> English is a wonderfully expressive language capable of
>> creating great
>>> works of literature by its ambiguity. I think that here 'and'
>> is
>>> ambiguous.  In a mathematical or scientific context, then yes,
>> 'and'
>>> is like the mathematical boolean requiring both sides to be
>> true for
>>> the result to be true.  In common English parlance, 'and' can
>> be just
>>> a synonym for 'or'.  In writing an engineering specification,
>> then it
>>> is worth spelling out which meaning is intended IMHO.  Thus if
>> this
>>> were 'both ... and ...'
>>> then I think that the boolean meaning is indicated. 'and' on
>> its own
>>> is capable of misinterpretation.  I do not see the same
>> ambiguity with
>>> 'or'.
>>> 
>>> HTH
>>> 
>>> Tom Petch
>>> 
> 
> ____________________________________________________________________________________________________________
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
> 
> This message and its attachments may contain confidential or privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.
> 
> _______________________________________________
> Teas mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]