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

From: Bob Briscoe <[email-masked]>
Date: Tue, 06 Nov 2007 23:25:37 +0000

Phil,

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:
<http://tools.ietf.org/wg/pcn/draft-ietf-pcn-architecture/draft-ietf-pcn-architecture-01.nits.txt>

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

____________________________________________________________________________
Bob Briscoe, <[email-masked]>      Networks Research Centre, BT Research
B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK.    +44 1473 645196 

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

---

From: <[email-masked]>
Date: Wed, 7 Nov 2007 11:10:59 -0000

Thanks bob, will add these into the next version
phil

> -----Original Message-----
> From: Briscoe,RJ,Bob,XVR9 BRISCORJ R
> Sent: 06 November 2007 23:26
> To: Eardley,PL,Philip,CXR9 R
> Cc: PCN IETF list
> Subject: draft-ietf-pcn-architecture-01.txt disambiguation suggestions
> 
> Phil,
> 
<http://tools.ietf.org/wg/pcn/draft-ietf-pcn-architecture/draft-ietf-pcn
-
> architecture-01.nits.txt>
> 
> 
> 1. Introduction
> 
> 
> >                                                         A
possibility
> >                                                     Alternatively,
if
> >                                                     the centralised
node
> severe. So PCN & encapsulation are orthogonal, but not PCN &
________________________________________________________________________
__
> __