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

From: Umut Keten <[email-masked]>
Date: Tue, 13 Sep 2016 21:44:24 +0000

Hello Adrian,

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?

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.
However the backwards compatability part has been misunderstood by me, Deborah asked me to add a section for that and honestly I did that expecting it meant "can you roll back to the old"

My mistake and sorry for the misunderstanding. I will update that accordingly ASAP.

All your suppose questions are valid, if an old format and new format would have different values in different sequences they would act upon it, ie if it receives an S bit it would handle it as such.

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.

Even now we are juggling with stuff like pre-classify, if we had more QoS we wouldn't have to. LTE backhaul i get 9 QoS and even that pains me.

I think the TTL field is too long, it can be of much better use as QoS.

Thank you again for your feedback Adrian, I truly appreciate it.

Regards,
Umut

-------- Orijinal mesaj --------
Başlangıç tarihi: Adrian Farrel <[email-masked]>
Tarih: 14 09 2016 00:21 (GMT+02:00)
Alıcı: Umut Keten <[email-masked]>
Cc: [email-masked]
Konu: RE: [mpls] FW: New Version Notification for draft-keten-mpls-expbit-00.txt

Hi Umut,

I'm interested that you write
   No issues are expected regarding backwards compatability as the
   sequence of the header remains unchanged.

Suppose that an old format packet reaches a new format router.
Suppose that the TTL on the old format packet is set to 192.
Won't the new format router decide that the TTL is zero?

Suppose that an old format packet has TTL of 193. Won't the new format router decide the S bit is set?

I suspect the first thing you need to do is not determine what the largest diameter of an MPLS network is, but what implementations in the field do with the field when initiating packets. For example, are their special cases where TTL is set to 255?

Cheers,
Adrian

From: mpls [mailto:[email-masked]] On Behalf Of Umut Keten
Sent: 13 September 2016 18:45
To: [email-masked]
Subject: [mpls] FW: New Version Notification for draft-keten-mpls-expbit-00.txt

Dear Members,

Hereby I would like you to take a look at my recently/newly posted draft:
https://tools.ietf.org/html/draft-keten-mpls-expbit-00

I sincerely belief that this fundamental change is required. Feedback/Interest/Advise is appreciated.

Kind Regards,
Umut

[tt_logo_]

Umut Keten

Ürün ve Servis Kıdemli Mimarı
Ürün ve Servis Sunumu Direktörlüğü
Teknoloji Genel Müdür Yardımcılığı

[email-masked]

03125551931

+90 (553) 349 96 69

<http://www.4nokta5g.com/>

Yasal Uyarı :
Bu elektronik posta işbu linki kullanarak ulaşabileceğiniz Koşul ve Şartlar dökümanına tabidir :
www.turktelekom.com.tr/tt/portal/email-yasal-uyari<http://www.turktelekom.com.tr/tt/portal/email-yasal-uyari>
-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, September 13, 2016 8:39 PM
To: Umut Keten <[email-masked]>
Subject: New Version Notification for draft-keten-mpls-expbit-00.txt

A new version of I-D, draft-keten-mpls-expbit-00.txt has been successfully submitted by Umut Keten and posted to the IETF repository.

Name:           draft-keten-mpls-expbit
Revision:       00
Title:          MPLS EXP/TC BIT EXPANSION
Document date:  2016-09-13
Group:          Individual Submission
Pages:          6
URL:            https://www.ietf.org/internet-drafts/draft-keten-mpls-expbit-00.txt
Status:         https://datatracker.ietf.org/doc/draft-keten-mpls-expbit/
Htmlized:       https://tools.ietf.org/html/draft-keten-mpls-expbit-00

Abstract:
  This document specifies the new label/header architecture for a new
  Multiprotocol Label Switching and proposes a new Label Standard.
  With this new architecture the aim is to provide more QoS options.

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Umut Keten <[email-masked]>
Date: Tue, 13 Sep 2016 22:06:28 +0000

A new version of I-D, draft-keten-mpls-expbit-01.txt has been successfully submitted by Umut Keten and posted to the IETF repository.

Revision:             01

Document date:              2016-09-14

Pages:                  6

URL:            https://www.ietf.org/internet-drafts/draft-keten-mpls-expbit-01.txt

Htmlized:       https://tools.ietf.org/html/draft-keten-mpls-expbit-01

Diff:           https://www.ietf.org/rfcdiff?url2=draft-keten-mpls-expbit-01

