RE: [PCN] PCN & tunnelling

[[e-mail]]

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
[phone]             FAX: [phone]
[e-mail]        Mobile: [phone]
----------------------------------------------------


________________________________

	From: [e-mail] [mailto:[e-mail]] 
	Sent: Wednesday, October 24, 2007 3:06 PM
	To: [e-mail]; [e-mail]
	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:[e-mail]] 
	Sent: 24 October 2007 14:30
	To: Eardley,PL,Philip,CXR9 R; [e-mail]
	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: [e-mail]
[mailto:[e-mail]] 
		Sent: Wednesday, October 24, 2007 6:24 AM
		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