Re: [tsvwg] COMMENT PLEASE: Which DSCP value should we use for LE PHB?

[<[e-mail]>]

Hi Roland,

the problem with unknown DSCPs arises on the _domain internal
ingress interface_ of the MPLS egress edge router, and traffic 
leaving the domain is concerned.

It's sufficient if a vendor allows classification based on DSCP ranges. 
I can configure a behaviour like a bit mask (as these are specific 
DSCP ranges). Could be DSCP bits 0-1, bits 0-2 that way.

Commonly used MPLS Short Pipe's Pen-ultimate Hop Popping (PHP) adds the 
complexity here. I doubt it will be removed or adapted due to Diffserv issues.

I'm trying to be pragmatic and figure out how to meet a maximum of 
constraints while finding a simple solution. In the end, an administrative 
obstacle like a pool discussion might be simpler to pass than running into 
conflicts with deployed solutions. I can't claim to know 
all solutions which see deployment within Deutsche Telekom's entire 
network. If anybody knows that for a bigger company, please speak up.

Regards, Ruediger

-----Ursprüngliche Nachricht-----
Von: Bless, Roland (TM) [mailto:[e-mail]] 
Gesendet: Mittwoch, 2. August 2017 14:31
An: Geib, Rüdiger <[e-mail]>
Cc: [e-mail]
Betreff: Re: [tsvwg] COMMENT PLEASE: Which DSCP value should we use for LE PHB?

Hi Rüdiger,

Am 02.08.2017 um 10:48 schrieb [e-mail]:
> in an MPLS domain, one generally may assign a bunch of DSCP to a 
> single Treatment Aggregate / PHB. That I think is quite useful.
> Unfortunately the top label is removed before the last MPLS domain 
> router is reached. Then an unknown and not re-marked DSCP is not 
> acceptable. Hence your guidance below isn't applicable in all 
> networks.

Thanks for pointing out MPLS/DiffServ interworking problems.
I'm more a DiffServ purist so I wasn't aware of such operational problems. In summary, the whole DiffServ deployment seems to be getting more complex by integrating MPLS constraints. I'm also not aware how common an AF deployment is, since you quoted (in your last mail) that bit-masking AF classes can be quite useful. So if I understood your statements correctly, it is not possible to carry a DSCP x in an MPLS aggregate and then use the same DSCP x at the egress to the next domain?

> There is a fairly simple and useful option allowing to combine 
> Treatment Aggregates, Diffserv forwarding across an MPLS domain and 
> maintenance of multiple DSCP. Per Treatment Aggregate:
> - classify DSCPs by bit-mask at ingress.
> - re-mark DSCPs by bit mask at ingress.
> - Diffserv forwarding by Treatment Aggregate
> - classify and forward by individual DSCP at the egress (if desired)
> - same holds for next domain
> 
> The other simple option I see without bit mask based re-mark is, again 
> per Treatment Aggregate:
> - classify DSCPs by bit-mask at ingress.
> - re-mark to _a single DSCP_ at ingress.
> - Diffserv forwarding by Treatment Aggregate
> - classify and forward by this single DSCP at the egress
> - same holds for next domain
> 
> I prefer a simple solution (and a standardized one, if possible). 

Speaking as DiffServ purist, DSCP classification _by bit-mask_ is non-conforming to RFC 2474.

> Of course it is technically possible to set up and maintain per DSCP 
> to PHB and individual DSCP re-mark tables, customized for each 
> interconnection. Interconnection DSCPs are not standardized.
> Many carriers operate multiple interconnections. 

The DiffServ architecture indeed requires to have agreements for each interconnection. However, in case you don't have negotiated any special treatment, a mapping of "any DSCP -> default PHB" should work. But if I understood you correctly, an incoming DSCP x may not be acceptable for the next DS domain, so you must remark?

Regards,
 Roland