Dear Dino,
Some clarifications on your comments
>>> It was never clear to me and no one could ever explain exactly why a
TEID is needed. I presumed for accounting reasons. But if there was a
one-to-one mapping between tunnel and user, why couldn’t the inner
addresses be used for accounting?
My comments inline marked [SB]
> >>> It was never clear to me and no one could ever explain exactly why a
> TEID is needed. I presumed for accounting reasons. But if there was a
> one-to-one mapping between tunnel and user, why couldn’t the inner
> addresses be used for accounting?
> >
> >
Dear Satoru,
I am Sridhar Bhaskaran - 3GPP CT4 delegate. In addition to John's questions, I
have few more questions for clarification.
1. Section 5.2.2 of the draft says,
UPF2_in : (Z,A) -> UPF2 maps the flow w/
SID l
Hi David Lake,
Could you please clarify what is your reference for the following statement?
>> The CT4 study for future user-plane makes it clear ***that for cross-domain
>> connections GTP is problematic on N9 and alternatives could be
>> considered.
Regards
gt;>>> PHB markign in the ole days) you lose the original value.
> >>>>>>>>> Encapsulation is useful here because you can map the inner to
> >>>>>>>>> outer and anywhere along the path you can PHB remark on the
> >>>>>>>>> outer header. And then the destination can see the orignal
> >>>>>>>>> source’s ToS/QoS/TC/flow-label
> >>>>> whatever.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> [Arashmid] Yes, I agree. The original value is lost with PHB.
> >>>>>>>> Encapsulation certainly makes things easier and the inner to
> >>>>>>>> outer mapping trick has been widely used in IP and MPLS(multiple
> >>>>>>>> labels like service and transport)
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>>> Using the information in UE's IP packet header can jeopardise
> >>>>>>>>>> the above tight QoS control. I think going
> >>>>>>>>>
> >>>>>>>>> Not if you encapsulate. But note with SRv6, you can possibly
> >>>>>>>>> retain the original flow-label if the SID can retain those bits
> >>>>>>>>> before overwriting the destination address from the option’s
> value.
> >>>>>>>>
> >>>>>>>> [Arashmid] Agree. Encapsulation does the trick again. That's why
> >>>>>>>> GTP has worked well and served the purpos in the mobile
> >>>>>>>> back-haul so far.
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Dino
> >>>>>>>>>
> >>>>>>>>>> down this path, operators need proof that they will be still
> >>>>>>>>>> in the driving
> >>>>>>>>> seat and QoS cannot be dictated/tampered by the UE or any
> >>>>>>>>> application running in it.
> >>>>>>>>>>
> >>>>>>>>>> Now, here is an interesting question for the operators. Would
> >>>>>>>>>> any operator
> >>>>>>>>> be interested in allowing QoS to be set by the UE or by
> >>>>>>>>> applications running in the UE and charged for by the network?
> >>>>>>>>> "Yes" could potentially imply impacts on the air interface, UE
> >>>>>>>>> resource block allocation and can make scheduling on the RAN
> >>>>>>>>> side
> >>>>> much more complex.
> >>>>>>>>>>
> >>>>>>>>>> Arashmid
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>> -Original Message-
> >>>>>>>>>>> From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Dino
> >>>>>>>>>>> Farinacci
> >>>>>>>>>>> Sent: 06 September 2018 12:45
> >>>>>>>>>>> To: Tom Herbert
> >>>>>>>>>>> Cc: ta-miyas...@kddi-research.jp; dmm
> >>>>>>>>>>> Subject: Re: [DMM] Comments to draft-hmm-dmm-5g-uplane-
> >>>>> analysis-
> >>>>>>> 01
> >>>>>>>>>>>
> >>>>>>>>>>>> Behcet,
> >>>>>>>>>>>>
> >>>>>>>>>>>> I was thinking if TEID is need then that can be encoded in a
> >>>>>>>>>>>> locator easily enough.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Tom
> >>>>>>>>>>>
> >>>>>>>>>>> Not if a locator is a PGW that is shared by many UEs.
> >>>>>>>>>>>
> >>>>>>>>>>> 3GPP wants per bearer awareness so they need a specific ID,
> >>>>>>>>>>> that could have been the UE’s IP address. And with IPv6 it
> >>>>>>>>>>> can be unique and not the issue that Sridhar brought up.
> >>>>>>>>>>>
> >>>>>>>>>>> If ILA was in use, just use the ILA-ID for this purpose.
> >>>>>>>>>>>
> >>>>>>>>>>> Dino
> >>>>>>>>>>>
> >>>>>>>>>>> ___
> >>>>>>>>>>> dmm mailing list
> >>>>>>>>>>> dmm@ietf.org
> >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/dmm
> >>>>>>>>
> >>>>
> >>>
> >>> ___
> >>> dmm mailing list
> >>> dmm@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/dmm
> >>>
> >>
> >>
> >
> > ___
> > dmm mailing list
> > dmm@ietf.org
> > https://www.ietf.org/mailman/listinfo/dmm
> > ___
> > dmm mailing list
> > dmm@ietf.org
> > https://www.ietf.org/mailman/listinfo/dmm
> >
>
>
> --
> --
> Shunsuke Homma
> >
> TEL: +81 422 59 3486
> FAX: +81 422 60 7460
>
> NTT Network Service Systems Labs.
> Musashino city, Tokyo, Japan
> --
>
> ___
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm
>
> ___
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm
>
--
o__
_> /__
(_) \(_)... Burn fat not fuel - Bike along to a healthier life and cleaner
world! :)
Sridhar Bhaskaran
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm
Dear Shunsuke,
Thank you for your responses. My further comments inline marked [SB-2]
Regards
Sridhar Bhaskaran
-Original Message-
From: Shunsuke Homma [mailto:homma.shuns...@lab.ntt.co.jp]
Sent: Wednesday, January 16, 2019 9:30 AM
To: Sridhar Bhaskaran ; dmm@ietf.org
Subject: Re
the UP over the wire? What are the issues with providing a "network instance"
(which could be mapped to a transport path) in the forwarding action rule of a
PDU session?
What are the advantages of carrying slice information in every packet?
Regards
Sridhar Bhaskaran
to the UPF for the
PDU session?
I may have number of other questions. But a basic clarity on the above is
required first. Could the authors please clarify?
Regards
Sridhar Bhaskaran
-Original Message-
From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of internet-dra...@ietf.org
Sent: Tu
and BP UPF are applicable to all SSC modes. SSC
modes do not have any relevance when selecting a transport path. The
description of SSC modes need to be corrected to rather reflect how / where the
PPR-ID is applied for different SSC modes.
Regards
Sridhar Bhaskaran
lt;https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdmm=04%7C01%7Cjohn.kaippallimalil%40futurewei.com%7C77632db844b34a8e561108d8bdb38cb8%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637467926158632424%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0
hairs
>
>
> ___
> dmm mailing list
> dmm@ietf.org
> www.ietf.org/mailman/listinfo/dmm
>
> ___
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailm
for passing
> information from the mobile network to transport network? whether there is
> any simplification or omission of information in the mapping to the DSCP?
>
>
>
> Best
>
> Xuesong
>
>
>
>
>
> *From:* Apn [mailto:apn-boun...@ietf.org] *On Behalf Of *Sridhar Bhas
ormation for differentiated services in transport network, although the
> two parameters act in different scopes?
>
>
>
> Best
>
> Xuesong
>
>
>
> *From:* Sridhar Bhaskaran [mailto:sridhar.bhaska...@gmail.com]
> *Sent:* Friday, January 22, 2021 12:39 PM
> *To:* Kaip
__
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm
>
--
o__
_> /__
(_) \(_)... Burn fat not fuel - Bike along to a healthier life and cleaner
world! :)
Sridhar Bhaskaran
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm
s a good comment. We can consider revising the text to
emphasize this in the next revision.
Thank you.
>
> Linda Dunbar
>
>
>
> ___
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm
>
--
o__
_> /__
(_) \(_)..
15 matches
Mail list logo