Abstract:

The IETF Secretariat

From: Umut Keten
Sent: Wednesday, September 14, 2016 12:44 AM
To: [email-masked]
Cc: [email-masked]
Subject: YNT: [mpls] FW: New Version Notification for draft-keten-mpls-expbit-00.txt

Hello Adrian,

Regards,
Umut

-------- Orijinal mesaj --------
Başlangıç tarihi: Adrian Farrel <[email-masked]<mailto:[email-masked]>>
Tarih: 14 09 2016 00:21 (GMT+02:00)
Alıcı: Umut Keten <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Konu: RE: [mpls] FW: New Version Notification for draft-keten-mpls-expbit-00.txt

Hi Umut,

Cheers,
Adrian

From: mpls [mailto:[email-masked]] On Behalf Of Umut Keten
Sent: 13 September 2016 18:45
To: [email-masked]<mailto:[email-masked]>
Subject: [mpls] FW: New Version Notification for draft-keten-mpls-expbit-00.txt

Dear Members,

Kind Regards,
Umut

[tt_logo_]

Umut Keten

[email-masked]<mailto:[email-masked]>

03125551931

+90 (553) 349 96 69

Yasal Uyarı :
-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Tuesday, September 13, 2016 8:39 PM
To: Umut Keten <[email-masked]<mailto:[email-masked]>>
Subject: New Version Notification for draft-keten-mpls-expbit-00.txt

Abstract:

The IETF Secretariat

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 14 Sep 2016 10:34:22 +0100

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?

> 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

---

From: Umut Keten <[email-masked]>
Date: Wed, 14 Sep 2016 10:18:51 +0000

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. 

	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…

	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.

>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:[email-masked]] 
Sent: Wednesday, September 14, 2016 12:34 PM
To: Umut Keten <[email-masked]>
Cc: [email-masked]
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?

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

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

Cheers,
Adrian

---

From: Huub van Helvoort <[email-masked]>
Date: Wed, 14 Sep 2016 12:32:25 +0200

Hello Umut,

I share Adrian's concerns.

What you propose is a revolution, not an evolution.
A revolution that requires that all network elements MUST be upgraded
(hardware and/or software) in the shortest possible time.
Even if the application is limited to a domain, the border elements
of the domain have to "translate" the format, an extra processing
burden.

The change of the position of the bottom of stack bit (S-bit) will
have the most disruptive effect.

Best regards, Huub.

-------

-- 
================================================================
Always remember that you are unique...just like everyone else...

---

From: <[email-masked]>
Date: Wed, 14 Sep 2016 10:54:29 +0000

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:[email-masked]] Im Auftrag von Umut Keten
Gesendet: Mittwoch, 14. September 2016 12:19
An: [email-masked]
Cc: [email-masked]
Betreff: Re: [mpls] FW: New Version Notification for draft-keten-mpls-expbit-00.txt

Hey Adrian,

	Only fair :-) Yes

   were marked accordingly?

Krgrds,
Umut

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

Umut,

Cheers,
Adrian

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

---

From: Umut Keten <[email-masked]>
Date: Wed, 14 Sep 2016 11:11:22 +0000

Hello group,

Please, only impact  and concerns, no one said a word about what the right thing to do is. Only concerns, because the proposed advises a change? Change on something that is 15 years old.

Nic and Adrian, I don't think that much of change is required and should we really discuss this at the beginning?

Almost 15 years ago 8 bits where assigned to TTL. Too much.
No one really can answer this? Instead of concerns?

Lets start from scratch by please answering these:
Do we really need all those TTL bits? Yes or No? Why?
Do/Could we need them for QoS? Yes or No? Why?

The existing Mechansisms are not enough.  IoT is coming (winter is coming :-) )

You are not going to solve this with pre-classify ing. I am presenting a solution where you do not have to pre classify at the edge. MPLS was envisioned to do this.
Unified MPLS will carry on doing this. You advise we will not do this but pre service classify at the edge. SO invest change at the edge but do not touch the MPLS.

Lets discuss first why we need all of those bits at TTL? Does anyone has anything to say regarding that?
Then lets discuss if more QoS would be handy?

Then after that we could see what concerns we have? And if they are really concerns?

Krgrds,
Umut

[tt_logo_]

Umut Keten

03125551931
+90 (553) 349 96 69

Yasal Uyarı :

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, September 14, 2016 1:54 PM
To: Umut Keten <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: AW: [mpls] FW: New Version Notification for draft-keten-mpls-expbit-00.txt

