Re: [Cats] [cats] draft-ietf-cats-usecases-requirements-00 -> traffic path enforcement type is missing

[Adrian Farrel <[e-mail]>]

I'd step back a bit and point out that "steering" involves selecting a
destination, and optionally selecting a way to get there. You would not
(necessarily) need one tunnel per "session" - more likely you would have
edge-compute tunnels of a few flavours and put traffic onto them.

 

However, the important thing is that the operator must be able to build a
network that scales. The operator may be given the option to build a network
that doesn't scale if that is their preference.

 

Now, one further point about R13. I see that requirement in the context of
"sticky state". And it says that the thing that binds the stickiness must
not need to be result in state on transit nodes. That seems to be a question
of steering at the ingress edge, not of forwarding within the network.

 

And, while we're here.

The document uses the term "session" without a definition. It would benefit
from one.

 

Cheers,
Adrian

 

From: Cats <[e-mail]> On Behalf Of Cheng Li
Sent: 06 September 2023 09:20
To: [e-mail]; Vasilenko Eduard
<vasilenko.eduard=[e-mail]>
Cc: cats <[e-mail]>
Subject: Re: [Cats] [cats] draft-ietf-cats-usecases-requirements-00 ->
traffic path enforcement type is missing

 

Agree with Zongpeng, and I also see the value of Eduard's proposal.

 

I am not really sure that is it OK to add it as a requirement now, but I am
OK to it If the WG agree to do so.

 

Respect,

Li Cheng

 

 

 

From: Cats <[e-mail] <mailto:[e-mail]> > On Behalf
Of [e-mail] <mailto:[e-mail]> 
Sent: Wednesday, September 6, 2023 8:16 AM
To: Vasilenko Eduard <vasilenko.eduard=[e-mail]
<mailto:vasilenko.eduard=[e-mail]> >
Cc: cats <[e-mail] <mailto:[e-mail]> >
Subject: Re: [Cats] [cats] draft-ietf-cats-usecases-requirements-00 ->
traffic path enforcement type is missing

 

Hi, Eduard 

 

    It is suggested that the CATS group firstly focuses on the requirement,
and the architecture.

    However, IMO, I would prefer the tunnel choice. 

    Meanwhile, a service point faraway may not be considered as an
candidate, so that perhaps we can have a fewer number of tunnels.

 

Best Regards

Zongpeng Du

 

  _____  

[e-mail] <mailto:[e-mail]>  &
[e-mail] <mailto:[e-mail]>  

 

From: Vasilenko Eduard <mailto:vasilenko.eduard=[e-mail]>


Date: 2023-09-05 16:05

To: cats <mailto:[e-mail]> 

Subject: Re: [Cats] [cats] draft-ietf-cats-usecases-requirements-00 ->
traffic path enforcement type is missing

Hi all,

Let's assume that the decision has been made and some traffic/session has
been decided to push to service instance X.

How?

It is MANDATORY to avoid states on the transit router hops. It is probably
what you mean in requirement R13 (I am not sure because of general "node"
terminology, "source node" for sure MUST keep all states).

We have potentially 2 choices:

1. Packet header modifications (like NAT, or to be more precise "like Load
Balancer").

2. Establish a tunnel (SRv6, SR-MPLS, VxLAN, whatever). Then only the
ingress router would keep states.

 

Of course, it is possible to be silent about this problem, and let all other
WGs decide themselves on their way of implementation.

IMHO: it is better to state clearly that header modification is not an
option.

 

By the way, we are talking here about Quadrillions (or Quintillions?) of
additional tunnels on a global scale.

It is evident that only "Source Routing" (SRv6 or SR-MPLS) is capable of
handling it because only SR is encoding the path in the packet itself.

Refreshment of huge tables through the control plane is not an option.

Maybe it is better to mention it too.

 

Best Regards

Eduard Vasilenko

Senior Architect

Network Algorithm Laboratory

Tel: [phone]

 

-- 

Cats mailing list

[e-mail] <mailto:[e-mail]> 

https://www.ietf.org/mailman/listinfo/cats