Subject: Re: [PCN] Review of pcn-architecture-02 draft

From: <[email-masked]>
Date: Mon, 4 Feb 2008 18:44:17 -0000

Hi Ruediger

Yes, pcn pkts can be tunnelled across a non-pcn region, and the original
pcn marking correctly recovered on decapsulation. However, for pcn to
operate you're assuming that the non-pcn region cannot ever suffer
problems, eg become congested. I think this is all captured in S3.1,
which is about the restrictions imposed by the Charter (and principles
of MBAC):

   We assume that the PCN-domain is a controlled environment, i.e. all
   the nodes in a PCN-domain run PCN and trust each other.  There are
   several reasons for proposing this assumption:
 
   ...
 
   o  Similarly, a PCN-boundary-node has to trust that all the PCN-nodes
      are doing PCN-marking.  A non PCN-node wouldn't be able to alert
      that it is suffering pre-congestion, which potentially would lead
      to too many PCN-flows being admitted (or too few being
      terminated).  Worse, a rogue node could perform various attacks,
      as discussed in the Security Considerations section.

            ...

   Note: All PCN-nodes need to be trustworthy.  However if it's known
   that an interface cannot become pre-congested then it's not strictly
   necessary for it to be capable of PCN-marking.  But this must be
   known even in unusual circumstances, eg after the failure of some
   links.

[joe asked for some tweaking of this last para, and I'm toying with
putting a mention of the issue somewhere else eg OAM section]

But the basic point is: a non-PCN region makes scenarios are interesting
but not in the current work scope. so we shouldn't worry about them at
the moment.

phil

-----Original Message-----
From: Geib, Ruediger [mailto:[email-masked]] 
Sent: 31 January 2008 08:36
To: Eardley,PL,Philip,CXR9 R
Cc: [email-masked]
Subject: RE: [PCN] Review of pcn-architecture-02 draft

Phil,

if the PCN domain spans across an embedded non PCN domain, then the PCN
marked packets may be tunneled without the outer header supporting PCN
while the PCN marks of the inner header should be left unchanged.
Examples are:

- backbone transit using a carrier IP VPN service

- a business access connected via L2TP over DSL

In both cases the carrier providing connectivity may not support PCN,
but the end point using that carrier connectivity product may be in a
PCN domain. It is important that the tunnel starts and ends in the same
PCN domain (which holds for the given examples). Once the charter allows
for extended discussion, the tunnel may also connect two PCN domains.

This scenario should be supported, I support Joe's view. Picking up
Joe's drafted text, what about the following (my changes marked):

A PCN domain may expand over a non PCN domain and wish to tunnel
PCN-traffic across this non-PCN-capable domain. The PCN-marks shouldn't
be visible outside the PCN-domain, which can be achieved by
encapsulating PCN packets with an outer header that does not support
PCN. In this mode on decapsulation, the inner PCN-capable header is used
without modification.

Deletions are hard to mark, that's why I highlighted "PCN".

I think, the scenario is somewhat similar to passing a non PCN capable
node (without a tunnel) in a PCN domain.

Regards, Ruediger

________________________________

	From: [email-masked] [mailto:[email-masked]] 
	Sent: Wednesday, January 30, 2008 7:45 PM
	To: [email-masked]; [email-masked]
	Subject: RE: [PCN] Review of pcn-architecture-02 draft

	Joe

	You make some comments on Section 5.7 Tunnelling, which I didn't
really understand.

	After 

	   An operator may wish to tunnel PCN-traffic from
PCN-ingress-nodes to

	   PCN-egress-nodes.  

	You deleted this:

	The PCN-marks shouldn't be visible outside the
	   PCN-domain, which can be achieved by doing the PCN-colour
function
	   (Section 5.3
<http://tools.ietf.org/html/draft-ietf-pcn-architecture-02#section-5.3>
) after all the other (PCN and tunnelling) functions.

	Why? Is this because you thought it too detailed to bother
saying? Or because you think PCN-colouring isnt needed? If the latter,
this is an argument about encoding - in which case I'll ignore the issue
until the encoding draft is done. 

	You added:

	  Also operator may wish to tunnel PCN-traffic across a
non-PCN-capable domain.  The PCN-marks shouldn't be visible outside the
PCN-domain, which can be achieved by encapsulating PCN packets with an
outer header that does not support the PCN function (tunnel). In this
mode on decapsulation, the inner PCN-capable header is used without
modification.

	I don't agree with this. if you send PCN-traffic outside the
PCN-domain then it's no longer PCN-traffic. 

	You made a lot of changes to the text about "partially
PCN-capable tunnel", ie where only one tunnel endpoint is in the PCN
domain

	Partly I think this is to do with encoding (again, I propose to
park the text until the encoding draft has progressed). 

	However:

	In the case "1.  The tunnel starts outside a PCN-domain and
finishes inside it."

	You wrote:

	       For this scenario when the tunnel ends, the PCN-ingress
node function must be performed after decapsulation of packet.

	I don't agree. The main ingress functions like policing have to
be done at the PCN-boundary-node.

	Thanks,

	phil

	-----Original Message-----
	From: Jozef Babiarz [mailto:[email-masked]] 
	Sent: 01 January 2008 20:03
	To: PCN IETF
	Subject: [PCN] Review of pcn-architecture-02 draft

	Hi Phil,

	The link below provides my detailed comments and suggested new
text for draft-ietf-pcn-architecture-02.

	Currently, my review covers, Section 1 through end of 5. New
text to be added is underlined and text to be deleted is crossed out. 

http://standards.nortel.com/pcn/draft-ietf-pcn-architecture-02-jb.doc
<http://standards.nortel.com/pcn/draft-ietf-pcn-architecture-02-jb.doc>

http://standards.nortel.com/pcn/draft-ietf-pcn-architecture-02-jb.pdf
<http://standards.nortel.com/pcn/draft-ietf-pcn-architecture-02-jb.pdf>

	Changes of note:

	- On terminology, changed PCN-boundary-node to PCN-edge-node. 

	- Made several changes in Section 5.2, 5.3, 5.4 and 5.5.

	- The changes in Section 5.7 on Tunneling that I made are with
the assumption that PCN marking will be conformant to RFC 4774,
Specifying Alternate Semantics for the Explicit Congestion Notification
(ECN) Field.

	- Most of the other changes through out the draft are editorial.

	I will send comments on remaining of the draft, Section 6 to end
in few days.

	Happy New Year!

	Regards, Joe

	email:[email-masked]

	Telephone:613-763-6098

_______________________________________________
PCN mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/pcn