Subject: [PCN] PCN & tunnelling

From: <[email-masked]>
Date: Wed, 24 Oct 2007 11:23:34 +0100

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/pcn

---

From: Michael Menth <[email-masked]>
Date: Wed, 24 Oct 2007 12:49:30 +0200

Hi Phil,

[email-masked] wrote:
>
> 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 
> 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 
> 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?
>

At first sight I find this solution quite simple and good.

There are many other open issues regarding how PCN should behave in the 
case of tunneling. In general, I think multi-domain issues are not yet 
well understood and tunneling can create very nasty side effects.
http://www1.ietf.org/mail-archive/web/pcn/current/msg00687.html
I find it is important to record these caveats linked with tunneling and 
interdomain aspects, but I don't think that PCN must be bullet-proof for 
everything, at least these problems should not prevent simple solutions 
in the near future.

Regards,

Michael

> Thanks,
>
> Phil/
>
> ------------------------------------------------------------------------
>

-- 
Dr. Michael Menth, Assistant Professor
University of Wuerzburg, Institute of Computer Science
Am Hubland, D-97074 Wuerzburg, Germany, room B206
phone: (+49)-931/888-6644, fax: (+49)-931/888-6632
mailto:[email-masked]
http://www3.informatik.uni-wuerzburg.de/research/ngn

---

From: "Geib, Ruediger" <[email-masked]>
Date: Wed, 24 Oct 2007 13:10:10 +0200

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: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, October 24, 2007 12:24 PM
To: [email-masked]
Subject: [PCN] PCN & tunnelling

Hi,

Thoughts?

Thanks,

Phil/

---

From: "Anna Charny (acharny)" <[email-masked]>
Date: Wed, 24 Oct 2007 09:29:53 -0400

Hi Phil,
 
Question: what would be the mechanism for knowing whether the egress of
the tunnel is in the PCN domain or not?  Are we assuming that a node
somehow advertises its PCN capability?  I do not think we ever
explicitly assumed that?
 
Anna 

________________________________

	From: [email-masked] [mailto:[email-masked]] 
	Sent: Wednesday, October 24, 2007 6:24 AM
	To: [email-masked]
	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. 

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

	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/

---

From: <[email-masked]>
Date: Wed, 24 Oct 2007 20:05:51 +0100

Anna,

I don't know.

For inspiration, I looked at rfc2983, diffserv & tunnels. S3.2 of this
talks about partially capable DS configs - only tunnel ingress is
DS-capable but not the egress. It says that 

If tunnel decapsulation processing discards
   the outer header's DSCP value without changing the inner header's
   DSCP value, the DS-capable tunnel ingress node is obligated to set
   the inner header's DSCP to a value compatible with the network at the
   tunnel egress.  The value 0 [is a good suggestion]

this approach is along the same lines to the one in the original email
below. Unfortunately 2983 doesn't say how the tunnel ingress node knows
about the characteristics of the network at the tunnel egress. Did the
DS people have anything in mind that might apply in the PCN case?

phil

-----Original Message-----
From: Anna Charny (acharny) [mailto:[email-masked]] 
Sent: 24 October 2007 14:30
To: Eardley,PL,Philip,CXR9 R; [email-masked]
Subject: RE: [PCN] PCN & tunnelling

Hi Phil,

Anna 

	Hi,

	Thoughts?

	Thanks,

	Phil/

---

From: <[email-masked]>
Date: Wed, 24 Oct 2007 20:06:47 +0100

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:[email-masked]] 
Sent: 24 October 2007 12:10
To: Eardley,PL,Philip,CXR9 R
Cc: [email-masked]
Subject: RE: [PCN] PCN & tunnelling

Phil,

Regards,

Rudiger

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

	Hi,

	Thoughts?

	Thanks,

	Phil/

---

From: "Geib, Ruediger" <[email-masked]>
Date: Thu, 25 Oct 2007 11:48:08 +0200

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: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, October 24, 2007 9:07 PM
To: Geib, Rudiger
Cc: [email-masked]
Subject: RE: [PCN] PCN & tunnelling

Ruediger,

phil

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

Phil,

Regards,

Rudiger

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

Hi,

Thoughts?

Thanks,

Phil/

---

