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

From: Robert Raszuk <[email-masked]>
Date: Wed, 13 May 2020 21:36:54 +0200

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.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 14 May 2020 09:59:32 +1200

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. 
> 
> plane it can use controller driven or existing protocol extensions (BGP) to distribute
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 14 May 2020 00:33:34 +0200

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.

---

From: Uma Chunduri <[email-masked]>
Date: Wed, 13 May 2020 16:44:47 -0700

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 <[email-masked]> wrote:

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

---

From: Gyan Mishra <[email-masked]>
Date: Wed, 13 May 2020 21:02:56 -0400

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 <[email-masked]> wrote:

> But not sure, what's the use of TE in a DC underlay.  Certainly,  there
> are other control plane ways to do this.
>
>
> 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.
>
>
>
>> I originally posted this in RTGWG then ADs recommended to move it to
>> TEAS. This is where it sits now.
>>
-- 

Gyan  Mishra

Network Engineering & Technology

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347

Email: [email-masked]

---

From: Gyan Mishra <[email-masked]>
Date: Wed, 13 May 2020 21:26:44 -0400

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 <[email-masked]> wrote:

>>>> > In the light of the discussion on effectively steering packets via
>>>> non routing computed paths there seems to be some sort of the umbrella

Gyan  Mishra

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347

---

From: Andrew Alston <[email-masked]>
Date: Thu, 14 May 2020 05:47:19 +0000

From: ipv6 <[email-masked]> On Behalf Of Gyan Mishra
Sent: Thursday, 14 May 2020 04:27
To: Uma Chunduri <[email-masked]>
Cc: 6man <[email-masked]>
Subject: Re: Do we really need to add state into each packet ...

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

Just some comments on this – as an operator – you are correct that choice is required.  Obviously, inter-op is also important – and I typically avoid running proprietary protocols.  But  here is the thing, there is ever indication that both CRH and SRH are going to be developed – with or without RFC’s.  In Montreal I raised this with one of the vendors involved more than a year ago – and in fact I went as far as to say that both parties were entrenched, there was code out there for both, because I’d seen it and used it – and in that case, perhaps it was time to start looking at a way to inter-op the two technologies.  I was told rather bluntly to my face that irrespective of what happened, there would be no inter-op, it wasn’t desired, and it was that particular vendor’s way or the highway.  On that day – all I’m going to say is that purchase orders got changed.

My take on this is pretty simple – we’re in a situation where firstly – there is no requirement for any vendor to implement any RFC – and there are MANY cases where vendors choose NOT to implement a particular RFC.  Some things move ahead post the RFC process and get properly implemented – some don’t, and then the operator chooses to run something or not, and tailors their purchasing options around those choices.  Now, while it is obviously not practical to standardize every idea – where we have a situation where there is on going development and clear indication that both systems are *GOING* to be developed – and both are asking for standardization – by refusing to do a working group call or adopt one of them – we are saying – we embrace proprietary protocols – because where there is customer demand – the development will happen.

Let us be real – do you think most operators give a damn about an RFC?  Some of the bigger ones, and myself, we like to know the rfc’s – but for most, they don’t care so long as it works.   End the day – the market is going to decide – the operators are going to decide – and in the face of lack of standardization – where two vendors are going to develop no matter what we do – what I predict happening is that you end up with two cases – one standard – one not – and then – if the non-standard one becomes popular in the market – and I’ve seen that happen as well, suddenly the vendor that went the other way will be under pressure to go ahead and implement something non-standard against the other vendors implementation – and we end up with a non-standard protocol with multiple implementations.  That – is in no one’s interests.

In the alternative case, we have two standards – vendor A and vendor B choose to implement the standard they prefer, with no obligation to implement the other.  If the market then decides the one a particular vendor chose NOT to implement is the better solution – either they convince their vendor to implement the other one, or, they get up and talk with their cheque books and walk out the door.  No harm, no foul.   The only reason I can see for one vendor actively fighting the standardization of something that they themselves are under no obligation to implement is to protect their own standard, and is a tacit acknowledgement that there is a chance the market may reject what they are doing and choose to go the other way.  That to me, is horribly reminiscent of anti-competitive protectionism – squash the competitions innovation to promote your own, rather than letting your good work win out in the free and open market, and it smacks of insecurity.  This behavior also creates a situation where once one vendor starts playing that game, the only alternative available to the other vendor is to start getting obstructive to protect their own interests, and we end up in a long and escalating battle of obstructionism to force the other vendor to back down – effectively creating a stale mate till both come to a draw.

