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

[Stewart Bryant <[e-mail]>]

Yes

PPR and SR (in whichever flavour) complement each other in useful ways, and both have a place in networks.

Stewart



> On 14 May 2020, at 02:02, 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 <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 <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 <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 <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] <mailto:[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] <mailto:[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] <mailto:[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 <https://tools.ietf.org/html/draft-raszuk-teas-ip-te-np-00>
> > Thx a lot,
> > 
> > Robert.
> > 
> > 
> > 
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > [e-mail] <mailto:[e-mail]>
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 <https://www.ietf.org/mailman/listinfo/ipv6>
> > --------------------------------------------------------------------
> > 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail] <mailto:[e-mail]>
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 <https://www.ietf.org/mailman/listinfo/ipv6>
> --------------------------------------------------------------------
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail] <mailto:[e-mail]>
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 <https://www.ietf.org/mailman/listinfo/ipv6>
> --------------------------------------------------------------------
> -- 
> Gyan  Mishra
> 
> Network Engineering & Technology 
> 
> Verizon 
> 
> Silver Spring, MD 20904
> 
> Phone: [phone]
> 
> Email: [e-mail] <mailto:[e-mail]>
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------