Hi Sri, My observations are very close to Tom’s. 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]> > wrote: > > Hi Tom: > > Marco and myself are planning to publish another proposal on anchor-less > mobility (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]> on behalf of Tom Herbert > <[email protected]> > 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 > > 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 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 > > > > > _______________________________________________ > ila mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ila
_______________________________________________ dmm mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmm
