Re: [Idr] Part 3 of CAR/CT Adoption call (7/14/2022 to 7/27/2022) - Operational Differences

[Robert Raszuk <[e-mail]>]

Hi Srihari,

> Also, what are we optimizing by doing this.

2.5 min of BGP propagation time for 1.5 million routes (as Jeff stated). Do
you think it is not worth to consider an aggregation in such a case ?

Imagine I have POD or Cluster with 1000 PEs (compute as PEs) and I see no
value in advertising all 1000s each with 5 colors especially considering
that such 5 colors will share identical links and paths to those compute.

Same if you replace compute by PEs.

> Trolling will result in your posts being put into the moderation queue.

Part 3 is about operational differences. Not every difference requires a
topology - some do some do not.

I quoted sections from both drafts ?

I do think this fear of moderation - when just pointing out operational
differences and asking clarification questions - simply inappropriate.

Thx,
R.





On Mon, Jul 25, 2022 at 3:07 PM Srihari Sangli <[e-mail]> wrote:

> Robert,
>
>
>
> Pls comments inline.
>
>
>
> Thanks & Regards,
>
>
>
> srihari…
>
>
>
>
>
> *From: *Idr <[e-mail]> on behalf of Robert Raszuk <
> [e-mail]>
> *Date: *Monday, 25 July 2022 at 7:02 AM
> *To: *Jeffrey Haas <[e-mail]>
> *Cc: *Sue Hares <[e-mail]>, idr@ietf. org <[e-mail]>
> *Subject: *Re: [Idr] Part 3 of CAR/CT Adoption call (7/14/2022 to
> 7/27/2022) - Operational Differences
>
> *[External Email. Be cautious of content]*
>
>
>
> All,
>
>
>
> Relative to the discussion about scale and stability of CAR vs CT proposal
> I would like to bring a very important difference.
>
>
>
> As part of NLRI, CAR defines a prefix as a real IPv4 or IPv6 prefix with
> length.  See section 2.9.2 of CAR draft
>
>
>
> CT however in its NLRI defines prefix as address of 32 or 128 bits and
> there is no length. See section 7 of CT draft.
>
>
>
> That means that even if the operator wishes to aggregate all 300K PEs into
> one prefix (per ASN or per POP or per pod/cluster etc ...) for a given
> color before it sends it over BGP with CT it is not an option. While in CAR
> it is.
>
>
>
> Srihari> Could you please describe the use case why would a customer want
> to do this. Also, what are we optimizing by doing this. Please also
> consider it is not just the sender that needs to do this work. Are you
> trying to optimize the bits on the wire ? Given different attributes these
> prefixes may have, I would say this can be a theoretical exercise.
>
>
>
>
>
>
>
>
>
> Leave alone that adding RD to the CT NLRI makes it even more impossible to
> aggregate.
>
>
>
> This is a fundamental difference especially when /32s or /128s are not
> needed to be sprayed to other ASNs.
>
>
>
> Till that is fixed I recommend that CT draft goes back to the drawing
> board and would not be even accepted as experimental. Its experiment has
> just concluded as a failure.
>
>
>
> Cheers,
>
> Robert
>
>
>
>
>
> On Mon, Jul 25, 2022 at 9:26 AM Robert Raszuk <[e-mail]> wrote:
>
> Hi,
>
>
>
> My point is that this is the first time we are facing the introduction of
> BGP invalidation (as you stated no resolution) by performance (or
> under-perfomance) of data plane metric.
>
>
>
> I think this has new consequences to the protocol which are nowhere near
> SAFI 4.
>
>
>
> Perhaps it could work just fine for reasonable scale. But the numbers
> being quoted of 1.5M color routes seems way too excessive and rather
> suggest different protocol encoding or one more layer of
> hierarchy/indirection needed.
>
>
>
> Many thx,
>
> R.
>
>
>
>
>
>
>
>
>
>
>
> On Mon, Jul 25, 2022 at 3:13 AM Jeffrey Haas <[e-mail]> wrote:
>
> Robert,
>
>
>
> I make no comment on how it is intended to be deployed. Only that the
> consequences protocol-wise are the same.
>
> Jeff
>
>
>
> On Jul 24, 2022, at 7:22 PM, Robert Raszuk <[e-mail]> wrote:
>
> 
>
> Hi Jeff,
>
>
>
> > The stability dynamics and impact of service route re-resolution are
> largely the same as BGP labeled unicast.
>
>
>
> I would quite not agree with the above.
>
>
>
> Reason being that labeled unicast is about reachability.
>
>
>
> Here we are talking about real promises of data plane "performance" hence
> we are dealing with completely different set of triggers for various data
> plane issues.
>
>
>
> Many thx,
>
> R.
>
>
>
>
>
>
>
>
>
>
>
> On Mon, Jul 25, 2022 at 1:10 AM Jeffrey Haas <[e-mail]> wrote:
>
> Robert,
>
>
>
> A partial comment from my mobile device.
>
>
>
> Withdraw encoding will pack much denser. On a total withdraw you likely
> could pack 200 or more prefixes per update.
>
>
>
> Implicit withdraw via replacement is clearly same speed as initial
> advertisement.
>
>
>
> The stability dynamics and impact of service route re-resolution are
> largely the same as BGP labeled unicast. Thus, beware churning your
> transport routes.
>
>
>
>
>
>
>
> Jeff
>
>
>
> On Jul 24, 2022, at 12:28 PM, Robert Raszuk <[e-mail]> wrote:
>
> 
>
> Hi Jeff,
>
>
>
> Sure 300k times 5 colors makes it 1.5M ...
>
>
>
> So I have a few different questions here.
>
>
>
> Assume in CAR/CT enabled domain one color has transport problems ... say
> low latency is becoming not so low due to interface queuing is transiently
> congesting for whatever reason between P1 and P2 nodes (not even running
> any BGP).
>
>
>
> Q1 - How (by what exact protocol) and how fast such issue with
> forwarding a given color via this domain will be visible at the CAR/CT
> layer ?
>
>
>
> Q2 - Assume Q1 is done - do we now need to withdraw 300K routes based on
> one color brownout ?
>
>
>
> Q3 - According to your math such CAR/CT reaction will take 30 sec. What if
> transport problem is transient and occurs for say 5-10 sec every 40 sec ?
>
>
>
> Q4 - Is there in any document an analysis on dynamics of CAR/CT signalling
> needed to make this at all practical in real deployments vs ppts ?
>
>
>
> We keep burning energy on encoding, but apologies if I missed it but I am
> not seeing the full picture here.
>
>
>
> Why not advertise just 5 colors between those domains in 5 NLRIs and
> define a new attribute to carry all the interdomain color mappings in it ?
>
>
>
> 5 being an example from the section 6.3.2 ... but realistically we could
> perhaps vastly simplify this if we define day one set of well-known colors
> instead of each domain inventing their own definition :)
>
>
>
> Maybe I am just too practical here - but your math inspired those
> questions :)
>
>
>
> Many thx,
>
> R.
>
>
>
>
>
> On Sun, Jul 24, 2022 at 4:47 PM Jeffrey Haas <[e-mail]> wrote:
>
> On Sun, Jul 24, 2022 at 10:44:49AM +0530, Ketan Talaulikar wrote:
> > The scalability requirements are captured here:
> >
> https://datatracker.ietf.org/doc/html/draft-hr-spring-intentaware-routing-using-color-00#section-6.3.2
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-hr-spring-intentaware-routing-using-color-00*section-6.3.2__;Iw!!NEt6yMaO-gk!CsQrDLldHnl4JxBSFvLAV5NjuafJxhdCiqWRL71OLt1IsarmAEPYSFOnUFJZgdAHr0jBtaZH1acgU8M$>
> >
> > This is the merged document that, I believe, captures the consensus that
> > both the CAR and CT solutions aim to address.
>
> Thanks, Ketan.
>
> Roughly 1.5 million routes.
>
> Presuming an example 10k update per second handling, roughly 2.5 minutes of
> convergence time without packing optimizations.
>
> -- Jeff
>
>
> Juniper Business Use Only
>