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

[Gyan Mishra <[e-mail]>]

There are of course two perspectives and a balancing act as to what
prevails and obtains WG and IETF adoption and becomes an RFC.

For operators it would be great to have many options in designers toolbox,
however their is a cost incurred for every steering flavor by the vendor
developers writing the code for the feature.

Of course the balancing act is the difficult one and for adoption an
agreement on which ones to develop and from that respect which one based on
market analysis will yield the most revenues residuals for years to come.

Some vendors may think their idea or philosophy is better then others and
so then comes down to the vendors that the the so called pillars that make
up that routing and switching network gear market share have to battle it
out and come to a consensus on what feature or technology is best for all
both the vendors revenue generation and marketability and operators end
users consuming the new features or technology.

Kind regards

Gyan

On Wed, May 13, 2020 at 9:02 PM Gyan Mishra <[e-mail]> wrote:

> Hi Uma
>
> Not sure if maybe you wanted to present yet another IGP based method of
> traffic steering that has data plane independence and uses the IGP based
> path objects “Preferred Path Routing”.
>
>    Preferred Path Routing (PPR) is a routing protocol mechanism
>    concerned with the creation of a routing path as specified in the
>    PPR-Path objects.  These can be signaled via appropriate IGPs (IS-IS,
>    OSPFv2, OSPFv3) and indicate the path for a data plane identifier
>    (PPR-ID).  With this, all PPR capable nodes along that path establish
>    forwarding state for the PPR-ID and any packet destined to the PPR-ID
>    would use that path instead of the IGP computed shortest path to the
>    destination.
>
>
> All
>
> With the PPR concept IGP based steering and Robert’s IP-TE+NP concept
> covers BGP based steering simple to BGP LS used with PCEP for centralized
> model steering instantiated solutions.  And with our SR flavors we have all
> the data plane based steering.
>
> I think with these control plane and data plane based steering models in a
> operators toolbox we have just about every style covered.  Each can be
> independently be tailored for any specific use case based on the
> requirements giving flexibility to the operators.  In the end the ultimate
> goal is providing the network architect many options that provide net-net
> the same results with different steering technologies so the designer can
> pick and chose which option works best to meet the desired objectives.
>
> Core ISIS Draft (for PPR liner paths): https://tools.ietf.org/html/draft-
> chunduri-lsr-isis-preferred-path-routing-04
>
> PPR Graphs/Tree Structure:
> https://tools.ietf.org/html/draft-ce-lsr-ppr-graph-01
>
>
>
> DMM/5G Use case draft for PPR:
> https://tools.ietf.org/html/draft-clt-dmm-tn-aware-mobility-05
>
>
>
> PPR LFA Draft: https://tools.ietf.org/html/draft-bryant-rtgwg-plfa-00
>
>
> Kind regards
>
>
> Gyan
>
> On Wed, May 13, 2020 at 7:44 PM 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
>>> --------------------------------------------------------------------
>>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> [e-mail]
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>>
> --
>
> Gyan  Mishra
>
> Network Engineering & Technology
>
> Verizon
>
> Silver Spring, MD 20904
>
> Phone: [phone]
>
> Email: [e-mail]
>
>
>
> --

Gyan  Mishra

Network Engineering & Technology

Verizon

Silver Spring, MD 20904

Phone: [phone]

Email: [e-mail]