Hi Robert, On Sun., 31 Mar. 2019, 02:33 Robert Raszuk, <[email protected]> wrote:
> Hi Mark, > > 1) Can you point me to IGP and BGP extensions which would allow to > propagate such "mapping tables" around ? > No, as don't think one specifically exists yet. That can be developed. There are already similar ones of course, such as those that distribute IP prefix to MPLS label mapping information. > 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 ? > I think so. My understanding of what SR is fundamentally about is to reduce control plane state and processing. The trade-off for reduced control plane state and processing is to instead carry and encode most or all of that information or its semantics as per-packet overhead. If the per-packet overhead becomes too large and expensive, then pushing some of that information and processing back into the control plane should be ok, as long as there is still a beneficial overall reduction in control plane state and processing. As MPLS SR SIDs are 20 bits, then rounding up to an octet boundary and a 32 bit alignment, I'd think 32 bit SIDs would be adequate to perform SR in an IPv6 network. As 32 bit SIDs are also the same size as IPv4 addresses, that may also create some opportunities to leverage IPv4 support in existing protocols to suite carrying and processing 32 bit SIDs with some, possibly slight, modification. For example, perhaps IPv4 Address Family support in OSPFv3 (RFC 5838) could be somehow leveraged to suit SR. Regards, Mark. > 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