In this particular case – and this is my personal opinion, you have two technologies – that in my view actually serve very different use cases (but that can debated).  There is clearly *some* support for both – from both vendors and operators alike.  There is clearly on going development of both.  We now choose – do we want to see one standard – one proprietary – and then risk the scenario above – or do we say – it is the enterprises, the operators, the customers who end up choosing – lets give them the choice and standardize both – and let the market decide?

To me – the latter makes far more sense – the protectionism I am seeing going on in this whole debate – and the blatant obstructionism – is nothing short of madness – and it may serve the vendors interests – but it sure as hell does not serve the operators interests, and at the end of the day, it’s the operators who are going to be buying the stuff – or not buying from the vendor that chooses not to implement it.  Let them have the choice, just as operators have the choice to implement or not implement against any RFC out there.

Thanks

Andrew

---

From: Gyan Mishra <[email-masked]>
Date: Thu, 14 May 2020 02:55:11 -0400

On Thu, May 14, 2020 at 1:47 AM Andrew Alston <
[email-masked]> wrote:

> *From:* ipv6 <[email-masked]> *On Behalf Of *Gyan Mishra
> *Sent:* Thursday, 14 May 2020 04:27
> *To:* Uma Chunduri <[email-masked]>
> *Cc:* 6man <[email-masked]>
> *Subject:* Re: Do we really need to add state into each packet ...
>
>
>
>
>
> Just some comments on this – as an operator – you are correct that choice
> is required.  Obviously, inter-op is also important – and I typically avoid
> running proprietary protocols.  But  here is the thing, there is ever
> indication that both CRH and SRH are going to be developed – with or
> without RFC’s.  In Montreal I raised this with one of the vendors involved
> more than a year ago – and in fact I went as far as to say that both
> parties were entrenched, there was code out there for both, because I’d
> seen it and used it – and in that case, perhaps it was time to start
> looking at a way to inter-op the two technologies.  I was told rather
> bluntly to my face that irrespective of what happened, there would be no
> inter-op, it wasn’t desired, and it was that particular vendor’s way or the
> highway.  On that day – all I’m going to say is that purchase orders got
> changed.
>
>
>
> My take on this is pretty simple – we’re in a situation where firstly –
> there is no requirement for any vendor to implement any RFC – and there are
> MANY cases where vendors choose NOT to implement a particular RFC.  Some
> things move ahead post the RFC process and get properly implemented – some
> don’t, and then the operator chooses to run something or not, and tailors
> their purchasing options around those choices.  Now, while it is obviously
> not practical to standardize every idea – where we have a situation where
> there is on going development and clear indication that both systems are *
> *GOING** to be developed – and both are asking for standardization – by
> refusing to do a working group call or adopt one of them – we are saying –
> we embrace proprietary protocols – because where there is customer demand –
> the development will happen.
>
>
>
> Let us be real – do you think most operators give a damn about an RFC?
> Some of the bigger ones, and myself, we like to know the rfc’s – but for
> most, they don’t care so long as it works.   End the day – the market is
> going to decide – the operators are going to decide – and in the face of
> lack of standardization – where two vendors are going to develop no matter
> what we do – what I predict happening is that you end up with two cases –
> one standard – one not – and then – if the non-standard one becomes popular
> in the market – and I’ve seen that happen as well, suddenly the vendor that
> went the other way will be under pressure to go ahead and implement
> something non-standard against the other vendors implementation – and we
> end up with a non-standard protocol with multiple implementations.  That –
> is in no one’s interests.
>
>
>
> In the alternative case, we have two standards – vendor A and vendor B
> choose to implement the standard they prefer, with no obligation to
> implement the other.  If the market then decides the one a particular
> vendor chose NOT to implement is the better solution – either they convince
> their vendor to implement the other one, or, they get up and talk with
> their cheque books and walk out the door.  No harm, no foul.   The only
> reason I can see for one vendor actively fighting the standardization of
> something that they themselves are under no obligation to implement is to
> protect their own standard, and is a tacit acknowledgement that there is a
> chance the market may reject what they are doing and choose to go the other
> way.  That to me, is horribly reminiscent of anti-competitive protectionism
> – squash the competitions innovation to promote your own, rather than
> letting your good work win out in the free and open market, and it smacks
> of insecurity.  This behavior also creates a situation where once one
> vendor starts playing that game, the only alternative available to the
> other vendor is to start getting obstructive to protect their own
> interests, and we end up in a long and escalating battle of obstructionism
> to force the other vendor to back down – effectively creating a stale mate
> till both come to a draw.
>
>
>
> In this particular case – and this is my personal opinion, you have two
> technologies – that in my view actually serve very different use cases (but
> that can debated).  There is clearly **some** support for both – from
> both vendors and operators alike.  There is clearly on going development of
> both.  We now choose – do we want to see one standard – one proprietary –
> and then risk the scenario above – or do we say – it is the enterprises,
> the operators, the customers who end up choosing – lets give them the
> choice and standardize both – and let the market decide?
>
>
>
> To me – the latter makes far more sense – the protectionism I am seeing
> going on in this whole debate – and the blatant obstructionism – is nothing
> short of madness – and it may serve the vendors interests – but it sure as
> hell does not serve the operators interests, and at the end of the day,
> it’s the operators who are going to be buying the stuff – or not buying
> from the vendor that chooses not to implement it.  Let them have the
> choice, just as operators have the choice to implement or not implement
> against any RFC out there.
>
>  Gyan> I am in complete agreement, as we both share the same operators
> viewpoint as we are the ones that get the short end of the stick when the
> vendors battle for adoption and protectionism squashes our the competition.
>
>
In the past not all operators cared about standards versus proprietary
> features or technologies, but now in this day and age, the expense of
> commodity hardware and proprietary asic’s will become a thing of the past
> as evolution shifts in the direction of merchant silicon and open flow open
> daylight and hardware hypervisor virtualization with NFV and VNF network
> functions sitting on any white box hardware running  virtual QCOW2
> instances of Juniper, Cisco or any vendor OS - the world we live the IETF
> standards are going to become even more and more important with
> virtualization and white box with vendor virutaual software and now
> interoperability with the mix vendors lines becoming grayed.
>
IETF standards are now of utmost importance for operators and thus the
> focus industry wide on standards and not wily nilly deploying proprietary
> features for production deployments.
>

    Due to the industry shift to virtualization and white box solutions on