Hi,

Regards

Nic

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

Hey Adrian,

       Only fair :-) Yes

  were marked accordingly?

Krgrds,
Umut

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

Umut,

Cheers,
Adrian

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 14 Sep 2016 11:23:22 +0000

+1.
As I see it, fine QoS differentiation is required in the "bottleneck" segments of the network, usually in the first/last mile.
And, AFAIK, neither IPTV set-top boxes, nor LTE Node Bs natively run MPLS; they use plain IP. 
So what you probably really need is ability to assign traffic classes based on the DSCP values in IP headers of the packets that leave the MPLS domain and continue as plain IP. Did I miss something?

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302
Email:   [email-masked]

-----Original Message-----
From: mpls [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, September 14, 2016 1:54 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [mpls] FW: New Version Notification for draft-keten-mpls-expbit-00.txt

Hi,

Regards

Nic

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

Hey Adrian,

	Only fair :-) Yes

   were marked accordingly?

Krgrds,
Umut

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

Umut,

Cheers,
Adrian

---

From: Umut Keten <[email-masked]>
Date: Wed, 14 Sep 2016 11:45:35 +0000

Hey Alexander,

Example: I have multiple domains of ADSL. A Domain has premium BE traffic. Yet at MPLS we receive the same DSCP bits.

Same counts for mobile backhaul, as a telco provider we give backhaul to multiple operators.
One operator I sell premium and I want him to have better BE traffic. Yet they will arrive with the same bits set.

But if I can differentiate them in the MPLS, I can say if I receive this bit from this port I set to this and from this port to this.

Currently we only have 8. I can't differentiate.

Krgrds,
Umut

[tt_logo_]

Umut Keten

03125551931
+90 (553) 349 96 69

Yasal Uyarı :

-----Original Message-----
From: Alexander Vainshtein [mailto:[email-masked]]
Sent: Wednesday, September 14, 2016 2:23 PM
To: [email-masked]; Umut Keten <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: RE: [mpls] FW: New Version Notification for draft-keten-mpls-expbit-00.txt

+1.

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

-----Original Message-----
From: mpls [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, September 14, 2016 1:54 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [mpls] FW: New Version Notification for draft-keten-mpls-expbit-00.txt

Hi,

Regards

Nic

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

Hey Adrian,

       Only fair :-) Yes

  were marked accordingly?

Krgrds,
Umut

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

Umut,

Cheers,
Adrian

---

From: Umut Keten <[email-masked]>
Date: Wed, 14 Sep 2016 11:50:07 +0000

Ok I thought of something else.

What if the architecture become like the below?

   Octets  0             1              2             3              4

   Bits   1 2 3 4 5 6 7 8

   Label   -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-+-+-+-+-

   Stack  |             Label               |  EXP   |S|   TTL    | X |

   Entry   -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-+-+-+-+-

     Figure 1

      Label:       Label Value, 20 bit

      EXP/TC/COS:  3 bits defined as TC, RFC 5462<https://tools.ietf.org/html/rfc5462>

      S:           Bottom of Stack, 1 bit

      TTL:         Time to Live, 6 bits

      X:          Complimentary QoS bit

We won't touch the S bit and the sequence. If a old and not upgraded router would receive the X bit it would simply set a strange TTL value (what would be the impact of that?)

A new router could make something complimentary to the QoS?

Krgrds,

Umut

From: mpls [mailto:[email-masked]] On Behalf Of Umut Keten
Sent: Wednesday, September 14, 2016 2:46 PM
To: Alexander Vainshtein <[email-masked]>; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [mpls] FW: New Version Notification for draft-keten-mpls-expbit-00.txt

Hey Alexander,

Krgrds,
Umut

[tt_logo_]

Umut Keten

03125551931

+90 (553) 349 96 69

Yasal Uyarı :
-----Original Message-----
From: Alexander Vainshtein [mailto:[email-masked]]
Sent: Wednesday, September 14, 2016 2:23 PM
To: [email-masked]<mailto:[email-masked]>; Umut Keten <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: [mpls] FW: New Version Notification for draft-keten-mpls-expbit-00.txt

+1.

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302
Email:   [email-masked]<mailto:[email-masked]>

-----Original Message-----
From: mpls [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Wednesday, September 14, 2016 1:54 PM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [mpls] FW: New Version Notification for draft-keten-mpls-expbit-00.txt

Hi,

Regards

Nic

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

Hey Adrian,

       Only fair :-) Yes

  were marked accordingly?

