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

[Gyan Mishra <[e-mail]>]

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]