commodify vendor software, vendors now know for their entire marketing
strategy to sell their brand name is based on IETF standards which is a
MUST, and as now no operator wants to entangled with a single vendor
solution running proprietary features as they want inter vendor
interoperability to work.

I think the IETF being an open forum, there really should never be any one
vendor with its muscle and market share dominance, that it trying to push
and squash out the smaller vendors who may have a solution that maybe far
better then the incumbent big vendor.

In the end we the operators big and small lose out with vendor
protectionism.  I for one don’t think there is any place for protectionism
in the IETF, as it defeats the goal and purpose set for for openness and
transparency and all development by anyone being treated as equal, and
equality among all developers representing vendors big or small as well as
individuals not having any affiliation or individuals representing an
operator and not having any vendor backing.

So I think that goes for operators or any individual without any major
affiliation as well that come up with an idea like myself representing
Verizon a tier 1 carrier and major worldwide stakeholder in the
marketplace.  Operators such as us that are part of the IETF, if we come up
with an idea to be developed, we should not get squashed by the vendor
consortium as well just because we don’t represent a vendor, but rather be
supported in coming up with the best possible idea that benefits all
operators consuming the feature of technology worldwide.

-- 

Gyan  Mishra

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347

---

From: Andrew Alston <[email-masked]>
Date: Thu, 14 May 2020 06:58:55 +0000

Due to the industry shift to virtualization and white box solutions on commodify vendor software, vendors now know for their entire marketing strategy to sell their brand name is based on IETF standards which is a MUST, and as now no operator wants to entangled with a single vendor solution running proprietary features as they want inter vendor interoperability to work.

I think the IETF being an open forum, there really should never be any one vendor with its muscle and market share dominance, that it trying to push and squash out the smaller vendors who may have a solution that maybe far better then the incumbent big vendor.

In the end we the operators big and small lose out with vendor protectionism.  I for one don’t think there is any place for protectionism in the IETF, as it defeats the goal and purpose set for for openness and transparency and all development by anyone being treated as equal, and equality among all developers representing vendors big or small as well as individuals not having any affiliation or individuals representing an operator and not having any vendor backing.

