[Teas] Packwt delay variation was Re: Éric Vyncke's No Objection on draft-ietf-teas-ietf-network-slices-22: (with COMMENT)

[tom petch <[e-mail]>]

From: Teas <[e-mail]> on behalf of Eric Vyncke (evyncke) <evyncke=[e-mail]>
Sent: 10 August 2023 06:29

Thank you, Adrian, for your detailed reply.

For the authors count, the authors being part of the WG, their point of view was implicit.

I was unaware that 'jitter' meant different things to many people, nice to know.

<tp>

The IPPM WG have been using packet delay variation for over 20 years and there is a definition thereof in RFC8912, citing RFC3393, to whit

"   This metric assesses packet delay variation with respect to the
   minimum delay observed on the periodic stream.  The output is
   expressed as the 95th percentile of the one-way packet delay
   variation distribution."

which is not what I would understand by jitter.

Tom Petch

Same as well for the {x, y, z} notation in RTG area, I often see <x, y, z> for tuples. But, if this is the RTG notation, then let's be it

Regards, (no need to reply)

-éric

On 09/08/2023, 19:21, "Adrian Farrel" <[e-mail] <mailto:[e-mail]>> wrote:


Thanks for reading, Eric.


Tl;dr No changes to the text in this case


> # COMMENTS
>
> ## Authors count
>
> This is mainly a note for the IESG as I wonder why for some WG/authors it is OK
> to have 7 authors and for some other WG/authors 6 is too many. IMHO, it is up
> to the WG to decide, hence I can only support having 7 authors on this one.
> I.e., no need for the authors/WG to reply.


Appreciate that you are not asking the authors, but this is something I care about.
I don't believe any number above 5 is OK for any WG.
But "special circumstances" apply in different cases and could suggest any number of authors if there is adequate justification.


The authors, I suppose, make their case, the shepherd analyses and synthesises, the chairs OK, the responsible AD approves, and the IESG filters.


> ## Section 2.3
>
> "Customers" request a service slice but do customers also use this slice ?


Section 3.2? There being no section 2.3, but the definition of "customer" is in 3.2.


Be careful to see the distinction between a slice and a slice service. This paragraph talks about a customer using a service (provided by...)


> Is it a common and accepted use of curled brackets in `{IETF Network Slice
> Service, connectivity construct, and SLOs/SLEs}` ? Honestly, I cannot
> understand the difference with normal parenthesis.


It is "common" to denote tuples with curly braces in RTG area RFCs, I think.


At worst they don't indicate a difference (to you), and at best they are understood as a tuple.


> ## Section 5.1.1.1.
>
> Should security also be part of SLO ? It is only mentioned in section 5.1.2.1.


Oh, but!
5.1.2.1 is about SLEs and 5.1.1.1 is about SLOs.
Security (provided by the network) is something the customer may request, but which the customer cannot (easily, through end-system measurements) verify to have been provided.
Thus, security cannot be an SLO, but might be an SLE.


> Is there a difference between the commonly used term of 'jitter' and the 'delay
> variation' ?


Oh, wow!
I have just been thoroughly through the mill with Bob Braden discussing draft-ietf-teas-rfc3272bis and the difference between jitter and delay variation.
I *think* that, in this case, packet delay variation is as defined in RFC 3393 (as cited in this document in 5.1.1.1) where it helpfully says, "The variation in packet delay is sometimes called "jitter". This
term, however, causes confusion because it is used in different ways by different groups of people." It then goes on to explain some of the interpretations applied to "jitter".


> ## Section 5.1.2.1.
>
> Is security only limited to 'encryption' (assuming that the end-goal is
> actually confidentiality with encryption being one means and not then end).
> Should also be authentication be part of the security ?


The text says:
A customer may request that the provider applies
encryption or other security techniques to traffic flowing between
SDPs of a connectivity construct within an IETF Network Slice
Service.


So, yes, the customer could make additional security requests of the service.
I'm not sure how authentication would be provided. It could be required in order to access the service (that is outside the specification of the service, I think), and it might be applied within the provider's network to authenticate that traffic arriving at an egress SDP came from the ingress SDP (although, there is not normally a requirement that the traffic being delivered at a network exit is matched to a network entry).


> ## Section 6.1
>
> Does an IETF network slice always require a centralised controller ? AFAICT,
> MPLS-VPN or EVPN are instances of IETF network slices and they usually do not
> require any controller.


So, who determines which sites are part of a VPN? Arguably, the user just goes to the egress and configures iBGP to advertise VPN membership. Except, how do you know which VPN ID to use?
There is some logical central controller (OSS or BSS in old money) that "owns" the information that defines the service.
What goes on in an NSC might be very lightweight in some realisations (e.g., those that use a L3VPN to realise slicing), but may be more complex in more scalable systems where the topology needs to be diced.


> ## RFC 8799
>
> Should RFC 8799 be mentioned in this document ?


We all love the Independent Stream.


I see three mentions of "domain" in this document:
2. "administrative domain"
6.2. "administrative domain"
6.3. "multi-domain"


Probably this document is not relying on any definition of a "limited domain" for its function. If you can see different, please say and we will try to fix it up.


Cheers,
Adrian





_______________________________________________
Teas mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/teas