Dear Ron, *> Furthermore, we should engineer for future requirements. *
Well let's see if we can meet current requirements first. Imagine that I have a trusted overlay domain over non trusted and non SR aware IPv6 underlay (likely operated by completely different team of engineers). My POPs are addressed from PA space I am attached to (for example my POPs are virtual computes in various cloud providers) and I have no freedom to choose IPv6 prefix to be the same across all such POPs. That effectively means that unless I insert full 128 bits to the packet header I will not be able to perform any segment routing in my existing network as clearly the base of your proposal relies on the fact that you have common IPv6 prefix (in your appendix 2001:db8::/64). Bottom line CRH does not work for this deployment model. *> Generally speaking, we should design for efficiency. * True and there is always the question of the right balance. Let's zoom into control plane aspect of your proposal. In your proposal your packet destination addresses MUST not be aggregated nor summarized for the apparatus to work. That is the same mistake as was made with MPLS exact match where today many networks is suffering with 1000s of /32s all over the place. Now we are talking about the same or even greater amount of /128s. No transit L3 network will allow me to inject those /128s for a very valid reasons. Consider that my network grows I would see value of ISIS area abstraction as presented this week in LSR. Well that means that again I would need to pollute my entire domain with host routes to make use of your idea. *Conclusion:* Yes I would like to significantly reduce packet size too that's why I proposed solution which can accomplish the goal all in control plane by proper handing of BGP indirection and recursion: REF: https://slideplayer.com/slide/12853563/ CRH assuming that the described above properties are not showstoppers for given deployment saves with say stack of five 32 bit SIDs for most common 576 bytes imix packet size 10% of saving when SID size goes down to 8 bits the saving are 13%. IMO we should have proper data plane solution as well as control plane solution not something in between which works only in specific scenarios are which again breaks basic IP address aggregation. Kind regards, Robert. PS. But if you choose to go ahead with CRH I would highly advise to make your CRH SID a variable length. On Fri, Mar 29, 2019 at 7:02 PM Ron Bonica <rbonica= [email protected]> wrote: > Hi Rajiv, > > Thanks for these kind words. > > Generally speaking, we should design for efficiency. Furthermore, we > should engineer for future requirements. For example, in the future, > service providers may require longer SID lists (5 or more!). We should plan > for that today. > > Likewise, in the future, people may deploy new applications that emit > short packets. We should also plan for that today. > > If we don't plan for future requirements, obsolescence will be much closer > than we expect. > > Ron > > > Juniper Internal > > > -----Original Message----- > > From: spring <[email protected]> On Behalf Of Rajiv Asati (rajiva) > > Sent: Thursday, March 28, 2019 11:37 AM > > To: [email protected] > > Cc: [email protected] > > Subject: [spring] IPv6-compressed-routing-header-crh > > > > Hi Ron, > > > > Very Interesting idea that you presented during SPRING session today. > Seems > > useful. > > > > Two comments/clarification - > > > > 1. One of the slides indicated that small packet size on the Internet > was ~500B > > and calculated ~10% due to Routing EH overhead accordingly. Of course, > if we > > look at mid packet size (800-1000B) or large packet size (1000~1400B), > then > > the overhead would be a lot less. > > > > We should also look at the % mix of small packets vs mid vs large size to > > calculate the impact. If mid to large packets were dominant (say, as > much as > > >70% given >80% of traffic is video (ABR etc) per the latest VNI studies > ), then > > the overhead impact due to non-compressed SID usage on the traffic would > > be even less over all. > > > > 2. Also, what % of savings do we get by using compressed RH vs non- > > compressed RH ? 24B vs 64B per packet !! > > > > > > Cheers, > > Rajiv > > > > _______________________________________________ > > spring mailing list > > [email protected] > > https://urldefense.proofpoint.com/v2/url?u=https- > > 3A__www.ietf.org_mailman_listinfo_spring&d=DwICAg&c=HAkYuh63rsuhr6 > > Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl- > > AWF2EfpHcAwrDThKP8&m=jmZxWm2Aql61pHCtvKteTsWzTqqt883W1s5m4 > > Hg4Fxg&s=Jd6XyAybfJQVqups1svIV2qgpN8t39yQZOjL0HT5UZw&e= > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > [email protected] > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
