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

[Gyan Mishra <[e-mail]>]

Thanks Toerless

I will follow up on teas with the discussion.

Thanks

Gyan

On Thu, May 14, 2020 at 12:48 PM Toerless Eckert <[e-mail]> wrote:

> Thanks, Gyan,
>
> I don't dare to compare to Roberts draft, so just re. PPR inline.
>
> On Thu, May 14, 2020 at 11:16:06AM -0400, Gyan Mishra wrote:
> > Robert & Uma
> >
> > As a compare and contrast of both of your control plane based steering
> > proposals at a high level teas-is-te is really made to work completely
> > independent of SR where PPR is truly meant  as complement to SR.
>                                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> I would say "complement/extend SR and beyond":
>
> PPR is intended to create consistent path-steering/traffic-engineering
> (PS/TE)
> mechanisms across hopefully arbitrary forwarding planes, IPv6, IPv6+SRH,
> MPLS, IPv4, and maybe even other forwarding planes, L2
> or future forwarding planes.
>
> I am not quite sure where e.g.: "no-SR" MPLS/IPv6 stops and where SR
> exactly starts.  To me, PPR-IDs could be seen as a form of SIDs, in which
> case it might be "extend SR", other may not agree, in which case it might
> be "complement SR". Hopefully thats just a terminology question, maybe more
> useful to first discuss functionality and then do terminology.
>
> > Your steering is based on IGP extensions creating routing paths with a
> new
> > concept of PPR path objects similar to RSVP TE ERO (Explicit Route
> Object)
> > and RRO(Record Route object) used for FRR n:1 facility protection.
>
> Not only paths but also graph object to be able to efficiently signal
> and establish more efficient path steering with fewer than eg: O(N^2)
> state/identifiers (which had been one of the issues when RSVP-TE was
> used for SP-core capacity optimization).
>
> > PPR sounds like a much needed complement to SR both SR-MPLS and SRv6 due
> to
> > MSD(maximum sid depth) issues incurred with SR-TE binding sid when adj
> sid
> > strict paths are used instead of loose prefix sid resulting in a much
> > larger data structure SID depth, resulting in MTU issues with very long
> > strict paths.
>
> PPR can be used with loose and strict semantic. The use-cases requiring
> strict semantic such as path-diversity/high-resilience where certainly
> starting points / motivators. MSD being a key issue, but i think not the
> only one.
>
> > Most SR deployments both SRv6 and SR-MPLS it using SR-TE at all it is
> > recommended to use centralized model with PCEP controller instantiation
> of
> > the intent based routing traffic steering.
> >
> > However, is it true that if PPR is used that the use or SR-TE can become
> > more viable with both SRv6 and SR-MPLS in distributed manual or hybrid
> > model can overcome MSD issues?
>
> Yes, PPR path calculation can be done centralized or decentralized.
>
> I would explicitly avoid the term distributed for PPR, because to me,
> distributed is the classical routing protocol model as we use it
> in IGP/BGP: There is no single-source of truth for a path but it
> is calculated in a collaborative, coordinated "distributed" fashion.
>
> In PPR, there is a single-source-of-truth for each path/graph.
> But there does not need to be a single-source-of-truth for all
> paths/graphs.
> Every PE for example can calculate and PPR originate paths/graphs for
> itself, much like the original model we had with RSVP-TE headend-LSR.
>
> PPR paths/graphs overcome the MSD issue, independent who calculates them,
> centralized or decentralied/distributed.
>
> > One other question related to PPR I thought it used some of the major
> > benefits of RSVP TE from a bandwidth management perspective with PCALC
> cSPF
> > capability to provide bandwidth reservations static or auto bandwidth but
> > now apply to non MPLS both IP and SR data planes.  I was trying to find
> > that section in any of the PPR drafts but could not find.
>
> The drafts do i think not yet necessarily describe all the non-protocol
> encoding pieces. also maybe better to take offline, or else 6man
> asks us to go for a TEAS (a bit too much TE for this mailing list i fear).
>
> Cheers
>     Toerless
>
> > Uma - I know we were supposed to go over PRR in depth and possible use
> > cases for Verizon but things got hectic with Covid unfortunately.  Maybe
> in
> > the next few weeks or so we can plan a review meeting.
> >
> > Kind regards
> >
> > Gyan
> >
> > On Thu, May 14, 2020 at 7:42 AM Stewart Bryant <[e-mail]
> >
> > wrote:
> >
> > > 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
> > >
> > > 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
> > > <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]
> > >
> > >
> > >
> > > --------------------------------------------------------------------
> > > 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]
>
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > [e-mail]
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
>
>
> --
> ---
> [e-mail]
>
-- 

Gyan  Mishra

Network Engineering & Technology

Verizon

Silver Spring, MD 20904

Phone: [phone]

Email: [e-mail]