Re: [Ila] Questions about SRv6 mobile user-plane
Jeff Tantsura <[email protected]> Fri, 26 Jan 2018 10:36:05 -0800
| Newsgroups | gmane.ietf.mip6 |
|---|---|
| Message-ID | <949DAF6E-4537-4BFE-A0D5-15AC0FC5198E__16506.5786372454$1516991677$gmane$org@gmail.com> |
--===============7140440278044727170== Content-Type: multipart/alternative; boundary=Apple-Mail-DA797D09-2AFD-4691-87BD-AA53D2C9A90A Content-Transfer-Encoding: 7bit --Apple-Mail-DA797D09-2AFD-4691-87BD-AA53D2C9A90A Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Sri, My observations are very close to Tom=E2=80=99s. Is new draft going to address questions asked or there will be follow up? Thanks! Regards, Jeff > On Jan 26, 2018, at 09:19, Sri Gundavelli (sgundave) <[email protected]> w= rote: >=20 > Hi Tom: >=20 > Marco and myself are planning to publish another proposal on anchor-less m= obility (leveraging SRv6). That may be of interest to you from ILA point of v= iew. We will post the draft in one or two weeks. >=20 >=20 > Regards > Sri >=20 >=20 >=20 >=20 >=20 >=20 > From: dmm <[email protected]> on behalf of Tom Herbert <tom@quantonium.= net> > Date: Friday, January 26, 2018 at 9:13 AM > To: "[email protected]" <[email protected]>, "[email protected]" <[email protected]> > Subject: [DMM] Questions about SRv6 mobile user-plane >=20 > Hello, >=20 > I am working on a comparison between ILA and SRv6 for the mobile user-plan= e. 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: >=20 > https://datatracker.ietf.org/meeting/100/materials/slides-100-dmm-srv6-for= -mobile-user-plane/ >=20 > - It's clear from the depicted use cases that extension header insertion i= s being done by intermediate nodes, but extension header insertion is curren= tly 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 resolv= e this? >=20 > - For the uplink use cases, this seems to be more like using SR to source r= oute to an egress router. In other words, it's not strictly related to mobil= ity. Is there some connection to mobility that I'm missing? >=20 > - The size or number of SR headers in the uplink cases seems to be larger t= han necessary (IMO minimizing these is important since each additional sid i= s ~1% overhead of standard MTU). In this first scenario sid[1]=3DA2::1 and D= A=3DA2::1-- this seems to be redundant information. Also this depicts a seco= nd SR being inserted, but the first one should no longer be relevant. Why no= t just discard the first one and save the overhead? In the second scenario, D= A is changing from A2::1 to A3::1, but AFAICT that was not done per the SR p= rocessing. What is the operation that happened here? (it's actaully looks li= ke an ILA transfomation). >=20 > - 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=3D= A2. A2 makes DA=3DA3. At A3 SR is processed, DA is restored to Internet addr= ess, and EH is removed. >=20 > - For downlink this does see to be relevant to mobility. But I have the sa= me 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 ident= ifier/locator speak) and set DA to A2, and then A2 sets DA to A1, A1 restore= s original packet for delivery. >=20 > - One possible typo. In the last use case slide SA=3DS:: and DA=3DD::, I b= elieve these should be swapped? >=20 > Thanks, > Tom >=20 > =20 >=20 >=20 > _______________________________________________ > ila mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ila --Apple-Mail-DA797D09-2AFD-4691-87BD-AA53D2C9A90A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=3D= utf-8"></head><body dir=3D"auto">Hi Sri,<div><br></div><div>My observations a= re very close to Tom=E2=80=99s.</div><div>Is new draft going to address ques= tions asked or there will be follow up?</div><div><br></div><div>Thanks!<br>= <br><div id=3D"AppleMailSignature">Regards,<div>Jeff</div></div><div><br>On J= an 26, 2018, at 09:19, Sri Gundavelli (sgundave) <<a href=3D"mailto:sgund= [email protected]">[email protected]</a>> wrote:<br><br></div><blockquote ty= pe=3D"cite"><div> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii">= <div>Hi Tom:</div> <div><br> </div> <div>Marco and myself are planning to publish another proposal on anchor-les= s mobility (leveraging SRv6). That may be of interest to you from ILA point o= f view. We will post the draft in one or two weeks.</div> <div><br> </div> <div><br> </div> <div>Regards</div> <div>Sri</div> <div><br> </div> <div><br> </div> <div><br> </div> <div><br> </div> <div><br> </div> <div><br> </div> <span id=3D"OLK_SRC_BODY_SECTION"> <div style=3D"font-family:Calibri; font-size:11pt; text-align:left; color:bl= ack; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM: 0= in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; BO= RDER-RIGHT: medium none; PADDING-TOP: 3pt"> <span style=3D"font-weight:bold">From: </span>dmm <<a href=3D"mailto:dmm-= [email protected]">[email protected]</a>> on behalf of Tom Herbert <= <a href=3D"mailto:[email protected]">[email protected]</a>><br> <span style=3D"font-weight:bold">Date: </span>Friday, January 26, 2018 at 9:= 13 AM<br> <span style=3D"font-weight:bold">To: </span>"<a href=3D"mailto:[email protected]"= >[email protected]</a>" <<a href=3D"mailto:[email protected]">[email protected]</a>>,= "<a href=3D"mailto:[email protected]">[email protected]</a>" <<a href=3D"mailto:il= [email protected]">[email protected]</a>><br> <span style=3D"font-weight:bold">Subject: </span>[DMM] Questions about SRv6 m= obile user-plane<br> </div> <div><br> </div> <div> <div> <div dir=3D"ltr"> <div>Hello,</div> <div><br> </div> <div>I am working on a comparison between ILA and SRv6 for the mobile user-p= lane. I have some questions/comments about SRv6 and particularly on the exam= ple use cases that were depicted in the slides that were presented in IETF10= 0:</div> <div><br> </div> <a href=3D"https://datatracker.ietf.org/meeting/100/materials/slides-100-dmm= -srv6-for-mobile-user-plane/">https://datatracker.ietf.org/meeting/100/mater= ials/slides-100-dmm-srv6-for-mobile-user-plane/</a><br> <div><br> </div> <div>- It's clear from the depicted use cases that extension header insertio= n is being done by intermediate nodes, but extension header insertion is cur= rently prohibited by RFC8200. There was an I-D posted on 6man to allow this f= or SR, but that was met with pushback. Is there going to be followup to resolve this?</div> <div><br> </div> <div>- For the uplink use cases, this seems to be more like using SR to sour= ce route to an egress router. In other words, it's not strictly related to m= obility. Is there some connection to mobility that I'm missing?</div> <div><br> </div> <div>- The size or number of SR headers in the uplink cases seems to be larg= er than necessary (IMO minimizing these is important since each additional s= id is ~1% overhead of standard MTU). In this first scenario sid[1]=3DA2::1 a= nd DA=3DA2::1-- this seems to be redundant information. Also this depicts a second SR being inserted, but th= e 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).</div> <div><br> </div> <div>- Considering the points above, could this have been done in the follow= ing manner to minimize overhead? A1 creates one SRH with one sid and makes D= A=3DA2. A2 makes DA=3DA3. At A3 SR is processed, DA is restored to Internet a= ddress, and EH is removed.</div> <div><br> </div> <div>- 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 id= entifier/locator speak) and set DA to A2, and then A2 sets DA to A1, A1 restores original packet for delive= ry.</div> <div><br> </div> <div>- One possible typo. In the last use case slide SA=3DS:: and DA=3DD::, I= believe these should be swapped?</div> <div><br> </div> <div>Thanks,</div> <div>Tom</div> <div><br> </div> <div> </div> <div><br> </div> <div><br> </div> </div> </div> </div> </span> </div></blockquote><blockquote type=3D"cite"><div><span>____________________= ___________________________</span><br><span>ila mailing list</span><br><span= ><a href=3D"mailto:[email protected]">[email protected]</a></span><br><span><a href=3D= "https://www.ietf.org/mailman/listinfo/ila">https://www.ietf.org/mailman/lis= tinfo/ila</a></span><br></div></blockquote></div></body></html>= --Apple-Mail-DA797D09-2AFD-4691-87BD-AA53D2C9A90A-- --===============7140440278044727170== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dmm mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmm --===============7140440278044727170==--