Re: Questions about SRv6 mobile user-plane
"Sri Gundavelli (sgundave)" <[email protected]> Fri, 26 Jan 2018 17:19:49 +0000
| Newsgroups | gmane.ietf.mip6 |
|---|---|
| Message-ID | <D690A211.2A1F12%[email protected]> |
--===============5000150726290623144== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_D690A2112A1F12sgundaveciscocom_" --_000_D690A2112A1F12sgundaveciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Tom: Marco and myself are planning to publish another proposal on anchor-less mo= bility (leveraging SRv6). That may be of interest to you from ILA point of = view. We will post the draft in one or two weeks. Regards Sri From: dmm <[email protected]<mailto:[email protected]>> on behalf of = Tom Herbert <[email protected]<mailto:[email protected]>> Date: Friday, January 26, 2018 at 9:13 AM To: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>= , "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: [DMM] Questions about SRv6 mobile user-plane 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://datatracker.ietf.org/meeting/100/materials/slides-100-dmm-srv6-for-= mobile-user-plane/ - It's clear from the depicted use cases that extension header insertion is= 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 fo= r SR, but that was met with pushback. Is there going to be followup to reso= lve this? - 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 mobi= lity. 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 t= han necessary (IMO minimizing these is important since each additional sid = is ~1% overhead of standard MTU). In this first scenario sid[1]=3DA2::1 and= DA=3DA2::1-- this seems to be redundant information. Also this depicts a s= econd SR being inserted, but the first one should no longer be relevant. Wh= y not just discard the first one and save the overhead? In the second scena= rio, DA is changing from A2::1 to A3::1, but AFAICT that was not done per t= he 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= =3DA2. A2 makes DA=3DA3. 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 sam= e 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 iden= tifier/locator speak) and set DA to A2, and then A2 sets DA to A1, A1 resto= res original packet for delivery. - One possible typo. In the last use case slide SA=3DS:: and DA=3DD::, I be= lieve these should be swapped? Thanks, Tom --_000_D690A2112A1F12sgundaveciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <[email protected]> Content-Transfer-Encoding: quoted-printable <html> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > </head> <body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; line-break:= after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-family: Cali= bri, sans-serif;"> <div>Hi Tom:</div> <div><br> </div> <div>Marco and myself are planning to publish another proposal on anchor-le= ss mobility (leveraging SRv6). That may be of interest to you from ILA poin= t of 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:b= lack; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM:= 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid;= BORDER-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 &l= t;<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:dmm@iet= f.org">[email protected]</a>" <<a href=3D"mailto:[email protected]">dmm@ietf.= org</a>>, "<a href=3D"mailto:[email protected]">[email protected]</a>" &= lt;<a href=3D"mailto:[email protected]">[email protected]</a>><br> <span style=3D"font-weight:bold">Subject: </span>[DMM] Questions about SRv6= mobile 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-= plane. I have some questions/comments about SRv6 and particularly on the ex= ample use cases that were depicted in the slides that were presented in IET= F100:</div> <div><br> </div> <a href=3D"https://datatracker.ietf.org/meeting/100/materials/slides-100-dm= m-srv6-for-mobile-user-plane/">https://datatracker.ietf.org/meeting/100/mat= erials/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 inserti= on is being done by intermediate nodes, but extension header insertion is c= urrently prohibited by RFC8200. There was an I-D posted on 6man to allow th= is for 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 sou= rce 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?</div> <div><br> </div> <div>- The size or number of SR headers in the uplink cases seems to be lar= ger than necessary (IMO minimizing these is important since each additional= sid is ~1% overhead of standard MTU). In this first scenario sid[1]=3DA2::= 1 and DA=3DA2::1-- this seems to be redundant information. Also this depicts a second SR being inserted, but t= he first one should no longer be relevant. Why not just discard the first o= ne 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 follo= wing manner to minimize overhead? A1 creates one SRH with one sid and makes= DA=3DA2. A2 makes DA=3DA3. At A3 SR is processed, DA is restored to Intern= et address, and EH is removed.</div> <div><br> </div> <div>- For downlink this does see to be relevant to mobility. But I have th= e same question, wouldn't it be less overhead to only use one SRH and one s= id? 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 deliv= ery.</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> </body> </html> --_000_D690A2112A1F12sgundaveciscocom_-- --===============5000150726290623144== 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 --===============5000150726290623144==--