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

[Huub van Helvoort <[e-mail]>]

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.

-------

On 14-09-16 11:34, Adrian Farrel wrote:
> 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

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