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

[Pablo Frank <[e-mail]>]

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