RE: [PCN] PCN & tunnelling

["Geib, Ruediger" <[e-mail]>]

Phil,
 
yes to your main conclusions. I also think we should not recommend to start tunnels within a PCN domain which end in the midlle of another one (especially, if this was breaking the single PCN domain assumption ;-).
 
Regards,
 
Rudiger

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
Sent: Thursday, October 25, 2007 12:41 PM
To: Geib, Rüdiger
Cc: [e-mail]
Subject: RE: [PCN] PCN & tunnelling



I'm going to leave commenting on the DSCP stuff to diffserv experts. Anyway, I assume the answer is "whatever happens in a diffserv network" - I don't see why the existence of PCN would make any odds.

 

Your other point is about what happens if the tunnel egress is at the PCN-egress-node. I agree with the basic point I think you're making, that there's no need for the copying operations when the tunnel egress is at the PCN-egress-node - or indeed when the tunnel ingress is at the PCN-ingress-node. Ie the values specific to the pcn-domain shouldn't be used outside. However I don't think your method necessarily works - for instance if the tunnel starts inside the PCN-domain - the PCN-egress-node still needs to do PCN-colouring ie sets the dscp & ecn fields to the values appropriate for use in the next domain  

 

Another way of looking at this (I think) is that tunnel ingress functions are done before PCN-ingress-node functions, and tunnel egress functions are done after PCN-egress functions does its PCN-metering function but before its PCN-colouring function. 

 

Phil/ 

 

 

-----Original Message-----
From: Geib, Ruediger [mailto:[e-mail]] 
Sent: 25 October 2007 10:48
To: Eardley,PL,Philip,CXR9 R
Cc: [e-mail]
Subject: RE: [PCN] PCN & tunnelling

 

Phil,

 

by propagating down DSCP and PCN settings at a tunnel end, a router can make sure that the next hop is able to correctly interpret these values - if this next hop is within its own domain. If the tunnel end is an edge router and the next hop is part of a different domain, then the edge router should neither change the inner header DSCP nor the PCN codepoints. Is that what you think of?

 

Regards,

 

Rudiger

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
Sent: Wednesday, October 24, 2007 9:07 PM
To: Geib, Rüdiger
Cc: [e-mail]
Subject: RE: [PCN] PCN & tunnelling

Ruediger,

 

Yes, it is a more general problem. I've been trying to read 2983 [diffserv & tunnels] and 3270 [mpls & diffserv - similar kinds of issues]

 

2983 has 2 conceptual models, Uniform & Pipe:

- Uniform: tunnel is an artefact on the e2e path from a traffic conditioning viewpoint; pkt effectively has one DS field that's used for traffic conditioning. Copy DSCP value to the outer header at encaps and copy outer header's dscp value to inner IP header at decaps. 

- Pipe: IP tunnel hides the nodes so they don't really participate in traffic conditioning. Tunnel egress ignores the outer header's dscp & uses the inner header's DSCP (or rather the traffic conditioning info it conveys - to cover the case where the same meaning is encoded by different values of dscp). Tunnel links DS domains at end points into a diffserv region ('virtually' contiguous). 

 

When it comes to PCN & tunnels, something analogous to the Uniform model seems more appropriate to me - ie the pkt effectively has one field for PCN-marking that's used for PCN-based adm ctrl (& termination); the operation is at decaps, if the outer header's PCN-marking is more severe than the inner IP header's, then copy it to the inner IP header. 

At least I think the Uniform model is best for the normal (?) case where the tunnel is within the PCN-domain - because we want all nodes in the PCN-domain to be able potentially to PCN-mark & hence contribute to the adm ctrl decisions. If the tunnel is partly within a PCN-domain and partly outside I think the uniform model is still the right one (not too sure - there are lots of things complicating it, some of which mentioned in first email below, but I think the conceptual model should still be the same]. 

 

Ruediger: question about what you call 'downpropagation', I assume this is the copying operation I refer to in the Uniform model. I agree with you for PCN marking [text is already in the archit draft on these lines]. However, you also mention downpropagation of DSCP which I don't think is correct. 

 

Ruediger, you mention where the DSCP values have different meanings at the tunnel ingress & egress (tunnel crosses a diffserv domain boundary). Yes, I believe this is a general diffserv issue and is covered by 2475.

 

phil

 

-----Original Message-----
From: Geib, Ruediger [mailto:[e-mail]] 
Sent: 24 October 2007 12:10
To: Eardley,PL,Philip,CXR9 R
Cc: [e-mail]
Subject: RE: [PCN] PCN & tunnelling

 

Phil,

 

I guess this is a general DiffServ issue too. In case [2] you assume the same DSCP to be used by the tunnel end point PCN domain as at the tunnel entry. This assumption may not hold, if the set DSCP is used for another service class or unused at the end point. 

 

I had a brief glance on RFC2983, "Differentiated Services and Tunnels". Downpropagation of outer IP header DSCP/PCN settings may be a fairly good recommendation.

 

Regards,

 

Rudiger

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
Sent: Wednesday, October 24, 2007 12:24 PM
To: [e-mail]
Subject: [PCN] PCN & tunnelling

Hi,

 

I was chatting with Bob about section 5.8 tunnelling. We've realised there's the following nasty case which we hadn't thought about. The scenario is when a tunnel starts inside a PCN-domain and finishes outside it. 

 

First we follow what happens when the current text is followed. Imagine that the pkt is PCN-marked by some PCN-node before the tunnel start node. On encapsulation the PCN-mark is copied onto the outer header. Hence the PCN-egress-node 'sees' the PCN-mark as normal - this is ok. The PCN-egress-node clears the marking in the (outer) header and forwards the pkt into the next domain. The pkt is decapsulated at the tunnel end point. But the decapsulated pkt is already PCN-marked. Potential problems: [1] if it's decapsulated in a non-PCN-domain, then the pkt may confuse nodes in this domain [depending on what encoding is used for a PCN-mark] ; [2] if it's decapsulated in a PCN-domain, then the pkt is PCN-marked [which might lead this PCN-domain to terminate or block a flow unnecessarily].

 

The problem arises because the PCN-egress-node clears PCN-marking on the outer header but not on the inner header. (This is a new problem compared with ECN & tunnelling.) 

 

Possible solution: if the pkt is PCN-marked, then the tunnel start node checks whether the tunnel egress is inside or outside the PCN-domain - if it's outside, then it clears the PCN-marking on the inner header (effectively it does this on behalf of the PCN-egress-node). (Also, the PCN-mark is copied onto the outer header, as the current text says.)

 

Thoughts?

 

Thanks,

Phil/  

_______________________________________________
PCN mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/pcn