Hi Mark, 1) Can you point me to IGP and BGP extensions which would allow to propagate such "mapping tables" around ?
2) Is there an agreement that solutions which require additional per SR path state in both control plane and now in data plane are really something we should be endorsing here ? Kind regards, R. On Sat, Mar 30, 2019 at 4:07 PM Mark Smith <[email protected]> wrote: > On Sun, 31 Mar 2019 at 00:23, Robert Raszuk <[email protected]> wrote: > > > > 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). > > > > I can't see that requirement. > > These are the steps where the IPv6 DA is determined from the SID. > There is no requirement stated that the IPv6 DAs in the mapping table > must all come from the same /64. > > * Search for SID[SL] in the table that maps SID's to IPv6 addresses > and interfaces. If SID[SL] cannot be found in that table, send an ICMP > Parameter Problem, Code 0, message to the Source Address, pointing to > SID[SL], and discard the packet. > > * Copy the address associated with SID[SL] to the IPv6 Destination Address. > > In the Strict Source Routing example (A.3), the SA and 3 DAs are all > from different /64s. > > > > 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 >
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
