Re: [tsvwg] draft diffserv-intercon: Handling of a scavenger class / CS1

[<[e-mail]>]

Hi Mikael,

if you attend the Prague IETF, let's meet there and discuss ways forward.

I note that DiffServ-Intercon doesn't meet your operational requirements. It is closer to reach mine (in Germany Ethernet and IP QoS interconnections are discussed with the regulator).
 
Starting new work with use cases certainly is a good idea. I share some of your interests, but I also note that we have differing views on others. So I'm happy to provide support where our interests overlap. That's bleaching and rewriting of DSCP ranges, both at interconnection.

IETF welcomes provider input also in TSVWG. I'm happy for every provider representative joining me in discussing operation related DiffServ issues in TSVWG. Once we are too many, a TSV OPS related WG may be helpful.

Regards,

Ruediger


-----Ursprüngliche Nachricht-----
Von: Mikael Abrahamsson [mailto:[e-mail]] 
Gesendet: Freitag, 26. Juni 2015 10:34
An: Geib, Rüdiger
Cc: [e-mail]
Betreff: Re: AW: [tsvwg] draft diffserv-intercon: Handling of a scavenger class / CS1

On Fri, 26 Jun 2015, [e-mail] wrote:

> I've asked my colleagues visiting RIPE and NANOG meetings for Diffserv 
> Interconnection related contacts, but feedback was limited. I guess 
> there's some truth in what you say - developers and more so 
> operational staff hardly participates in IETF work.

I don't understand what "Diffserv Interconnection related contacts" would be. This would most likely be handled by peering managers and IP network architects that do the rest of the network design.

> If you are aware of DiffServ Interconnection related agreements of 
> NANOG please let me know. I think there's nothing discussed by RIPE.

In the operational community things are done largely by interpersonal connections and discussions on mailing lists that then create de-facto ways of doing things.

> Bleaching of "Ip precedence bits" is not within scope of Diffserv 
> Intercon and it will stay out of scope (it is an informational draft 
> and it cannot and is not supposed to change standards).

Right now most ISPs will bleach all 6 bits for Internet traffic. My proposal was to come up with a solution that allowed them to bleach the CS bits.

> Carrier representatives interested in a standard allowing to remark, 
> say, ranges of DSCPs (bleaching by precedence is bad wording) should 
> collectively draft a suitable document. I guess, if at all, this is 
> only picked up by standardization if a significant number of provider 
> representatives express interest. If you know some more provider 
> representatives willing to co-author such a draft, please let me know.

I have already suggested what I think would be achievable in real life. I am willing to bring this to nanog and ask for opinions from the operational community.

> I've had some text related to the issue in very early versions of the draft.

I propose that what I want to do isn't applicable to your draft, I just realised I had jumped into the discussion without reading it. I now have quickly scanned through it, and your text isn't applicable to Internet peering at all.

So what I want to achieve would need a new document. I have no idea how it applies to all the other documents out there because there are just too many for someone not focusing on this area, to overlook. I have been architecting Internet backbones for 15 years.

I would like to see a document that applies to Internet traffic only, scavenger class and BE only, that basically proposes to bleach CS bits and leave the rest of the bits intact, and then suggests how to configure queuing behavior for Internet access to take this into account. It should be an operational document which includes deployment cases and how to configure this using commonly used equipment.

I think the disconnect here is that in the IETF DSCP and the rest is considered transport, but by most operators, DSCP and queuing behaviour is done by IP engineers and IP architects. These people go to v6ops, potentially to 6man, routing protocol WG:s and similar IP control and forwarding groups, they don't really attend what IETF calls transport. I also get the feeling that people in here don't really attend NANOG or other places where the people who actually forward packets and configure queues attend. So we have two groups who never interact.

So there is really a need for TSV-OPS or something, that actually talks about how to implement what's in the DSCP related documents, and the IETF needs to somehow try to attract operational people in there. I have non idea how to achieve this.

-- 
Mikael Abrahamsson    email: [e-mail]