Krgrds,
Umut

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

Umut,

Cheers,
Adrian

_______________________________________________
mpls mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mpls

_______________________________________________
mpls mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mpls

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 14 Sep 2016 12:04:30 +0000

Umut,
Mapping of DSCP to TC usually can be defined per ingress interface (when an IP packet enters the MPLS domain).
What is probably missing is ability to define this mapping per service instance or per egress interface when the packet leaves the MPLS domain.

What is not needed IMHO is more traffic classes within the MPLS domain.

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

From: mpls [mailto:[email-masked]] On Behalf Of Umut Keten
Sent: Wednesday, September 14, 2016 2:50 PM
To: [email-masked]
Subject: Re: [mpls] FW: New Version Notification for draft-keten-mpls-expbit-00.txt

   Octets  0             1              2             3              4

   Bits   1 2 3 4 5 6 7 8

     Figure 1

      X:          Complimentary QoS bit

Krgrds,

Umut

To: Alexander Vainshtein <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

Hey Alexander,

Krgrds,
Umut

[tt_logo_]

Umut Keten

03125551931

+90 (553) 349 96 69

Yasal Uyarı :
-----Original Message-----
From: Alexander Vainshtein [mailto:[email-masked]]
Sent: Wednesday, September 14, 2016 2:23 PM
To: [email-masked]<mailto:[email-masked]>; Umut Keten <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: [mpls] FW: New Version Notification for draft-keten-mpls-expbit-00.txt

+1.

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

-----Original Message-----
From: mpls [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Wednesday, September 14, 2016 1:54 PM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [mpls] FW: New Version Notification for draft-keten-mpls-expbit-00.txt

Hi,

Regards

Nic

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

Hey Adrian,

       Only fair :-) Yes

  were marked accordingly?

Krgrds,
Umut

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

Umut,

Cheers,
Adrian

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 14 Sep 2016 12:09:01 +0000

Umut,
As for your proposed modification:

1.       Since all LSRs are supposed to decrement TTL (as they understand it), an "old" LSR that receives a packet from a "new" one and forwards it to a "new" one would modify the TC in an unpredictable way

2.       In addition, this proposal would break the OAM functionality provided by LSP Ping in Traceroute mode.

>From my POV, each of these concerns should be considered as a stopper.

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

From: Alexander Vainshtein
Sent: Wednesday, September 14, 2016 3:04 PM
To: 'Umut Keten' <[email-masked]>
Cc: [email-masked]
Subject: RE: [mpls] FW: New Version Notification for draft-keten-mpls-expbit-00.txt

Umut,

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

   Octets  0             1              2             3              4

   Bits   1 2 3 4 5 6 7 8

     Figure 1

      X:          Complimentary QoS bit

Krgrds,

Umut

Hey Alexander,

Krgrds,
Umut

[tt_logo_]

Umut Keten

03125551931

+90 (553) 349 96 69

Yasal Uyarı :
-----Original Message-----
From: Alexander Vainshtein [mailto:[email-masked]]
Sent: Wednesday, September 14, 2016 2:23 PM
To: [email-masked]<mailto:[email-masked]>; Umut Keten <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: [mpls] FW: New Version Notification for draft-keten-mpls-expbit-00.txt

+1.

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

-----Original Message-----
From: mpls [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Wednesday, September 14, 2016 1:54 PM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [mpls] FW: New Version Notification for draft-keten-mpls-expbit-00.txt

Hi,

Regards

Nic

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

Hey Adrian,

       Only fair :-) Yes

  were marked accordingly?

Krgrds,
Umut

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

Umut,

Cheers,
Adrian

---

From: Alexander Okonnikov <[email-masked]>
Date: Wed, 14 Sep 2016 15:15:57 +0300

Hello Umut,

Also, what about setting TTL greater than 63 - it is very possible that 
Uniform model for TTL processing is used. If you propose new scheme, 
Uniform model cannot not be used anymore.

