Satoru: There are 2 deployment scenarios for mobile core: overlay on packet transport and integrated. Can you identify the line items applicable to the overlay architecture?
Kalyani -----Original Message----- From: ila [mailto:ila-boun...@ietf.org] On Behalf Of Satoru Matsushima Sent: Monday, January 29, 2018 1:30 AM To: dmm <dmm@ietf.org> Cc: Tom Herbert <t...@quantonium.net>; i...@ietf.org Subject: [E] Re: [Ila] [DMM] Questions about SRv6 mobile user-plane Hello Tom, To make the overhead discussion quantitative and realistic, I’ve made a spreadsheet of user-plane total overhead comparison by deployment scenarios. https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_spreadsheets_d_1Fx8ilE-5FbQPkhFBoSd-2DqRS5ok2IO1i0VZbmwzZJNVh0g_edit-3Fusp-3Dsharing&d=DwIGaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=IdiSODh8aDRjdCeGgd9MznLHMYKgKcs_YSwXBDiaofh47oilzaXYRYETcBynUdpT&m=_lz35skZpHqFfzeq6RxkaHJWHMyiYtwcnWZimRwEENI&s=9LAu7dC44lPXoBoWT3q4QX5sjTPDhk1cmWlg7IQe8ks&e= This includes not only for mobility, but also range of possible cases of real deployment in operators to fulfill isolation, quality and reliability requirements for mobile networks. Some of them seem most likely cases, but others sound extreme. But I’d like to share all those scenarios to make us aware of them when it comes to packet overhead in real deployments. The total overhead length of the scenarios which exceed 2x SIDs (58) and 4x SIDs (90) cases are highlighted with red color to the number and the cell respectively in the sheet. Please take a look at it. The sheet looks a bit busy but you may find some interesting points, or errors. Any comments and corrections from all of you are really welcome. Best regards, --satoru > 2018/01/27 2:13、Tom Herbert <t...@quantonium.net>のメール: > > Hello, > > I am working on a comparison between ILA and SRv6 for the mobile user-plane. > I have some questions/comments about SRv6 and particularly on the example use > cases that were depicted in the slides that were presented in IETF100: > > https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_meeting_100_materials_slides-2D100-2Ddmm-2Dsrv6-2Dfor-2Dmobile-2Duser-2Dplane_&d=DwIGaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=IdiSODh8aDRjdCeGgd9MznLHMYKgKcs_YSwXBDiaofh47oilzaXYRYETcBynUdpT&m=_lz35skZpHqFfzeq6RxkaHJWHMyiYtwcnWZimRwEENI&s=ZNHAtXtIVbyuoqhI52nadcPqREIaQSmrfuvqGd5eNs8&e= > > - It's clear from the depicted use cases that extension header insertion is > being done by intermediate nodes, but extension header insertion is currently > prohibited by RFC8200. There was an I-D posted on 6man to allow this for SR, > but that was met with pushback. Is there going to be followup to resolve this? > > - For the uplink use cases, this seems to be more like using SR to source > route to an egress router. In other words, it's not strictly related to > mobility. Is there some connection to mobility that I'm missing? > > - The size or number of SR headers in the uplink cases seems to be larger > than necessary (IMO minimizing these is important since each additional sid > is ~1% overhead of standard MTU). In this first scenario sid[1]=A2::1 and > DA=A2::1-- this seems to be redundant information. Also this depicts a second > SR being inserted, but the first one should no longer be relevant. Why not > just discard the first one and save the overhead? In the second scenario, DA > is changing from A2::1 to A3::1, but AFAICT that was not done per the SR > processing. What is the operation that happened here? (it's actaully looks > like an ILA transfomation). > > - Considering the points above, could this have been done in the following > manner to minimize overhead? A1 creates one SRH with one sid and makes DA=A2. > A2 makes DA=A3. At A3 SR is processed, DA is restored to Internet address, > and EH is removed. > > - For downlink this does see to be relevant to mobility. But I have the same > question, wouldn't it be less overhead to only use one SRH and one sid? i.e. > A3 creates an SRH with just one sid that is the S:: (identifier in > identifier/locator speak) and set DA to A2, and then A2 sets DA to A1, A1 > restores original packet for delivery. > > - One possible typo. In the last use case slide SA=S:: and DA=D::, I believe > these should be swapped? > > Thanks, > Tom > > > > > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_dmm&d=DwIGaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=IdiSODh8aDRjdCeGgd9MznLHMYKgKcs_YSwXBDiaofh47oilzaXYRYETcBynUdpT&m=_lz35skZpHqFfzeq6RxkaHJWHMyiYtwcnWZimRwEENI&s=6ufOvi6aVOB4UAgZ20C9fFetELBoi5NRATcN3cAtidY&e= _______________________________________________ ila mailing list i...@ietf.org https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_ila&d=DwIGaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=IdiSODh8aDRjdCeGgd9MznLHMYKgKcs_YSwXBDiaofh47oilzaXYRYETcBynUdpT&m=_lz35skZpHqFfzeq6RxkaHJWHMyiYtwcnWZimRwEENI&s=unue-FGp3cEFg55AqMvWox0Xn5j2Ks05OxC4LYu-kyU&e= _______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
