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

[Umut Keten <[e-mail]>]

New draft uploaded thanks to Pablo and Huub!

Open for new comments:


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



Name:                  draft-keten-mpls-expbit

Revision:             02

Title:                     MPLS EXP/TC BIT EXPANSION

Document date:              2016-09-15

Group:                 Individual Submission

Pages:                  6

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

Status:         https://datatracker.ietf.org/doc/draft-keten-mpls-expbit/

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

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



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: mpls [mailto:[e-mail]] On Behalf Of Umut Keten
Sent: Thursday, September 15, 2016 9:56 PM
To: Pablo Frank <[e-mail]>; [e-mail]
Subject: RE: [mpls] FW: New Version Notification for draft-keten-mpls-expbit-00.txt

Hello Pablo,

First of all thank you for your comment.

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

Untill now someone here yet has to answer the TTL question, do we need the full length? My opinion it's a waste of bits. Maybe soneone can give an example where it is used.

Everyone till now only had to say what couldn't be done and concerns. Your reply is godgiven, thank you for that.

If your an enteprise sure you can fix priority at ip level, if you are a telco and your network is sometimes overutilized you would like to prioritize better instead of investing.

Back to your suggestion:


   Octets  0             1              2             3              4

   Bits   1 2 3 4 5 6 7 8

   Label   -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-+-+-+-+-
   Stack  |             Label               |  EXP   |S| X |    TTL     |
   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
      X:           Complimentary QoS bits
      TTL:         Time to Live, 6 bits

20 bits label : 3 bits COS : 1 bit S : 2 bit X : 6 bit TTL

I think it is brilliant.

I will update the draft accordingly.

Lets see, thanks again for your suggestion.


Krgrds,
Umut





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

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 <[e-mail]<mailto:[e-mail]>> 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: [phone]<tel:%2B972-39266302>
Cell:      [phone]<tel:%2B972-549266302>
Email:   [e-mail]<mailto:[e-mail]>

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

Cc: [e-mail]<mailto:[e-mail]>
Subject: RE: [mpls] FW: New Version Notification for draft-keten-mpls-expbit-00.txt

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 <[e-mail]<mailto:[e-mail]>>
Tarih: 14 09 2016 15:04 (GMT+02:00)
Alıcı: Umut Keten <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
Konu: 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.

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

Regards,
Sasha

Office: [phone]<tel:%2B972-39266302>
Cell:      [phone]<tel:%2B972-549266302>
Email:   [e-mail]<mailto:[e-mail]>

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


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:[e-mail]] On Behalf Of Umut Keten
Sent: Wednesday, September 14, 2016 2:46 PM
To: Alexander Vainshtein <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>
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.

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



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



[e-mail]<mailto:[e-mail]>



03125551931

[phone]<tel:%2B90%20%28553%29%20349%2096%2069>




[cid:image002.png@01D20E9E.2934BF30]<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: Alexander Vainshtein [mailto:[e-mail]]
Sent: Wednesday, September 14, 2016 2:23 PM
To: [e-mail]<mailto:[e-mail]>; Umut Keten <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>
Subject: RE: [mpls] FW: New Version Notification for draft-keten-mpls-expbit-00.txt

+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: [phone]<tel:%2B972-39266302>
Cell:      [phone]<tel:%2B972-549266302>
Email:   [e-mail]<mailto:[e-mail]>

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

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]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[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]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[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]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/mpls

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

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