14.09.2016 15:09, Alexander Vainshtein пишет:
> 1.Since all LSRs are supposed to decrement TTL (as they understand 
> it), an “old” LSR that receives a packet from a “new” one and forwards 
> it to a “new” one would modify the TC in an unpredictable way
>
> 2.In addition, this proposal would break the OAM functionality 
> provided by LSP Ping in Traceroute mode.
>
> *From:*Alexander Vainshtein
> *Sent:* Wednesday, September 14, 2016 3:04 PM
> *To:* 'Umut Keten' <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* RE: [mpls] FW: New Version Notification for 
> draft-keten-mpls-expbit-00.txt
>
> Umut,
>
> Mapping of DSCP to TC usually can be defined per ingress interface 
> (when an IP packet enters the MPLS domain).
>
> What is probably missing is ability to define this mapping per service 
> instance or per egress interface when the packet leaves the MPLS domain.
>
> <mailto:[email-masked]>
>
> *From:*mpls [mailto:[email-masked]] *On Behalf Of *Umut Keten
> *Sent:* Wednesday, September 14, 2016 2:50 PM
> *To:* [email-masked] <mailto:[email-masked]>
> *Subject:* Re: [mpls] FW: New Version Notification for 
> draft-keten-mpls-expbit-00.txt
>
> We won’t touch the S bit and the sequence. If a old and not upgraded 
> router would receive the X bit it would simply set a strange TTL value 
> (what would be the impact of that?)
> *From:*mpls [mailto:[email-masked]] *On Behalf Of *Umut Keten
> *Sent:* Wednesday, September 14, 2016 2:46 PM
> *To:* Alexander Vainshtein <[email-masked] 
> <mailto:[email-masked]>>; [email-masked] 
> <mailto:[email-masked]>; [email-masked] 
> <mailto:[email-masked]>
> *Cc:* [email-masked] <mailto:[email-masked]>
> *Subject:* RE: [mpls] FW: New Version Notification for 
> draft-keten-mpls-expbit-00.txt
>
> Hey Alexander,
>
> Example: I have multiple domains of ADSL. A Domain has premium BE 
> traffic. Yet at MPLS we receive the same DSCP bits.
>
> One operator I sell premium and I want him to have better BE traffic. 
> Yet they will arrive with the same bits set.
>
> But if I can differentiate them in the MPLS, I can say if I receive 
> this bit from this port I set to this and from this port to this.
>
> tt_logo_
> **
> *Umut Keten*
> [email-masked] <mailto:[email-masked]>
>
> 	
> 	
>
> 03125551931
>
> 	
> 	
>
> +90 (553) 349 96 69
>
> 	
> 	
>
> *<http://www.4nokta5g.com/>*
>
> *Yasal Uyarı :**
> *Bu elektronik posta işbu linki kullanarak ulaşabileceğiniz Koşul ve 
> Şartlar dökümanına tabidir :*
> **www.turktelekom.com.tr/tt/portal/email-yasal-uyari* 
> <http://www.turktelekom.com.tr/tt/portal/email-yasal-uyari>
>
> To: [email-masked] <mailto:[email-masked]>; Umut Keten 
> <[email-masked] 
> <mailto:[email-masked]>>; [email-masked] 
> <mailto:[email-masked]>
> Cc: [email-masked] <mailto:[email-masked]>
> As I see it, fine QoS differentiation is required in the "bottleneck" 
> segments of the network, usually in the first/last mile.
> So what you probably really need is ability to assign traffic classes 
> based on the DSCP values in IP headers of the packets that leave the 
> MPLS domain and continue as plain IP. Did I miss something?
>
> Regards,
> Sasha
>
> Office: +972-39266302
> Cell:      +972-549266302
> <mailto:[email-masked]>
>
> From: mpls [mailto:[email-masked]] On Behalf Of 
> [email-masked] <mailto:[email-masked]>
> To: [email-masked] 
> <mailto:[email-masked]>; [email-masked] 
> <mailto:[email-masked]>
> Cc: [email-masked] <mailto:[email-masked]>
> 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
>
> An: [email-masked] <mailto:[email-masked]>
> Cc: [email-masked] <mailto:[email-masked]>
>        Not really, I think this is a whole package at once and treated 
> as such. I believe this discussion should have started earlier though.
>
>        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.
>
>        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.
>
>        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.
>
>        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.
>
> >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
> 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.
>
> 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 ;-)
>
>
>
> Cc: [email-masked] <mailto:[email-masked]>
> 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?
>
> 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
>
> [email-masked] <mailto:[email-masked]>
> [email-masked] <mailto:[email-masked]>

---

From: Umut Keten <[email-masked]>
Date: Wed, 14 Sep 2016 12:27:16 +0000

Alexander hi,

I don't agree. I think we need more QoS classes. I personally could do with a lower class then BE, something like a trash class.

