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

[Alexander Okonnikov <[e-mail]>]

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 пишет:
>
> 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: [phone]
>
> Cell: [phone]
>
> Email: [e-mail]
>
> *From:*Alexander Vainshtein
> *Sent:* Wednesday, September 14, 2016 3:04 PM
> *To:* 'Umut Keten' <[e-mail]>
> *Cc:* [e-mail]
> *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.
>
> What is not needed IMHO is more traffic classes within the MPLS domain.
>
> Regards,
>
> Sasha
>
> Office: [phone]
>
> Cell: [phone]
>
> 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]
>
> 	
> 	
>
> *<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]
> Cell:      [phone]
> 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]
> https://www.ietf.org/mailman/listinfo/mpls