RE: [PCN] PCN & tunnelling

[<[e-mail]>]

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