Zahed,
please see inline:
On 08/06/2023 12:42, Zaheduzzaman Sarker wrote:
On Thu, Jun 8, 2023 at 9:36 AM Peter Psenak <[email protected]
<mailto:[email protected]>> wrote:
Zahed,
please see inline:
On 08/06/2023 07:00, Zaheduzzaman Sarker via Datatracker wrote:
> Zaheduzzaman Sarker has entered the following ballot position for
> draft-ietf-lsr-ip-flexalgo-13: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to
cut this
> introductory paragraph, however.)
>
>
> Please refer to
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
<https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/>
> for more information about how to handle DISCUSS and COMMENT
positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-lsr-ip-flexalgo/
<https://datatracker.ietf.org/doc/draft-ietf-lsr-ip-flexalgo/>
>
>
>
>
----------------------------------------------------------------------
> COMMENT:
>
----------------------------------------------------------------------
>
> Thanks for working on this specification.
>
> I have no comment from TSV point of view. However, the
description in section 3
> is a not clear to me. It references 5G system and N3 interfaces
then describes
> the need for UPF selection based on some sort of session needs.
However, I
> could not relate how IP addresses plays role in that selection
and where in 5G
> system this is done or planned to be done based of IP addresses?
is there any
> deployment case or already deployed UPF selection based on just
IP addresses?
yes. The real field example is where the mobile site accepts both data
and voice traffic. Voice traffic is sent from mobile site to the voice
gateway that has its own unique address. That traffic needs low latency
paths. Rest of the data traffic is routed to its destination using best
effort path.
Here, I think you are talking about the QoS framework that 3GPP has ,
and it also involves radio bearer, radio schedulers and more.
we are not claiming it's 5G specific. We are using 5G as an example -
the section name has "Example" in it. We picked the 5G example because
that is one of the real field deployments, where IP Flex-algo is used.
In the context of this draft, we focus on IP, radio portion is unchanged.
The IP
address only could be one part of it.
certainly, but that is the part relevant to this draft.
It is not the case that if you
have certain IP address your traffic would get the extra treatment it
wants.
no, but with IP flex-algo, we can make it that way.
The bearer concept is not new to 5G system and applicable to 4G
system as well. The current text I think is very shy on explaining the
concept and relating it to IP address.
All we say is that if the specific traffic/service can be identified by
the IP address, traffic to it can use constrained based paths using IP
algo.
thanks,
Peter
>
> If this section supposed to be the motivation of this whole
specification then
> it need to be improved in description on how this specification
helps in the
> usecase it describes. Or may be removed from the specification.
Section 3 is an example of the use case. It's one of the motivations
behind the spec.
I don't mind removing it, but I feel it has some value. Not sure how to
improve it, if you can suggest the better wording, I can certainly
use it.
I can help with text if I can understand use case better. Right now that
is not the case.
//Zahed
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
