Hi Robert,
Thanks for the review.
There is no requirement that all SIDs come from the same prefix. However, I can
see how you might get that impression. In two of the examples, all SIDs do come
from the same prefix. In the next draft version, I will update the examples so
that prefixes come from different prefixes.
I have not yet submitted the control plane documents. However, I can assure you
that the will be remarkably short and simple. All you have to do is advertise a
capability and a SID to address mapping.
Ron
Juniper Internal
From: Robert Raszuk <[email protected]>
Sent: Saturday, March 30, 2019 9:23 AM
To: Ron Bonica <[email protected]>
Cc: Rajiv Asati (rajiva) <[email protected]>; [email protected]; [email protected]
Subject: Re: [spring] IPv6-compressed-routing-header-crh
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/<https://urldefense.proofpoint.com/v2/url?u=https-3A__slideplayer.com_slide_12853563_&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=ewuLblkfLjwoO8YK40dZe30-7hMWm2NinGDf4UsUpJA&s=GOt3LiSwdCnkoijg62t5ij7ZxyrhbAHQ7RQW9E84jhk&e=>
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
<[email protected]<mailto:[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]<mailto:[email protected]>> On
> Behalf Of Rajiv Asati (rajiva)
> Sent: Thursday, March 28, 2019 11:37 AM
> To: [email protected]<mailto:[email protected]>
> Cc: [email protected]<mailto:[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]<mailto:[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]<mailto:[email protected]>
Administrative Requests:
https://www.ietf.org/mailman/listinfo/ipv6<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_ipv6&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=ewuLblkfLjwoO8YK40dZe30-7hMWm2NinGDf4UsUpJA&s=meQ-iz0QWyQ093HWHIwJyq5tb5j9wctL5eeH3TpRKXc&e=>
--------------------------------------------------------------------
_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring
