Re: Do we really need to add state into each packet ...

Hi Brian,

Thank you for great feedback. Yes this is out of scope for 6man - I just
share here based on some comments that we need simpler solution for path
steering,

I originally posted this in RTGWG then ADs recommended to move it to TEAS.
This is where it sits now.

I wrote it last year just to document the idea. As I am not longer a vendor
I do not have much power behind to do proper marketing and implementation.
My recent years of experience with IETF prove that unless you are a vendor
to push your idea through is super hard if not impossible at all.

For signalling many thx for the suggestion. I am actually not familiar with
ANIMA at all so perhaps if someone sees it fits there I am welcome help :)
BGP signalling for it is ready as standardized in IDR already. Some people
want to couple everything into BGP, some prefer to decouple it from BGP ...
one size will not fit all.

For 6man perhaps the only interesting part is to keep it as an example that
packet's path steering without per flow state or RSVP-TE style signaling in
network elements is easy to accomplish today - if someone just starts to
think a bit outside of the source routing box  :)

Kind regards,
R.

On Wed, May 13, 2020 at 11:59 PM Brian E Carpenter <
brian.e.carpenter@gmail.com> wrote:

> Hi Robert,
>
> At first glance I like this proposal. It seems to be less contentious
> than SRH because it is 100% based on encapsulation, but have about
> the same power.
>
> >    However depending on the required TE scale, on the network size, as
> >    well as on the TE path complexity, real production deployments will
> >    likely utilize automation in order to provision such configurations.
> >    Local NMS can be used successfully to provision all participating
> >    segment nodes with proper set of path lists.
>
> I would propose this as an obvious use case for the ANIMA mechanisms.
> An autonomic service agent in each participating node could communicate
> with its peers via the autonomic control plane (i.e. in complete security
> and independently of the data plane) and with a relevant TE agent in the
> NMS. That's completely compatible with your suggestion about YANG models,
> scaleable, and decouples the solution from BGP.
>
> Now clearly this is out of scope for 6MAN, so I wonder where it will
> be discussed?
>
> Regards
>    Brian
>
> On 14-May-20 07:36, Robert Raszuk wrote:
> > Dear 6man WG,
> >
> > In the light of the discussion on effectively steering packets via non
> routing computed paths there seems to be some sort of the umbrella
> assumption that we must add that information into each packet.
> >
> > For example in CRH proposal we read:
> >
> >    The CRH allows IPv6 source nodes to specify the path that a packet
> >    takes to its destination.
> >
> > So let's me just bring up a reference to the document I wrote last year
> which
> > illustrates that without putting any extra extension headers into each
> packet
> > it can be easily steered within a controlled domain.
> >
> > It also does not need to define any new data plane extensions and for
> control
> > plane it can use controller driven or existing protocol extensions (BGP)
> to distribute
> > local mapping information.
> >
> > Note also that those mappings are not per flow but large aggregated
> mappings.
> >
> > If folks are analyzing should we adopt CRH as "IPv6 friendly" I would
> say that
> > nothing is more friendly then absolutely no change to the data plane.
> >
> > Ref:
> >
> > https://tools.ietf.org/html/draft-raszuk-teas-ip-te-np-00
> > Thx a lot,
> >
> > Robert.
> >
> >
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > ipv6@ietf.org
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
> >
>
>