I can map the lowest to BE and thats it, but some services I would like to map lower.
Mapping the more important BE one higher then BE is no option, it would affect other services.

Saying we don't need more QoS, surely you can't mean that.

Krgrds,
Umut

-------- Orijinal mesaj --------
Başlangıç tarihi: Alexander Vainshtein <[email-masked]>
Tarih: 14 09 2016 15:04 (GMT+02:00)
Alıcı: Umut Keten <[email-masked]>
Cc: [email-masked]
Konu: RE: [mpls] FW: New Version Notification for draft-keten-mpls-expbit-00.txt

Umut,

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

   Octets  0             1              2             3              4

   Bits   1 2 3 4 5 6 7 8

     Figure 1

      X:          Complimentary QoS bit

We won’t touch the S bit and the sequence. If a old and not upgraded router would receive the X bit it would simply set a strange TTL value (what would be the impact of that?)

Krgrds,

Umut

Hey Alexander,

Krgrds,
Umut

[tt_logo_]

Umut Keten

03125551931

+90 (553) 349 96 69

Yasal Uyarı :
-----Original Message-----
From: Alexander Vainshtein [mailto:[email-masked]]
Sent: Wednesday, September 14, 2016 2:23 PM
To: [email-masked]<mailto:[email-masked]>; Umut Keten <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: [mpls] FW: New Version Notification for draft-keten-mpls-expbit-00.txt

+1.

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

-----Original Message-----
From: mpls [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Wednesday, September 14, 2016 1:54 PM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [mpls] FW: New Version Notification for draft-keten-mpls-expbit-00.txt

Hi,

Regards

Nic

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

Hey Adrian,

       Only fair :-) Yes

  were marked accordingly?

Krgrds,
Umut

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

Umut,

Cheers,
Adrian

---

From: Mark Tinka <[email-masked]>
Date: Wed, 14 Sep 2016 14:39:27 +0200

On 14/Sep/16 14:27, Umut Keten wrote:

> Alexander hi,
>
> I don't agree. I think we need more QoS classes. I personally could do
> with a lower class then BE, something like a trash class.
>

I don't think we need more QoS.

We run 4 classes, 1 of which is reserved for NC. So effectively, we run
3 classes for actual service (BE, AF and EF). We've struggled to use
anything more, not that we are trying.

The issue with QoS is not the number of classes you have, but how much
classification you realistically do. This is a lot more difficult in a
service provider network compared to the enterprise. The fact that MPLS
is protocol-independent also means adding more classes to it somewhat
defeats the purpose.

But, YMMV.

Mark.

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 14 Sep 2016 12:39:30 +0000

Umut,
I can only repeat that from my POV we do not need more traffic classes within the MPLS domain. Let's agree to disagree about that if you wish.

I am also absolutely opposed to any proposals to change the label stack encoding because such a change would not be backward-compatible.
FYI, attempts to change the label stack encoding have been already rejected by the MPLS WG when T-MPLS was originally proposed; eventually, MPLS-TP t(hat does not change label stack encoding) has replaced it.

My 2c,
Sasha

Office: +972-39266302
Cell:      +972-549266302

From: Umut Keten [mailto:[email-masked]]
Sent: Wednesday, September 14, 2016 3:27 PM
To: Alexander Vainshtein <[email-masked]>
Cc: [email-masked]
Subject: RE: [mpls] FW: New Version Notification for draft-keten-mpls-expbit-00.txt

Alexander hi,

Krgrds,
Umut

-------- Orijinal mesaj --------
Başlangıç tarihi: Alexander Vainshtein <[email-masked]<mailto:[email-masked]>>
Tarih: 14 09 2016 15:04 (GMT+02:00)
Alıcı: Umut Keten <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Konu: RE: [mpls] FW: New Version Notification for draft-keten-mpls-expbit-00.txt

Umut,

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

   Octets  0             1              2             3              4

   Bits   1 2 3 4 5 6 7 8

     Figure 1

      X:          Complimentary QoS bit

Krgrds,

Umut

Hey Alexander,

Krgrds,
Umut

[tt_logo_]

Umut Keten

03125551931

+90 (553) 349 96 69

Yasal Uyarı :
-----Original Message-----
From: Alexander Vainshtein [mailto:[email-masked]]
Sent: Wednesday, September 14, 2016 2:23 PM
To: [email-masked]<mailto:[email-masked]>; Umut Keten <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: [mpls] FW: New Version Notification for draft-keten-mpls-expbit-00.txt

