Использование DSCP это если short-pipe или uniform модель по отношению к маркировке и только на интерфейсе на выходе из MPLS (Egress PE)

Почему два класса пропадают непонятно, если честно. Один под Control Plane трафик, а второй?

и это как правило предполагает ре-классификацию на Outgoing Interface на основе DSCP (которой доверять нельзя в большей части случаев) или 802.1p.

ну по классике принято один из верхних использовать для control plane, второй для management plane, хотя это конечно все условность и все зависит от фантазий архитектора

ну и да, в реальной жизни на транспорте нескольких классов вполне достаточно. ну не будешь же ты фантазии каждого гос. заказчика (наверное все читали фантазии российской налоговой) проецировать на транспорт.

выделение mgmt/OAM в отдельный FC спорно конечно, можно смешать с коммерческим трафиком с теми же требованиями и характеристиками.
Только если у тебя в OAM какие то метрики собираются, тогда да.
Да, согласен, это больше условность.

но вопрос остаётся в силе, что делать если надо иметь больше 6-7 FC для коммерческого трафика

если у кого-то в реальности встанет такая задача, то скорее всего придется переходить с mpls на vxlan

SRv6 больше нравится )

да это хуйня какая-то мертворожденная

или гонять vlan-тегированный mpls и комбинировать 802.1p с mpls tc метками, будет у тебя 6 бит

ну правда если оборудование сможет по 802.1p+mpls tc пихать в нужный FC

а чё там?

у них много лет в тендерах был h-qos очень сложный в требования, кто-то явно перечитал маркетинговых презентаций по qos

не знаю как щас, но не думаю что что-то поменялось

Тут есть несколько вариантов направлений копания, в зависимости от специфики потребностей. Ограничение тут по ширине поля для маркировок, и если надо больше битов - то надо пользовать больше меток. Две группы вариантов - это энтропия и туннелирование. Если используем энтропию, то у нас есть всего 9 бит (LSP + ELI + EL), и в которых можно напрямую отобразить входящее значение DSCP или другой сигнал. Транзитный узел, если умеет обрабатывать EL, будет видеть все три поля TC, и тогда уже вопрос реализации на нем, как он сможет это интерпретировать. Что хорошо в этом методе - EL по определению разрешает копаться глубже чем обрабатываемая метка. Вариант с туннелированием похож - также две метки (это вложенный туннель, конечные точки внешнего и внутреннего туннеля совпадают), и сигнал идет раздельно по 3 бита в каждой метке. Так как нет специальной метки как в варианте с EL, то вопрос копания глубже имеет некоторый серый оттенок - но это не принципиальное ограничение. С этим вариантом надо быть немного более осторожным с раздаванием меток - они обе будут иметь значение, и их обоих надо координировать на концах LSP. Тонкости будут в конкретике реализации этих механизмов, и, как правило, это не интероперабельно. С большой вероятностью L-LSP будет проще, если потребность только в увеличении количества классов трафика, а не еще какие-нибудь функции.

5-7 лет назад на оборудовании к которому у меня был доступ (много всякого разного) не умело запихивать в нужную очередь в зависимости от того что лежит во внутренних mpls TC полях. если так рассуждать, то можно тупо напрямую DSCP анализировать, который лежит в оригинальном пакете

актуальное железо и софт на нем умеет учитывать сразу несколько TC из mpls заголовков разной глубины?

без вручную написанных MF классификаторов  - нет

ну а чем ручное написание плохо кроме захламления и поддержвания конфига в актуальном состоянии?