From: <[email-masked]>
Date: Thu, 25 Oct 2007 10:51:34 +0100

Michael

Am re-writing tunnelling section and wanted to come back to an issue you
raise in
http://www1.ietf.org/mail-archive/web/pcn/current/msg00687.html. 
" 1st problem: how do we find the ingress node X of the packet at its
PCN egress Y?"

I don't see why tunnelling makes this harder, assuming that the
signalling msg (or whatever is setting up the PCN-flow) follows the same
path as the data will. 

Thanks
phil

---

From: <[email-masked]>
Date: Thu, 25 Oct 2007 11:40:54 +0100

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:[email-masked]] 
Sent: 25 October 2007 10:48
To: Eardley,PL,Philip,CXR9 R
Cc: [email-masked]
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: [email-masked] [mailto:[email-masked]]
	Sent: Wednesday, October 24, 2007 9:07 PM
	To: Geib, Rüdiger
	Cc: [email-masked]
	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]

	- 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:[email-masked]] 
	Sent: 24 October 2007 12:10
	To: Eardley,PL,Philip,CXR9 R
	Cc: [email-masked]
	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: [email-masked] [mailto:[email-masked]]
		Sent: Wednesday, October 24, 2007 12:24 PM
		To: [email-masked]
		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/

---

From: "Geib, Ruediger" <[email-masked]>
Date: Thu, 25 Oct 2007 12:50:58 +0200

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: [email-masked] [mailto:[email-masked]]
Sent: Thursday, October 25, 2007 12:41 PM
To: Geib, Rüdiger
Cc: [email-masked]
Subject: RE: [PCN] PCN & tunnelling

Phil/ 

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

Phil,

Regards,

Rudiger

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

Ruediger,

phil

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

Phil,

Regards,

Rudiger

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

Hi,

Thoughts?

Thanks,

Phil/

---

From: [email-masked]
Date: Mon, 29 Oct 2007 15:57:38 -0400

Phil,
 
As the author of RFC 2983, I was going to point you to this text.
 
Regarding the characteristics of the other end of the tunnel, there
isn't any magic; one has to know this (or figure it out) as part of
setting up the tunnel.  RFC 2983 was written from a core networks
point of view so the expected sort of tunnel is one being used for
traffic management, so its reasonable to expect that the nature of
the other endpoint is known when the tunnel is set up.
 
If in doubt, clearing out everything (e.g., DSCP of 0) is generally
a good course of action for a tunnel headed elsewhere, and if the
tunnel winds up back in the same domain, unbeknownst to the admins,
shame on those who weren't paying attention.
 
Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

	From: [email-masked] [mailto:[email-masked]] 
	Sent: Wednesday, October 24, 2007 3:06 PM
	To: [email-masked]; [email-masked]
	Subject: RE: [PCN] PCN & tunnelling

	Anna,

	I don't know.

	For inspiration, I looked at rfc2983, diffserv & tunnels. S3.2
of this talks about partially capable DS configs - only tunnel ingress
is DS-capable but not the egress. It says that 

	If tunnel decapsulation processing discards
	   the outer header's DSCP value without changing the inner
header's
	   DSCP value, the DS-capable tunnel ingress node is obligated
to set
	   the inner header's DSCP to a value compatible with the
network at the
	   tunnel egress.  The value 0 [is a good suggestion]

	this approach is along the same lines to the one in the original
email below. Unfortunately 2983 doesn't say how the tunnel ingress node
knows about the characteristics of the network at the tunnel egress. Did
the DS people have anything in mind that might apply in the PCN case?

	phil

	-----Original Message-----
	From: Anna Charny (acharny) [mailto:[email-masked]] 
	Sent: 24 October 2007 14:30
	To: Eardley,PL,Philip,CXR9 R; [email-masked]
	Subject: RE: [PCN] PCN & tunnelling

	Hi Phil,

	Question: what would be the mechanism for knowing whether the
egress of the tunnel is in the PCN domain or not?  Are we assuming that
a node somehow advertises its PCN capability?  I do not think we ever
explicitly assumed that?

	Anna 

		From: [email-masked]
[mailto:[email-masked]] 
		Sent: Wednesday, October 24, 2007 6:24 AM
		To: [email-masked]
		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].

		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/