So I think that goes for operators or any individual without any major affiliation as well that come up with an idea like myself representing Verizon a tier 1 carrier and major worldwide stakeholder in the marketplace.  Operators such as us that are part of the IETF, if we come up with an idea to be developed, we should not get squashed by the vendor consortium as well just because we don’t represent a vendor, but rather be supported in coming up with the best possible idea that benefits all operators consuming the feature of technology worldwide.

I 100% agree with the sentiments expressed above – in every single way.  It is sad however when I am told – bluntly – that “If operators had their way there would be 10 solutions for everything, and as such, they don’t really have a place in the IETF” (paraphrased) – and was told that by someone who will remain unnamed – but was in a chair position within one of the working groups.

Andrew

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 14 May 2020 11:29:28 +0200

Hi Uma,

Just one clarification to your response. IP-TE + NP proposal does not
require BGP only network. Not at all. Network can run IGP as today, may or
may not run any BGP based services.

All I am stating in the draft is that one option to signal the translation
state is to leverage existing protocol extension "Advertising Segment
Routing Policies in  BGP", but this is just an option - not a requirement
of any sort to make the proposal work.

Many thx,
Robert

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 14 May 2020 12:42:31 +0100

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 <[email-masked]> 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”.
> 
> 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 <[email-masked] <mailto:[email-masked]>> 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 <[email-masked] <mailto:[email-masked]>> 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 <[email-masked] <mailto:[email-masked]>> wrote:
> Hi Robert,
> 
> > 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.
> > 
> > 
> > 
> > [email-masked] <mailto:[email-masked]>
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 <https://www.ietf.org/mailman/listinfo/ipv6>
> [email-masked] <mailto:[email-masked]>
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 <https://www.ietf.org/mailman/listinfo/ipv6>
> [email-masked] <mailto:[email-masked]>
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 <https://www.ietf.org/mailman/listinfo/ipv6>
> Email: [email-masked] <mailto:[email-masked]>
> 
>

---

From: Gyan Mishra <[email-masked]>
Date: Thu, 14 May 2020 11:16:06 -0400

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 <[email-masked]>
wrote:

> <https://tools..ietf.org/html/draft-bryant-rtgwg-plfa-00>
>
>
> Kind regards
>
>
> Gyan
>

Gyan  Mishra

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 14 May 2020 18:47:54 +0200

Thanks, Gyan,

I don't dare to compare to Roberts draft, so just re. PPR inline.

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

> 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

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.

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

> 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

> > path objects ???Preferred Path Routing???.
> >
> > With the PPR concept IGP based steering and Robert???s IP-TE+NP concept
> >>>> > nothing is more friendly then absolutely no change to the data plane..
> >>>> >
> >>>> > Ref:
> >>>> >

-- 
---
[email-masked]

---

From: Uma Chunduri <[email-masked]>
Date: Thu, 14 May 2020 10:13:30 -0700

Hi Robert,

Thanks for the clarification.

> may not run any BGP based services.
Right.
I guess, I misunderstood earlier, as P nodes don't run BGP (generally). Per
draft,  if segment endpoint is a P node then it is required to run BGP.
You also indicated PCE (PCE-CC ?) usage as alternative approach (section 5).

> of any sort to make the proposal work.

Sure.  Got it now.  Shall go through this more thoroughly.

Any ways, as the title of the thread, yes,  there are many ways to do this
(each with it's own strengths) with out including the state in each packet.

But there are cases where per packet information is useful too (NP and
additional non-path info..).
--
Uma C.

---

From: Gyan Mishra <[email-masked]>
Date: Thu, 14 May 2020 19:25:23 -0400

Thanks Toerless

I will follow up on teas with the discussion.

Thanks

Gyan

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

> > On Thu, May 14, 2020 at 7:42 AM Stewart Bryant <[email-masked]
> >
> > wrote:
> >
> > > Yes
> > >
> > >>>> > It also does not need to define any new data plane extensions and
> for
> > >>>> control
> > >>>> > 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
> > >>>> > Administrative Requests:
> https://www.ietf.org/mailman/listinfo/ipv6
> > >>>> >
-- 

Gyan  Mishra

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347