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

[Greg Mirsky <[e-mail]>]

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

Regards, Greg

On Wed, Sep 14, 2016 at 5:39 AM, Alexander Vainshtein <
[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]
>
> Cell:      [phone]
>
> Email:   [e-mail]
>
>
>
> *From:* Umut Keten [mailto:[e-mail]]
> *Sent:* Wednesday, September 14, 2016 3:27 PM
> *To:* Alexander Vainshtein <[e-mail]>
>
> *Cc:* [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]>
>
> Tarih: 14 09 2016 15:04 (GMT+02:00)
>
> Alıcı: Umut Keten <[e-mail]>
>
> Cc: [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]
>
> Cell:      [phone]
>
> Email:   [e-mail]
>
>
>
> *From:* mpls [mailto:[e-mail] <[e-mail]>] *On
> Behalf Of *Umut Keten
> *Sent:* Wednesday, September 14, 2016 2:50 PM
> *To:* [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] <[e-mail]>] *On
> Behalf Of *Umut Keten
> *Sent:* Wednesday, September 14, 2016 2:46 PM
> *To:* Alexander Vainshtein <[e-mail]>;
> [e-mail]; [e-mail]
> *Cc:* [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
>
>
>
>
>
>
>
>
>
> [image: 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]
>
>
>
> 03125551931
>
> [phone]
>
> * <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]
> <[e-mail]>]
> Sent: Wednesday, September 14, 2016 2:23 PM
> To: [e-mail]; Umut Keten <[e-mail]>;
> [e-mail]
> Cc: [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]
> Cell:      [phone]
> Email:   [e-mail]
>
> -----Original Message-----
> From: mpls [mailto:[e-mail] <[e-mail]>] On
> Behalf Of [e-mail]
> Sent: Wednesday, September 14, 2016 1:54 PM
> To: [e-mail]; [e-mail]
> Cc: [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] <[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] <[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
>
> _______________________________________________
> mpls mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls
>
> _______________________________________________
> mpls mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls
>
>