RE: [PCN] PCN & tunnelling

[[e-mail]]

Yes, this looks ok.
 
Sorry for the delayed reply,
--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: Thursday, November 22, 2007 7:13 AM
	To: Black, David; [e-mail]
	Subject: RE: [PCN] PCN & tunnelling
	
	

	David, 

	I tried to improve the draft to reflect your comments, is it ok?

	 

	[from draft-pcn-architecture-02 S5.7]

	 

	Potential issues arise for a "partially PCN-capable tunnel", ie
where
	   only one tunnel endpoint is in the PCN domain:
	 
	   1.  The tunnel starts outside a PCN-domain and finishes
inside it.
	       If the packet arrives at the tunnel ingress with the same
	       encoding as used within the PCN-domain to indicate
PCN-marking,
	       then this could lead the PCN-egress-node to falsely
measure pre-
	       congestion.
	 
	   2.  The tunnel starts inside a PCN-domain and finishes
outside it.
	       If the packet arrives at the tunnel ingress already
PCN-marked,
	       then it will still have the same encoding when it's
decapsulated
	       which could potentially confuse nodes beyond the tunnel
egress.
	 
	   In line with the solution for partially capable DiffServ
tunnels in
	   [2983], the following rules are applied:
	 
	   o  For case (1), the tunnel egress node clears any
PCN-marking on the
	      inner header.  This rule is applied before the 'copy on
	      decapsulation' rule above.
	 
	   o  For case (2), the tunnel ingress node clears any
PCN-marking on
	      the inner header.  This rule is applied after the 'copy on
	      encapsulation' rule above.
	 
	   Note that the above implies that one has to know, or figure
out, the
	   characteristics of the other end of the tunnel as part of
setting it
	   up.

	 

	Ok?

	 

	Also, in S6 there's listed an Open issue:

	o  Scenarios with only one tunnel endpoint in the PCN domain may
make
	      it harder for the PCN-egress-node to gather from the
signalling
	      messages (eg RSVP, NSIS) the identity of the
PCN-ingress-node.

	 

	Any comments?

	 

	Thanks

	phil

	 

	 

	-----Original Message-----
	From: [e-mail] [mailto:[e-mail]] 
	Sent: 29 October 2007 19:58
	To: Eardley,PL,Philip,CXR9 R; [e-mail]
	Cc: [e-mail]
	Subject: RE: [PCN] PCN & tunnelling

	 

	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