[PCN] draft-ietf-pcn-architecture-01.txt disambiguation suggestions

Bob Briscoe <rbriscoe@jungle.bt.co.uk> Tue, 06 November 2007 23:26 UTC

Return-path: <pcn-bounces@ietf.org>
Received: from [] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpXo7-0004hH-PU; Tue, 06 Nov 2007 18:26:07 -0500
Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IpXo7-0004hC-Aj for pcn-confirm+ok@megatron.ietf.org; Tue, 06 Nov 2007 18:26:07 -0500
Received: from [] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpXo6-0004h4-Vh for pcn@ietf.org; Tue, 06 Nov 2007 18:26:07 -0500
Received: from smtp4.smtp.bt.com ([]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IpXo6-0000Ky-DM for pcn@ietf.org; Tue, 06 Nov 2007 18:26:06 -0500
Received: from i2kc06-ukbr.domain1.systemhost.net ([]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Nov 2007 23:26:05 +0000
Received: from cbibipnt05.iuser.iroot.adidom.com ([]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Nov 2007 23:26:05 +0000
Received: From bagheera.jungle.bt.co.uk ([]) by cbibipnt05.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1194391563975; Tue, 6 Nov 2007 23:26:03 +0000
Received: from mut.jungle.bt.co.uk ([]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id lA6NPae8013046; Tue, 6 Nov 2007 23:25:48 GMT
Message-Id: <>
X-Sender: rbriscoe@pop3.jungle.bt.co.uk
X-Mailer: QUALCOMM Windows Eudora Version 5.2.1
Date: Tue, 06 Nov 2007 23:25:37 +0000
To: "EARDLEY, Phil" <philip.eardley@bt.com>
From: Bob Briscoe <rbriscoe@jungle.bt.co.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Spam-Score: -1.36 () ALL_TRUSTED
X-Scanned-By: MIMEDefang 2.56 on
X-OriginalArrivalTime: 06 Nov 2007 23:26:05.0052 (UTC) FILETIME=[66D213C0:01C820CC]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1
Cc: PCN IETF list <pcn@ietf.org>
Subject: [PCN] draft-ietf-pcn-architecture-01.txt disambiguation suggestions
X-BeenThere: pcn@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: PCN WG list <pcn.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pcn>, <mailto:pcn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/pcn>
List-Post: <mailto:pcn@ietf.org>
List-Help: <mailto:pcn-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pcn>, <mailto:pcn-request@ietf.org?subject=subscribe>
Errors-To: pcn-bounces@ietf.org


Arch draft is looking v good now (I've just started the OAM text I 
promised). Thanks for making all the changes.

A few review comments (none are substantial - they are either nits or ways 
to help readers avoid misinterpreting)...

First, note the auto-generated nits off the IETF tools page:

1. Introduction

>                                                         A possibility
>       after re-chartering is to consider that the PCN-domain encompasses
>       several DiffServ domains that don't trust each other

Suggest change 'Diffserv domains' -> 'autonomous systems', as the term 
"Diffserv domain" carries extra baggage that isn't in PCN, particularly 
ingress traffic conditioning.

There are many other occurrences of the term 'Diffserv domain' throughout, 
but this is the only one I would ask to be changed.

However, preferably where "Diffserv domain" is cited as [RFC2475], I would 
like to see an explicit statement that we do NOT imply PCN needs or uses 
traffic conditioning like the majority of RFC2475 deployments (although we 
discuss a scenario where it does).

A large part of RFC2475 is about traffic conditioning. So citing RFC2475 
without this caveat could be misread as "Take a Diffserv domain with all 
its traffic conditioning, then add all the PCN stuff as well." From bitter 
experience, I know people reading IETF docs often make assumptions we 
didn't expect.

5.7. Addressing

>                                                     Alternatively, if
>       PCN-traffic is always tunnelled across the PCN-domain, then the
>       PCN-ingress-node's address is simply the source address of the
>       outer packet header - but then the PCN-ingress-node needs to know
>       the address of the PCN-egress-node

, using one of the many automated tunnel endpoint discovery mechanisms 
available (e.g. signalling or probing over the data route, interrogating 
routing, using a centralised broker) or by manual configuration


{I figured that people will read this as an open issue unless we make it 
clear that common solutions are available.}

>                                                     the centralised node
>       may need to know the addresses of the PCN-ingress-node and PCN-
>       egress-node, the PCN-egress-node

may need to

>know the address of the PCN-
>       ingress-node, and the PCN-ingress-node

may need to

>know the address of the
>       centralised node.  NOTE: Consideration of the centralised case is
>       out of scope of the initial PCN WG Charter.

5.8. Tunnelling

>                                               PCN-marking is then
>    orthogonal to tunnel encapsulation /decapsulation.

I think this contradicts the statement just before that decapsulation has 
to overwrite inner with outer if it is more severe. That requires the 
decapsulator to have knowledge of PCN, to know which marking is more 
severe. So PCN & encapsulation are orthogonal, but not PCN & decapsulation.


Bob Briscoe, <bob.briscoe@bt.com>      Networks Research Centre, BT Research
B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK.    +44 1473 645196 

PCN mailing list