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

[Gyan Mishra <[e-mail]>]

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.

Robert

So your proposal is a centralized PCEP controller based instantiated
solution.  Can it be used with manual or distributed mode as well.  Also I
believe you mentioned it can be used with SR but their is direct tie or any
inter dependency between your proposal and SRv6 or SR-MPLS - correct?

Can your draft be used to help with MSD issues as what Uma’s PPR is geared
towards?

Also I see it does use some of the feature benefits RSVP TE such as ERO and
RRO objects, but does it also reuse cSPF PCALC static and auto bandwidth
features of RSVP which is very useful for bandwidth management for MPLS
customers.  It also used TI-LFA FRR local protection features which is
great and one of the major uses of RSVP-TE.

Uma

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.  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.

>From the draft below I do see that PPR has data plane option for both IPv4
and IPv6 data planes.

https://tools.ietf.org/html/draft-chunduri-isis-preferred-path-routing-00#page-17

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?

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.

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]