Subject: [conex] Using DSCP

From: Teco Boot <[email-masked]>
Date: Fri, 1 Apr 2011 11:02:47 +0200

Seen the struggle finding bits in IPv4 and IPv6 headers for 
Conex signaling, we could explore the option using codepoints
from DSCP pools 2 & 3 (EXP/LU). This limits Conex to separate
set of PHBs. But the approach would work equivalent for v4 and 
v6, without to much trouble.

Is a limitation to Default PHB acceptable?

Teco

---

From: Bob Briscoe <[email-masked]>
Date: Fri, 01 Apr 2011 10:46:57 +0100

Teco,

There's an architectural objection, which we might be able to 
side-step for experiments, but also a practical objection:

- architectural: as you point out, ConEx should be orthogonal to DS, 
and therefore, if we used the DS field, we would need to pair up a 
DSCP up against every DSCP in use.

- pragmatic: I'd like to be able to do experiments on the public 
Internet, so the participating users have a reason to want to take 
part in the experiment (rather than being limited to just a few 
sites). DSCPs often get bleached, and relying on local use would mean 
not being able to use e2e paths unless they were wholly within 
networks participating in the experiment.

Bob

At 10:02 01/04/2011, Teco Boot wrote:
>_______________________________________________
>conex mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/conex

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design

---

From: Teco Boot <[email-masked]>
Date: Fri, 1 Apr 2011 12:23:03 +0200

Bob,

Op 1 apr 2011, om 11:46 heeft Bob Briscoe het volgende geschreven:

> Teco,
> 
> There's an architectural objection, which we might be able to side-step for experiments, but also a practical objection:
> 
> - architectural: as you point out, ConEx should be orthogonal to DS, and therefore, if we used the DS field, we would need to pair up a DSCP up against every DSCP in use.

Yes. But Conex for Default PHB would be the far most important one. Conex PHBs are mapped to Default PHB by default.

> - pragmatic: I'd like to be able to do experiments on the public Internet, so the participating users have a reason to want to take part in the experiment (rather than being limited to just a few sites). DSCPs often get bleached, and relying on local use would mean not being able to use e2e paths unless they were wholly within networks participating in the experiment.

Yes. Public Internet has limitations. But the experiment could show Conex benefits where it worked.
The IPv6 destination option requires IPv6 connectivity. Not available everywhere yet, I think.

Very pragmatic: 
 - use DSCP for Default PHB traffic;
 - use IPv6 Destination Option for other PHB;
 - forget IPv4 && non_Default_PHB.
Some people force us to such model. We could document this pressure, and use is as reasoning for this pragmatic approach.

Teco

---

From: Bob Briscoe <[email-masked]>
Date: Fri, 01 Apr 2011 13:51:38 +0100

Teco,

At 11:23 01/04/2011, Teco Boot wrote:
> > - architectural: as you point out, ConEx should be orthogonal to 
> DS, and therefore, if we used the DS field, we would need to pair 
> up a DSCP up against every DSCP in use.
>
>Yes. But Conex for Default PHB would be the far most important one. 
>Conex PHBs are mapped to Default PHB by default.
>
> sites). DSCPs often get bleached, and relying on local use would 
> mean not being able to use e2e paths unless they were wholly within 

Why not Dst Opt for all IPv6? Otherwise there's interop issues.

>  - forget IPv4 && non_Default_PHB.

Well, I'm working on the IPv4 case. See draft-briscoe-ipv4-id-reuse

I know we're not chartered for v4, but v4 obviously requires some 
groundwork that needs starting in parallel if it is to be ready for 
any future rechartering to extend ConEx to v4. (not to mention v6 
which needs a complete brain-transplant)

>Some people force us to such model. We could document this pressure, 
>and use is as reasoning for this pragmatic approach.

Yes, I argued for documenting this too.

We have actually found a requirement that wasn't recognised when v6 
was built. v6 extensions headers and hop-by-hop options assumed there 
are only three types of IP-aware node: router, tunnel endpoint or host.

However, there can be IP-aware nodes between the endpoints that are 
not necessarily routers; in our case traffic management nodes, or 
more generally IP-monitoring functions that may trigger some action.

We need a header-type that always gets copied to the outer and is not 
encrypted, but which is ignored hop-by-hop by routers, then it can 
still be seen by this new type of node (monitor).

Bob