+1.

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

-----Original Message-----
From: mpls [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Wednesday, September 14, 2016 1:54 PM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [mpls] FW: New Version Notification for draft-keten-mpls-expbit-00.txt

Hi,

Regards

Nic

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

Hey Adrian,

       Only fair :-) Yes

  were marked accordingly?

Krgrds,
Umut

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

Umut,

Cheers,
Adrian

---

From: Pablo Frank <[email-masked]>
Date: Thu, 15 Sep 2016 14:29:19 -0400

Umut, I won't comment on whether we _should_ do this, but...

IF what you say is true and that MPLS networks don't need such large TTLs
then it seems that stealing the 2 most-significant-bits from the TTL would
be much less harmful than the least-significant-bits.  If your assumption
is correct, these bits will "never" be decremented.  The other
consideration is that certain OAM mechanisms rely on TTL decrementing to
zero to trap frames.  I think you would have to specify that OAM protocols
in this new architecture would never set these "extended" TC bits.  Given
your stated intent to use these as extra "trash" tiers, perhaps that's not
such a big deal (i.e. who wants to do performance monitoring of "trash"
tier anyway?).  Alternatively, you could look at these as "premium" trash
tiers and hopping too much is grounds to have your extended TC
"downgraded".

In terms of whether this could be implemented as a software upgrade in
existing gear, I think the answer is a qualified "yes".  Certainly NPU /
FPGA / NFV-based solutions could add this functionality with a software
upgrade.  Even semi-programmable ASICs (like the one that's named after a
pile of sand) could do this with some clever reconfiguration /
programming.  Only fully baked-in ASICs would have difficulty implementing
this.  But the variant that I've described is backwards compatible so I
think it meets your requirements.

regards,
Pablo

On Wed, Sep 14, 2016 at 8:39 AM, Alexander Vainshtein <
[email-masked]> wrote:

