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

[Robert Raszuk <[e-mail]>]

Hi Uma,

Just one clarification to your response. IP-TE + NP proposal does not
require BGP only network. Not at all. Network can run IGP as today, may or
may not run any BGP based services.

All I am stating in the draft is that one option to signal the translation
state is to leverage existing protocol extension "Advertising Segment
Routing Policies in  BGP", but this is just an option - not a requirement
of any sort to make the proposal work.

Many thx,
Robert

On Thu, May 14, 2020 at 1:44 AM Uma Chunduri <[e-mail]> wrote:

> Hi Robert,
>
> Thanks for pointing this draft. Certainly useful, if some one wants to do
> TE with out upgrading the data plane *and* use BGP in their network. If
>
> BGP only networks on the rise, then this can be readily used (DC underlay
> stuff - that started happening in 2011 or so "why BGP is a better IGP").
>
> But not sure, what's the use of TE in a DC underlay.  Certainly,  there
> are other control plane ways to do this.
>
>
> >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  :)
>
>
> Fully agree.  I personally feel the ability to insert/delete in the
> underlying data plane is very important for any of the data plane proposals
> (for long
>
> term viability). There is no easy way to get there, given the tall order
> of 8200 and *also* various current proposals +
>
> how the whole waves of discussions happened on this topic periodically
> over an year now.
>
>
> --
> Uma C.
>
>
>
> On Wed, May 13, 2020 at 3:34 PM Robert Raszuk <[e-mail]> wrote:
>
>> 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 <
>> [e-mail]> 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
>>> > [e-mail]
>>> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>> > --------------------------------------------------------------------
>>> >
>>>
>>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> [e-mail]
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>>
>