Re: [mpls] FW: New Version Notification for draft-keten-mpls-expbit-00.txt

[<[e-mail]>]

Hi,

I think all the use cases can be fulfilled with the existing mechanisms, no need to add more service differentiation to the MPLS network. In fact in most of the cases you want to keep the number of classes as low as possible (and do a suitable mapping at the network edges).

Changes which require a "Greenfield" approach also from my point of view expensive, because it requires the update of the whole network "at once" (and we should also have in mind that networks are not necessarily single vendor). 

Regards

Nic

-----Ursprüngliche Nachricht-----
Von: mpls [mailto:[e-mail]] Im Auftrag von Umut Keten
Gesendet: Mittwoch, 14. September 2016 12:19
An: [e-mail]
Cc: [e-mail]
Betreff: Re: [mpls] FW: New Version Notification for draft-keten-mpls-expbit-00.txt

Hey Adrian,


> What if I respond by asking you a question first?  ;-) 
	Only fair :-) Yes

>I think you are asking four questions that need to be handled separately. 
	Not really, I think this is a whole package at once and treated as such. I believe this discussion should have started earlier though.

>1. Do we need more service differentiation in MPLS networks?
	My personal answer is definitely yes. My polling of some principle engineers at vendors and various contacts in my environment (linkedin included) would like to see this happening.
	This actually a question for this group? People here in the mailing list should answer this by their own experiences.

	Some examples where we could use some extra QoS from my own design experiences:

	1st was that every home should be able to have more iptv settop boxes and the added requirement that if 1 of the boxes started using VoD it should have priority in the network. (marketing request)

	2nd LTE mobile backhaul which has 9 qos settings I couldn't match. We are also doing DSL bonding with LTE (MPTCP) and the internet traffic from LTE when bonded had to be lower then best effort so the normal mobile user and our 800mhz 	spectrum would not be overutilized.

	3rd government offices(who have a lot to say in Turkey) wanted their internet traffic classsed. Their internet traffic was 'more' important, they where willing to pay.

	4th data over voice (POS) should have higher priority then normal voice. 


>2. Would MPLS routers be able to deliver the differentiation if the packets
   were marked accordingly?
	Again my answer is yes(for Alcatel/Nokia SR routers) I have TAC supported these. The other routers I should assume they should be able to do so as well. 

>3. How should we achieve additional service differentiation in MPLS
   networks. There are many possible approaches (TC bits, label stacks,
   control plane, using some of the label bits, reworking the shim header
   as you suggest, ...) and I don't (yet) have an opinion although it seems
   to me that a non-backward compatible forwarding plane change is an 
   expensive solution.

	Expensive solution? I don't think so (experience from the timetra OS Alcatel) However the vendors should answer this. 

	My opinion is that an OS upgrade could be sufficient, after the upgrade the routers could have a feature new/old. This then in turn could be handled over NMS.

>4. Are all 8 bits of the TTL field needed?

	I honestly don't think so, again this is something for the whole group to answer.

>Well, this works for greenfield, but this is not necessarily a field upgrade (i.e., some implementations may need hardware upgrades) and that is a really expensive solution. I guess the vendors will be delighted to sell a whole set of new routers to replace what is deployed, but are the operators willing to spend the money? And will they upgrade the whole network in one go - that sounds like a little more than a flag day... maybe a flag month?

	I answered this question partially above, I don't think an OS upgrade will cost that much as you suggest. More drastic upgrades have been performed in the past, this surely should not e one of them.

> So this is just an example of a backwards compatibility issue. If special settings of TTL are configurable options that can be disabled, then everything will be fine (so long as you remember to configure your entire network). On the other hand, if the special settings are more fundamental then more protocol work may be needed. An approach here is to ask the working group a specific question -- Does anyone know of reasons why the MPLS TTL is set greater than 63? e
>Does anyone know of reasons why the MPLS TTL is set greater than 63?
Well ? Does someone? I have been looking for an answer for a long time now. 
It is a waste of a lot of bits imho. Way better of in the QoS field :-)

And yes someone had to be first Adrian, 32 QoS settings will be cheered for. I had a eurake moment because I had to design impossible stuff last 2 years and some of t I solved by making a MPLS above our current MPLS.

Surely some of you had issue's when implementing Mobile Backhaul LTE? They come with 9 QoS.

And surely IoT is going to be a major problem? Anyone?
Let's say I have medical IoT's which should have high priority? Wouldn't it be much simpler to have a QoS set for that? Because now it looks like all IoT is going to be BE traffic. Wouldn't it be nice to differentiate this?


Lets try to build on this Adrian and the rest of the group, because after this day you all will also wonder why we have 8 bits for TTL and maybe all these years we have wasted these bits :-)


Krgrds,
Umut

PS: anyone else from the group going to participate in this discussion? Would be nice to have more voices ;-)



-----Original Message-----
From: Adrian Farrel [mailto:[e-mail]] 
Sent: Wednesday, September 14, 2016 12:34 PM
To: Umut Keten <[e-mail]>
Cc: [e-mail]
Subject: RE: [mpls] FW: New Version Notification for draft-keten-mpls-expbit-00.txt

Umut,

> Thanks for your reply. I will answer your question regarding 
> compatability after asking a question first. What is your opinion on 
> the huge TTL and couldn't it be better used as QoS?

What if I respond by asking you a question first?  ;-)

I think you are asking four questions that need to be handled separately.
1. Do we need more service differentiation in MPLS networks?
2. Would MPLS routers be able to deliver the differentiation if the packets
   were marked accordingly?
3. How should we achieve additional service differentiation in MPLS
   networks. There are many possible approaches (TC bits, label stacks,
   control plane, using some of the label bits, reworking the shim header
   as you suggest, ...) and I don't (yet) have an opinion although it seems
   to me that a non-backward compatible forwarding plane change is an 
   expensive solution.
4. Are all 8 bits of the TTL field needed?

> Regarding your question new/old format.
> My expectation is the following and correct me if I am wrong:  I do 
> not expect an MPLS network to be half upgraded with new format router.

Well, this works for greenfield, but this is not necessarily a field upgrade (i.e., some implementations may need hardware upgrades) and that is a really expensive solution. I guess the vendors will be delighted to sell a whole set of new routers to replace what is deployed, but are the operators willing to spend the money? And will they upgrade the whole network in one go - that sounds like a little more than a flag day... maybe a flag month?

> Your last question however regarding if the 255 is ever set for 
> special reasons? I have no clue! Even so if it is ever set for some 
> special occasion the more QoS possibilities surely should outweigh that.

So this is just an example of a backwards compatibility issue. If special settings of TTL are configurable options that can be disabled, then everything will be fine (so long as you remember to configure your entire network). On the other hand, if the special settings are more fundamental then more protocol work may be needed. An approach here is to ask the working group a specific question -- Does anyone know of reasons why the MPLS TTL is set greater than 63? e

I'd be really interested to hear what other operators think about your problem statement. That's not because I don't believe you, but because I find it interesting that others haven't previously raised the concern - but someone has to be first :-)

Cheers,
Adrian

_______________________________________________
mpls mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mpls