> Umut,
>
> I can only repeat that from my POV we do not need *more traffic classes
> within the MPLS domain*. Let’s agree to disagree about that if you wish.
>
>
>
> I am also *absolutely* *opposed* to any proposals to change the label
> stack encoding because such a change would not be backward-compatible.
>
> FYI, attempts to change the label stack encoding have been already
> rejected by the MPLS WG when T-MPLS was originally proposed; eventually,
> MPLS-TP t(hat does not change label stack encoding) has replaced it.
>
>
>
> My 2c,
>
> Sasha
>
>
>
> Office: +972-39266302
>
> Cell:      +972-549266302
>
> *From:* Umut Keten [mailto:[email-masked]]
> *Sent:* Wednesday, September 14, 2016 3:27 PM
> *To:* Alexander Vainshtein <[email-masked]>
>
> *Cc:* [email-masked]
> *From:* mpls [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *Umut Keten
> *To:* [email-masked]
>       EXP/TC/COS:  3 bits defined as TC, RFC 5462 <https://tools.ietf.org/html/rfc5462>
>
> *From:* mpls [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *Umut Keten
> *To:* Alexander Vainshtein <[email-masked]>;
> [email-masked]; [email-masked]
> *Cc:* [email-masked]
> Example: I have multiple domains of ADSL. A Domain has premium BE traffic.
> Yet at MPLS we receive the same DSCP bits.
>
> But if I can differentiate them in the MPLS, I can say if I receive this
> bit from this port I set to this and from this port to this.
>
> * <http://www.4nokta5g.com/>*
>
> *Yasal Uyarı :*
>
> * Bu elektronik posta işbu linki kullanarak ulaşabileceğiniz Koşul ve
> Şartlar dökümanına tabidir : *
> *www.turktelekom.com.tr/tt/portal/email-yasal-uyari*
> From: Alexander Vainshtein [mailto:[email-masked]
> <[email-masked]>]
> based on the DSCP values in IP headers of the packets that leave the MPLS
> domain and continue as plain IP. Did I miss something?
>
> Regards,
> Sasha
>
> Office: +972-39266302
> Cell:      +972-549266302
> From: mpls [mailto:[email-masked] <[email-masked]>] On
> Behalf Of [email-masked]
> 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
>
> Von: mpls [mailto:[email-masked] <[email-masked]>] Im
> Auftrag von Umut Keten
>        Not really, I think this is a whole package at once and treated as
> such. I believe this discussion should have started earlier though.
>
>        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.
>
> 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.
>
> supported these. The other routers I should assume they should be able to
> do so as well.
>
>        Expensive solution? I don't think so (experience from the timetra
> OS Alcatel) However the vendors should answer this.
>
> upgrade the routers could have a feature new/old. This then in turn could
> be handled over NMS.
>
> 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?
>
> 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.
>
> 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
> 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.
>
> 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
>
> From: Adrian Farrel [mailto:[email-masked] <[email-masked]>]
> 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?
>
> 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
>
> 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
>

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 15 Sep 2016 20:03:39 -0700

Hi Umut, et. al,
I concur with Sasha.

Regards, Greg

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 15 Sep 2016 20:06:57 -0700

Hi Umut,
the right term to use would be CoS (Class of Service), not QoS (Quality of
Service). Whether it is DSCP, PCP or TC, in case of MPLS, these are all CoS
markings that are interpreted by network elements according to QoS policies.

Regards,
Greg

On Wed, Sep 14, 2016 at 5:27 AM, Umut Keten <[email-masked]>
wrote:

> *From:* mpls [mailto:[email-masked]] *On Behalf Of *Umut Keten

---

From: Umut Keten <[email-masked]>
Date: Fri, 16 Sep 2016 07:56:06 +0000

Heya Greg,

After the input from Paulo:

Backward compatability part received an update and the concern should be minimilized. Please review recent mail and draft.

Krgrds,
Umut

-------- Orijinal mesaj --------
Başlangıç tarihi: Greg Mirsky <[email-masked]>
Tarih: 16 09 2016 06:03 (GMT+02:00)
Alıcı: Alexander Vainshtein <[email-masked]>
Cc: Umut Keten <[email-masked]>, [email-masked]
Konu: RE: [mpls] FW: New Version Notification for draft-keten-mpls-expbit-00.txt

Hi Umut, et. al,
I concur with Sasha.

Regards, Greg

On Wed, Sep 14, 2016 at 5:39 AM, Alexander Vainshtein <[email-masked]<mailto:[email-masked]>> wrote:
Umut,
I can only repeat that from my POV we do not need more traffic classes within the MPLS domain. Let’s agree to disagree about that if you wish.

My 2c,
Sasha

Office: +972-39266302<tel:%2B972-39266302>
Cell:      +972-549266302<tel:%2B972-549266302>
Email:   [email-masked]<mailto:[email-masked]>

From: Umut Keten [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Wednesday, September 14, 2016 3:27 PM
To: Alexander Vainshtein <[email-masked]<mailto:[email-masked]>>

Alexander hi,

Krgrds,
Umut

-------- Orijinal mesaj --------
Başlangıç tarihi: Alexander Vainshtein <[email-masked]<mailto:[email-masked]>>
Tarih: 14 09 2016 15:04 (GMT+02:00)
Alıcı: Umut Keten <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Konu: RE: [mpls] FW: New Version Notification for draft-keten-mpls-expbit-00.txt

Umut,

Regards,
Sasha

Office: +972-39266302<tel:%2B972-39266302>
Cell:      +972-549266302<tel:%2B972-549266302>
Email:   [email-masked]<mailto:[email-masked]>

   Octets  0             1              2             3              4

   Bits   1 2 3 4 5 6 7 8

     Figure 1

      X:          Complimentary QoS bit

Krgrds,

Umut

Hey Alexander,

Krgrds,
Umut

[tt_logo_]

Umut Keten

03125551931

+90 (553) 349 96 69<tel:%2B90%20%28553%29%20349%2096%2069>

Yasal Uyarı :
-----Original Message-----
From: Alexander Vainshtein [mailto:[email-masked]]
Sent: Wednesday, September 14, 2016 2:23 PM
To: [email-masked]<mailto:[email-masked]>; Umut Keten <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: [mpls] FW: New Version Notification for draft-keten-mpls-expbit-00.txt

+1.

Regards,
Sasha

Office: +972-39266302<tel:%2B972-39266302>
Cell:      +972-549266302<tel:%2B972-549266302>
Email:   [email-masked]<mailto:[email-masked]>

-----Original Message-----
From: mpls [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Wednesday, September 14, 2016 1:54 PM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [mpls] FW: New Version Notification for draft-keten-mpls-expbit-00.txt

Hi,

Regards

Nic

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

Hey Adrian,

       Only fair :-) Yes

  were marked accordingly?

Krgrds,
Umut

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

Umut,

Cheers,
Adrian